쿠버네티스 배포 전략 종류 (rolling update, recreate ...)

Kubernetes 배포를 사용하면 포드 및 ReplicaSet를 선언적으로 생성할 수 있다. 원하는 상태를 정의할 수 있으며 배포 컨트롤러는 관련 리소스의 현재 상태를 지속적으로 모니터링하고 원하는 상태에 맞게 포드를 배포한다.

 

배포 전략은 다양한 버전의 Kubernetes 애플리케이션을 생성, 업그레이드 또는 다운그레이드하는 방법을 정의한다. 기존 소프트웨어 환경에서 애플리케이션을 배포하거나 업그레이드하면 다운타임과 서비스 중단이 발한다. Kubernetes는 여러 애플리케이션 인스턴스에 대한 롤링 업데이트를 수행하고 가동 중지 시간을 피하거나 최소화할 수 있는 몇 가지 배포 전략을 제공하여 이를 방지할 수 있다.

Kubernetes 배포 전략에 대해 알아보자.

 

• Rolling deployment
• Reacreate
• Ramped slow rollout 
• Best-effort controlled rollout
• Canary deployment

 

---

Rolling deployment

롤링 배포는 Kubernetes의 기본 배포 전략이다. 기존 pod 버전을 새 버전으로 교체하여 클러스터 가동 중지 시간 없이 pod를 하나씩 천천히 업데이트한다. 

롤링 업데이트는 이전 버전으로 pod 축소를 시작하기 전에 readiness probe를 사용하여 새 pod가 준비되었는지 확인한다. 문제가 있는 경우 전체 클러스터를 중지하지 않고 업데이트를 중지하고 롤백할 수 있다.

배치 전략을 세분화하려면 매니페스트 파일의 spec:strategy 섹션에서 매개변수를 변경하면 된다. maxSurge 및 maxUnavailable 이라는 두 가지 선택적 매개변수가 있다 . 

• MaxSurge는 배포에서 한 번에 만들 수 있는 최대 포드 수를 지정. 숫자(예: 5) 또는 필요한 총 포드 수의 백분율(예: 10%,항상 다음 정수로 반올림). MaxSurge를 설정하지 않은 경우 암시적 기본값은 25%.
• MaxUnavailable은 롤아웃 중에 사용할 수 없는 최대 포드 수를 지정. MaxSurge와 마찬가지로 절대 숫자 또는 백분율로 정의할 수 있다. 

이러한 매개변수 중 적어도 하나는 0보다 커야 한다. 이러한 매개 변수의 값을 변경하면 아래와 같이 다른 배포 전략을 정의할 수 있다.

 

Recreate

이것은 모든 이전 pods를 종료하고 새 pods로 교체하는 기본 배포 패턴이다.다음과 같이 매니페스트의 spec:strategy:type 섹션을 Recreate 로 설정한다.

새 팟(Pod)이 애플리케이션의 새 버전과 함께 롤아웃되는지 확인하기 전에 이전 팟(Pod)이 삭제되기 때문에 재생성 전략은 가동 중지 시간을 초래할 수 있다.

 

Ramped Slow Rollout

ramped rollout은 이전 복제본을 제거하는 동안 새 복제본을 생성하여 pods를 점진적으로 업데이트합니다. 매번 롤아웃할 복제본 수를 선택할 수 있다. 또한 사용할 수 없는 pods가 없는지 확인해야 합니다. 

이 전략과 일반 롤링 배포의 차이점은 새 복제본이 롤아웃되는 속도를 제어할 수 있다는 것이다. 예를 들어 업데이트의 위험을 줄이기 위해 한 번에 1개 또는 2개의 노드만 업데이트되도록 정의할 수 있다.

이 동작을 정의하려면 maxSurge를 1로 설정하고 maxUnvailable을 0으로 설정한다. 즉, 배포는 사용 가능한 포드가 없는지 확인하면서 한 번에 하나의 포드를 롤링한다.

 

 

Best-effort Controlled Rollout

ramped rollout의 단점은 특히 대규모로 애플리케이션을 롤아웃하는 데 시간이 걸린다는 것이다. 대안은 "best-effort controlled rollout"이다. 이렇게 하면 롤아웃이 더 빨라지지만 노드 간에 일정 비율의 다운타임을 허용함으로써 더 높은 위험을 감수해야 한다.

• maxUnavailable을 특정 비율로 설정하면 업데이트가 가동 중지 시간이 있는 특정 양의 포드를 허용할 수 있음.
• maxSurge를 0으로 설정하여 배포에 항상 동일한 수의 포드가 있도록 합니다. 이렇게 하면 업데이트 중에 최상의 리소스 활용이 가능하다.

이렇게 하면 주어진 시간에 제한된 수의 pods가 다운되도록 하면서 가능한 한 빨리 pods를 신속하게 교체하는 효과가 있다. 

 

Canary Deployment

카나리아 배포는 일반적으로 애플리케이션의 백엔드에서 몇 가지 새로운 기능을 테스트하는 데 사용된다. 애플리케이션의 두 개 이상의 서비스 또는 버전이 병렬로 배포된다. 하나는 기존 버전을 실행하고 다른 하나는 새로운 기능을 사용한다. 사용자는 점차 새 버전으로 이동하여 새 버전을 실제 사용자에게 노출하여 유효성을 검사할 수 있다. 오류가 보고되지 않으면 새 버전 중 하나를 모든 사용자에게 점진적으로 배포할 수 있다.

 

 

 

 

 

 

참조) https://spot.io/resources/kubernetes-autoscaling/5-kubernetes-deployment-strategies-roll-out-like-the-pros/#a1