클러스터 업그레이드는 왜 배포처럼 canary와 soak가 필요할까: GKE custom rollout sequencing으로 보는 플랫폼 변경 관리

• 카테고리: infra_dev
• 예상 읽기 시간: 10분
• 오늘의 질문: 애플리케이션은 canary로 배포하면서, 왜 Kubernetes 클러스터 버전 업그레이드는 한 번에 밀어도 된다고 생각할까?
• 핵심 출처:
  • GKE release notes - New features - 2026-07-14, 확인일 2026-07-23
  • About rollout sequencing with custom stages - Google Cloud Docs, 확인일 2026-07-23
  • Sequence the rollout of cluster upgrades with custom stages - Google Cloud Docs, 확인일 2026-07-23
  • About release channels - Google Cloud Docs, 확인일 2026-07-23
  • Collect specific Prometheus metrics from Kubernetes - Google Cloud Docs, 확인일 2026-07-23

1. 왜 지금 봐야 하나

2026년 7월 14일 GKE release notes에는 작은 팀도 눈여겨봐야 할 변화가 들어갔다. Rollout sequencing with custom stages가 GA가 됐다. 이름만 보면 “GKE 업그레이드 편의 기능”처럼 보이지만, 운영 관점에서는 더 큰 신호다.

이제 클러스터 업그레이드도 애플리케이션 배포처럼 단계, canary, soak time, pause/resume/cancel을 가진 변경 관리 대상이 됐다.

애플리케이션을 배포할 때는 보통 조심한다. staging에 먼저 올리고, production 일부 트래픽에 canary로 내보내고, 지표가 괜찮으면 전체로 넓힌다. 그런데 클러스터 버전, 노드 이미지, kubelet, CNI, admission, sidecar, autoscaler 같은 “플랫폼 아래쪽”은 여전히 자동 업그레이드 일정에 맡기거나, maintenance window 하나로 묶어 생각하기 쉽다.

문제는 플랫폼 변경이 앱 코드보다 덜 위험하지 않다는 점이다. 클러스터 업그레이드는 워크로드 재시작, Pod scheduling, HPA/VPA 동작, PDB, CSI/CNI, observability agent, sidecar compatibility, deprecated API 사용 여부를 한 번에 건드릴 수 있다. 장애가 나면 원인도 “방금 merge한 PR”보다 찾기 어렵다.

오늘의 핵심 문장은 이것이다.

클러스터 업그레이드는 인프라 이벤트가 아니라, 제품을 떠받치는 플랫폼 배포다. 그래서 canary와 soak, 그리고 되돌릴 의사결정 지표가 필요하다.

2. 핵심 개념

GKE rollout sequencing은 여러 GKE 클러스터의 자동 업그레이드 순서를 제어하는 기능이다. custom stages 버전은 기존 fleet-based sequencing보다 더 세밀하다. 공식 문서는 새 환경을 만든다면 custom stages를 권장한다고 설명한다.

여기서 알아야 할 개념은 다섯 가지다.

첫째, fleet이다. fleet은 여러 GKE 클러스터를 논리적으로 묶는 단위다. 예를 들어 testing, staging, production 같은 환경별 fleet을 만들 수 있다. rollout sequencing은 이 fleet들을 기반으로 업그레이드 순서를 정한다.

둘째, stage다. stage는 업그레이드 순서의 한 단계다. custom stages에서는 한 stage가 하나의 fleet을 참조하고, 필요하면 label selector로 그 fleet 안의 일부 클러스터만 고를 수 있다. 예를 들어 production fleet 안에서 canary=true 라벨이 붙은 클러스터만 먼저 올릴 수 있다.

셋째, soak time이다. soak time은 어떤 stage의 업그레이드가 끝난 뒤 다음 stage로 넘어가기 전 기다리는 시간이다. 공식 문서에 따르면 stage별 soak time은 최대 30일까지 설정할 수 있고, sequence 전체 soak time에는 제한이 있다. 중요한 것은 “그냥 기다림”이 아니라 “새 버전 위에서 워크로드가 정상인지 관찰하는 시간”이라는 점이다.

넷째, RolloutSequence와 Rollout 객체다. RolloutSequence는 업그레이드 순서 자체를 정의하는 리소스이고, Rollout은 특정 버전이 그 순서를 따라 진행되는 상태를 보여준다. custom stages는 pause, resume, cancel, stage completion 같은 운영 조작도 지원한다.

다섯째, release channel이다. GKE release channel은 Rapid, Regular, Stable, Extended처럼 버전 도입 속도와 안정성의 균형을 고르는 장치다. 공식 문서는 rollout sequencing을 쓰려면 클러스터들을 release channel에 맞춰 관리하는 것을 권장한다. release channel은 “어떤 버전 후보가 들어오는가”를 정하고, rollout sequencing은 “그 후보를 어떤 순서로 검증할 것인가”를 정한다.

간단히 그리면 이렇게 볼 수 있다.

Release channel: 어떤 GKE 버전이 자동 업그레이드 대상이 되는가
        |
        v
RolloutSequence: 그 버전을 어떤 stage 순서로 밀 것인가
        |
        v
