[Kubernetes]Rolling Updates

배포를 업데이트하는 다양한 방법

1. kubectl apply 명령어 사용: 업데이트된 배포 사양 YAML 파일을 사용하여 kubectl apply 명령어를 실행합니다. 이 방법은 Pod 사양과 같은 배포 사양의 변경 사항을 업데이트할 수 있습니다. 예를 들어, 이미지 버전을 변경하는 경우에 사용할 수 있습니다.
2. kubectl set 명령어 사용: kubectl set 명령어를 사용하여 배포의 Pod 템플릿 사양을 변경할 수 있습니다. 이 방법은 이미지, 리소스 또는 선택기 값과 같은 Pod 템플릿 사양을 변경할 수 있습니다.
3. kubectl edit 명령어 사용: kubectl edit 명령어를 사용하여 배포 사양 파일을 직접 편집할 수 있습니다. 이 명령어는 vim 편집기를 사용하여 사양 파일을 열고 변경 사항을 직접 수정할 수 있습니다. 파일을 저장하고 나가면 kubectl이 업데이트된 파일을 자동으로 적용합니다.
4. GCP 콘솔 사용: GCP 콘솔에서 배포 매니페스트를 편집하고 추가 옵션과 함께 롤링 업데이트를 수행할 수 있습니다. 이 방법은 GCP 콘솔을 통해 배포를 업데이트하는 방법입니다.

이러한 방법들을 사용하여 배포를 업데이트할 수 있으며, 롤링 업데이트 전략을 사용하여 새로운 ReplicaSet에서 새로운 Pod를 시작하고 이전 ReplicaSet에서 모든 Pod를 삭제하는 방식으로 업데이트를 진행할 수 있습니다. 이를 통해 애플리케이션의 가용성을 보장하면서 업데이트를 수행할 수 있습니다.

 

Rolling updates

롤링 업데이트 전략은 애플리케이션의 가용성을 보장하면서 새로운 업데이트를 제어된 방식으로 배포하는 방법입니다. 아래는 롤링 업데이트 전략의 작동 방식입니다:

1. 업데이트가 시작되면 새로운 ReplicaSet에서 새로운 Pod가 시작됩니다.
2. 이후 이전 ReplicaSet의 모든 Pod가 삭제됩니다.
3. 이 과정은 새로운 Pod와 이전 Pod 사이의 트래픽을 조절하면서 점진적으로 진행됩니다.
4. 이러한 방식으로 업데이트가 천천히 배포되므로 애플리케이션의 가용성이 유지됩니다.

롤링 업데이트 전략은 Google Kubernetes Engine (GKE)에서 자동으로 처리되며, 애플리케이션의 중단 없이 업데이트를 수행할 수 있습니다. 이 방법을 사용하면 사용자에게 최소한의 영향을 주면서 업데이트를 안전하게 배포할 수 있습니다.

 

Rolling updates의 단점

1. 시간이 걸릴 수 있습니다: 롤링 업데이트는 새로운 Pod들을 점진적으로 배포하고 이전 Pod들을 삭제하는 과정을 거치기 때문에 시간이 걸릴 수 있습니다. 특히, 애플리케이션의 규모가 크고 복잡할수록 업데이트에 소요되는 시간이 더 오래 걸릴 수 있습니다.
2. 트래픽 분배의 제한: 롤링 업데이트는 새로운 Pod들이 안정화되는 동안 이전 Pod들이 트래픽을 계속해서 처리하도록 보장합니다. 하지만 이는 새로운 Pod들이 트래픽을 처리하는 능력에 제한을 두는 것을 의미하기도 합니다. 따라서, 업데이트 동안에는 애플리케이션의 성능이 일시적으로 저하될 수 있습니다.
3. 롤백의 어려움: 롤링 업데이트가 진행 중일 때, 문제가 발생하면 롤백을 수행하기가 어려울 수 있습니다. 새로운 Pod들이 이미 배포되고 이전 Pod들이 삭제되었기 때문에, 롤백을 하려면 이전 버전의 Pod들을 다시 배포해야 할 수 있습니다. 이는 추가적인 시간과 작업을 요구할 수 있습니다.
4. 자원 소모: 롤링 업데이트는 새로운 Pod들을 추가로 생성하고 이전 Pod들을 삭제하는 과정을 거치기 때문에, 자원 소모가 발생할 수 있습니다. 특히, 업데이트 동안에는 새로운 Pod들과 이전 Pod들이 동시에 실행되므로, 더 많은 자원이 필요할 수 있습니다.

이러한 단점들을 고려하여 롤링 업데이트 전략을 수행할 때는 충분한 시간과 자원을 확보하고, 롤백 계획을 갖추는 것이 중요합니다. 또한, 업데이트 동안에는 애플리케이션의 성능 변화를 모니터링하고 사용자에게 영향을 최소화하기 위해 적절한 조치를 취해야 합니다.

 

Rolling updates 변수

• max unavailable 값: max unavailable은 롤아웃 프로세스 중에 사용할 수 없는 Pod의 최대 수를 지정합니다. 이 값을 설정할 때 고려해야 할 사항은 다음과 같습니다:
  • 업데이트 중에 사용할 수 없는 Pod의 수를 최소화하려면 이 값을 낮게 설정할 수 있습니다.
  • 그러나 너무 낮게 설정하면 업데이트 중에 일시적으로 일부 Pod가 사용할 수 없을 수 있으므로 서비스의 안정성에 영향을 줄 수 있습니다.
  • 일반적으로는 기본값인 25%를 사용하는 것이 안정적인 업데이트를 유지하는 데 도움이 될 수 있습니다.
• max surge 값: max surge는 새로운 ReplicaSet에서 동시에 생성할 수 있는 최대 Pod 수를 지정합니다. 이 값을 설정할 때 고려해야 할 사항은 다음과 같습니다:
  • 새로운 ReplicaSet에서 동시에 생성할 수 있는 Pod 수를 제한하려면 이 값을 낮게 설정할 수 있습니다.
  • 그러나 너무 낮게 설정하면 업데이트 프로세스가 더 길어질 수 있으며, 업데이트가 완료되기까지 시간이 오래 걸릴 수 있습니다.
  • 일반적으로는 기본값인 25%를 사용하는 것이 안정적인 업데이트를 유지하는 데 도움이 될 수 있습니다.

Rolling updates 예시

요구되는 pods 수: 10개

max unavailable: 20%는 10개(Desired Pods 수) * 0.8(1 - 0.2) = 최소 8개의 pods를 사용 가능

max surge: 최대 5개 생성 가능

1. Old Replica 10개 있습니다.

2. max surge가 5개 이므로 5개의 pods 를 New Replica에 생성

3. max unavailable 가 20% 이므로 최소 8개의 pods 가동 되야 하므로 3개를 남기고 제거

4. max surge가 5개 이므로 추가로 5개의 pods 를 New Replica에 생성하여 10개 생성 완료

5. Old Replica 남은 3개 제거하며 Update 완료

 

추가 옵션

Progress Deadline Seconds는 Deployment가 진행되지 못했다고 보고하는 대기 기간을 지정하는 옵션입니다. 이 기간 동안 Deployment가 진행되지 않으면, Deployment는 실패로 간주됩니다.

Min ready seconds는 Pod가 사용 가능한 상태로 간주되기 전에 기다려야 하는 시간을 정의하는 옵션입니다. 이 시간 동안 Pod의 컨테이너 중 하나도 충돌하지 않고 사용 가능한 상태가 되면, Pod가 사용 가능한 상태로 간주됩니다. 기본값은 0으로, Pod가 준비되면 즉시 사용 가능한 상태로 간주됩니다.