kube-api-server

Kuernetes의 구성도를 보면 Control Plane(Master Node) 내부의 모든 컴포넌트들의 중간에는 api가 존재하며, api를 제외한 다른 컴포넌트들은 서로 상호작용하고 있지 않습니다.

Kubernetes에 대해 자세히 모르는 상태로 이 그림만 보아도 Kubernetes에서 kube-api-server가 얼마나 중요한 역할을 하고 있는지는 쉽게 알 수 있을 것 같습니다.

Kubernetes 구조에서 설명드렸다시피 api-server는 Kubernetes 클러스터에서 중심 역할을 하는 통로라고 볼 수 있습니다. 모든 컴포넌트들은 api-server를 중심으로 동작하고, 사용자가 클러스터에 명령을 내릴 때 그 명령을 전달받고 수행하는것도 api-server이며, 클러스터 내부에 존재하는 컴포넌트들 중 유일하게 etcd와 상호작용 하는 컴포넌트입니다.

kube-api-server를 제외한 Scheduler, controller 등 다른 컴포넌트들은 자신들의 역할을 수행하기 위한 정보를 etcd에서 직접 가져오는 것이 아닌 api-server를 통해 전달받습니다.

---

Kubernetes 동작 방식

그렇다면 이 api-server를 중심으로 Kubernetes가 어떻게 동작하는지 알아보겠습니다.

Kubernetes의 동작방식은 위의 다이어그램과 같습니다.
자세한 순서를 설명하면 이렇습니다.

1. User가 Deployment 생성 명령어 수행(kubectl 사용 또는 API 요청 전달)
2. api-server가 etcd에 요청된 정보 저장
3. controller는 api-server를 주시(Watch)하고 있다가 생성되지 않은 Deployment가 있다는 사실을 인지
4. controller가 ReplicaSet을 만들어서 정보를 api-server에 전달
5. api-server는 ReplicaSet의 정보를 etcd에 저장
6. controller는 api-server를 주시하고 있다가 비어있는 ReplicaSet이 있다는 사실을 인지
7. Deployment 명세에 따라 pod 생성 후 정보를 api-server에 전달
8. api-server는 해당 정보를 etcd에 저장
9. Scheduler는 api-server를 주시하고 있다가 배치되지 않은 pod이 있다는 사실을 인지
10. Scheduler는 pod을 Bind할 노드를 선정해서 api-server에 전달
11. api-server는 Scheduler에서 받은 pod와 Bind 노드 정보를 etcd에 저장
12. api-server는 kubelet에 pod을 생성하라고 전달
13. kubelet은 Worker Node의 container runtime(Docker 등)을 통해 pod 명세에 따른 컨테이너 생성
14. 생성한 pod 정보를 api-server에 전달
15. api-server는 전달받은 pod 정보를 etcd에 저장

추가적으로 Kubernetes에서 오브젝트를 생성하는 것은 Action이 아닙니다.

Docker에서는 docker run {image}를 통해 특정 image를 통한 컨테이너를 실행시키라는 Action을 수행합니다.

하지만 Kubernetes는 오브젝트를 생성하라는 Action을 수행하는 것이 아닌, 오브젝트의 정보를 Kubernetes에 선언하면 그 선언한 상태(desired state)와 동일하게 클러스터를 유지시키기 위해 현재 상태(current state)를 끊임없이 모니터링하고 원하는 상태(desired state)와 현재 상태(current state)에 차이가 있으면 이를 일치하도록 만드는 형태로 동작합니다.