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
를 통해 전달받습니다.
그렇다면 이 api-server
를 중심으로 Kubernetes
가 어떻게 동작하는지 알아보겠습니다.
Kubernetes
의 동작방식은 위의 다이어그램과 같습니다.
자세한 순서를 설명하면 이렇습니다.
Deployment
생성 명령어 수행(kubectl 사용 또는 API 요청 전달)api-server
가 etcd
에 요청된 정보 저장controller
는 api-server
를 주시(Watch)하고 있다가 생성되지 않은 Deployment
가 있다는 사실을 인지controller
가 ReplicaSet
을 만들어서 정보를 api-server
에 전달api-server
는 ReplicaSet
의 정보를 etcd
에 저장controller
는 api-server
를 주시하고 있다가 비어있는 ReplicaSet
이 있다는 사실을 인지Deployment
명세에 따라 pod
생성 후 정보를 api-server
에 전달api-server
는 해당 정보를 etcd
에 저장Scheduler
는 api-server
를 주시하고 있다가 배치되지 않은 pod
이 있다는 사실을 인지Scheduler
는 pod
을 Bind할 노드를 선정해서 api-server
에 전달api-server
는 Scheduler
에서 받은 pod
와 Bind 노드 정보를 etcd
에 저장api-server
는 kubelet
에 pod
을 생성하라고 전달kubelet
은 Worker Node
의 container runtime
(Docker
등)을 통해 pod
명세에 따른 컨테이너 생성pod
정보를 api-server
에 전달api-server
는 전달받은 pod
정보를 etcd
에 저장추가적으로 Kubernetes
에서 오브젝트를 생성하는 것은 Action이 아닙니다.
Docker
에서는 docker run {image}를 통해 특정 image를 통한 컨테이너를 실행시키라는 Action을 수행합니다.
하지만 Kubernetes
는 오브젝트를 생성하라는 Action을 수행하는 것이 아닌, 오브젝트의 정보를 Kubernetes
에 선언하면 그 선언한 상태(desired state)
와 동일하게 클러스터를 유지시키기 위해 현재 상태(current state)
를 끊임없이 모니터링하고 원하는 상태(desired state)
와 현재 상태(current state)
에 차이가 있으면 이를 일치하도록 만드는 형태로 동작합니다.