이 페이지의 일부 또는 모든 정보는 S3NS의 Cloud de Confiance에 적용되지 않을 수 있습니다. 자세한 내용은 Google Cloud와의 차이점을 참조하세요.

Google은 AI 기술을 사용하여 콘텐츠를 사용자의 기본 언어로 번역합니다. AI 번역에는 오류가 있을 수 있습니다.

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

Autopilot Standard

출시 시퀀싱을 사용하여 여러 환경에서 Google Kubernetes Engine (GKE) 클러스터의 자동 클러스터 업그레이드 순서를 관리할 수 있습니다. 예를 들어 프로덕션 클러스터를 업그레이드하기 전에 사전 프로덕션 클러스터에서 새 버전을 검증할 수 있습니다. GKE는 이 기능의 이전 버전인 함대 기반 출시 순서 지정도 제공합니다. 이 버전은 기능이 더 제한적이며 새 환경에는 권장되지 않습니다.

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

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

개요

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

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

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

출시 순서 지정 전략 선택

GKE는 두 가지 버전의 출시 시퀀싱을 제공합니다. 두 버전 모두 점진적인 Fleet 기반 업그레이드라는 동일한 핵심 원칙을 기반으로 하지만 새 환경에는 맞춤 단계가 있는 출시 시퀀싱을 사용하는 것이 좋습니다.

맞춤 단계가 있는 출시 순서 (새 환경에 권장): 이 버전은 플릿 기반 모델의 발전된 버전으로, 더 세부적인 제어와 유연성을 제공하지만 Cloud de Confiance 콘솔 지원이 없습니다. 맞춤 단계를 사용하면 라벨을 사용하여 Fleet 내에서 특정 단계를 정의할 수 있으므로 더 광범위한 출시 전에 소규모 프로덕션 클러스터에 새 버전을 배포하는 등 더 복잡한 출시 전략에 적합합니다. 또한 특정 버전으로의 출시를 시작하고, 시퀀스에서 출시할 업그레이드 유형을 선택하고, 출시를 일시중지하거나 취소하는 등 출시를 더 세부적으로 제어할 수 있습니다. 출시 시퀀스를 처음 만드는 경우 이 옵션을 선택합니다.
함대 기반 출시 순서 지정: Cloud de Confiance 콘솔에서 사용할 수 있는 유일한 버전이지만, 그 외에는 기능이 제한적이며 출시 순서를 처음 만드는 경우에는 권장되지 않습니다.

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

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

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

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

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

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

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

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

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

주요 개념

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

권장사항:

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

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

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

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

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

GKE가 출시 시퀀스에서 새 출시를 시작합니다. 기본적으로 특정 출시 채널의 부 버전 클러스터에 대해 GKE가 새 자동 업그레이드 대상을 설정하면 출시가 시작됩니다. 맞춤 단계로 출시 순서를 지정하는 경우 출시 순서에서 선택한 특정 버전으로 새 출시를 트리거할 수도 있습니다.
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 전반에서 각 클러스터가 동일한 출시 채널(이 경우 일반 채널)에 등록되어 있으며 모든 클러스터가 동일한 부 버전을 실행합니다.

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

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

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

그런 다음 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의 모든 클러스터가 포함됩니다.

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

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

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

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

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

또한 관리자는 문제가 감지되면 출시를 일시중지하거나 해당 단계의 변경사항이 확실하고 즉시 진행할 준비가 된 경우 단계를 완료하는 등의 작업을 통해 출시를 관리할 수 있습니다.

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

GKE가 새 버전 출시를 시작하는 방법

기본적으로 GKE는 새 자동 업그레이드 대상을 설정할 때 새 출시를 만듭니다. GKE에서 롤아웃하기 위해 선택하는 버전은 시퀀스에 있는 클러스터의 마이너 버전과 출시 채널에 따라 다릅니다. 예를 들어 클러스터가 일반 채널에서 GKE 버전 1.35를 실행하고 GKE가 자동 업그레이드 대상을 1.35.5-gke.1000000으로 설정하는 경우 GKE는 새 Rollout를 만듭니다.

하지만 GKE에서 출시할 버전을 선택할 수도 있습니다.

특정 버전 출시

