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

출시 시퀀싱으로 클러스터 업그레이드에 관한 정보

Autopilot Standard

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

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

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

개요

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

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

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

출시 순서 지정 전략 선택

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

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

Fleet 기반 출시 시퀀스

출시 시퀀싱으로 클러스터를 자동으로 업그레이드하려면 동일한 출시 채널 및 부 버전이 있는 클러스터를 배포 단계로 그룹화한 Fleet을 사용합니다. Fleet 시퀀스와 각 클러스터 그룹 간에 원하는 적응 시간을 정의합니다. 그런 다음 GKE가 출시 채널에서 자동 업그레이드에 사용할 새 버전을 선택하면 클러스터 그룹이 정의된 순서로 업그레이드되며 개발자는 업그레이드가 프로덕션 클러스터와 함께 시작되기 전에 워크로드가 새 버전에서 예상대로 실행되는지 확인할 수 있습니다.

다음 다이어그램은 GKE가 Fleet로 정리된 출시 시퀀스에 따라 클러스터를 자동으로 업그레이드하는 방법을 보여줍니다.

클러스터를 Fleet으로 그룹화하는 Fleet 기반 출시 시퀀스입니다. — **그림:** Fleet 기반 출시 시퀀스

함대 기반 시퀀스를 사용하면 GKE가 이 시퀀스의 모든 클러스터가 등록된 출시 채널에서 새 업그레이드 대상을 제공할 때 GKE는 이 시퀀스에서 이러한 클러스터 함대를 업그레이드합니다. 업스트림 함대의 클러스터는 최대 5개의 함대에 대해 다운스트림 함대의 클러스터에 대한 새 버전을 검증합니다. 출시 시퀀스에서 업스트림은 이전 그룹을 참조하고 다운스트림은 다음 그룹을 참조합니다.

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만 사용할 수 있습니다.

맞춤 단계를 사용한 출시 순서에 대한 자세한 내용은 맞춤 단계를 사용한 출시 순서 정보를 참고하세요.

이 문서의 나머지 부분은 플릿 기반 출시 순서에만 적용됩니다.

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 사용 또는 기타 이유로 인해 클러스터가 업그레이드되지 않을 수도 있습니다.

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

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

출시 시퀀스의 그룹의 경우 특정 버전에 대해 어느 정도의 적응 시간이 필요한 경우 기본 적응 시간을 재정의할 수 있습니다.

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

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

예를 들어 지역 은행의 플랫폼 관리자는 세 가지 기본 배포 환경(테스트, 스테이징, 프로덕션)을 관리합니다. 각 환경에는 Fleet으로 구성된 클러스터 그룹이 있습니다. 출시 시퀀싱에 필요한 대로 관리자는 동일한 출시 채널(해당 Fleet에서는 일반 채널)의 세 가지 Fleet 전반에서 각 클러스터를 등록했으며 모든 클러스터가 동일한 부 버전을 실행합니다.

관리자는 출시 시퀀싱을 사용하여 이러한 환경에서 GKE가 클러스터를 업그레이드하는 순서를 정의합니다. 출시 순서를 지정하면 관리자에게 프로덕션 환경이 새 버전으로 업그레이드되기 전에 새 버전의 GKE에 있는 클러스터에서 워크로드가 예상대로 실행되는지 확인할 수 있습니다. 이 시퀀스는 Fleet 기반 출시 시퀀스 다이어그램에 나와 있습니다.

관리자는 Fleet 간의 적응 시간을 사용하여 워크로드가 새 버전의 GKE에서 예상대로 실행되는지 확인합니다. 테스트 Fleet의 경우 관리자는 2주 동안 워크로드 실행 방식을 테스트할 수 있도록 적응 시간을 14일로 설정합니다. 스테이징의 경우 워크로드가 이미 테스트에서 실행된 후 추가 시간이 많이 필요하지 않으므로 적응 시간을 7일로 설정합니다.

관리자는 다음 상황 중 하나에서 수행할 수 있는 특정 버전으로의 업그레이드 기본 적응 시간을 재정의할 수도 있습니다.

관리자는 적응 시간이 완료되기 전에 버전 검증을 완료하고 다음 Fleet으로 업그레이드를 진행하려고 하므로 적응 시간을 0으로 설정합니다.
관리자가 일부 워크로드에서 문제를 발견하여 업그레이드를 진행하기 전에 새 버전을 검증하는 데 시간이 더 필요하므로 적응 시간을 최대 30일로 설정합니다.

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

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

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

Fleet 기반 출시 자격 요건

