쿠버네티스/도커(쿠버네티스 구성 요소 간 통신)

마스터 노드

0. kubectl
   쿠버네티스 클러스터에 명령을 내리는 역할로 다른 구성 요소들과 다르게 바로 실행되는 명령 형태인 binary로 배포되기 때문에 마스터 노드에 있을 필요는 없지만 통상적으로 API 서버와 주로 통신하여 마스터 노드에 구성

1. api 서버
   쿠버네티스 클러스터의 중심 역할을 하는 통로. 주로 상태 값을 저장하는 ectd와 통신하며 그 밖의 요소들 또한 api 서버를 중심에 두고 통신하므로 api 서버를 중심에 두고 통신하므로 api 서버의 역할이 매우 중요하다.

2. ectd
   구성 요소들의 상태 값이 모두 저장되는 곳
   실제로 ectd 외의 다른 구성 요소는 상태 값을 관리하지 않는다. 그러므로 etcd의 정보만 백업돼 있다면 긴급한 장애 상황에서도 쿠버네티스 클러스터는 복구할 수 있다. 또한 etcd는 분산 저장이 가능한 key-value 저장소이므로, 복제해 여러 곳에 저장해 두면 하나의 etcd에서 장애가 나더라도 시스템의 가용성을 확보할 수 있다.

3. 컨트롤러 매니저
   컨트롤러 매니저는 쿠버네티스 클러스터의 오브젝트 상태를 관리한다. 예를들어 워커 노드에서 통신이 되지 않는 경우, 상태 체크와 복구는 컨트롤러 매니저에 속한 노드 컨트롤러에서 이루어진다. 다른 예로 레플리카셋 컨트롤러는 레플리카셋에 요청받은 파드 개수대로 파드를 생성한다. 서비스와 파드를 연결하는 역할을 하는 엔드 포인트 컨트롤러 또한 컨트롤러 매니저이다. 이와 같이 다양한 상태 값을 관리하는 주체들이 컨트롤러 매니저에 소속돼 각자의 역할을 수행한다.

4. 스케줄러
   노드의 상태와 자원, 레이블, 요구 조건 등을 고려해 파드를 어떤 워커 노드에 생성할 것인지를 결정하고 할당합니다. 스케줄러라는 이름에 걸맞게 파드를 조건에 맞는 워커 노드에 지정하고, 파드가 워커 노드에 할당되는 일정을 관리하는 역할을 담당한다.

워커 노드

5. kubelet
   파드의 구성 내용(PodSpec)을 받아서 컨테이너 런타임으로 전달하고, 파드 안의 컨테이너들이 정상적으로 작동하는지 모니터링한다.

6. 컨테이너 런타임(CRI - Container Runtime interface)
   파드를 이루는 컨테이너의 실행을 담당한다. 파드 안에서 다양한 종류의 컨테이너가 문제 없이 작동하게 만드는 표준 인터페이스이다.

7. 파드(Pod)
   한 개 이상의 컨테이너로 단일 목적의 일을 하기 위해서 모인 단위. 즉, 웹 서버 역할을 할 수도 있고 로그나 데이터를 분석할 수도 있다. 여기서 중요한 것은 파드는 언제라도 죽을 수 있는 존재라는 점이다. 가상 머신은 언제라도 죽을 수 있다고 가정하고 디자인하지 않지만, 파드는 언제라도 죽을 수 있다고 가정하고 설계됐기 때문에 쿠버네티스는 여러 대안을 디자인했다.

위 순서 외의 요소

11. 네트워크 플러그인
    쿠버네티스 클러스터의 통신을 위해서 네트워크 플러그인을 선택하고 구성해야 한다. 네트워크 플러그인은 일반적으로 cni로 구성하는데, 주로 사용하는 cni에는 캘리코, 플래널, 실리움, 큐브 라우터, 로마나, 위브넷 등이 있다.

12. CoreDNS
    클라우드 네이티브 컴퓨팅 재단에서 보증하는 프로젝트로, 빠르고 유연한 DNS 서버. 쿠버네티스 클러스터에서 도메인 이름을 이용해 통신하는데 사용. 실무에서 쿠버네티스 클러스터를 구성하여 사용할 때는 ip보다 도메인 네임을 편리하게 관리해주는 CoreDNS를 사용하는 것이 일반적이다.

사용자가 배포된 파드에 접속할 때

1. kube-proxy
   쿠버네티스 클러스터는 파드가 위치한 노드에 kube-proxy를 통해 파드가 통신할 수 있는 네트워크를 설정. 이때 실제 통신은 br_netfilter와 iptables로 관리한다.

2. 파드
   이미 배포된 파드에 접속하고 필요한 내용을 전달받는다. 이때 대부분 사용자는 파드거 어느 워커 노드에 위치하는지 신경 쓰지 않아도 된다.