예를 들어 보안 취약점을 신속하게 패치하거나 GKE 클러스터의 심각한 문제를 해결하려는 경우 특정 버전으로 출시를 시작할 수도 있습니다. 이 작업은 GKE가 자동 업그레이드 대상을 설정할 때와 마찬가지로 출시 시퀀스 전반에 걸쳐 출시를 시작하는 Rollout 객체를 만듭니다. 새 버전을 출시하려면 특정 버전 출시를 참고하세요.

클러스터에 새 버전을 최대한 빨리 출시해야 하는 경우 개별 클러스터에 대해 수동 클러스터 업그레이드를 대신 실행할 수 있습니다. 수동 클러스터 업그레이드는 클러스터 수준에서 실행됩니다.

출시 시퀀스에서 GKE가 실행하는 업그레이드 유형 선택

기본적으로 GKE는 컨트롤 플레인 및 노드에 대한 패치 버전 및 마이너 버전 업그레이드를 포함하여 모든 유형의 클러스터 업그레이드를 출시 시퀀스에 출시합니다.

업그레이드에는 네 가지 주요 유형이 있습니다.

컨트롤 플레인의 패치 버전 업그레이드
노드의 패치 버전 업그레이드
컨트롤 플레인의 마이너 버전 업그레이드
노드의 부 버전 업그레이드

출시 시퀀스에서 클러스터 업그레이드 범위를 제한하여 특정 유형의 업그레이드만 실행할 수 있습니다. 예를 들어 GKE에서 노드 업그레이드가 아닌 컨트롤 플레인 업그레이드만 출시하도록 하려면 출시 시퀀스에 이를 지정하면 됩니다.

출시 시퀀스의 클러스터 업그레이드 범위를 제한하면 GKE는 필수 자동 업그레이드를 제외하고 출시 시퀀스의 클러스터에 대해 해당 유형의 자동 업그레이드를 실행하지 않습니다. 자세한 내용은 필수 자동 업그레이드 출시를 참고하세요. 클러스터 업그레이드 범위를 제한해도 제한한 유형의 진행 중인 출시가 취소되지는 않습니다. GKE에서 해당 유형의 향후 출시를 생성하는 것만 방지됩니다.

GKE는 클러스터의 노드를 컨트롤 플레인보다 최신 버전으로 업그레이드하지 않으므로 컨트롤 플레인 업그레이드의 범위를 제한하면 노드 업그레이드도 제한할 수 있습니다.

출시 시퀀스에서 자동 업그레이드 범위를 제한하려면 출시 시퀀스에서 GKE가 실행하는 업그레이드 유형 선택을 참고하세요.

출시 시퀀스의 범위를 제한하는 것은 유지보수 제외와 유사하지만 유지보수 제외는 클러스터 내의 개별 클러스터 또는 노드 풀에 설정됩니다.

필수 자동 업그레이드 출시

클러스터가 출시 시퀀스에 등록되었는지 여부에 관계없이 GKE는 보안 및 호환성을 위해 클러스터를 자동으로 업그레이드합니다. 출시 시퀀스의 클러스터에서 90일 동안 컨트롤 플레인을 업그레이드하지 않았거나 클러스터에서 지원 종료에 도달한 마이너 버전을 실행하는 경우 GKE는 자동 업그레이드를 실행하기 위해 필수 출시를 만듭니다. 이러한 출시를 통해 클러스터의 성능, 가용성, 보안을 유지할 수 있습니다. GKE는 롤아웃 범위 제한, 유지보수 제외 또는 지연의 기타 이유와 관계없이 이러한 시나리오에 대한 롤아웃을 만듭니다.

이러한 유형의 출시를 일시중지하거나 취소할 수 없습니다. GKE는 출시 시퀀스 등록 여부와 관계없이 이러한 유형의 클러스터 업그레이드를 실행합니다.

이러한 정책에 관한 자세한 내용은 다음 섹션을 참고하세요.

출시 자격요건

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

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

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

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

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

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

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

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

30일 후 강제 소킹

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

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

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

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

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

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

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

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

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

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

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

출시 시퀀싱 알림

