쿠버네티스는 마스터 노드와 워커 노드로 구성되어 있으며 마스터 노드 내부에는 etcd, api-server, controller-manager, scheduler 가 있으며 워커 노드에는 kubelet, kube-proxy가 있다고 알려져 있습니다.
이 포스팅에서 이들 컴포넌트들이 pods, replicaset, daemonset, deployment, service 등의 형태로 어떻게 구성되어 있는지 한번 살펴 보고자 합니다.
쿠버네티스 구조를 인터넷에 검색해 보면 아래와 같이 kube-proxy와 kubelet 은 워커 노드에 존재하는 것을 알 수 있습니다. 보통 pods, replicaset, deployment 등의 자원들은 워커 노드에 생성된다라고 여겨지는데 실제로 마스터 노드에서도 생성 가능합니다. 그 말은 즉 마스터 노드에도 워커 노드의 구성 컴포넌트들인 kubelet과 kube-proxy 가 존재하다는 의미입니다.
마스터 노드내부에 kube-proxy 가 설치되어 있는 걸 볼 수 있습니다.
마찬가지로 kubelet 도 마스터 노드에 설치되어 있습니다.
다만 마스터노드에는 taints 설정을 통해 자원이 마스터 노드에 생성되지 않도록 설정되어 있습니다.
마스터 노드의 내부
etcd, api-server, controller-manager, scheduler 들은 마스터 노드의 컴포넌트들입니다. 이들은 다름 아닌 pods 로서 마스터 노드 내부에 존재하게 됩니다. 즉 마스터 노드가 처음에 구성될 때 etcd, api-server, controller-manager, scheduler pods 들을 생성하게 됩니다. 각 구성요소들은 yaml 파일이 /etc/kubernates/manifest/ 내부에 존재합니다.
이들을 static pods 라고 불리며 우리가 직접 yaml 파일을 통해 pods를 생성하지 않아도 kubelet 이 직접 pods을 올리고 관리합니다.
pods의 이름 중 마지막에 -controlplane이라는 접미어가 붙는 것을 볼 수 있습니다.
만약 사용자가 고의로 static pods 중 하나를 지운다면 어떻게 될까요?
kube-apiserver을 지우고 다시 pods 를 검색해보니 9초 전에 다시 생성되었음을 알 수 있습니다.
만약 사용자가 직접 kube-apiserver.yaml 을 실행해 pods을 생성하면 어떻게 될까요?
kube-apiserver라는 pods 가 생성되었음을 확인할 수 있습니다. 이 pods는 static pods가 아니기 때문에 뒤에 접미사 -controlplane 이 붙지 않으며 삭제한다고 해도 다시 복구되지 않습니다.
다시 본론으로 돌아가 마스터 노드에는 무엇이 어떻게 존재하는지 확인해 보겠습니다.
아래의 그림이 실제 마스터 노드의 구조입니다. 좀 더 자세히 살펴 보겠습니다.
Namespace
마스터노드에는 4개의 네임스페이스가 존재합니다.
어떠한 자원을 생성하게 되면 특정 namespace에 포함시킬 수 있습니다. 특정 namespace로의 지정이 없으면 default에 포함되게 됩니다.
마스터 노드를 구성하는 etcd, api-server, controller-manager, scheduler들은 kube-system이라는 namespace 안에서 static pods로 존재합니다.
Deployment
생성될 자원의 dns 정보를 위한 coredns 가 deployment로 kube-system이라는 namespace 내부에 존재합니다. 생성되는 자원들의 dns 서버는 이 coredns가 됩니다. deployment 형태로 구성되어 2개의 pods 가 존재합니다. 그리고 clusterIP라는 service와 연결되어 있습니다.
Replicaset
Deployment 는 Replicaset 보다 상위 개념입니다. Replicaset으로 지정된 Pods를 관리해줍니다. 그리고 Replicaset을 관리하는 역할은 Deployment 가 하게 됩니다.
만약 Replicaset에 장애가 발생하거나 삭제된다면 어떻게 될까요? Deployment 가 이를 복구해 줍니다.
Replicaset을 지우고 다시 get을 통해 검색해 보니 9초전에 새로 생성되었음을 알 수 있습니다.
Service
쿠버네티스 클러스터 내 dns 정보를 담고 pods들의 dns 서버 역할을 하는 coredns는 2개의 pods로 구성되어 있습니다. 이 pods 위에서 clusterip 역할을 하기 위한 service 가 kube-dns입니다.
coredns 2개의 ip을 보게 되면 10.244.0.4, 10.244.0.5이지만 service를 통해 10.96.0.10의 53, 9153 포트를 통해 이 둘 중 하나의 pods와 통신하게 됩니다. pods의 경우 ip가 언제 바뀔지 모르기 때문에 다른 pods들의 dns 서버 주소를 coredns pods의 ip로 지정하는 것이 어렵습니다.
Pods
마스터 노드에는 8개의 pods가 기본적으로 존재합니다. 정확히 4개의 static pods와 4개의 일반 pods 가 존재합니다.
static pods는 지정된 경로에 yaml 파일이 존재하기만 하면 kubelet 이 알아서 생성시켜줍니다. 클러스터 내 dns 정보를 위한 coredns pods 2개와 CNI(Container Network Interface)중 하나의 종류로서 flannel pods 그리고 네트워크 통신을 위한 kube-proxy 가 있습니다.
그 외
kubelet
kubelet 은 pods 등의 형태가 아니라 호스트 OS에 설치되는 서비스입니다. kubelet 이 쿠버네티스의 자원(pods, Deployment 등)을 생성하는 역할을 합니다. pods는 하나 이상의 container로 구성되어 있는 단위인데 사용자는 yaml 파일 또는 create 등의 명령어로 자원을 생성할 때 kubelet 이 컨테이너를 생성시킵니다.
우리는 docker run~~ 등의 명령어로 컨테이너를 생성한 적은 없지만 kubelet이 만들어 놓은 컨테이너들이 아래와 같이 있습니다.
docker
docker는 container rumtime의 한 종류로서 pods 가 각 node에서 실행되게끔 하는 역할을 합니다. 4가지의 종류가 있는데 이제 조만간 docker는 제외된다고 합니다. 그렇다고 해서 docker 이미지를 사용할 수 없는 것은 아닙니다. 마스터 노드에 docker 대신 아래 중 하나를 설치해 container rumtime으로 대체해야 합니다.