내용에 들어가기 앞서 먼저 전체적인 내용을 가볍게 정리하겠습니다.
전체 요약
클러스터 = 마스터 노드 + 워커 노드
마스터 노드 = 감독과 같은 존재, 실제로 경기 뛰지 않음
워커 노드 = 선수들과 같은 존재, 실제로 경기를 뜀
마스터 노드는 컨트롤 플레인을 통해 워커 노드를 관리한다.
컨트롤 플레인의 구성요소 = 'kube-apiserver' + 'kube-controller-manager' + 'kube-scheduler' + 'cloud-controller-manager' + etcd
워커 노드의 구성요소 = 'kube-let' + 'kube-proxy'
마스터 노드
마스터 노드 역할
마스터 노드는 스포츠에서 감독과 같은 존재입니다. 마스터 노드에서 컨테이너를 실행하지 않으며 워커 노드에서 실행되는 컨테이너를 관리하는 역할을 한다. 따라서 도커 엔진 같은 컨테이너 엔진도 설치되지 않는다. 스포츠에서 감독이 선수를 관리하고 전술을 짜되 직접 경기를 뛰지 않는 것과 같다.
클러스터는 마스터 노드에 설정된 내용에 따라 워커 노드가 관리되며 사람이 계획하지 않아도 자율적으로 동작한다. 관리자는 마스터 노드 초기 설정 후 가끔 조정만 하면 되며, 관리자가 직접 워커 노드를 관리하는 일도 없다.
마스터 노드 구성 요소
마스터 노드는 컨트롤 플레인을 통해 워커 노드를 관리하고, 컨트롤 플레인의 구성요소는 다음과 같습니다.
cloud-controller-manager : 클라우드 서비스와 연동해 서비스를 생성한다.
etcd : 클러스터 관련 정보 전반을 관리하는 데이터베이스
kube-apiserver : 외부와 통신하는 프로세스, kubectl로부터 명령을 전달받아 실행한다.
kube-scheduler : 파드를 워커노드에 할당한다.
kube-controller-manager : 컨트롤러를 통합 관리, 실행한다.
워커 노드
워커노드 구성요소
kube-let : 마스터 노드에 있는 kube-scheduler와 연동하며 워커 노드에 파드를 배치하고 실행한다. 또 실행 중인 파드의 상태를 정기적으로 모니터링하며 kube-scheduler에 통지한다.
kube-proxy : 네트워크 통신의 라우팅 메커니즘
이렇게 마스터 노드와 워커 노드에 대해 알아 봤습니다.