GKE는 클러스터 수준에서 클러스터 업그레이드에 관한 중요한 정보를 제공하는 클러스터 알림을 전송합니다. 또한 GKE는 맞춤 단계가 있는 출시 시퀀스 및 해당 출시 시퀀스로 진행되는 출시에 대한 알림을 제공합니다. 예를 들어 출시 단계가 시작되거나 완료되거나 차단되면 GKE에서 알림을 전송합니다. 또는 출시 시퀀스를 잘못 구성한 경우 GKE에서 알림을 전송합니다. 자세한 내용은 클러스터 알림 문서와 RolloutEvent 및 RolloutSequenceEvent의 각 섹션을 참고하세요.

출시 관리

GKE가 출시 시퀀스의 클러스터에 새 버전을 출시할 때 다음 작업을 사용하여 클러스터와 워크로드가 변경에 어떻게 반응하는지 평가하는 동안 프로세스를 제어할 수 있습니다. 또한 새 출시를 만들어 특정 버전을 출시할 수 있습니다.

업그레이드가 진행되는 동안 상태를 확인할 수 있습니다. 업그레이드 진행 방식에 따라 다음 하위 섹션에 설명된 작업을 사용할 수 있습니다.

롤아웃 일시중지

진행 중인 출시를 일시중지할 수 있습니다. 예를 들어 클러스터와 출시되는 새 버전에 잠재적인 문제가 있는 것으로 확인되면 출시를 일시중지할 수 있습니다. GKE는 이 버전으로의 새 업그레이드 작업을 시작하지 않으므로 필요에 따라 문제를 조사할 수 있습니다. GKE는 진행 중인 업그레이드 작업을 중지하지 않지만 후속 단계를 포함하여 새 작업을 시작하지는 않습니다.

출시를 일시중지하려면 출시 일시중지를 참고하세요.

출시를 일시중지한 후 출시를 재개하거나 취소할 수 있습니다. 출시는 최대 90일까지 일시중지할 수 있습니다. 90일이 지나면 GKE에서 출시를 취소합니다.

출시를 일시중지해도 후속 출시가 시작되는 것을 막을 수는 없습니다. 하지만 이러한 출시가 일시중지된 출시 단계를 대체하지는 않습니다. 예를 들어 GKE가 이미 1단계와 2단계에 1.34.8-gke.1000000을 출시했고 3단계에서 출시를 일시중지한 경우 GKE는 1.35.5-gke.1163000으로 새 출시를 시작하고 처음 두 단계의 클러스터를 업그레이드할 수 있습니다. 하지만 3단계에서 1.34.8-gke.1000000 출시가 완료되거나 취소될 때까지는 GKE가 3단계에서 1.35.5-gke.1163000으로의 업그레이드를 시작하지 않습니다.

출시 시퀀스에 진행 중인 출시가 여러 개 있고 이를 모두 일시중지하려면 각 출시를 개별적으로 일시중지해야 합니다. GKE가 추가 출시를 시작하지 못하도록 하려면 출시 시퀀스에서 GKE가 실행하는 업그레이드 유형을 선택하면 됩니다.

출시 재개

잠재적인 문제를 조사하고 업그레이드를 진행할 준비가 되면 90일 미만으로 일시중지된 일시중지된 출시를 재개할 수 있습니다. 동일한 유형 (컨트롤 플레인 출시 또는 노드 출시)의 다른 출시가 동일한 단계에서 동시에 실행되고 있지 않은 경우에만 일시중지된 출시를 재개할 수 있습니다. 기술적 또는 비즈니스적 이유로 GKE에 의해 자동으로 일시중지된 출시를 재개할 수도 있지만, 재개하기 전에 주의하는 것이 좋습니다.

출시를 재개하면 GKE는 출시 시퀀스의 단계에서 새 버전을 계속 출시하기 위해 새 업그레이드 작업을 시작합니다.

출시를 재개하려면 출시 재개를 참고하세요.

출시 취소

활성 상태이거나 일시중지된 출시를 포함하여 출시를 취소할 수 있습니다. 출시를 취소하면 GKE에서 동일한 버전의 새 출시를 자동으로 만들지 않습니다. 하지만 출시를 취소해도 GKE에서 이후 버전을 출시하는 것을 막을 수는 없습니다. GKE가 이후 버전도 출시하지 않도록 하려면 진행 중인 모든 출시를 취소하고 출시 시퀀스에서 클러스터 업그레이드의 범위를 제한하세요.