Stage 1: test fleet -> soak
Stage 2: staging fleet -> soak
Stage 3: prod canary clusters -> soak
Stage 4: remaining prod clusters -> soak
        |
        v
관측 지표와 runbook: 계속 진행 / 일시정지 / 취소 / 수동 조치

3. 최신 이슈와 연결

이번 GA에서 눈에 띄는 점은 “업그레이드를 순서대로 한다”보다 “운영자가 중간에 판단할 수 있는 표면이 늘었다”는 것이다. release notes는 custom stages가 다음 기능을 제공한다고 요약한다.

• 환경 간 custom stage 정의
• patch version만 sequence에 포함하고 minor version은 제외하는 식의 rollout scope 선택
• 특정 버전 rollout 시작
• rollout pause, resume, cancel, stage complete 관리

공식 개념 문서는 custom stages가 label selector를 통해 production 안에서도 작은 subset을 먼저 업그레이드하는 전략을 지원한다고 설명한다. 예를 들어 production fleet 전체를 한 번에 올리는 대신, 낮은 트래픽 region이나 canary cluster를 먼저 올리고 soak time 동안 검증한 뒤 다음 region으로 진행할 수 있다.

운영 절차 문서는 더 구체적인 제약도 말한다. 각 stage는 최대 하나의 fleet을 참조할 수 있고, label selector로 fleet 일부를 먼저 골랐다면 같은 fleet의 나머지 클러스터를 담는 catch-all stage가 필요하다. 한 클러스터가 여러 stage에 걸리면 가장 이른 stage에만 배정된다. 이런 규칙은 사소해 보이지만, 실제 운영에서는 중요하다. stage 설계가 모호하면 “업그레이드에서 빠진 prod cluster” 또는 “canary인 줄 알았는데 전체 prod에 가까운 stage”가 생길 수 있기 때문이다.

또 하나 연결해서 볼 변화는 관측성이다. 같은 GKE release notes는 1.34 이상에서 Managed Service for Prometheus가 cAdvisor의 PSI(Pressure Stall Information) metrics를 수집할 수 있다고 설명한다. PSI는 CPU, memory, I/O가 부족해 컨테이너·Pod·node가 얼마나 stall되는지를 보는 신호다. “업그레이드 후 에러율은 안 올랐는데 tail latency가 이상하다” 같은 상황에서, 리소스 압박과 스케줄링 변화를 더 빨리 의심할 수 있다.

즉 2026년의 클러스터 업그레이드 관리는 두 방향으로 움직인다.

1. 업그레이드를 stage로 쪼개서 blast radius를 줄인다.
2. soak time 동안 볼 지표를 더 구체화한다.

4. 개발자 관점 해석

개발자가 이 주제를 배울 때 가장 조심해야 할 오해는 “GKE가 자동 업그레이드해주니 우리 팀이 할 일은 없다”는 생각이다.

관리형 Kubernetes는 control plane과 node upgrade 작업의 많은 부분을 대신해준다. 하지만 제품 관점의 안전성 판단까지 대신해주지는 않는다. GKE가 “업그레이드가 완료됐다”고 말하는 것과, 우리 서비스가 “새 플랫폼 버전 위에서 정상적으로 돈다”는 것은 다른 문장이다.

그래서 rollout sequencing은 자동화를 줄이는 기능이 아니라, 자동화를 운영 정책 안으로 넣는 기능에 가깝다.

작은 팀이라면 아래 세 가지 차이를 분리해서 봐야 한다.

1) Maintenance window와 rollout stage는 다르다

maintenance window는 “언제 바꿔도 되는가”에 가깝다. rollout stage는 “어떤 순서로 위험을 노출할 것인가”에 가깝다. 둘 다 필요하지만 역할이 다르다. 새벽 3시에 전체 production을 한 번에 업그레이드하면, 시간은 조심했지만 blast radius는 줄이지 못한 것이다.

2) Canary는 트래픽 비율만이 아니다

앱 배포에서 canary는 1% 트래픽을 떠올리기 쉽다. 클러스터 업그레이드에서 canary는 “대표성이 있는 작은 클러스터”일 수 있다. 예를 들어 낮은 트래픽 region, 내부 사용자용 cluster, batch worker 전용 cluster, 특정 node pool 조합을 먼저 올려볼 수 있다. 중요한 것은 canary가 production과 너무 다르면 검증 가치가 낮고, 너무 크면 blast radius가 커진다는 점이다.

3) Soak time은 대기 시간이 아니라 검증 계약이다

soak-duration: 604800s라고 적는 순간 7일을 기다리는 것이 전부가 아니다. 그 7일 동안 어떤 SLO, error budget, node pressure, restart count, deployment latency, queue backlog, cost spike를 볼지 정해야 한다. 지표가 없으면 soak는 “아무 일 없기를 바라는 시간”이 된다.

5. 내 프로젝트에 적용할 체크포인트

GKE를 쓰지 않더라도 아래 체크리스트는 Kubernetes 운영 전반에 쓸 수 있다.

