디플로이먼트로 pod를 생성하는 경우 내부 로직이 어떻게 될까?
처음부터 이 사진을 드립다 보면 어지러울 수 있다..
설명과 같이 찬찬히 따라와보자.
-
Create Deployment
당연하게도 사용자는 디플로이먼트 매니페스트를 가진 Yaml 파일을 준비해 kubectl 명령으로 쿠버네티스를 게시한다.
Kubelet은 매니페스트를 HTTP POST 요청으로 쿠버네티스 API 서버에 전송한다. -
API 서버는 디플로이먼트 정의를 검증하고 etcd에 저장한 후 kubectl에 응답을 돌려준다.
-
API 서버 감시 메커니즘을 이용해 디플로이먼트 목록을 관찰하던 모든 API 서버 클라이언트는 새로운 디플로이먼트 리소스가 생성되면 즉시 통보를 받는다.
사용자는 디플로이먼트 생성을 날렸으니 디플로이먼트 컨트롤러가 반응하겠죠?
- 디플로이먼트는 실제로 파드를 생성하는 하나 이상의 레플리카셋에 의해 뒷받침 됩니다.
따라서, 디플로이먼트는 새로운 디플로이먼트 오브젝트가 감지되면 현재 디플로이먼트 정의를 이용해 레플리카셋을 생성합니다.
레플리카셋 컨트롤러가 새로 생성된 레플리카셋을 낚아챕니다.
컨트롤러는 레플리카셋에 정의된 복제본 수와 파드 셀렉터와 일치하는 실행 중인 파드가 충분한지 확인합니다.
그런 다음 컨트롤러는 레플리카셋의 파드 템플릿을 기반으로 파드 리소스를 생성합니다.
(디플로이먼트 컨트롤러는 레플리카셋을 생성할 때 디플로이먼트에서 파드 템플릿을 복사한다.)
- 새로 생성된 파드는 etcd에 저장되었지만, 중요한 거는 어느 노드로 할당된거는 없습니다!!
태어는 났는데 이름이 없는 꼴이랄까?
무튼! 스케줄러는 파드를 감시하다가 nodeName 속성이 없는 파드를 발견하면 파드에 가장 적합한 노드를 선정해 파드를 노드에 할당합니다.
이제 파드 정의에는 파드가 실행되어야할 노드 이름이 들어있습니다.
지금까지의 모든 일은 쿠버네티스 컨트롤 플레인에서 일어났습니다.
이 전체 과정에 참여했던 컨트롤러는 API 서버로 리소스를 갱신하는 일 외에 실질적 작업을 한게 없습니다.
그말의 뜻은 지금까지 워커노드는 아무것도 하지 않았고 파드의 컨테이너는 아직 시작되지 않았습니다.
파드의 컨테이너 이미지는 아직 다운로드되지 않았습니다.
- 이제 워커노드의 누군가 등장합니다.
이제 파드가 특정 노드로 스케줄링되면, 해당 노드(워커 노드)의 kubelet이 마침내 동작하기 시작합니다.
Kubelet은 API 서버에서 파드 변경사항을 감시하다가 노드에 스케줄링된 새 파드를 발견하면, 파드 정의를 검사하고 도커 또는 사용중인 컨테이너 런타임에 파드의 컨테이너를 시작하도록 지시합니다.
컨테이너 런타임은 이제 컨테이너를 시작합니다.
