[K8s] k8s Pod 생성 시 벌어지는 일

Pod

K8s의 Pod는 쿠버네티스에서 생성하고 관리할 수 있는 배포 가능한 가장 작은 컴퓨팅 단위이다. 하나 이상의 컨테이너의 그룹이며, 이 그룹은 스토리지 및 네트워크를 공유하고, 해당 컨테이너를 구동하는 방식에 대한 명세를 갖는다. 파드의 콘텐츠는 항상 함께 배치되고, 함께 스케줄되며, 공유 콘텍스트에서 실행된다.

ReplicaSet

yaml 파일 혹은 kubectl run 명령어를 통해 Pod를 생성할 수 있다. 하지만 Pod만 생성할 경우 Pod에 문제가 생겨 해당 Pod가 다운되거나, 종료되었을 때 쿠버네티스가 해당 Pod를 다시 생성할 수 없다.

Pod에 문제가 생겨 종료되었을 때, 해당 Pod를 복구할 수 있는 쿠버네티스의 기능을 Self-Healing 이라고 한다. Self-Healing 기능을 위해서는 ReplicaSet이 필요하다.

ReplicaSet은 주기적으로 Pod를 감시하며, 사용자가 설정한 수만큼 Pod가 실행되고 있는지를 확인한다.

Deployment

Deployment는 ReplicaSet을 관리하는 controller다. 또한, ReplicaSet에서는 지원하지 않았던 배포 관한 전까지도 지원하며, 문제가 생겼을 때 롤백을 어떤 식으로 진행할지에 대한 설정도 가능하다.

Deployment를 사용하면 더욱 안정적으로 Pod들의 운영이 가능하기 때문에 Pod를 생성할 때 Pod만 생성하는 것이 아니라 Deployment 단위로 생성하게 된다.

 

Pod가 생성되는 순서를 kubectl get events 명령어로 살펴보면, Deployment가 먼저 생성되고 Deployment에 의해 ReplicaSet이 만들어진다. 최종적으로 ReplicaSet 설정된 사용자의 설정에 따라 Pod가 생성된다.

k8s Cluster 내부

쿠버네티스 클러스터 내부는 각각 마스터 노드와 워커 노드로 분리되어 있다.

마스터 노드 내부에는 API Server, Scheduler, Controller Manager, etcd 와 같은 컴포넌트들이 존재한다. 워커 노드 내부에는 kubelet, kubeProxy 가 존재하며, kubectl 명령어를 사용할 때마다 각 노드에 존재하는 컴포넌트들이 상호작용하게 된다.

 

또한 각 컴포넌트들은 watch 라는 매커니즘을 가지고 있다. 예를 들어, API Server는 etcd를 지속적으로 watch 하며, API Server에 변경사항이 발생할 경우 해당 변경사항이 etcd로 업데이트 된다. etcd 는 API 변경사항을 새롭게 저장하게 되고, 그에 따라 etcd 에도 변경사항이 발생하게 된다.

 

etcd에 변경사항이 발생하게 될 경우, etcd를 watch하고 있는 API Server에 notify를 보내게 되고, API Server 또한 API Server를 watch 하고 있는 Components에 notify를 보내게 된다.

위와 같은 구조를 쿠버네티스 클러스터에 실제로 적용시키게 되면, 다음과 같은 흐름을 볼 수 있다.

Components 들은 API Server를 watch하고 있고, API Server는 etcd를 watch하고 있다. kubectl run 명령어를 통해 Deployment 단위로 Pod를 생성하게 되면 결과적으로 아래와 같은 흐름에 따라 Pod가 생성된다.

꽤 복잡해보이지만, 흐름을 정리하면 다음과 같다.

 

kubectl run 명령 실행시 Deployment Resource에 변화가 생기고 해당 Resource 를 watch 하고 있던 Controller 에 notify가 응답으로 보내지게 된다. 해당 notify에 따라 Controller는 Resource에 Resource 생성을 위한 요청을 Controller에 보내게 된다.

 

이 과정이 반복되고 최종적으로 Pod Resource에서 보내진 notify가 Scheduler로 보내지고, 해당 Scheduler가 워커 노드에 Pod를 생성하게 된다.

 

워커 노드에 Pod가 생성되는 과정까지 상세히 살펴보자. 우선 Scheduler는 API Server에 수집되고 있는 워커 노드에 대한 자원 사용량과 Affinity, Taint 등의 정보를 통해 Pod를 생성하기에 최적인 워커 노드를 선발한다.

최종적으로는 Pod Resource에 변경사항이 발생하고 해당 변경사항을 워커 노드의 kubelet이 감지하여 Pod를 생성한다.