이 페이지는 Cloud Translation API를 통해 번역되었습니다.

맞춤 단계가 있는 출시 시퀀싱 정보

Autopilot Standard

출시 시퀀싱을 사용하여 여러 환경에서 Google Kubernetes Engine (GKE) 클러스터의 자동 클러스터 업그레이드 순서를 관리할 수 있습니다. 예를 들어 프로덕션 클러스터를 업그레이드하기 전에 사전 프로덕션 클러스터에서 새 버전을 검증할 수 있습니다. GKE는 맞춤 단계 없이 더 선형적인 모델을 사용하는 출시 시퀀싱의 일반 버전도 제공합니다.

이 문서에서는 사용자가 다음을 알고 있다고 가정합니다.

출시 순서를 구성하려면 클러스터 업그레이드 출시 순서 지정을 참고하세요.

개요

GKE 출시 시퀀싱을 사용하면 개발 환경의 클러스터를 먼저 업그레이드한 다음 테스트 환경, 마지막으로 프로덕션 환경의 클러스터를 업그레이드하는 등 환경 간 클러스터 업그레이드의 특정 순서를 정의할 수 있습니다. 이 점진적 전략은 내장된 베이크 시간을 제공하므로 업그레이드가 가장 중요한 시스템에 도달하기 전에 잠재적인 문제를 발견하고 완화할 수 있습니다.

출시 시퀀싱은 환경 (예: 테스트)에 매핑되는 GKE 클러스터의 논리적 그룹인 Fleet 개념을 기반으로 합니다. 이 기능을 사용하려면 Fleet으로 구성된 시퀀스를 정의하고 각 그룹 간의 적응 시간을 설정합니다. GKE가 새 버전을 선택하면 클러스터가 정의된 순서로 업그레이드되므로 버전이 프로덕션 환경에 완전히 배포되기 전에 워크로드를 검증할 수 있습니다.

Fleet은 경량 멤버십을 지원하며, 이를 사용하면 모든 Fleet 수준 구성과 기능을 사용 설정하지 않고도 출시 시퀀싱을 위해 클러스터를 논리적으로 그룹화할 수 있습니다. 경량 멤버십은 Fleet 수준 네임스페이스 동일성과 같은 전체 Fleet 관리의 다른 영향 없이 출시 시퀀싱을 사용하려는 경우에 적합합니다. 자세한 내용은 경량 멤버십을 참고하세요.

출시 순서 지정 전략 선택

GKE는 두 가지 버전의 출시 시퀀싱을 제공합니다. 두 버전 모두 점진적이고 함대 기반 업그레이드라는 동일한 핵심 원칙을 기반으로 하지만 유연성 수준은 다릅니다. 이 섹션에서는 사용 사례에 가장 적합한 버전을 결정하는 데 도움을 줍니다.

Fleet 기반 출시 시퀀싱 (GA): 이 버전은 정식 버전이며 대부분의 프로덕션 사용 사례에 권장되는 전략입니다. Fleet 기반 출시 시퀀싱은 환경 (예: 테스트, 스테이징, 프로덕션) 전반에 걸쳐 업그레이드를 점진적으로 출시하는 안정적이고 지원되는 방법을 제공하며, 선형 Fleet 시퀀스를 사용합니다.
맞춤 단계가 있는 출시 시퀀싱 (미리보기): 이 버전은 Fleet 기반 모델의 발전된 버전으로, 더 세밀한 제어와 유연성을 제공합니다. 맞춤 단계를 사용하면 라벨을 사용하여 Fleet 내에서 특정 단계를 정의할 수 있으므로 더 광범위한 출시 전에 소규모 프로덕션 클러스터에 새 버전을 배포하는 등 더 복잡한 출시 전략에 적합합니다. 유연성이 더 필요하거나 최신 출시 시퀀싱 기능을 미리 보려면 이 옵션을 선택하세요.

이 문서의 나머지 부분은 맞춤 단계가 있는 출시 순서에만 적용됩니다.

맞춤 단계를 사용한 출시 시퀀싱

