[K8S] 쿠버네티스 파드의 생명주기

쿠버네티스의 장점은 쿠버네티스의 구성요소들이 하는 일이 명확하게 구분되어있어서 각자의 역할만 충실하게 한다면 클러스터 시스템이 안정적으로 운영된다는 점이다.

 

각자의 역할이 명확히 나눠진 점은 마이크로서비스 아키텍쳐(MSA) 구조와도 밀접하다.

또한 역할이 나뉘어있기 때문에 문제가 발생했을 때 디버깅하기도 쉽다.

 

 

파드의 생명주기란?

파드가 생성, 수정, 삭제되는 과정을 의미한다. 알아보자

 

1. 개발자가 kubectl 커맨드라인을 통해서 API 서버에 파드 생성을 요청한다. (create)
2. API 서버는 etcd안에 전달된 내용을 모두 기록해 클러스터의 상태 값을 항상 최신으로 유지한다.
   따라서 각 요소(etcd, API서버, 컨트롤러 매니저, 스케줄러)가 상태를 업데이트할 때마다 API 서버를 통해서 etcd에 기록된다.
   
   
3. API 서버에 파드 생성이 요청된 것을 컨트롤러 매니저가 인식하면 컨트롤러 매니저는 파드를 생성하고, 파드가 만들어졌다는 정보를 API 서버에 전달한다. 이때 어떤 노드(서버)에 파드를 적용할지는 아직 결정되지 않은 상태로 파드만 생성된다.
   
   
4. API 서버를 통해 파드가 생성되었다는 정보를 스케줄러가 인식한다. 스케줄러는 생성된 파드를 어떤 워커 노드에 적용할지 조건을 고려해서 결정한다. 그리고 해당 워커 노드에 파드를 띄우도록 API 서버에 요청한다.
5. API 서버에 전달된 정보대로 스케줄러가 지정한 워커노드에 파드가 속해있는지 스케줄러가 직접 kubelet 커맨드라인으로 확인한다.
   
   
6. 아직 생성이 안되어있기 때문에 kubectl에서 컨테이너 런타임으로 파드 생성을 요청한다.
7. 파드가 생성되고 사용가능한 상태가 된다.

모든 요청이 API 서버를 거쳐서 이어진다는걸 볼 수 있다.

 

이 부분은 쿠버네티스를 이해하는데 중요한 부분이다.

쿠버네티스는 작업을 순서대로 진행하는 workflow 구조가 아니다.

이를 선언적인(declarative) 시스템 구조라고 한다.

즉, 각 요소가 추구하는 상태를 선언하면 현재 상태와 맞는지 점검하고 그것에 맞추려고 노력하는 구조이다.

 

따라서 개발자가 추구하는 상태를 API 서버에 선언하면 다른 요소들이 API 서버에 들려서 자신의 현재 상태와 비교하고 그에 맞게 상태를 변경하려고 한다.

 

여기서 API는 현재 상태 값을 가지고 있는데, 이것을 보존해야하기 때문에 etcd가 필요한 것이다. 그래서 API 서버와 etcd는 한몸처럼 움직이도록 설계되어있다.

 

그런데 쿠버네티스에서 워커 노드는 절차적인 workflow 구조로 설계된다.

쿠버네티스가 kubelet과 컨테이너 런타임을 통해 파드를 새로 생성하고 제거해야하는 구조이기 때문에 절차적인 방식이 시스템의 성능을 높이는데 더 효율적이기 때문이다.

반면에 마스터 노드는 이미 생성된 파드들을 유기적으로 연결하는 역할을 가지기 때문에 클러스터를 안정적으로 유지하기 위해서 선언적인 시스템으로 구성된다.

 

 

상태 변경 -> 감시 -> 차이 발견 -> 상태 변경 -> ....

 

추구하는 상태와 현재 상태를 맞추려고 한다.
항상성