출시를 취소하려면 출시 취소를 참고하세요.

취소된 버전과 동일한 버전을 출시해야 하는 경우 특정 버전을 출시하세요.

출시 단계 완료

예를 들어 해당 단계에서 테스트를 완료하여 버전의 롤아웃이 롤아웃 시퀀스의 다음 단계로 진행될 수 있다고 확신하는 경우 단계를 완료하여 롤아웃을 수동으로 진행할 수 있습니다. 단계를 완료하면 GKE에서 아직 업그레이드하지 않은 클러스터는 해당 출시의 일부로 업그레이드되지 않습니다. 단계를 완료하면 남은 침수 시간도 건너뜁니다. 이 작업은 출시 시퀀스 수준에서 soak 시간을 변경하지 않아도 된다는 의미이기도 합니다.

출시 단계를 완료하려면 출시 단계 완료를 참고하세요.

출시 시퀀스를 변경하여 출시 관리

전체 출시 시퀀스에 영향을 미치는 작업을 실행하여 출시를 관리할 수도 있습니다. 하지만 출시를 일시중지하는 등 이전 섹션에 설명된 조치를 취한 후 삭제하는 것이 좋습니다. 출시 시퀀스를 변경하면 향후 출시가 시퀀스에서 작동하는 방식에 영향을 미칠 뿐만 아니라 진행 중인 출시가 취소될 수도 있습니다. 하나의 출시만 변경하려면 전체 시퀀스를 변경하는 대신 제공된 도구를 사용하여 하나의 출시를 관리하세요.

하지만 하나의 새 버전 출시뿐만 아니라 모든 출시에서 출시 시퀀스가 작동하는 방식을 변경하려면 다음 섹션인 출시 시퀀스 관리를 참고하세요.

개별 클러스터 업그레이드를 제어하여 출시 관리

개별 클러스터 업그레이드의 경우 다음 도구를 사용하여 업그레이드를 관리할 수 있습니다.

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

자세한 내용은 출시 시퀀싱이 다른 업그레이드 기능에서 작동하는 방식을 참고하세요.

출시 시퀀스 관리

출시 시퀀스를 관리하려면 다음과 같은 기본 작업을 수행하면 됩니다.

출시 시퀀스 나열
출시 시퀀스 설명

또한 출시 시퀀스 수정, 출시 시퀀스에서 클러스터 무시와 같은 작업을 실행할 수 있습니다. 이러한 작업은 다음 하위 섹션에 설명되어 있습니다.

전체 출시 시퀀스 대신 한 버전의 출시를 관리하는 방법을 자세히 알아보려면 이전 섹션인 출시 관리를 참고하세요.

출시 시퀀스에서 클러스터 무시

기본적으로 출시 시퀀스에 포함된 클러스터는 출시 시퀀스의 일부로 업그레이드됩니다. 특정 단계에 클러스터를 추가할 수 있으며, Fleet에 있고 라벨이 지정되지 않은 클러스터는 함께 업그레이드됩니다.

하지만 출시 시퀀스에 포함하지 않으려는 클러스터가 있는 경우 새 버전을 출시할 때 GKE가 클러스터를 무시하도록 라벨을 지정할 수 있습니다. 예를 들어 특정 클러스터를 업그레이드하기 전에 추가 시간이 필요한 경우 이 작업을 수행해야 할 수 있습니다. 출시 시퀀스에서 하나 이상의 클러스터를 무시할 수 있습니다.

출시 시퀀스의 클러스터를 무시하면 GKE는 새 버전을 출시할 때 이를 고려하지 않으며 지원 종료 시 자동 업그레이드 및 90일 동안 업그레이드되지 않은 컨트롤 플레인의 자동 업그레이드를 포함한 필수 자동 업그레이드를 제외하고 클러스터에 대한 자동 업그레이드를 실행하지 않습니다.

출시 순서에서 클러스터를 무시하려면 출시 순서에서 클러스터 무시를 참고하세요.

출시 시퀀스 수정

기존 출시 시퀀스에서 출시 진행 방식을 변경하려면 다음 두 가지 방법 중 하나로 시퀀스를 수정하면 됩니다.