맞춤 단계로 출시 순서를 사용하면 차량 업그레이드 순서를 정의하고 소크 시간을 설정합니다. 또한 다음 작업을 수행할 수도 있습니다.

라벨을 사용하여 Fleet 내의 특정 클러스터 하위 집합을 타겟팅할 수 있는 세부 단계로 시퀀스를 정의하여 단계적 출시와 같은 전략에 적합합니다.
새로운 RolloutSequence 및 Rollout API 객체를 통해 더 많은 제어 기능과 관측 가능성을 확보하세요.

이 방법을 사용하면 클러스터 업그레이드를 가장 유연하고 세부적으로 제어할 수 있습니다. Fleet 내의 특정 클러스터 하위 집합을 타겟팅하려면 label-selector를 사용하여 특정 Kubernetes 라벨이 있는 클러스터만 타겟팅합니다.

다음 다이어그램은 GKE가 맞춤 단계를 사용하는 출시 시퀀스에서 클러스터를 자동으로 업그레이드하는 방법을 보여줍니다. 단계는 prod fleet에서 canary이라는 label-selector가 있는 클러스터를 타겟팅합니다.

GKE의 맞춤 단계가 있는 출시 시퀀스 — **그림:** 맞춤 단계가 있는 출시 시퀀스

이 시퀀스의 모든 클러스터가 등록된 출시 채널에서 새 업그레이드 대상을 사용할 수 있게 되면 GKE는 먼저 테스트 Fleet의 클러스터를 업그레이드한 다음 스테이징 Fleet의 클러스터를 업그레이드합니다. 그런 다음 프로덕션 플릿에서 GKE는 label-selector와 일치하는 클러스터에 우선순위를 부여합니다. prod-cluster-1에 canary: true 라벨이 지정되어 있으므로 GKE는 이 클러스터를 다음에 업그레이드합니다. 이 단계에는 라벨 선택기가 없으므로 GKE는 프로세스가 끝날 때 프로덕션 Fleet (Main 단계)의 나머지 모든 클러스터를 업그레이드합니다.

단계 간에 구성된 적응 시간 동안 업그레이드된 클러스터에서 워크로드가 예상대로 실행되는지 확인할 수 있습니다. 위의 예에서는 프로덕션 Fleet에 하나의 맞춤 단계를 보여주지만, Fleet에 여러 단계를 추가하거나 여러 단계가 있는 하나의 Fleet만 사용할 수 있습니다.

주요 개념

소크 시간: 이 기간은 단계의 모든 클러스터가 업그레이드된 후 발생하는 구성 가능한 대기 기간입니다. 이 베이킹 시간을 통해 한 환경에서 새 버전을 검증하고 업그레이드가 다음 환경으로 진행되기 전에 잠재적인 문제를 포착할 수 있습니다. 시퀀스의 각 단계에 최대 30일의 소크 시간을 구성할 수 있습니다. 사전 프로덕션 단계에서 더 긴 소크 시간을 사용하면 검증에 더 많은 시간을 할애할 수 있습니다.
RolloutSequence: 업그레이드 시퀀스를 정의하는 데 사용하는 기본 리소스입니다. RolloutSequence에는 순서가 지정된 일련의 단계가 포함되어 있으며, 업그레이드가 다음 단계로 진행되기 전에 이전 단계의 클러스터가 완전히 업그레이드되고 적응 기간이 완료되었는지 확인합니다.
Rollout: 이 객체를 사용하면 시퀀스를 통해 단일 버전 업그레이드의 진행 상황을 관찰할 수 있습니다. Rollout를 사용하여 출시 상태를 확인하고, 진행 상황을 추적하고, 클러스터가 업그레이드 대상이 아닌지 여부와 그 이유를 확인할 수 있습니다.
전용 호스트 프로젝트: 전용 Google Cloud프로젝트를 사용하여 RolloutSequence 객체를 호스팅하는 것이 좋습니다. 전용 프로젝트에 시퀀스를 배치하면 출시 시퀀스를 위한 중립적인 중앙 제어 지점이 제공되며 이는 CI/CD 파이프라인을 관리하기 위한 권장사항과 유사합니다.

