Google Cloud는 GKE 서비스에서 이제 정식 출시(GA)된 2단계 컨트롤 플레인 업그레이드를 제공한다고 발표했습니다. 이를 통해 고객은 소프트웨어 바이너리 업그레이드와 데이터 형식 마이그레이션을 분리할 수 있으며, 마이너 버전 변경 중에 롤백 가능 기간을 유지할 수 있습니다.

GKE에 더 안전한 경로가 필요했던 이유

Kubernetes 컨트롤 플레인을 다음 마이너 버전으로 업그레이드하는 것은 항상 위험을 수반해 왔습니다. 1.33에서 1.34로 이동하는 것은 바이너리를 교체할 뿐만 아니라 기본 데이터 구조도 다시 작성합니다. 새 버전에 버그가 포함되어 있으면 클러스터를 단순히 되돌릴 수 없습니다. 관리자는 오래된 데이터베이스 스냅샷을 복구하거나 전체 클러스터를 다시 구축해야 하는데, 이는 시간이 많이 걸리고 오류가 발생하기 쉬운 과정입니다.

2단계 업그레이드 작동 방식

새로운 흐름은 업그레이드를 두 개의 별도 단계로 나눕니다.

  • 1단계 – 바이너리 업그레이드(에뮬레이션 모드). GKE는 기존 데이터 형식을 유지하면서 컨트롤 플레인 바이너리를 대상 버전으로 교체합니다. 새로운 데이터 구조가 작성되지 않기 때문에 이 단계 내내 클러스터는 롤백 가능한 안전한 상태를 유지합니다.
  • 2단계 – 마무리(Finalization). 설정 가능한 대기 기간이 지나면 GKE는 저장된 데이터를 새 형식으로 변환합니다. 이 변환이 완료되면, 롤백을 위해 2단계 프로세스가 방지하고자 했던 것과 동일한 스냅샷 복구 작업이 필요하게 됩니다.

이러한 분리를 통해 운영자가 되돌릴 수 없는 데이터 마이그레이션을 확정하기 전에 프로덕션 환경에서 업그레이드된 바이너리를 관찰할 수 있는 "소크 윈도우(soak window)"가 생성됩니다.

실제 소크 윈도우 활용

GKE는 소크 기간 동안 API 지연 시간, 오류율, Pod 상태와 같은 주요 상태 지표를 자동으로 모니터링합니다. 서비스에서 이상 징후가 감지되면 롤아웃을 중단하고 클러스터를 롤백이 가능한 바이너리 전용 상태로 유지합니다. Google은 이 패턴을 따르는 업그레이드의 성공률이 99.999%에 달한다고 밝혔습니다.

GKE의 자동 업그레이드 기능을 사용하는 클러스터의 경우, 플랫폼이 수동 개입 없이 전체 2단계 시퀀스를 조율합니다. 완전한 제어를 선호하는 사용자는 Cloud CLI 또는 Terraform을 통해 프로세스를 실행할 수 있습니다.

수동 2단계 업그레이드 실행

48시간의 안전 기간을 둔 일반적인 수동 업그레이드 방식은 다음과 같습니다.

gcloud beta container clusters upgrade my-cluster \
  --location=us-central1 \
  --cluster-version=1.34.1-gke.1829001 \
  --control-plane-soak-duration=48h \
  --master

현재 상태를 확인하려면:

gcloud container clusters describe my-cluster \
  --location=us-central1 \
  --format="yaml(rollbackSafeUpgradeStatus)"

소크 기간 중 결함이 발견되면 관리자는 롤백 명령을 실행하여 데이터 손실 없이 이전 버전으로 되돌릴 수 있습니다. 클러스터가 안정적임이 확인되면 complete-control-plane-upgrade 명령을 사용하여 업그레이드를 조기에 완료할 수 있습니다.

제한 사항 및 요구 사항

  • 이 기능은 버전 1.33 이상을 실행하는 GKE 클러스터에 적용됩니다.
  • 한 번에 하나의 마이너 버전만 업그레이드할 수 있으며, 버전을 건너뛰는 것은 지원되지 않습니다.
  • Autopilot 및 리전형(regional) 클러스터 모두 2단계 프로세스 전반에 걸쳐 사용 가능한 상태로 유지됩니다.

잠재적인 단점

바이너리와 데이터 업그레이드를 분리하면 업그레이드 일정에 추가 단계가 생기므로, 빠른 버전 변경이 필요한 조직의 경우 전체 작업 시간이 길어질 수 있습니다. 또한 소크 기간은 자동화된 상태 확인에 의존하므로, 고도로 맞춤화된 워크로드를 실행하는 팀은 엣지 케이스의 회귀(regression)를 포착하기 위해 GKE의 모니터링을 자체 관측성(observability) 도구로 보완해야 할 수도 있습니다.

향후 주목할 점

Google은 여전히 많은 경우 클러스터 전체 재생성이 필요한 메이저 버전 업그레이드까지 이 2단계 모델을 확장할 로드맵을 공개하지 않았습니다. 관찰자들은 노드 풀(node-pool) 업그레이드를 위한 유사한 안전 장치에 대한 발표나, 소크 윈도우 확인을 자동화할 수 있는 서드파티 CI/CD 파이프라인과의 통합 여부에 주목할 것입니다.

핵심 요약: 바이너리 업그레이드와 데이터 마이그레이션을 분리함으로써, GKE는 플랫폼 엔지니어에게 마이너 버전 변경 시 실질적인 롤백 기간을 제공합니다. 이를 통해 다운타임을 최소화하면서 클러스터 유지 관리의 운영 비용을 줄일 수 있습니다.