출시 시퀀싱으로 클러스터를 자동으로 업그레이드하려면 출시 시퀀스의 모든 Fleet에 있는 모든 클러스터가 동일한 업그레이드 대상을 수신해야 합니다. 클러스터는 동일한 출시 채널에 등록되어야 하며 업그레이드 대상이 부 버전별로 설정되었으므로 클러스터는 동일한 부 버전을 실행하는 것이 좋습니다. 그러나 다음 예시의 출시와 같은 일부 출시의 경우 여러 부 버전의 클러스터가 동일한 대상을 수신했습니다. 즉, 여러 부 버전을 실행하는 출시 시퀀스에서 클러스터가 성공적으로 업그레이드될 수 있습니다.

시퀀스의 버전 출시 상태를 확인하여 상태에 대한 자세한 정보와 버전 자격요건 문제로 인해 업그레이드가 진행되지 않는지 확인할 수 있습니다. 버전 불일치에 따라서는 진행하기 위해 수동으로 클러스터를 업그레이드하거나 클러스터 업그레이드 그룹에서 삭제하는 등의 작업을 수행해야 할 수 있습니다. 출시 시퀀스의 클러스터에 적격한 업그레이드 대상이 없는 경우 GKE는 클러스터의 기존 마이너 버전이 지원 종료에 도달할 때까지 클러스터를 자동 업그레이드하지 않습니다.

출시 자격요건 문제를 해결하려면 출시 자격요건 문제 해결을 참조하세요.

GKE 출시 버전 예시

예를 들어 2025-R45 출시 버전은 일반 채널에 등록된 클러스터의 여러 부 버전에 대한 업그레이드 대상을 설정합니다. 업그레이드 대상은 새로운 부 버전 (1.30~1.31)이거나 새 패치 버전 (1.31.x-gke.x~1.31.13-gke.1023000)일 수 있습니다. 이 출시 버전의 일반 채널에서는 특정 부 버전의 클러스터에 대해 다음과 같은 새 버전을 사용할 수 있게 되었습니다.

1.30 버전의 클러스터가 1.31.13-gke.1023000으로 업그레이드되었습니다.
1.31 버전의 클러스터가 1.32.9-gke.1108000으로 업그레이드되었습니다.
1.32 버전의 클러스터가 1.33.5-gke.1162000으로 업그레이드되었습니다.

최상위 업스트림 그룹이 모든 업그레이드 대상 수신

새 버전을 검증할 수 있는 업스트림 그룹이 없는 시퀀스의 첫 번째 그룹의 클러스터의 경우 GKE는 이러한 업그레이드 대상이 서로 다른지 여부에 관계없이 적격한 업그레이드 대상으로 모든 클러스터를 업그레이드합니다. 예를 들어 시퀀스의 첫 번째 그룹에서 일부 클러스터가 1.30을 실행 중인 경우 해당 클러스터를 1.31.13-gke.1023000으로 업그레이드하고 1.32를 실행하는 클러스터를 1.33.5-gke.1162000으로 업그레이드할 수 있습니다. 이는 시퀀스의 첫 번째 그룹의 경우 새 버전을 검증할 업스트림 그룹이 없으므로 GKE가 모든 업그레이드 대상을 이러한 클러스터에 대해 자격을 갖춘 것으로 간주하기 때문입니다.

업스트림 그룹은 한 버전만 검증해야 함

다운스트림 그룹의 클러스터가 업그레이드를 시작하려면 업스트림 그룹이 다운스트림 그룹의 모든 클러스터가 요건을 충족하는 단일 공통 업그레이드 대상을 검증해야 합니다. 업스트림 그룹에 두 가지 다른 버전으로 성공적으로 업그레이드된 클러스터가 있는 경우 (업스트림 그룹이 시퀀스의 첫 번째 그룹인 경우 발생할 수 있음) 업스트림 그룹은 두 버전 중 낮은 버전을 다운스트림 그룹의 공통 업그레이드 대상으로 검증합니다. 예를 들어 업스트림 그룹에 1.31.13-gke.1023000으로 업그레이드된 클러스터와 1.33.5-gke.1162000으로 업그레이드된 클러스터가 있는 경우 그룹은 1.31.13-gke.1023000을 다운스트림 그룹의 공통 업그레이드 대상으로 검증합니다.

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

다운스트림 그룹에 업스트림 그룹에서 검증한 업그레이드 대상보다 최신 버전을 실행하는 클러스터가 있는 경우 GKE는 업그레이드 대상의 요건을 충족하는 클러스터를 업그레이드하고 이미 최신 버전을 사용하는 클러스터는 무시합니다. 다운스트림 그룹의 클러스터 중 하나 이상이 업그레이드 대상에 적합한 경우 이 동작으로 인해 출시 시퀀스가 진행되지 않는 일은 없습니다.

예를 들어 업스트림 그룹에서 1.32로의 업그레이드를 검증했고 다운스트림 그룹에 1.31과 1.33을 실행하는 클러스터가 있는 경우 GKE는 1.31을 실행하는 클러스터를 1.32로 업그레이드하고 1.33을 실행하는 클러스터는 무시합니다.