권장사항:

전용 호스트 프로젝트에서 RolloutSequence 리소스를 만들고 관리합니다.

단계: 단계는 출시 시퀀스의 단계입니다. 각 단계에는 함께 업그레이드되는 클러스터 그룹이 포함됩니다.
Fleet: Fleet은 클러스터를 그룹화하는 기본 방법입니다. 출시 시퀀스의 단계는 하나의 Fleet만 참조할 수 있습니다.
라벨 선택기: 출시 시퀀스는 하나 이상의 단계로 구성됩니다. 각 단계에는 하나의 Fleet의 클러스터가 포함되며, 클러스터에서 라벨 선택기를 사용하여 Fleet을 여러 단계로 추가로 분할할 수 있습니다. 이 접근 방식을 사용하면 프로덕션 클러스터의 작은 하위 집합이 먼저 업그레이드되는 단계적 출시와 같은 전략을 사용할 수 있습니다.

GKE가 출시 시퀀스에서 클러스터를 업그레이드하는 방법

GKE가 클러스터를 업그레이드할 때 먼저 제어 영역이 업그레이드된 후 노드가 업그레이드됩니다. 출시 시퀀스에서는 이 프로세스를 사용하여 클러스터가 계속 업그레이드되지만 클러스터의 그룹 (Fleet)이 업그레이드되는 순서도 제어합니다. 또한 한 그룹에서 다음 그룹으로 업그레이드가 진행되기 전에 GKE가 일시중지되는 시간을 정의하는 적응 시간을 지정합니다.

출시 시퀀스의 클러스터 업그레이드는 다음 단계로 진행됩니다.

GKE는 특정 출시 채널의 부 버전 클러스터에 새로운 자동 업그레이드 대상을 설정하며, 출시 노트는 다음 메시지와 유사합니다. '이번 출시를 통해 일반 채널에서 자동 업그레이드가 사용 설정된 컨트롤 플레인과 노드가 버전 1.29에서 버전 1.30.14-gke.1150000으로 업그레이드됩니다.'
GKE는 첫 번째 클러스터 그룹에서 클러스터 제어 영역을 새 버전으로 업그레이드하기 시작합니다. GKE가 클러스터의 제어 영역을 업그레이드한 후 클러스터의 노드 업그레이드를 시작합니다. GKE는 출시 시퀀스에서 클러스터를 업그레이드할 때 유지보수 가용성을 고려합니다.
GKE는 컨트롤 플레인 업그레이드를 위해 다음 단계를 수행합니다.
1. 첫 번째 그룹의 모든 클러스터 제어 영역 업그레이드가 완료되면 GKE는 제어 영역 업그레이드의 적응 기간을 시작합니다. 제어 영역 업그레이드가 시작된 후 30일이 지나면 GKE는 적응 기간을 시작합니다.
2. 첫 번째 그룹의 클러스터 제어 영역 업그레이드의 적응 기간이 완료되면 GKE는 두 번째 그룹의 제어 영역을 새 버전으로 업그레이드하기 시작합니다. 하지만 다음 사항에 유의하세요.
  - 경우에 따라 GKE는 두 번째 그룹의 클러스터 컨트롤 플레인을 업그레이드하기 전에 첫 번째 그룹의 클러스터 컨트롤 플레인을 여러 번 업그레이드할 수 있습니다. 이러한 상황이 발생하면 GKE는 다음 속성도 있는 최신 버전을 선택합니다.
    - 버전은 첫 번째 그룹에 의해 검증됩니다.
    - 버전은 두 번째 그룹 클러스터의 컨트롤 플레인 버전보다 최대 1개 마이너 버전이 높습니다.
  - GKE는 첫 번째 그룹에서 검증한 자동 업그레이드 대상보다 버전이 최신인 두 번째 그룹의 클러스터 제어 영역을 업그레이드하지 않습니다.
