kubernetes 이해하고 사용해보기

저번 글에서 kubernetes 설치 및 환경 구축이 끝났고,

이번 글부터는 사용해보면서 구성 요소이나 모르는 부분들에 대해 정리해볼까 한다.

 

먼저,

kubectl get pods --all-namespaces

만약

위와같은 에러가 발생한다면,

* 마스터 노드의 경우 /etc/kubernetes/admin.conf 파일을 $HOME/.kube/config로 복사후 chown으로 소유자를 변경해준다 mkdir -p $HOME/.kube sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config sudo chown $(id -u):$(id -g) $HOME/.kube/config

* 워커 노드의 경우 쿠버네티스 초기화 후 kubectl init 마스터 노드의 admin.conf를 자신의 $HOME/.kube/config 경로에 넣어주면 된다. scp /etc/kubernetes/admin.conf root@192.168.56.101:/home/vagrant/.kube/config sudo chown $(id -u):$(id -g) $HOME/.kube/config

 

 

모든 네임스페이스에서 파드를 수집해 보여준다.

여기서 네임스페이스는 많이 들어봤을거고,

파드(Pod)는 무엇인가..?

하나 이상의 컨테이너로 단일 목적의 일을 하기 위해서 모인 단위이다.

그림으로 그리면 이렇지 않을까 싶다.

특징에 대해 나열하면 다음과 같다.

1. 기본적으로 하나의 파드에는 하나 이상의 컨테이너가 포함된다. 필요에 따라 하나의 파드에 여러 컨테이너를 포함시킬 수 있다.

2. 파드는 노드 IP와 별개로 고유 IP를 할당 받으며, 파드 안의 컨테이너들은 그 IP를 공유한다.

3. 파드 자체는 일반적으로 1개의 IP만 가진다. (단, Multus CNI 이용 등 특정 조건에 한해 2개의 IP를 가질 수도 있다.)

4. 파드 안의 컨테이너들은 동일한 볼륨과 연결이 가능하다.

5. 파드는 클러스터에서 배포의 최소 단위이고, 특정 네임스페이스(Namespace) 안에서 실행된다.

6. 파드는 기본적으로 반영속적(ephemeral)이다.

위의 특징들을 가지고 있기 때문에 무언가를 구동 시키기 위한 일회성 자원이라고 내 나름대로 해석할 수 있을 것 같다.

예를 들면, 특정 노드가 죽으면 해당 노드의 pod들이 살아있는 다른 노드로 옮겨지기도 하고, 반대의 경우도 생긴다.

이 부분은 말로는 이해하기 힘들 수 있으니 테스트 해보면서 확인해보도록 하겠다.

---

위에서 쿠버네티스의 구성 요소 중 하나인 pod에 대해 알아봤고, 이제 나머지에 대해 알아보자.

마스터 노드
1. kubectl	쿠버네티스 컨트롤러로 클러스터에 명령을 내리는 역할. 일반적인 경우 API 서버와 주로 통신. 반드시 마스터 노드에 있을 필요는 없다.
2. API 서버	쿠버네티스 클러스터의 중심 역할. 주로 상태 값을 저장하는 etcd와 통신. 모든 상황과 목표를 설정하는 관리자.
3. etcd	구성 요소들의 상태 값이 모두 저장되는 곳. etcd의 정보만 있으면 장애상황에서도 클러스터 복구 가능. 분산저장이 가능한 Key-Value 저장소이므로 복재해 여러 곳에 저장해 두면 시스템 가용성 확보 가능. 분산저장할 경우 kubespray로 구성. 리눅스의 etc 디렉토리와 ditributed의 합성어.
4. 컨트롤러 매니저	클러스터의 오브젝트 상태를 관리. 워커 노드에서 통신이 되지 않는 경우 상태 체크와 복구는 클러스터에 속한 노드 컨트롤러에서 이루어진다. 서비스와 파드를 연결하는 역할. 다양한 상태 값을 관리하는 주체들이 컨트롤러 매니저에 소속
5. 스케줄러	노드의 상태와 자원, 레이블, 요구 조건 등을 고려해 파드를 어떤 워커 노드에 생성할 것인지를 결정 및 할당 파드를 조건에 맞는 워커 노드에 지정하고 파드가 워커 노드에 할당되는 일정을 관리하는 역할

 

워커 노드
1. kubelet	pod의 구성 내용(PodSpec)을 받아서 컨테이너 런타임으로 전달하고, pod 안의 컨테이너들이 정상적으로 작동하는지 모니터링 // 워커 노드에서 get pods했을때 있을줄 알았는데 없다..
2. CRI	Container Runtime Interface pod를 이루는 컨테이너의 실행을 담당 pod 안에서 다양한 종류의 컨테이너가 문제 없이 작동하게 만드는 표준 인터페이스
3. Pod	위에 설명 참고.

 

기타.

1. kube-proxy : pod에 위치한 노드에 kube-proxy를 통해 pod와 통신.

2. CoreDNS : DNS 서버, 도메인 네임 편리하게 관리.

---

이건 파드 생성 과정을 그림으로 정리한거다.

위에 참고한 링크에 자세한 설명이 있으니 한번정도 봐두면 좋을 것 같다.

 

할 내용이 많아서 일단은 여기까지쓰고

다음 글에서 이어가겠다.