업스트림 그룹은 다음 그룹의 클러스터와 일치하는 버전을 검증해야 함

업스트림 그룹의 클러스터가 다음 그룹의 클러스터가 요건을 충족하는 버전과 다른 버전을 검증한다면 GKE는 다운스트림 그룹의 클러스터를 자동으로 업그레이드할 수 없습니다.

예를 들어 첫 번째 그룹의 모든 클러스터가 1.31.13-gke.1023000으로 업그레이드되었지만 두 번째 그룹의 클러스터가 1.32.9-gke.1108000과 같은 최신 버전을 실행 중인 경우 두 번째 그룹의 클러스터는 자동으로 업그레이드되지 않습니다. 첫 번째 그룹은 1.31.13-gke.1023000을 검증했지만 두 번째 그룹의 클러스터 (현재 1.32)는 업그레이드 대상 1.33.5-gke.1162000만 충족하므로 GKE는 이러한 클러스터를 자동으로 업그레이드할 수 없습니다. 이 상황에서 업그레이드를 진행하려면 그룹 간 자격요건 수정을 참고하세요.

업스트림 그룹이 다운스트림 그룹의 여러 업그레이드 대상을 검증했습니다.

다운스트림 그룹의 클러스터를 업그레이드하기 전에 GKE가 업스트림 그룹의 클러스터를 여러 번 업그레이드한 경우 GKE는 다운스트림 그룹의 클러스터를 업스트림 그룹에서 검증하고 다운스트림 그룹의 클러스터가 요건을 충족하는 최신 버전으로 업그레이드합니다. 컨트롤 플레인 업그레이드의 경우 이 버전은 다운스트림 그룹의 클러스터 컨트롤 플레인 버전보다 최대 1개 마이너 버전까지 높을 수 있습니다. 노드 업그레이드의 경우 이 버전은 다운스트림 그룹의 클러스터 컨트롤 플레인 버전과 같을 수 있지만 그보다 늦을 수는 없습니다.

예를 들어 프로덕션 클러스터를 포함한 다운스트림 그룹의 업그레이드를 일시적으로 방지하기 위해 유지보수 제외를 구성한 경우 이 시나리오가 관련됩니다. 하지만 사전 프로덕션 클러스터를 포함하는 업스트림 그룹에서는 업그레이드를 방지하기 위해 유지보수 제외를 사용하지 않았습니다. 따라서 업스트림 그룹은 여러 번 업그레이드되어 잠재적인 업그레이드 대상이 여러 개 있지만 다운스트림 그룹은 업그레이드되지 않았습니다.

30일 이내에 완료되지 않은 업그레이드는 시퀀스를 차단 해제하기 위해 강제 적응됩니다.

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

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

출시 시퀀싱은 클러스터 수명 주기의 업그레이드 측면을 제어할 수 있는 기능 모음에 포함된 한 기능입니다. 이 섹션에서는 이 기능이 클러스터 업그레이드와 관련하여 사용 가능한 다른 일부 기능에서 작동하는 방식을 설명합니다.

유지보수 기간 및 제외에서 Fleet 기반 출시 시퀀싱의 작동 방식

GKE는 출시 시퀀싱을 사용하여 클러스터를 업그레이드할 때 유지보수 기간 및 유지보수 제외를 준수합니다. GKE는 클러스터의 유지보수 기간 내에서만 클러스터 업그레이드를 시작합니다. 유지보수 제외를 사용하여 클러스터가 일시적으로 업그레이드되지 않게 할 수 있습니다. GKE가 유지보수 기간 또는 유지보수 제외로 인해 클러스터를 업그레이드할 수 없는 경우 클러스터 업그레이드가 그룹 내에서 완료되지 않을 수 있습니다. 유지보수 기간 또는 유지보수 제외로 인해 클러스터 업그레이드를 30일 이내에 완료할 수 없는 경우 모든 클러스터가 업그레이드를 완료했는지 여부에 관계없이 그룹이 적응 단계에 들어갑니다.

유지보수 제외를 임시 조치로 사용하여 시퀀스가 그룹으로의 출시를 완료하고 다음 그룹으로 이동하는 것을 방지할 수 있습니다. 자세한 내용은 그룹의 버전 출시 완료 지연을 참고하세요.

Fleet 기반 출시 시퀀싱이 지원 중단 사용 감지 시 작동하는 방식

GKE는 특정 지원 중단된 API 및 기능의 사용을 감지하면 클러스터 업그레이드를 일시중지합니다. 출시 시퀀스의 그룹에 있는 클러스터에 대한 자동 업그레이드도 일시중지됩니다. 자세한 내용은 GKE에서 Kubernetes 지원 중단 작동 방식을 참고하세요.