GKE는 컨트롤 플레인 업그레이드와 동시에 노드 업그레이드를 위해 다음 단계를 수행합니다.
1. 첫 번째 그룹의 모든 클러스터 노드 업그레이드가 완료되면 GKE가 노드 업그레이드의 적응 기간을 시작합니다. 노드 업그레이드가 시작된 후 30일이 지나면 GKE에서도 적응 기간을 시작합니다.
2. 첫 번째 그룹의 노드 업그레이드 적응 기간이 완료되면 GKE는 두 번째 그룹의 노드를 새 버전으로 업그레이드하기 시작합니다. 단, 다음 사항을 고려하세요.
  - 경우에 따라 GKE는 두 번째 그룹의 클러스터 노드를 업그레이드하기 전에 첫 번째 그룹의 클러스터 노드를 여러 번 업그레이드할 수 있습니다. 이러한 상황이 발생하면 GKE는 다음 속성도 있는 최신 버전을 선택합니다.
    - 버전은 첫 번째 그룹에 의해 검증됩니다.
    - 버전이 두 번째 그룹의 클러스터 컨트롤 플레인 버전보다 최신이 아닙니다.
  - GKE는 첫 번째 그룹에서 검증한 자동 업그레이드 대상보다 버전이 최신인 두 번째 그룹의 클러스터 노드를 업그레이드하지 않습니다.
GKE는 출시 시퀀스의 모든 그룹에 있는 클러스터가 새 업그레이드 대상으로 업그레이드될 때까지 두 번째 그룹에서 세 번째 그룹으로 이러한 단계를 반복합니다.

각 그룹에서 클러스터가 업그레이드되는 동안 적응 시간 동안 새 GKE 버전을 실행하는 클러스터로 워크로드가 예상대로 작동하는지 확인합니다 .

유지보수 기간이나 유지보수 제외, 지원 중단된 API 사용 또는 기타 이유로 인해 클러스터가 업그레이드되지 않을 수도 있습니다.

출시 시퀀스에서 업그레이드를 제어하는 방법

출시 시퀀스에서 클러스터 업그레이드를 사용하면 클러스터 그룹이 정의된 순서대로 업그레이드되고 선택한 기간 동안 각 그룹에 적응됩니다. 업그레이드가 진행되는 동안 필요에 따라 상태를 확인하고 출시 시퀀스를 관리할 수 있습니다. 다음과 같은 방법으로 프로세스를 제어할 수도 있습니다.

출시 시퀀스 내 그룹의 기본 적응 시간을 수정할 수 있습니다. 이는 테스트를 통해 특정 버전에 더 많거나 적은 적응 시간이 필요한 것으로 밝혀진 경우에 유용합니다. 이 변경사항은 수정 후 생성된 모든 현재 및 향후 출시 (모든 버전)의 기본 soak 시간을 업데이트합니다.

개별 클러스터 업그레이드의 경우 다음 도구를 계속 사용할 수 있습니다.
- 노드 풀 업그레이드를 취소, 재개, 롤백 또는 완료하는 등의 작업을 수행하여 업그레이드를 수동으로 제어합니다.
- 유지보수 기간 및 유지보수 제외를 사용하여 클러스터의 업그레이드 가능 시기를 결정합니다.
- 이러한 노드에서 실행되는 워크로드에 따라 속도와 위험 허용 범위 간의 균형을 맞추도록 노드 업그레이드 전략을 구성합니다.

예시: 지역 은행이 테스트에서 프로덕션으로 변경사항을 점진적으로 출시

지역 은행의 플랫폼 관리자는 세 가지 기본 배포 환경(테스트, 스테이징, 프로덕션)을 관리합니다. 프로덕션 클러스터는 중요도 수준이 다양한 여러 리전에 분산되어 있습니다. 업그레이드를 효과적으로 관리하기 위해 관리자는 각 환경의 클러스터를 Fleet으로 그룹화합니다. 출시 시퀀싱에 필요한 대로 세 가지 Fleet 전반에서 각 클러스터가 동일한 출시 채널(이 경우 일반 채널)에 등록되어 있으며 모든 클러스터가 동일한 부 버전을 실행합니다.

