Workload
Pod
Pod는 쿠버네티스(Kubernetes, k8s)의 중요한 구성 요소로, 컨테이너를 표현하는 k8s API의 최소 단위로 사용된다. 각 Pod 내부에는 하나 이상의 컨테이너가 포함될 수 있으며, 이 컨테이너들은 저장 공간과 네트워크 자원을 공유한다. 이는 Pod가 쿠버네티스 클러스터 내에서 실행 중인 컨테이너들의 집합을 나타낸다는 점에서 중요하다.
Pod는 생성 및 관리가 가능한 가장 작은 컴퓨팅 단위로, 명세에 따라 Pod를 종료해도 다시 명세대로 생성되어 복구된다. 개발자들은 일반적으로 Pod를 직접 만들지 않고, Deployment, Job 등의 워크로드 리소스를 통해 Pod가 생성되도록 한다. 특히, Pod의 상태를 추적하고 관찰할 필요가 있는 경우에는 StatefulSet을 사용할 수 있다.
Pod는 단일 또는 다중 컨테이너를 포함하는 sidecar 패턴 등 다양한 패턴으로 사용될 수 있다. 쿠버네티스 내에서는 이러한 워크로드가 파드 집합 내에서 실행된다.
Pod이 실행된 후 해당 노드에 심각한 장애나 오류가 발생하면 관련된 모든 Pod는 실패 상태가 된다. 하지만 Pod은 자동으로 다시 생성될 수 있으며, 이 과정은 컨트롤러를 통해 자동으로 관리된다. 컨트롤러는 지정된 상태를 유지하며, 올바른 수의 Pod가 실행되는지, 올바른 유형의 Pod가 실행되는지를 확인한다. 이는 Pod가 쿠버네티스에서 안정적으로 운영될 수 있도록 하는 중요한 기능이다.
Deployment
Deployment는 쿠버네티스 클러스터에서 애플리케이션을 배포하는 가장 일반적인 방식으로 사용된다. 이 방식은 ReplicaSet 컨트롤러를 활용하여 복제(replica) 수를 보장하고, 애플리케이션의 확장(scaling)이 가능하게 한다. 또한, Rolling Update 및 Rollback을 지원함으로써 배포 중에 애플리케이션을 업데이트하거나 이전 버전으로 복구할 수 있게 한다.
Deployment는 '애플리케이션의 인스턴스를 어떻게 생성하고 업데이트할 것인가'에 대한 설명서 역할을 하며, 원하는 상태를 정의하고 이를 달성하기 위해 컨트롤러가 지속적으로 모니터링하고 조정한다. 쿠버네티스의 초기 버전에서는 Replication Controller를 사용하여 앱을 배포했으나, 현재는 Deployment가 기본 메커니즘으로 사용된다.
Deployment는 Pod와 ReplicaSet의 명세를 포함하며, 이 명세는 인스턴스 생성, 운영 중인 Pod의 상태 유지, 롤링 업데이트 실행, 필요시 중단 후 재개배포, 그리고 롤백을 가능하게 한다. 이와 같이 Deployment는 배포 후 변경이 없는 애플리케이션의 효율적인 관리를 가능하게 하며, 파드 개수 유지 및 버전 관리 기능을 제공한다.
이러한 모든 기능은 쿠버네티스 클러스터의 Control Plane에 의해 조율되며, Deployment Controller는 배포된 애플리케이션의 인스턴스를 모니터링하고 필요한 경우 self-healing을 제공한다. 이는 Deployment가 쿠버네티스에서 애플리케이션 배포 및 관리의 핵심 도구 중 하나로 자리 잡은 이유이다.
업데이트 방식
Recreate: 이 방식은 기존에 실행 중인 모든 파드를 삭제하고 새 파드를 생성한다. 이 과정에서 다운타임이 필연적으로 발생한다는 단점이 있지만, 업데이트의 복잡성을 최소화할 수 있다.
Rolling Update: 새 버전의 배포를 시작하면서 동시에 기존 버전의 파드 수를 점진적으로 줄여나가는 방식이다. 이 방식은 무중단 배포를 가능하게 하며, 업데이트 중 이전 버전과 새 버전의 파드가 일시적으로 공존한다는 점은 고려해야 할 단점이다. maxUnavailable과 maxSurge 라는 두 가지 중요한 설정을 통해 롤링 업데이트의 성능을 조절할 수 있다. maxUnavailable은 롤링 업데이트 중 사용할 수 없는 파드의 최대 개수를, maxSurge는 추가로 생성할 수 있는 파드의 최대 수를 정의한다.
Blue/Green Deployment: 이 방식은 새로운 버전의 배포가 완료된 후, 트래픽을 기존 버전에서 새 버전으로 한 번에 전환하는 방법이다. 무중단 배포가 가능하며 롤백이 용이하다는 장점이 있지만, 두 버전의 애플리케이션을 동시에 유지해야 하기 때문에 리소스를 2배로 사용하는 단점이 있다.
Canary Deployment: 이 방식은 새 버전과 이전 버전을 동시에 운영하면서, 처음에는 소량의 트래픽만 새 버전으로 보내 테스트를 진행한다. 이후 문제가 없다면 점차적으로 트래픽을 새 버전으로 이동시키는 방식이다. 이 방법은 신규 버전의 안정성을 점진적으로 검증할 수 있으나, 복잡한 트래픽 라우팅과 모니터링이 필요하다는 단점이 있다.
각각의 배포 방식은 특정 상황과 요구에 맞춰 선택되어야 하며, 이는 애플리케이션의 요구 사항과 운영 환경의 복잡성에 따라 달라진다.