노드 업그레이드 전략에서 출시 시퀀싱의 작동 방식

노드는 출시 시퀀스에서 업그레이드될 때 구성된 노드 업그레이드 전략을 사용합니다. 출시 시퀀싱을 사용하지 않는 클러스터 업그레이드와 마찬가지로 GKE는 Autopilot 노드에 대해 일시 급증 업그레이드를 사용합니다. 자세한 내용은 노드 자동 업그레이드를 참고하세요.

노드 업그레이드를 30일 이내에 완료할 수 없으면 그룹이 모든 클러스터 업그레이드를 완료했는지 여부에 관계없이 적응 단계에 들어갑니다. 특히 큰 노드 풀에서 노드 업그레이드 전략으로 인해 표준 클러스터의 노드 업그레이드가 완료되는 데 시간이 오래 걸리는 경우 이러한 상황이 발생할 수 있습니다. 또한 노드 업그레이드가 완료되기에 유지보수 기간이 충분히 길지 않은 경우 악화될 수 있습니다.

출시 시퀀싱이 출시 채널에서 작동하는 방식

출시 시퀀싱에서는 출시 채널을 사용해야 합니다. 출시 시퀀스의 모든 그룹에 있는 모든 클러스터가 동일한 출시 채널에 있어야 합니다.

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

이전 업그레이드 대상에 대한 클러스터 업그레이드가 출시 시퀀스에서 아직 진행되는 동안 새 버전이 출시 채널의 업그레이드 대상이 되는 경우, 다운스트림 그룹이 이전 업그레이드를 수신하는 동안 업스트림 그룹이 새 버전의 출시를 시작할 수 있습니다. 예를 들어 시퀀스의 세 번째 그룹이 1.31.12-gke.1265000으로 출시되는 경우 시퀀스의 첫 번째 그룹에서 1.31.13-gke.1008000을 동시에 출시할 수 있습니다.

Fleet 기반 출시 시퀀싱 선택 시 고려사항

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

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

동일 프로덕션 환경에서 동일한 출시 채널 또는 부 버전에 없는 클러스터가 있습니다.
최대 5개의 클러스터 그룹으로만 출시 시퀀스를 만들 수 있으므로 5개의 배포 단계에만 매핑할 수 없는 업그레이드를 자동화해야 합니다. 여러 출시 시퀀스에서 그룹을 연결하여 5개 이상의 그룹이 있는 출시 시퀀스를 만들 수는 없습니다. Fleet 기반 시퀀스에는 최대 5개의 Fleet이 포함될 수 있습니다.
한 그룹의 클러스터가 자동 업그레이드 대상 버전을 다르게 지정하게 하는 수동 업그레이드를 자주 수행합니다.

Fleet 기반 출시 시퀀싱의 제한사항

롤아웃 순서로 클러스터를 성공적으로 업그레이드하려면 다음 제한사항을 준수해야 합니다.

출시 시퀀스의 모든 클러스터가 동일한 출시 채널에 등록되어 있는지 확인합니다. 또한 하나의 업그레이드 대상을 검증하기 위해 모든 클러스터가 동일한 부 버전을 실행하는 것이 좋습니다. 자세한 내용은 출시 자격 요건을 참조하세요.
주기(그룹에 다운스트림 그룹이 업스트림 그룹으로 있음) 또는 브랜치(그룹에 두 개 이상의 다운스트림 그룹이 있음)가 없는 선형 출시 시퀀스를 만듭니다.
동일한 조직의 클러스터 간에 출시 시퀀스를 만듭니다. 여러 조직에 걸쳐 있는 클러스터로 시퀀스를 만들 수는 없습니다.

Fleet 기반 출시 시퀀싱의 알려진 문제

그룹에 다른 위치의 클러스터가 포함된 경우 새 버전의 점진적 출시로 인해 일시적으로 일부 클러스터에서만 클러스터 업그레이드를 사용할 수 있습니다. 이 동작은 첫 번째 클러스터 그룹에서 발생할 가능성이 높으며, 일주일 안에 해결됩니다.
출시 시퀀스에 빈 그룹이 있는 경우 버전 검증에 미치는 영향은 다음 조건에 따라 다릅니다.
- 빈 그룹에 업스트림 그룹이 없는 경우 빈 그룹이 버전을 검증할 수 없으므로 클러스터 업그레이드는 다운스트림 그룹으로 진행되지 않습니다.
- 빈 그룹에 업스트림 그룹이 있는 경우 대기 중인 모든 클러스터 업그레이드는 COMPLETE 상태로 전환되고 다운스트림 그룹에 전파됩니다.

다음 단계

클러스터 업그레이드 출시 순서 지정
맞춤 단계를 사용한 출시 시퀀싱에 대해 알아봅니다.