관리자의 주요 목표는 은행의 중요한 프로덕션 환경에 도달하기 전에 새 GKE 버전을 철저히 검증하는 것입니다. 또한 트래픽이 적은 리전의 클러스터를 먼저 점진적으로 업그레이드한 다음 트래픽이 많은 리전으로 이동하고 마지막으로 가장 중요한 리전으로 이동하려고 합니다. 이를 위해 커스텀 단계가 포함된 출시 시퀀싱을 사용하여 지역에 따라 프로덕션 클러스터에 라벨을 지정하는 점진적 업그레이드 전략을 정의합니다. 이 방법을 사용하면 전체 출시 전에 프로덕션 트래픽의 작은 하위 집합에서 새 버전을 검증할 수 있습니다.

이 계획을 구현하기 위해 관리자는 프로덕션 Fleet의 클러스터에 다음 라벨을 적용합니다.

us-west1 (트래픽이 적음)의 클러스터에는 prod-region: us-west1 라벨이 지정됩니다.
europe-west1 (트래픽이 더 많음)의 클러스터에는 prod-region: europe-west1 라벨이 지정됩니다.
us-east1 (가장 중요한 트래픽)의 클러스터에는 라벨이 지정되지 않습니다. 시퀀스 내의 Fleet의 최종 단계는 나머지 모든 클러스터의 '모두'로 작동해야 합니다. 따라서 관리자는 이러한 나머지 클러스터에 라벨을 추가할 필요가 없습니다.

그런 다음 CI/CD 구성을 관리하는 데 사용되는 전용 호스트 프로젝트에서 RolloutSequence 객체를 정의합니다. 이 새로운 시퀀스는 다음과 같은 5가지 단계로 구성됩니다.

테스트: 이 단계에는 testing Fleet의 모든 클러스터가 포함됩니다. 관리자는 철저한 검증을 위해 3일의 적응 시간을 설정합니다.
스테이징: 이 단계에는 staging 차량의 모든 클러스터가 포함되며 3일의 소크 시간이 있습니다.
us-west1 리전의 프로덕션: 이 단계는 프로덕션 플릿을 타겟팅하지만 label-selector을 사용하여 prod-region: us-west1 라벨이 있는 클러스터만 포함합니다. 이 단계에서는 관리자가 3일간의 소킹 시간을 통해 프로덕션 클러스터의 작은 하위 집합에서 문제를 모니터링할 수 있습니다.
europe-west1 리전의 프로덕션: 이 단계에는 prod-region: europe-west1 라벨이 있는 production Fleet의 클러스터가 포함됩니다. 관리자는 더 철저한 검증을 위해 적응 시간을 4일로 더 길게 설정합니다.
us-east1 리전의 프로덕션: 이 최종 단계에는 production Fleet의 나머지 클러스터, 즉 us-east1의 모든 클러스터가 포함됩니다.

이 접근 방식을 사용하면 관리자가 프로덕션 업그레이드를 세부적으로 제어할 수 있으므로 전체 프로덕션 환경에 영향을 미치기 전에 잠재적인 문제를 포착하여 업그레이드 프로세스의 안전성과 안정성을 크게 개선할 수 있습니다.

정기 패치 업그레이드 중에 은행의 자동 테스트가 스테이징 환경에서 예상보다 훨씬 빠르게 완료됩니다. 관리자는 새 버전이 안정적이라고 판단하고 스테이징 Fleet 업그레이드 후 3일간의 적응 시간이 이러한 유형의 루틴 업데이트에 불필요하게 길다고 결정합니다.

이 출시를 가속화하기 위해 관리자는 RolloutSequence 정의를 수정하고 프로덕션 함대의 us-west1 단계의 소크 기간을 줄입니다. RolloutSequence 정의가 변경되면 현재 및 향후 모든 출시의 기본 흡수 시간이 업데이트되므로 관리자는 이 특정 패치 출시가 완료된 후 흡수 시간을 원래 3일 기간으로 되돌려야 합니다. 이 접근 방식을 사용하면 향후 부 버전 업그레이드 시 표준의 더 신중한 소크 시간이 적용됩니다.

