쿠버네티스(kubernetes) 아키텍처

쿠버네티스 클러스터는 크게 2가지 종류로 구성됩니다. 클러스터를 관리하는 역할을 하는 마스터(master)와 실제 컨테이너를 실행시키는 작업을 하는 노드(node)입니다. 구성도는 다음과 같습니다.

마스터에는 etcd, kube-apiserver, kube-scheduler, kube-controller-manager, kubelet, kube-proxy, docker등이 실행됩니다. 각 프로세스들이 다른 장비에 별개로 떠도 실제 쿠버네티스 클러스터를 운영하는데 이상은 없지만 마스터 장비 1대에는 위에 있는 프로세스 한 묶음을 같이 실행하는게 일반적인 구성입니다. 마스터는 고가용성을 위해서 3대 정도를 실행해서 운영합니다. 평소에 실제 리더로서 클러스터를 관리하는 마스터는 1대이고 나머지 2대는 대기중입니다. 그러다가 리더 마스터에 장애가 발생하면 자연스럽게 나머지 2대중 1대로 리더역할이 넘어가게 됩니다. 클러스터를 좀 더 안정적으로 운영하려면 마스터를 5대로 운영할 수도 있습니다.

노드는 쿠버네티스 초기에는 미니언(minion)이라고 불렸었는데, 현재는 노드라고 부릅니다. 쿠버네티스 소스나 데이터 저장구조를 보면 아직까지 미니언이라고 쓰여 있는 부분들이 남아 있습니다. 노드에는 kubelet, kube-proxy, docker등이 실행됩니다. 실제 사용자가 사용하는 컨테이너들은 대부분 노드에서 실행됩니다.

다음 그림을 보면 마스터와 노드가 어떤 구조로 통신하는지 알 수 있습니다.

그림을 잘 보시면 각각의 프로세스의 중심에 kube-apiserver가 있는걸 볼 수 있습니다. 쿠버네티스의 모든 통신의 중심에는 apiserver가 있습니다. apiserver를 통해서 다른 프로세스들이 서로 필요한 정보를 주고 받게 됩니다. 그리고 etcd에 대한 접근도 다른 프로세스는 하지 않고 apiserver만 하고 있는걸 볼 수 있습니다. 먼저 마스터 서버를 보면 kubelet이 마스터에 있는 도커를 관리한다는걸 알 수 있고 도커내에 컨테이너로 kuber-scheduler, kube-controller-manager, kube-apiserver, kube-proxy가 떠 있는걸 볼 수 있습니다. 쿠버네티스 초기에는 이런 쿠버네티스 관리용 프로세스들은 컨테이너가 아니라 직접 서버내의 프로세스로 실행했었는데 최근에는 이렇게 관리용 프로세스들 조차 컨테이너로 실행하고 있습니다. 이 프로세스들은 모두 하이퍼큐브(hyperkube)라는 하나의 바이너리 파일로 컴파일되어 있고 실행할때 각각 다른 옵션을 줌으로써 각각의 역할을 하도록 되어 있습니다. etcd는 컨테이너가 아니라 프로세스로 빠져 있는걸 볼 수 있습니다. etcd까지 컨테이너로 설정할 수 있긴 하지만 여기서는 컨테이너가 아닌 서버 프로세스로 실행해도 구성이 가능하다는걸 보여주기 위해서 따로 실행하는 형식으로 보여드립니다. 

마찬가지로 노드를 보면 kubelet이 도커를 관리하는걸 볼 수 있습니다. kubelet은 마스터의 apiserver를 바라보고 있으면서 포드의 생성/관리/삭제를 담당하게 됩니다. 노드의 kube-proxy는 마스터와는 다르게 컨테이너가 아니라 프로세스로 띄우도록 했는데요. 마스터와 마찬가지로 컨테이너로 띄울 수도 있습니다.