Kubernetes Deployment Strategy

Overview

Kubernetes Deployment Strategy 에 대해서 알아본다.

출처 : https://spacelift.io/blog/kubernetes-deployment-strategies

 

---

 

Kubernetes Deployment Strategy란?

Kubernetes에서 배포 전략(deployment strategies) 은 새로운 애플리케이션 버전 또는 컨테이너 이미지를 배포할 때, Pod(또는 Pod 집합)를 어떻게 업데이트할지 정의합니다. 주요 배포 전략은 두 가지이다.

• RollingUpdate (기본 전략)
• Recreate

 

RollingUpdate (기본값)

• RollingUpdate는 Kubernetes의 기본값이자 가장 널리 사용되는 전략이다. 배포 내의 Pod을 점진적으로 업데이트
• 롤링 업데이트 동안 Kubernetes는 새로운 버전의 Pod을 생성하고, 동시에 오래된 Pod을 소규모 배치로 종료한다. 이 과정에서 일부 Pod이 계속 실행되므로 다운타임이 최소화
• 이 전략은 고가용성 을 유지해야 하는 경우 이상적
• maxUnavailable: 업데이트 중 사용할 수 없는 Pod의 최대 수(또는 비율)를 지정한다. 예를 들어, maxUnavailable: 25%는 업데이트 중 최대 25%의 Pod이 다운될 수 있음을 의미
• maxSurge: 원하는 복제본 수를 초과하여 임시로 생성할 수 있는 추가 Pod의 최대 수(또는 비율)를 지정합한. 예를 들어, maxSurge: 1은 업데이트 중 임시로 하나의 추가 Pod을 생성할 수 있음을 의미
• 장점: 새로운 Pod을 점진적으로 업데이트하고 배포하여 서비스 다운타임이 없다.
• 사용 사례: 업데이트 중 연속적인 가용성이 필요한 프로덕션 환경에 이상적

spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1 # 업데이트 중 최대 1개의 Pod가 다운될 수 있다.
      maxSurge: 1 # 업데이트 중 임시로 1개의 추가 Pod이 생성될 수 있다.

 

Recreate

• Recreate 전략에서는 Kubernetes가 기존 Pod을 모두 삭제한 후 새로운 Pod을 생성
• 이 전략은 새로운 버전이 배포될 때 오래된 애플리케이션이 실행되지 않도록 보장
• 장점: 단순하고 기존 인스턴스를 모두 종료한 후 새로운 버전을 깨끗하게 배포
• 단점: 새로운 Pod이 생성될 때까지 모든 Pod이 종료되므로 다운타임이 발생
• 사용 사례: 짧은 다운타임이 허용되거나 이전 버전을 완전히 중지해야 하는 애플리케이션에 적합

spec:
  strategy:
    type: Recreate

 

추가 배포 전략

• Blue/Green
• Canary
• A/B
• Ramped Slow Rollout
• Best-Effort Controlled Rollout
• Shadow Deployment

 

블루/그린 배포(Kubernetes에 기본이 아님)

• 블루/그린 배포에는 이전 포드(파란색)가 계속해서 트래픽을 처리하는 동안 완전히 별도의 새 포드(녹색) 세트를 생성하는 작업이 포함된다.
• 새 버전이 확인되면 트래픽이 이전 버전(블루)에서 새 버전(그린)으로 전환된다.
• 외부 도구나 서비스 메시(예: Istio, Linkerd) 또는 수동 수신/서비스 업데이트가 필요하다.

 

장점

• 트래픽을 이전 버전으로 다시 전환하여 쉽게 롤백할 수 있다.
• 다운타임이 거의 0에 가깝다.

 

단점

• 두 배의 리소스가 필요하다(Blue + Green)
• 더 복잡한 설정
• 사용 사례: 다운타임이 허용되지 않고 롤백이 즉시 이루어져야 하는 프로덕션 환경

 

 

카나리아 배포(수동 관리를 통한 부분적 기본)

• 이전 버전을 계속 실행하면서 새 버전의 애플리케이션(새 Pod)을 점진적으로 도입하는 작업이 포함
• 트래픽은 새 버전으로 점진적으로 라우팅되므로 테스트 및 모니터링이 가능

 

장점

• 일부 사용자를 대상으로 변경 사항을 테스트하여 위험을 최소화
• 대부분의 트래픽이 여전히 이전 버전으로 라우팅되므로 롤백이 더 간단해졌다.

 

단점

• 종종 서비스 메시 도구 또는 수신 컨트롤러를 사용하는 트래픽 분할 메커니즘이 필요하다. 더욱 복잡한 트래픽 관리
• 사용 사례: 실제 사용자 트래픽을 사용하여 프로덕션에서 업데이트를 검증한다.

 

 

 

---

Reference

https://github.com/somaz94/DevOps-Engineer/wiki/KR_%EC%BF%A0%EB%B2%84%EB%84%A4%ED%8B%B0%EC%8A%A4

https://kubernetes.io/docs/concepts/workloads/controllers/deployment/

https://spacelift.io/blog/kubernetes-deployment-strategies