관리자는 유지보수 기간 및 제외를 사용하여 은행 업무 중단을 최소화할 수 있는 기간에 GKE가 클러스터를 업그레이드하도록 합니다. GKE는 출시 시퀀스에서 업그레이드된 클러스터에 대해 유지보수 가용성을 고려합니다.

GKE가 영업시간 이후에만 클러스터를 업그레이드하도록 관리자가 클러스터의 유지보수 기간을 구성했습니다.
또한 관리자는 유지보수 제외를 사용하여 클러스터 워크로드에 대한 문제가 감지되면 클러스터가 일시적으로 업그레이드되지 않도록 방지합니다.

관리자는 노드에 일시 급증 업그레이드와 블루/그린 업그레이드를 함께 사용하여 이러한 노드에서 실행되는 워크로드에 따라 속도와 위험 허용 범위 간의 균형을 맞춥니다.

출시 자격요건

맞춤 단계를 사용하여 시퀀스를 통해 버전을 출시하려면 클러스터가 출시 채널에서 업그레이드 대상이 될 수 있어야 합니다. 새 GKE 버전을 사용할 수 있게 되면 시퀀스의 클러스터가 새 버전을 사용할 수 있는 경우 시스템에서 Rollout 객체를 만듭니다. 모든 클러스터를 동일한 출시 채널에 등록하는 것이 좋지만, 그렇지 않은 경우 GKE는 시퀀스에서 가장 보수적인 채널의 버전을 선택합니다. 예를 들어 안정화 버전 채널과 일반 채널이 혼합된 클러스터의 경우 GKE는 안정화 버전 채널의 버전을 선택합니다.

그러면 Rollout가 RolloutSequence에 정의된 단계를 진행합니다. 지정된 단계 내에서 컨트롤 플레인 출시와 노드 풀 출시는 동시에 실행될 수 있습니다. 이 진행을 관리하는 주요 규칙은 단계가 특정 버전으로 SOAKING 상태에 있는 동안 단계가 최신 버전의 새로운 Rollout를 시작할 수 없다는 것입니다. 이렇게 하면 다음 업그레이드가 시작되기 전에 버전을 완전히 검증할 수 있습니다. 출시 객체를 모니터링하여 각 클러스터의 진행 상황과 자격 요건을 확인할 수 있습니다. 클러스터가 부적격하게 만드는 버전 불일치가 발견되면 시퀀스를 진행하기 위해 클러스터를 수동으로 업그레이드하는 등의 조치를 취해야 할 수 있습니다. 클러스터가 출시 대상이 아닌 경우 GKE는 현재 버전이 지원 종료에 도달할 때까지 클러스터를 자동으로 업그레이드하지 않습니다.

업그레이드 대상보다 최신 버전을 실행하는 클러스터는 업그레이드를 방지하지 않습니다.

시퀀스의 단계에 출시의 대상 버전보다 최신 버전을 실행하는 클러스터가 포함된 경우 GKE는 대상 버전에 적합한 클러스터를 업그레이드하고 이미 최신 버전을 사용하는 클러스터는 무시합니다. 이 동작은 출시 시퀀스가 다음 단계로 진행되는 것을 방지하지 않습니다.

예를 들어 단계의 출시 대상 버전이 1.32이고 해당 단계에 1.31과 1.33을 모두 실행하는 클러스터가 있는 경우 GKE는 1.31 버전의 클러스터를 1.32로 업그레이드하고 이미 1.33 버전인 클러스터는 무시합니다.

이전 단계에서 다음 단계의 업그레이드 타겟을 여러 개 충족했습니다.

시퀀스의 이전 단계에서 여러 새 버전의 출시를 완료할 수 있지만 후속 단계는 일시중지되거나 (예: 유지보수 제외) 이전 업그레이드를 아직 처리하고 있습니다. 이 경우 후속 스테이지가 새 업그레이드를 수락할 준비가 되면 GKE는 스테이지를 검증된 최신 버전으로 업그레이드합니다. 컨트롤 플레인 업그레이드의 경우 이 버전은 후속 단계의 클러스터 컨트롤 플레인 버전보다 최대 1개 부 버전이 늦을 수 있습니다. 노드 업그레이드의 경우 이 버전은 후속 단계의 클러스터 컨트롤 플레인 버전과 같을 수 있지만 그보다 늦을 수는 없습니다.