시퀀스를 정의한 YAML 구성 파일을 수정하여 출시 시퀀스를 수정합니다.
시퀀스에서 클러스터를 수정합니다.

출시 시퀀스를 수정하면 다음과 같은 결과가 발생합니다.

출시 시퀀스에서 단계를 추가하거나, 단계를 삭제하거나, 단계의 순서를 변경하거나, 단계를 수정하는 경우(예: 해당 단계의 프로젝트 ID 또는 라벨 선택기를 변경하는 경우) GKE는 활성 출시를 모두 취소합니다.
단계의 soak 시간을 변경해도 GKE는 활성 출시를 취소하지 않습니다.

출시 시퀀스를 수정하려면 출시 시퀀스 수정을 참고하세요.

다음은 순서대로 클러스터를 수정하는 경우 발생하는 상황입니다.

Fleet에서 클러스터를 삭제하여 출시 시퀀스에서 클러스터를 삭제하면 활성 출시가 계속됩니다. GKE는 시퀀스에 등록되지 않은 클러스터의 일반적인 절차에 따라 클러스터를 자동으로 업그레이드할 수 있습니다.
출시 시퀀스에서 Fleet에 클러스터를 추가하면 GKE는 아직 추가된 단계를 통과하지 않은 활성 출시의 일부로 이 클러스터를 업그레이드합니다. 하지만 출시의 단계가 완료된 경우 GKE는 해당 출시에서 클러스터를 업그레이드하지 않습니다.
출시 시퀀스 구성을 수정하지 않고 클러스터를 다른 단계로 이동하면 클러스터를 이동하는 단계의 완료 여부에 따라 다음이 발생합니다.
- 이미 출시가 완료된 단계로 클러스터를 이동하면 GKE는 해당 출시에서 클러스터를 업그레이드하지 않습니다.
- 출시에서 이미 업그레이드된 클러스터를 완료되지 않은 후반 단계로 이동하면 GKE는 클러스터를 무시하고 출시 진행을 중단하지 않습니다.

시퀀스의 클러스터를 수정하려면 Fleet에 클러스터 등록을 참고하세요. Cloud de Confiance by S3NS

제한사항

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

Cloud de Confiance 콘솔을 사용하여 맞춤 단계가 있는 출시 시퀀스를 만들거나 볼 수 없습니다.
출시 시퀀스에서 Fleet을 참조하는 경우 전체 Fleet을 포함해야 합니다. 이 제약 조건은 label-selector를 사용하여 Fleet의 일부 클러스터만 타겟팅하는 단계를 정의하는 경우 (예: 단계별 배포) 동일한 Fleet의 나머지 모든 클러스터를 포함하는 후속 '모두' 단계도 정의해야 함을 의미합니다. 이 포괄적 단계는 동일한 Fleet을 타겟팅하지만 label-selector를 포함하지 않으므로 시퀀스의 이전 단계에서 선택되지 않은 모든 클러스터를 자동으로 포함합니다.
롤아웃 중에 시퀀스를 수정하는 경우, 특히 참여 클러스터에 영향을 미치는 변경사항이 있으면 GKE는 기존 롤아웃을 모두 즉시 취소합니다. 시퀀스의 소크 시간만 수정하면 GKE에서 출시를 취소하지 않습니다.
스테이지는 최대 하나의 Fleet을 참조할 수 있습니다. 단일 단계에 여러 차량을 포함할 수 없습니다.
단일 Fleet은 하나의 출시 시퀀스에서만 참조할 수 있습니다. 두 출시 시퀀스가 동일한 플릿을 참조할 수는 없습니다.
가속화된 패치 자동 업그레이드를 사용하는 출시 시퀀싱으로 클러스터를 업그레이드할 수 없습니다.
최대 15단계로 출시 시퀀스를 만들 수 있습니다.
Fleet에는 최대 250개의 클러스터를 포함할 수 있습니다. 경량 멤버십이 있는 클러스터의 경우 Fleet에서 최대 2,000개의 클러스터에 대한 할당량 증가를 요청할 수 있습니다. 자세한 내용은 할당량 및 한도를 참고하세요.
모든 단계에서 시퀀스당 최대 90일까지의 소크 시간을 구성할 수 있습니다.

알려진 문제

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

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

다음 단계

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