출시 시퀀싱을 사용하여 여러 환경에서 Google Kubernetes Engine(GKE) 클러스터의 자동 클러스터 업그레이드 순서를 관리할 수 있습니다. 예를 들어 프로덕션 클러스터를 업그레이드하기 전에 사전 프로덕션 클러스터에서 새 버전을 검증할 수 있습니다. 이 기능을 사용하려면 클러스터 업그레이드, 출시 채널 및 Fleet 관리를 숙지해야 합니다
시작하려면 클러스터 업그레이드 출시 순서 지정을 참조하세요.
환경 간 업그레이드 검증
출시 시퀀싱으로 클러스터를 자동으로 업그레이드하려면 같은 출시 채널과 부 버전이 있는 클러스터를 배포 단계로 그룹화한 Fleet 또는 팀 범위를 사용합니다. Fleet 시퀀스나 팀 범위 시퀀스를 선택하고 각 클러스터 그룹 간에 원하는 소크 테스트 시간을 설정합니다. 그런 다음 GKE가 출시 채널에서 자동 업그레이드에 사용할 새 버전을 선택하면 클러스터 그룹이 정의된 순서로 업그레이드되며 개발자는 업그레이드가 프로덕션 클러스터와 함께 시작되기 전에 워크로드가 새 버전에서 예상대로 실행되는지 확인할 수 있습니다.
Fleet 기반 출시 시퀀스
다음 다이어그램은 GKE가 Fleet으로 구성된 출시 시퀀스에서 클러스터를 자동으로 업그레이드하는 방법을 보여줍니다.
Fleet 기반 시퀀스를 사용하면 GKE가 이 시퀀스의 모든 클러스터가 등록된 출시 채널에서 새 업그레이드 대상을 사용할 수 있도록 하면 GKE는 이 시퀀스로 이러한 클러스터 Fleet을 업그레이드합니다. 업스트림 Fleet의 클러스터는 최대 3개의 Fleet에 대해 다운스트림 Fleet 클러스터의 새 버전을 검증합니다. 출시 시퀀스에서 업스트림은 이전 그룹을 참조하고 다운스트림은 다음 그룹을 참조합니다.
업그레이드가 업스트림 Fleet에서 완료된 후 다운스트림 Fleet에서 시작되기 전에 Fleet 간에 구성된 소크 시간 동안 워크로드가 업그레이드된 클러스터에서 예상대로 실행되는지 확인할 수 있습니다.
팀 기반 출시 시퀀스
팀 또는 애플리케이션별로 Fleet의 클러스터를 더 세분화한 경우 팀 범위 간에 출시 시퀀스를 만들 수 있습니다. 팀 범위는 Fleet 클러스터의 하위 집합을 특정 애플리케이션 팀과 연결하기 위한 엔터프라이즈 Fleet 수준의 구성으로, 출시 시퀀스뿐만 아니라 액세스 제어 및 팀 범위 관찰 가능성 등 팀 기반 기능을 지원하는 데 사용할 수 있습니다.
팀 범위를 사용하면 Fleet에서 각각 자체 출시 채널, 업그레이드 대상, 독립적인 적응 시간이 있는 여러 출시 시퀀스를 만들 수 있습니다. 팀 기반 출시 시퀀스는 Fleet이 아닌 각 Fleet의 특정 팀 클러스터 간에 업그레이드가 검증된다는 점을 제외하면 Fleet 기반 출시 시퀀스와 동일하게 작동합니다. 이는 특히 팀의 클러스터 내에서 업그레이드를 관리하려는 애플리케이션 운영자에게 유용합니다.
팀 기반 출시 시퀀싱은 미리보기 상태이며 Fleet 기반 출시 시퀀싱은 정식 버전(GA) 상태입니다.
GKE가 출시 시퀀스에서 클러스터를 업그레이드하는 방법
GKE가 클러스터를 업그레이드할 때 먼저 제어 영역이 업그레이드된 후 노드가 업그레이드됩니다. 출시 시퀀스에서는 이 프로세스를 사용하여 클러스터가 계속 업그레이드되지만 클러스터의 그룹(Fleet 또는 범위)이 업그레이드되는 순서도 제어하며 한 그룹에서 다음 그룹으로 업그레이드가 진행되기 전에 GKE가 일시중지되는 시간을 선택하는 적응 시간을 지정합니다.
출시 시퀀스의 클러스터 업그레이드는 다음 단계로 진행됩니다.
- GKE는 특정 출시 채널의 부 버전의 클러스터에 대해 새로운 자동 업그레이드 대상을 설정하며 출시 노트에는 다음과 비슷한 메시지가 표시됩니다. '이 출시 버전에서 일반 채널에 자동 업그레이드가 사용 설정된 제어 영역과 노드는 1.21 버전에서 1.22.15-gke.1000 버전으로 업그레이드됩니다.'
- GKE는 클러스터 제어 영역을 첫 번째 클러스터 그룹의 새 버전으로 업그레이드하기 시작합니다. GKE가 클러스터의 제어 영역을 업그레이드하면 GKE는 클러스터 노드 업그레이드를 시작합니다. GKE는 출시 시퀀스에서 클러스터를 업그레이드할 때 유지보수 가용성을 준수합니다.
- GKE는 제어 영역 업그레이드에 대해 다음 단계를 수행합니다.
- 첫 번째 그룹의 모든 클러스터 제어 영역 업그레이드가 완료되거나 제어 영역 업그레이드가 시작된 후 30일이 지나면 GKE는 제어 영역 업그레이드의 적응 기간을 시작합니다.
- 첫 번째 그룹에서 클러스터 제어 영역 업그레이드의 적응 기간이 완료된 후 GKE가 두 번째 그룹에서 제어 영역 업그레이드를 시작합니다.
- GKE는 제어 영역 업그레이드와 동시에 노드 업그레이드에 대해 다음 단계를 수행합니다.
- 첫 번째 그룹의 모든 클러스터 노드 업그레이드가 완료되거나 노드 업그레이드가 시작된 후 30일이 지나면 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 기반 및 팀 기반 출시 시퀀스 간 전환 안내를 따르세요.
이 기능을 사용하려면 단일 테넌시 클러스터가 필요합니다. 즉, 각 개별 클러스터는 단일 팀에만 연결됩니다. 공유 클러스터(일반 Fleet팀 관리에서 지원됨)는 출시 시퀀싱에 지원되지 않습니다. Fleet팀 관리에서 팀의 클러스터 관리에 대해 자세히 알아보세요.
출시 자격요건
출시 시퀀싱으로 클러스터를 자동으로 업그레이드하려면 출시 시퀀스의 모든 그룹(Fleet 또는 범위)에 있는 모든 클러스터가 동일한 업그레이드 대상을 수신해야 합니다. 클러스터는 동일한 출시 채널에 등록되어야 하며 업그레이드 대상이 부 버전별로 설정되었으므로 클러스터는 동일한 부 버전을 실행하는 것이 좋습니다. 그러나 다음 예시의 출시와 같은 일부 출시의 경우 여러 부 버전의 클러스터가 동일한 대상을 수신했습니다. 즉, 여러 부 버전을 실행하는 출시 시퀀스에서 클러스터가 성공적으로 업그레이드될 수 있습니다.
시퀀스의 버전 출시 상태를 확인하여 상태에 대한 자세한 정보와 버전 자격요건 문제로 인해 업그레이드가 진행되지 않는지 확인할 수 있습니다. 버전 불일치에 따라서는 진행하기 위해 수동으로 클러스터를 업그레이드하거나 클러스터 업그레이드 그룹에서 삭제하는 등의 작업을 수행해야 할 수 있습니다. 출시 시퀀스의 클러스터에 적격한 업그레이드 대상이 없는 경우 GKE는 클러스터의 기존 마이너 버전이 지원 종료에 도달할 때까지 클러스터를 자동 업그레이드하지 않습니다.
출시 자격요건 문제를 해결하려면 출시 자격요건 문제 해결을 참조하세요.
GKE 출시 버전 예시
예를 들어 2022-R25 출시 버전은 일반 채널에 등록된 클러스터의 여러 부 버전에 대한 업그레이드 대상을 설정합니다. 업그레이드 대상은 새로운 부 버전(1.20~1.21)이거나 새 패치 버전(1.21.x-gke.x~1.21.14-gke.4300)일 수 있습니다. 이 출시 버전의 일반 채널에서는 특정 부 버전의 클러스터에 다음과 같은 새로운 버전을 사용할 수 있었습니다.
- 1.20 및 1.21의 클러스터가 1.21.14-gke.4300으로 업그레이드되었습니다.
- 1.22의 클러스터가 1.23.8-gke.1900으로 업그레이드되었습니다.
- 1.24의 클러스터가 1.24.5-gke.600으로 업그레이드되었습니다.
최상위 업스트림 그룹이 모든 업그레이드 대상 수신
새 버전을 검증할 수 있는 업스트림 그룹이 없는 시퀀스의 첫 번째 그룹의 클러스터의 경우 GKE는 이러한 업그레이드 대상이 서로 다른지 여부에 관계없이 적격한 업그레이드 대상으로 모든 클러스터를 업그레이드합니다. 예를 들어 시퀀스의 첫 번째 그룹에서 일부 클러스터가 1.20을 실행 중인 경우 해당 클러스터를 1.21.14-gke.4300으로 업그레이드하고 1.24를 실행하는 클러스터를 1.24.5-gke.600로 업그레이드할 수 있습니다. 이는 시퀀스의 첫 번째 그룹의 경우 새 버전을 검증할 업스트림 그룹이 없으므로 GKE가 모든 업그레이드 대상을 이러한 클러스터에 대해 자격을 갖춘 것으로 간주하기 때문입니다.
업스트림 그룹은 한 버전만 검증해야 함
모든 다운스트림 그룹에서 GKE가 클러스터를 업그레이드할 수 있는지 여부는 업스트림 그룹이 이 그룹의 모든 클러스터가 요건을 충족하는 하나의 업그레이드 대상을 검증했는지 여부에 따라 다릅니다. 일반적으로 이는 모든 클러스터가 동일한 부 버전에서 시작됨을 의미합니다. 그러나 예시 출시 버전에서 1.20 및 1.21의 클러스터에는 동일한 업그레이드 대상이 있으므로 동일한 그룹에서 두 버전을 실행하는 클러스터는 1.21.14-gke.4300로의 업그레이드를 검증합니다.
한 그룹의 모든 클러스터에 동일한 업그레이드 대상이 없으면 이 그룹은 다음 그룹의 하나의 업그레이드 대상을 검증할 수 없습니다. 이 경우 GKE는 다운스트림 그룹의 클러스터를 자동으로 업그레이드할 수 없습니다. 예를 들어 첫 번째 그룹에서 일부 클러스터를 1.21.14-gke.4300으로 업그레이드하고 다른 클러스터를 1.23.8-gke.1900으로 업그레이드하면 그룹에서 검증된 버전 하나를 받지 못했으므로 두 번째 그룹의 클러스터를 자동으로 업그레이드할 수 없습니다. 이 상황에서 업그레이드를 진행하려면 그룹의 자격요건 수정을 참조하세요.
업스트림 그룹은 다음 그룹의 클러스터와 일치하는 버전을 검증해야 함
업스트림 그룹의 클러스터가 다음 그룹의 클러스터가 요건을 충족하는 버전과 다른 버전을 검증한다면 GKE는 다운스트림 그룹의 클러스터를 자동으로 업그레이드할 수 없습니다.
예를 들어 첫 번째 그룹의 모든 클러스터가 1.21.14-gke.4300으로 업그레이드되었지만 두 번째 그룹의 클러스터가 1.22를 실행 중인 경우(업그레이드 대상은 1.23.8-gke.1900) 두 번째 그룹의 클러스터는 자동으로 업그레이드되지 않습니다. 첫 번째 그룹은 1.21.14-gke.4300을 검증했지만 두 번째 그룹의 클러스터(현재 1.22)는 업그레이드 대상 1.23.8-gke.1900만 충족하므로 GKE는 이러한 클러스터를 자동으로 업그레이드할 수 없습니다. 이 상황에서 업그레이드를 진행하려면 그룹 간 자격요건 수정을 참조하세요.
다른 업그레이드 기능에서 출시 시퀀싱의 작동 방식
출시 시퀀싱은 클러스터 수명 주기의 업그레이드 측면을 제어할 수 있는 기능 모음에 포함된 한 기능입니다. 이 섹션에서는 이 기능이 클러스터 업그레이드와 관련하여 사용 가능한 다른 일부 기능에서 작동하는 방식을 설명합니다.
유지보수 기간 및 제외에서 출시 시퀀싱의 작동 방식
GKE는 출시 시퀀싱으로 클러스터를 업그레이드할 때 유지보수 기간 및 유지보수 제외를 준수합니다. GKE는 클러스터의 유지보수 기간 내에만 클러스터 업그레이드를 시작합니다. 유지보수 제외를 사용하여 클러스터 업그레이드를 일시적으로 방지할 수 있습니다. GKE가 유지보수 기간 또는 유지보수 제외로 인해 클러스터를 업그레이드할 수 없는 경우 클러스터 업그레이드가 그룹 내에서 완료되지 않을 수 있습니다. 유지보수 기간 또는 유지보수 제외로 인해 클러스터 업그레이드를 30일 이내에 완료할 수 없는 경우 모든 클러스터가 업그레이드를 완료했는지 여부에 관계없이 그룹이 적응 단계에 들어갑니다.
유지보수 제외를 임시 조치로 사용하여 시퀀스가 그룹으로의 출시를 완료하고 다음 그룹으로 이동하는 것을 방지할 수 있습니다. 자세한 내용은 그룹의 버전 출시 완료 지연을 참조하세요.
출시 시퀀싱이 지원 중단 사용 감지 시 작동하는 방식
GKE는 지원 중단된 특정 API 및 기능의 사용을 감지하면 클러스터 업그레이드를 일시중지합니다. 출시 시퀀스의 그룹에 있는 클러스터에 대한 자동 업그레이드도 일시중지됩니다. 자세한 내용은 GKE에서 Kubernetes 지원 중단의 작동 방식을 참조하세요.
노드 업그레이드 전략에서 출시 시퀀싱의 작동 방식
노드 업그레이드는 출시 시퀀스에서 업그레이드될 때 구성된 노드 업그레이드 전략을 사용합니다. 출시 시퀀싱을 사용하지 않는 클러스터 업그레이드와 마찬가지로 GKE는 Autopilot 노드에 일시 급증 업그레이드를 사용합니다. 자세한 내용은 자동 노드 업그레이드를 참조하세요.
노드 업그레이드를 30일 이내에 완료할 수 없으면 그룹이 모든 클러스터 업그레이드를 완료했는지 여부에 관계없이 적응 단계에 들어갑니다. 특히 큰 노드 풀에서 노드 업그레이드 전략으로 인해 표준 클러스터의 노드 업그레이드가 완료되는 데 시간이 오래 걸리는 경우 이러한 상황이 발생할 수 있습니다. 또한 노드 업그레이드가 완료되기에 유지보수 기간이 충분히 길지 않은 경우 악화될 수 있습니다. 자세한 내용은 유지보수 기간 구성 시 고려사항을 참조하세요.
출시 시퀀싱이 출시 채널에서 작동하는 방식
출시 시퀀싱에서는 출시 채널을 사용해야 합니다. 출시 시퀀스의 모든 그룹에 있는 모든 클러스터가 동일한 출시 채널에 있어야 합니다.
시퀀스에서 여러 업그레이드 수신
이전 업그레이드 대상에 대한 클러스터 업그레이드가 출시 시퀀스에서 아직 진행되는 동안 새 버전이 출시 채널의 업그레이드 대상이 되는 경우, 다운스트림 그룹이 이전 업그레이드를 수신하는 동안 업스트림 그룹이 새 버전의 출시를 시작할 수 있습니다. 예를 들어 시퀀스의 세 번째 그룹이 1.24.2-gke.100으로 출시되는 경우 시퀀스의 첫 번째 그룹에서 1.24.3-gke.500을 동시에 출시할 수 있습니다.
출시 시퀀싱 선택 시 고려사항
새 버전을 출시하기 전에 한 환경에서 새 버전을 검증하여 클러스터 업그레이드를 관리하려면 출시 시퀀싱을 사용하는 것이 좋습니다.
하지만 다음 설명 중 하나라도 해당하는 경우 환경에 적합하지 않을 수 있습니다.
- 동일 프로덕션 환경에서 동일한 출시 채널 또는 부 버전에 없는 클러스터가 있습니다.
- 최대 3개의 클러스터 그룹으로만 출시 시퀀스를 만들 수 있으므로 3개의 배포 단계에만 매핑할 수 없는 업그레이드를 자동화해야 합니다. 여러 출시 시퀀스의 그룹을 연결하여 3개 이상의 그룹이 있는 출시 시퀀스를 만들 수 없습니다.
- Fleet 관리를 사용할 수 없습니다.
- 한 그룹의 클러스터가 자동 업그레이드 대상 버전을 다르게 지정하게 하는 수동 업그레이드를 자주 수행합니다.
팀 기반 출시 시퀀스를 만들려면 또한 Fleet 호스트 프로젝트에서 GKE Enterprise를 사용 설정할 수 있어야 합니다.
제한사항
출시 시퀀싱으로 클러스터를 성공적으로 업그레이드하려면 다음 제한사항을 준수해야 합니다.
- 팀 기반 출시 시퀀싱을 사용하는 경우 하나의 팀 범위에만 클러스터를 등록합니다. 클러스터가 여러 팀 범위에 등록되면 GKE에서 팀 기반 출시 시퀀스로 클러스터를 자동으로 업그레이드할 수 없습니다.
- 동일한 Fleet 내에서 여러 팀 범위로 팀 기반 출시 시퀀스를 만드는 것은 지원되지 않습니다.
- 주기(그룹에 다운스트림 그룹이 업스트림 그룹으로 있음) 또는 브랜치(그룹에 두 개 이상의 다운스트림 그룹이 있음)가 없는 선형 출시 시퀀스를 만듭니다.
- 팀 범위 간에 출시 시퀀스를 만들거나 Fleet 간에 출시 시퀀스를 만듭니다. Fleet과 팀 범위가 모두 동일한 시퀀스에 있는 혼합 시퀀스를 만들 수 없습니다.
- 출시 시퀀스의 클러스터가 모두 동일한 출시 채널에 등록되었고 동일한 부 버전을 실행하는지 확인합니다.
알려진 문제
- 그룹에 다른 위치의 클러스터가 포함된 경우 새 버전의 점진적 출시로 인해 일시적으로 일부 클러스터에서만 클러스터 업그레이드를 사용할 수 있습니다. 이는 첫 번째 클러스터 그룹에서 발생할 가능성이 높으며, 일주일 안에 해결됩니다.
- 출시 시퀀스에 빈 그룹이 있는 경우 버전 검증에 미치는 영향은 다음 조건에 따라 다릅니다.
- 빈 그룹에 업스트림 그룹이 없으면 빈 그룹이 버전을 검증할 수 없으므로 클러스터 업그레이드가 다운스트림 그룹으로 진행되지 않습니다.
- 빈 그룹에 업스트림 그룹이 있으면 대기 중인 모든 클러스터 업그레이드가
COMPLETE상태가 되고 다운스트림 그룹에 전파됩니다.
- GKE에서 패치 및 마이너 업그레이드를 추적하는 방식으로 인해 동일한 유형 및 버전의 두 업그레이드를 확인할 수 있지만 범위 상태를 확인할 때는 상태가 다를 수 있습니다.