예를 들어 프로덕션 클러스터의 업그레이드를 일시적으로 방지하기 위해 유지보수 제외를 구성한 경우 이 시나리오가 관련됩니다. 사전 프로덕션 클러스터에 동일한 유지보수 제외가 없으면 이러한 클러스터가 여러 번 업그레이드되어 여러 새 버전이 적합할 수 있지만 프로덕션 단계는 업그레이드되지 않습니다.

30일 후 강제 적응

출시 시퀀스에서 클러스터 업그레이드를 완료하도록 지원하기 위해 GKE는 최대 업그레이드 시간 (30일) 내에 모든 클러스터에서 각각 컨트롤 플레인 또는 노드 업그레이드가 완료되지 않으면 그룹의 적응 기간을 시작합니다. 그룹의 나머지 클러스터에 대한 업그레이드는 소킹 기간 동안 계속될 수 있습니다.

다른 업그레이드 기능에서 출시 시퀀싱의 작동 방식

출시 시퀀싱은 다른 GKE 업그레이드 기능과 함께 작동합니다.

유지보수 기간 및 유지보수 제외: 유지보수 기간 및 유지보수 제외를 사용하여 클러스터에서 업그레이드가 가능한 시기와 불가능한 시기를 제어할 수 있습니다. GKE는 클러스터의 유지보수 기간 내에서만 클러스터 업그레이드를 시작합니다. 유지보수 제외를 사용하여 클러스터가 일시적으로 업그레이드되지 않게 할 수 있습니다. GKE가 유지보수 기간 또는 제외로 인해 클러스터를 업그레이드할 수 없는 경우 이로 인해 스테이지에서 클러스터 업그레이드가 완료되지 않을 수 있습니다. 유지보수 기간 또는 제외로 인해 클러스터 업그레이드를 30일 이내에 완료할 수 없는 경우 모든 클러스터가 업그레이드를 완료했는지 여부에 관계없이 단계가 적응 단계에 들어갑니다. 제어 영역 및 노드 풀 출시를 지정된 단계 내에서 동시에 실행할 수 있습니다.
노드 업그레이드 전략: 출시 시퀀싱은 구성된 노드 업그레이드 전략(예: 블루-그린 업그레이드)에 영향을 주지 않습니다. 출시 시퀀싱이 없는 클러스터 업그레이드와 마찬가지로 GKE는 Autopilot 노드에 대해 일시 급증 업그레이드를 사용합니다. 자세한 내용은 노드 자동 업그레이드를 참고하세요.

노드 업그레이드를 30일 이내에 완료할 수 없으면 그룹이 모든 클러스터 업그레이드를 완료했는지 여부에 관계없이 적응 단계에 들어갑니다. 특히 큰 노드 풀에서 노드 업그레이드 전략으로 인해 표준 클러스터의 노드 업그레이드가 완료되는 데 시간이 오래 걸리는 경우 이러한 상황이 발생할 수 있습니다. 또한 노드 업그레이드가 완료되기에 유지보수 기간이 충분히 길지 않은 경우 악화될 수 있습니다.
출시 채널: 출시 시퀀스의 모든 클러스터를 동일한 출시 채널에 등록하는 것이 좋습니다.
지원 중단 사용 감지: GKE의 지원 중단 사용 감지는 여전히 예상대로 작동하며 지원 중단된 API를 사용하는 클러스터의 업그레이드를 일시중지할 수 있습니다.
수동 업그레이드: 시퀀스의 첫 번째 단계에서 클러스터를 수동으로 업그레이드하는 것만으로는 해당 버전을 검증하거나 출시를 트리거하여 진행할 수 없습니다. 자동 출시 프로세스는 출시 채널에 설정된 공식 자동 업그레이드 타겟에 따라 진행됩니다. 수동 업그레이드는 클러스터를 업데이트하지만, 해당 버전이 지정된 자동 업그레이드 대상이 된 후에만 시퀀스가 진행되기 시작합니다.

