[쿠버네티스] Deployment 쉽게 이해하기: Pod를 안정적으로 배포하는 방법

WorkLoad

Workload는 쿠버네티스 클러스터에서 실행되는 애플리케이션의 실행 단위입니다.

쿠버네티스는 Pod를 직접 실행 단위로 사용하지만, 실제 운영에서는 Pod를 단독으로 관리하기보다 Deployment, StatefulSet, DaemonSet, Job, CronJob 같은 Workload 리소스를 통해 Pod의 생성, 배포, 복구, 확장, 업데이트를 자동으로 관리합니다.

개발자 관점에서는 Kubernetes의 모든 리소스를 깊게 이해하지 않더라도, Workload 리소스만 제대로 이해하고 다룰 수 있어도 실무 운영에 큰 도움이 됩니다. Deployment, StatefulSet, DaemonSet, Job과 같은 Workload는 애플리케이션의 배포, 실행, 복구, 확장과 직접적으로 연결되는 Kubernetes의 주요 리소스입니다.

Deployment

Deployment는 동일한 Pod의 그룹을 의도한 상태(Desired State)로 관리하기 위한 쿠버네티스 오브젝트 입니다. 사용자가 원하는 Pod 개수, 이미지 버전 등 명시해두면 ReplicaSet을 통해 API서버와 지속적으로 동기화를 하면서 해당 상태를 유지하도록 애플리케이션의 배포 및 관리를 수행합니다.

 

Kubernetes에서 애플리케이션을 안정적으로 운영하기 위해서는 Pod를 단독으로 생성하기보다, Pod의 개수와 상태를 지속적으로 관리해주는 상위 리소스를 사용하는 것이 일반적입니다. 

Deployment 리소스는 다음과 같은 특징을 가집니다.

👉 Pod 재시작 / 스케줄링에도 불변 ID가 부여되지 않아 Pod Name이 변경 됨

👉 ReplicaSet을 통해 자유자제로 Scale In / Scale Out / Auto Scale 수행
👉 컨트롤 플레인에 의해 Pod는 최적화된 노드로 스케줄링 수행
👉 롤링 업데이트 / 롤백 제공

다만 테스트나 간단한 실행 목적이라면 Deployment, ReplicaSet과 같은 상위 리소스 없이 Pod만 단독으로 생성할 수도 있습니다. 이때는 kubectl run 명령어를 사용해 간단하게 Pod를 실행할 수 있습니다.  하지만, 실무에서는 위와같이 파드만 생성하는 경우는 없습니다.

kubectl run nginx-pod --image=nginx --restart=Never

현재 Kubernetes에서 가장 많이 사용되는 방식은 다음과 같은 구조입니다.

Deployment
 └── ReplicaSet
      └── Pod

 

Deployment는 애플리케이션 배포를 담당하는 상위 리소스이고, ReplicaSet은 Deployment가 선언한 Pod 개수를 유지하는 역할을 수행합니다. 예를 들어 사용자가 Deployment에 replicas: 3을 선언하면, ReplicaSet은 실제로 Pod가 3개 유지되도록 관리합니다. Pod가 장애로 종료되거나 노드 문제가 발생하면 ReplicaSet이 새로운 Pod를 생성하여 원하는 상태를 맞춥니다.

또한 Deployment는 단순히 Pod 개수를 유지하는 것뿐만 아니라, 롤링 업데이트, 롤백, 버전 관리와 같은 배포 기능을 제공합니다. 즉, Deployment는 ReplicaSet을 직접 제어하면서 애플리케이션의 배포 전략까지 관리하는 리소스라고 볼 수 있습니다

 

초기 Kubernetes에서는 Pod의 복제 수를 유지하기 위해 ReplicationController라는 리소스를 직접 사용하는 방식이 있었습니다.

ReplicationController
 └── Pod

ReplicationController는 지정된 개수만큼 Pod가 유지되도록 관리하는 역할을 했습니다. 현재의 ReplicaSet과 유사한 역할을 했지만, selector 기능이 제한적이었고 배포 전략을 관리하는 기능도 부족했습니다.

 

이후 Kubernetes에서는 ReplicationController보다 더 유연한 selector를 지원하는 ReplicaSet이 등장했고, 그 위에 배포와 업데이트를 관리하는 Deployment가 표준 방식으로 자리 잡았습니다.

 

현재는 일반적으로 ReplicationController를 직접 사용하기보다는 Deployment를 사용합니다. Deployment가 ReplicaSet을 자동으로 생성하고, ReplicaSet이 Pod를 관리하는 구조가 Kubernetes의 일반적인 애플리케이션 배포 방식입니다.

ReplicaSet은 지정된 수의 동일한 Pod 복제본이 항상 실행되도록 보장하는 Kubernetes 오브젝트입니다. Pod 장애나 노드 이슈가 발생하면 새로운 Pod를 생성하여 원하는 복제 수를 유지하고, 애플리케이션의 가용성을 보장합니다.

일반적으로 Deployment의 하위 리소스로 동작하며, Deployment는 ReplicaSet을 통해 배포 버전 관리, 롤링 업데이트, 롤백을 수행합니다. ReplicaSet은 Kubernetes에서 안정적인 애플리케이션 운영과 무중단 배포를 가능하게 하는 핵심 리소스 중 하나입니다.

 

 

 
Deployment의 배포 플로우를 정리하면 아래와 같습니다.

1. 사용자가 kubectl apply -f deployment.yaml을 실행하면 요청은 API Server로 전달
2. API Server는 Deployment 오브젝트를 검증한 뒤 etcd에 저장.
3. Controller Manager 내부의 Deployment Controller가 Deployment 변경을 감지하고, ReplicaSet을 생성

 

4. ReplicaSet Controller는 원하는 replicas 수에 맞게 Pod 오브젝트를 생성합니다. 이 시점의 Pod는 아직 어느 노드에 배치될지 정해지지 않은 Pending 상태이며, nodeName 값이 비어 있습니다.

 

5. Scheduler는 아직 노드가 지정되지 않은 Pending Pod를 감지하고, 각 노드의 리소스 상태와 제약 조건을 기준으로 filtering/scoring을 수행한 뒤 적절한 노드를 선택

6. Scheduler는 선택한 노드 정보를 Pod에 바인딩하고, API Server를 통해 Pod의 nodeName을 업데이트
7. 해당 노드의 kubelet은 자신에게 할당된 Pod Spec을 감지
8. kubelet은 CRI를 통해 containerd 같은 Container Runtime에 컨테이너 생성을 요청
9. Container Runtime은 필요한 컨테이너 이미지를 Registry에서 Pull.
10. 이미지 Pull이 완료되면 Container Runtime이 컨테이너를 생성하고 실행
11. kubelet은 Pod와 컨테이너 상태를 지속적으로 확인하고, 그 결과를 API Server로 업데이트

 

12. kube-proxy는 Service가 존재하는 경우 Service와 Pod 간 통신을 위한 네트워크 규칙을 관리하지만, Deployment 배포 자체의 핵심 흐름에는 직접 관여하지 않습니다.