• 클러스터를 dev, staging, prod 같은 환경 기준으로만 나누고 있는가, 아니면 production 안의 canary subset도 정의돼 있는가?
• release channel 또는 버전 정책을 문서화했는가? Rapid/Regular/Stable을 어떤 환경에 쓰는지 설명할 수 있는가?
• production 전체 업그레이드 전에 먼저 올릴 “대표성 있는 작은 클러스터”가 있는가?
• stage별 soak time 동안 확인할 지표가 정해져 있는가?
• 업그레이드 후 확인할 deprecated API, admission error, scheduler latency, Pod restart, node pressure, queue backlog, p95/p99 latency가 대시보드에 있는가?
• cluster label이 stage selector로 쓰여도 안전할 만큼 일관되게 관리되는가?
• 업그레이드가 멈췄을 때 누가 pause/resume/cancel 결정을 내리는지 runbook에 적혀 있는가?
• maintenance window와 maintenance exclusion이 rollout stage 설계와 충돌하지 않는가?
• observability 비용을 고려해 필요한 Prometheus metric만 수집하는 정책이 있는가?

특히 metric collection은 조심해야 한다. Google Cloud의 Prometheus metric 수집 문서는 이미 활성화된 GKE metrics package에 들어 있는 metric을 수동으로 다시 수집하면 중복 값이 생길 수 있다고 경고한다. 업그레이드 검증용 지표를 늘릴 때도 “무조건 많이 수집”이 아니라 “soak 판단에 필요한 최소 신호”를 고르는 습관이 필요하다.

6. 오늘 10분 액션

오늘 바로 할 수 있는 실습은 YAML을 만들기 전에 표를 만드는 것이다.

stage | 대상 | label selector | soak | 통과 조건 | 멈춤 조건
1 | dev fleet | 없음 | 2일 | error rate 정상, deprecated API 없음 | control plane/node upgrade 실패
2 | staging fleet | 없음 | 3일 | e2e test/pass, p95 latency 정상 | restart spike, admission error
3 | prod fleet canary | canary=true | 3일 | p99 latency/queue backlog 정상 | SLO burn rate 상승
4 | prod fleet rest | 없음(catch-all) | 7일 | incident 없음 | node pressure/PSI 이상

이 표를 만들면서 세 가지를 확인하라.

1. canary cluster가 실제 production 위험을 대표하는가? 내부 트래픽만 받는 cluster라면 ingress, autoscaling, secret, queue 부하를 검증하지 못할 수 있다.
2. soak 통과 조건이 숫자로 적혀 있는가? “문제 없으면 진행”은 조건이 아니다. 예: 24시간 동안 critical alert 0건, p99 latency 10% 이상 악화 없음, queue backlog baseline 대비 2배 이상 지속 없음.
3. 멈춤 조건이 자동화와 연결돼 있는가? 알림만 울리고 rollout은 계속 진행되면 의미가 없다. 최소한 누가 언제 pause 결정을 내리는지 정해야 한다.

GKE를 쓰는 팀이라면 다음 단계로 custom stages 문서의 예시처럼 RolloutSequence 초안을 만들어볼 수 있다.

- stage:
    fleet-projects:
    - projects/dev
    soak-duration: 172800s
- stage:
    fleet-projects:
    - projects/staging
    soak-duration: 259200s
- stage:
    fleet-projects:
    - projects/prod
    label-selector: resource.labels.canary=='true'
    soak-duration: 259200s
- stage:
    fleet-projects:
    - projects/prod
    soak-duration: 604800s

이 YAML에서 마지막 prod stage는 catch-all 역할을 한다. canary label이 없는 나머지 production cluster가 이 단계로 들어간다.

7. 더 볼 자료

• GKE release notes: 2026년 7월 custom-stage rollout sequencing GA와 PSI metrics 지원 흐름을 확인한다.
• GKE custom stages 개념 문서: RolloutSequence, Rollout, stage, fleet, label selector, soak time의 역할을 다시 본다.
• GKE custom stages how-to: dedicated host project, IAM role, catch-all stage, label selector 제약을 확인한다.
• GKE release channels 문서: Rapid/Regular/Stable/Extended의 버전 도입 속도와 자동 업그레이드 모델을 이해한다.
• GKE Prometheus metric 수집 문서: soak time 동안 볼 지표를 늘릴 때 중복 수집과 비용을 점검한다.

중복 회피 메모

로컬 content/generated와 Supabase 최근 infra_dev 글을 확인했다. 최근 글은 GitHub Linked Artifacts 기반 code-to-cloud traceability, Kubernetes In-place Pod Resize, Terraform state secret, GitHub Actions step-level parallelism, OpenTelemetry semantic convention 카디널리티, RDS delayed replica, GitHub secret scanning triage, Vercel AI Gateway routing, GitHub Actions 보안, Kubernetes Indexed Job 실패 예산, Cloudflare Queues backlog/DLQ를 다뤘다. 이번 글은 Kubernetes를 다시 언급하지만 Pod 리소스 resize나 batch Job 재시도 예산이 아니라, GKE custom-stage rollout sequencing GA를 계기로 클러스터 버전 업그레이드를 canary stage, soak time, release channel, 관측 지표가 붙은 플랫폼 배포로 관리하는 방법에 집중해 중복을 피했다.