시퀀스에서 여러 업그레이드 수신

출시 채널은 클러스터의 업그레이드 타겟을 선택합니다. 이전 대상에 대한 업그레이드가 아직 진행 중인 동안 새 버전을 사용할 수 있게 되면 후반 단계에서 이전 업그레이드를 계속 수신하는 경우에도 첫 번째 단계에서 새 버전의 출시를 시작할 수 있습니다. 예를 들어 시퀀스의 세 번째 그룹이 버전 1.31.12-gke.1265000으로 출시되는 경우 시퀀스의 첫 번째 그룹에서 버전 1.31.13-gke.1008000을 동시에 출시할 수 있습니다.

출시 시퀀싱 선택 시 고려사항

새 버전을 출시하기 전에 한 환경에서 새 버전을 검증하여 클러스터 업그레이드를 관리하려면 출시 시퀀싱을 사용하는 것이 좋습니다.

하지만 다음 중 하나라도 해당하는 경우 환경에 적합하지 않을 수 있습니다.

동일 프로덕션 환경에서 동일한 출시 채널 또는 부 버전에 없는 클러스터가 있습니다.
한 그룹의 클러스터가 자동 업그레이드 대상 버전을 다르게 지정하게 하는 수동 업그레이드를 자주 수행합니다.

제한사항

맞춤 단계로 출시 시퀀싱을 사용하여 클러스터를 업그레이드할 때는 다음 제한사항이 적용됩니다.

Google Cloud 콘솔을 사용하여 맞춤 단계가 있는 출시 시퀀스를 만들거나 볼 수 없습니다.
출시 시퀀스에서 Fleet을 참조하는 경우 전체 Fleet을 포함해야 합니다. 이 제약 조건은 label-selector를 사용하여 Fleet의 일부 클러스터만 타겟팅하는 단계를 정의하는 경우 (예: 단계별 배포) 동일한 Fleet의 나머지 모든 클러스터를 포함하는 후속 '모두' 단계도 정의해야 함을 의미합니다. 이 포괄적 단계는 동일한 Fleet을 타겟팅하지만 label-selector를 포함하지 않으므로 시퀀스의 이전 단계에서 선택되지 않은 모든 클러스터를 자동으로 포함합니다.
출시 중에 시퀀스를 수정하는 경우, 특히 참여 클러스터에 영향을 미치는 변경사항이 있는 경우 GKE는 기존 출시를 모두 즉시 취소합니다. 시퀀스의 soak time만 수정하면 GKE에서 출시를 취소하지 않습니다.
특정 버전의 활성 출시를 수동으로 가속화할 수는 없습니다. 출시 시퀀스 정의에서 soak 기간을 수정하면 변경사항이 수정 후 생성된 모든 현재 및 향후 출시의 기본 soak 시간에 업데이트됩니다.
GKE는 지원 종료에 도달한 클러스터를 지원되는 버전으로 자동 업그레이드하며, 이 업그레이드는 정의된 출시 순서를 따르지 않을 수 있습니다.
스테이지는 최대 하나의 Fleet을 참조할 수 있습니다. 단일 스테이지에 여러 플릿이 있을 수 없습니다.
단일 Fleet은 하나의 출시 시퀀스에서만 참조할 수 있습니다. 두 출시 시퀀스가 동일한 플릿을 참조할 수 없습니다.

알려진 문제

이 섹션에서는 맞춤 단계가 있는 출시 순서 지정의 알려진 문제를 간략하게 설명합니다.

출시 시퀀스의 단계에 클러스터가 포함되어 있지 않으면 해당 단계는 건너뛰지만 해당 단계에 정의된 흡수 시간은 출시가 다음 단계로 진행되기 전에 계속 경과합니다.

다음 단계

맞춤 단계로 클러스터 업그레이드 출시 순서 지정