Standard 클러스터 업그레이드

이 페이지에서는 Google Kubernetes Engine(GKE) Standard 클러스터에서의 자동 및 수동 업그레이드 작동 방식에 대하여 설명하고 관련 작업 및 설정에 대한 상세 정보를 제공하는 링크를 소개합니다. 이 정보를 참조하여 워크로드 중단을 최소화하면서 클러스터를 업데이트하여 안정성을 확보하고 보안을 유지할 수 있습니다.

자동 프로비저닝에서 클러스터 업그레이드가 작동하는 방식에 대한 상세 설명은 Autopilot 클러스터 업그레이드를 참조하세요.

클러스터 및 노드 풀 업그레이드의 작동 방식

이 섹션에서는 클러스터에서 자동 또는 수동 업그레이드가 어떻게 작동하는지 설명합니다. 자동 업그레이드의 경우 GKE에서 자동 업그레이드를 시작합니다. GKE는 모든 GKE 클러스터의 자동 및 수동 업그레이드를 관찰하고 문제가 발생하면 개입합니다.

클러스터를 업그레이드하기 위해 GKE에서 제어 영역과 노드가 실행하고 있는 버전을 업데이트합니다. 클러스터는 최신 부 버전(예: 1.24~1.25) 또는 최신 패치 버전(예: 1.24.2-gke.100~1.24.5-gke.200)으로 업그레이드됩니다. 자세한 내용은 GKE 버전 관리 및 지원을 참조하세요.

클러스터를 출시 채널에 등록하면 클러스터의 제어 영역 업그레이드를 완료한 후 노드 풀의 업그레이드를 시작하기 전에 잠깐 동안만(보통 며칠이며 현재 버전에 따라 다름) 또는 제어 영역이 수동으로 업그레이드 된 경우를 제외하고 노드가 동일한 버전의 GKE를 실행합니다. 자세한 정보는 출시 노트를 참조하세요.

클러스터 업그레이드

이 섹션에서는 GKE에서 클러스터를 자동 업그레이드하거나 개발자가 수동 업그레이드를 시작하는 경우의 예상 결과를 설명합니다.

  • 영역 클러스터에는 단일 제어 영역만 있습니다. 업그레이드하는 동안 워크로드는 계속 실행되지만 업그레이드가 완료될 때까지 새 워크로드를 배포하거나 기존 워크로드를 수정하거나 클러스터 구성을 다르게 변경할 수 없습니다.

  • 리전 클러스터에는 제어 영역의 여러 복제본이 있으며 한 번에 하나의 복제본만 무작위 순서로 업그레이드됩니다. 업그레이드하는 동안 클러스터는 고가용성을 유지하며 각 제어 영역의 복제본은 업그레이드하는 동안에만 사용할 수 있습니다.

유지보수 기간 또는 유지보수 제외가 구성되면 가능한 경우에 한해 적용됩니다.

노드 풀 업그레이드

이 섹션에서는 GKE에서 노드 풀을 자동 업그레이드하거나 개발자가 수동 노드 풀 업그레이드를 시작하는 경우의 예상 결과를 설명합니다.

GKE는 클러스터에서 한 번에 하나의 노드 풀을 자동으로 업그레이드합니다. 또는 하나 이상의 노드 풀을 동시에 수동으로 업그레이드할 수 있습니다. 기본적으로 노드 풀 내의 노드는 한 번에 하나씩 임의의 순서로 업그레이드됩니다. 여러 영역에 분산된 노드 풀에서 업그레이드는 영역별로 수행됩니다. 영역 내에서 노드는 정의되지 않은 순서로 업그레이드됩니다.

GKE 노드 풀 업그레이드를 사용하면 클러스터 환경의 니즈에 따라 업그레이드 프로세스를 조정할 수 있는 구성 가능한 기본 제공 업그레이드 전략 2개 중에서 선택할 수 있습니다. 일시 급증 및 블루-그린 업그레이드 전략에 대한 자세한 내용은 업그레이드 전략을 참조하세요.

노드 풀을 업그레이드하는 동안에는 업그레이드를 취소하지 않는 한 클러스터 구성을 변경할 수 없습니다.

GKE는 가능한 경우 자동 업그레이드 중에 유지보수 기간 및 유지보수 제외를 준수합니다. 수동 업그레이드는 구성된 유지보수 기간 및 유지보수 제외를 무시합니다.

노드 업그레이드 방법

노드 풀 업그레이드 중에 노드 업그레이드 방법은 노드 풀 업그레이드 전략 및 구성 방법에 따라 다릅니다. 하지만 기본 단계는 일관적으로 유지됩니다. 노드를 업그레이드할 수 있도록 GKE는 노드에서 포드를 삭제합니다.

노드가 업그레이드되면 포드에 다음과 같은 결과가 발생합니다.

  1. Kubernetes가 새 포드를 예약하지 않도록 노드가 차단됩니다.
  2. 그런 다음 노드가 드레이닝됩니다. 즉, 포드가 삭제됩니다. 일시 급증 업그레이드의 경우 GKE는 최대 1시간 동안 포드의 PodDisruptionBudget과 GracefulTerminationPeriod 설정을 따릅니다. 블루/그린 업그레이드를 사용하면 더 긴 적응 시간을 구성하는 경우 이 시간을 확장할 수 있습니다.
  3. 제어 영역은 컨트롤러가 관리하는 Pod를 다른 노드로 다시 예약합니다. 다시 예약할 수 없는 포드는 다시 예약할 수 있을 때까지 대기중 단계로 유지됩니다.

노드 풀 업그레이드 프로세스는 업그레이드 전략, 노드 수, 워크로드 구성에 따라 몇 시간이 걸릴 수 있습니다.

노드 업그레이드 시간에 영향을 미치는 고려사항

노드 업그레이드를 완료하는 데 더 오래 걸리게 만들 수 있는 구성은 다음과 같습니다.

노드 업그레이드 전략

GKE는 노드 풀 업그레이드 방법을 결정하는 구성 가능한 기본 제공 전략을 제공합니다. 노드 업그레이드 전략을 사용하는 변경사항 유형에 대한 자세한 내용은 GKE에서 일시 급증 업그레이드를 사용하는 경우 및 GKE가 블루-그린 업그레이드를 사용하는 경우를 참조하세요.

일시 급증 업그레이드

기본적으로 노드 풀 업그레이드에는 일시 급증 업그레이드 전략이 사용됩니다. 일시 급증 업그레이드는 순차적 방법을 사용하여 노드를 업그레이드합니다. 이 전략은 중단 없는 증분식 변경을 처리할 수 있는 애플리케이션에 가장 적합합니다. 이 전략을 사용하면 노드가 순환 기간에 업그레이드됩니다. 이 설정을 사용하면 한 번에 업그레이드할 수 있는 노드 수와 업그레이드로 인한 중단 정도를 변경하여 환경 요구사항을 위한 속도와 중단 간의 가장 적합한 균형을 찾을 수 있습니다.

블루/그린 업그레이드

또 다른 방식은 두 가지 환경(원본 및 새 환경)이 한 번에 유지관리되어 최대한 쉽게 롤백할 수 있는 블루-그린 업그레이드입니다. 블루/그린은 더 많은 리소스를 소모하며 변경사항에 더 민감한 애플리케이션에 더 적합합니다. 이 전략을 사용하면 워크로드가 원래 '블루' 환경에서 새 '그린' 환경으로 점진적으로 마이그레이션되며 적응 시간을 통해 새 구성으로 검증됩니다. 필요한 경우 워크로드를 기존 '블루' 환경으로 빠르게 롤백할 수 있습니다.

노드 업그레이드 전략 작동 방식에 대한 자세한 내용은 노드 업그레이드 전략을 참조하세요.

노드 업그레이드 전략의 리소스 요구사항

일시 급증 업그레이드는 maxSurge가 0보다 크게 설정된 경우 추가 노드를 만들고 블루-그린 업그레이드는 일시적으로 노드 풀의 노드 수를 두 배로 늘립니다. 이를 위해서는 Compute Engine 할당량, 리소스 가용성, 예약 용량에 따라 리소스를 추가해야 합니다. 노드 풀에 리소스가 부족하면 업그레이드가 오래 걸리거나 실패할 수 있습니다.

프로젝트에 노드 업그레이드에 충분한 리소스가 있는지 확인하는 방법과 환경에 리소스가 제한된 경우에 수행할 작업에 대한 자세한 내용은 노드 업그레이드용 리소스 확인을 참조하세요.

자동 업그레이드

Standard 클러스터를 만들면 기본적으로 클러스터 및 노드 풀에서 자동 업그레이드가 사용 설정됩니다.

GKE는 클러스터 제어 영역 보안을 담당하고 새 GKE 버전이 자동 업그레이드 대상으로 선택된 경우 클러스터를 업그레이드합니다. 인프라 보안은 GKE에서 높은 우선순위로, 이러한 제어 영역이 정기적으로 업그레이드되며 중지될 수 없습니다. 그러나 유지보수 기간 및 유지보수 제외를 적용하여 제어 영역과 노드의 업그레이드를 일시적으로 정지할 수 있습니다.

GKE 공유 책임 모델의 일환으로 노드, 컨테이너, 포드의 보안은 고객이 책임집니다. 노드 자동 업그레이드는 기본적으로 사용 설정됩니다. 권장되지는 않지만 노드 자동 업그레이드 사용 중지는 가능합니다. 노드 자동 업그레이드를 선택 해제해도 클러스터의 제어 영역 업그레이드가 차단되지 않습니다. 노드 자동 업그레이드를 선택 해제한 경우 클러스터의 노드가 클러스터 버전과 호환되는 버전을 실행하고 해당 버전이 Kubernetes 버전 차이 지원 정책을 준수하는지 확인해야 합니다.

자동 업그레이드가 적용되는 경우(또는 적용되지 않는 경우)를 세부적으로 제어하려면 유지보수 기간 및 유지보수 제외를 구성하면 됩니다.

클러스터의 노드 풀이 클러스터 API와 호환되려면 제어 영역 버전의 부 버전을 기준으로 3버전 이상 뒤처지지 않아야 합니다. 또한 노드 풀 버전에 따라 각 노드에 설치되는 소프트웨어 패키지의 버전이 달라집니다. 노드 풀을 클러스터 버전으로 업데이트하는 것이 좋습니다.

클러스터를 출시 채널에 등록하면 노드는 항상 클러스터의 제어 영역 업그레이드를 완료한 후 지정된 노드 풀의 업그레이드를 시작하기 전까지 짧은 기간(현재 출시 버전에 따라 다르지만 보통 며칠) 동안 클러스터 자체와 동일한 버전의 GKE를 실행합니다. 자세한 정보는 출시 노트를 참조하세요.

자동 업그레이드 대상 버전이 선택되는 방식

새로운 GKE 버전은 정기적으로 출시되지만 자동 업그레이드 대상 버전이 바로 선택되지는 않습니다. 이전 버전을 부분적으로 실행하는 클러스터의 자동 업그레이드 대상으로 GKE에서 선택하는 GKE 버전은 클러스터를 충분히 사용하고 시간이 경과해도 안정적인 것으로 입증된 버전입니다.

새 자동 업그레이드 대상은 출시 노트에 발표됩니다. 사용 가능한 버전이 자동 업그레이드 대상으로 선택될 때까지 수동으로 업그레이드할 수 있습니다. 특정 버전이 클러스터 자동 업그레이드와 노드 자동 업그레이드 대상으로 몇 주 동안 선택되는 경우가 간혹 있습니다.

새 부 버전이 일반 안정화 버전으로 출시되면 일반적으로 사용 가능한 부 버전 중에서 가장 오래된 버전의 지원이 중단됩니다. 지원되지 않는 부 버전을 실행하는 클러스터는 자동으로 다음 부 버전으로 업그레이드됩니다.

부 버전(예: v1.14.x)이 같은 클러스터는 새 패치 출시 버전으로 자동 업그레이드될 수 있습니다.

출시 채널을 사용하면 버전을 직접 관리하는 대신 버전 안정성을 기준으로 클러스터 및 노드 풀 버전을 제어할 수 있습니다.

버전 출시 시기에 영향을 미치는 요소

새 버전에서 클러스터의 안정성과 신뢰성을 보장하기 위해 GKE는 버전 출시 중에 특정 관행을 따릅니다.

여기에는 다음을 비롯하여 다양한 관행이 포함됩니다.

  • GKE는 Google Cloud 리전과 영역에 변경사항을 점진적으로 출시합니다.
  • GKE는 출시 채널에 패치 버전을 점진적으로 출시합니다. 사용량이 누적되고 안정성이 계속 유지되면 패치가 안정적인 출시 채널로 승격되기 전에 빠른 출시 채널, 일반 출시 채널 순으로 지정된 적응 시간이 됩니다. 출시 채널에서 적응 시간 동안 패치 버전에 문제가 발견되면 해당 버전은 다음 채널로 승격되지 않으며 최신 패치 버전에서 문제가 해결됩니다.
  • GKE는 패치 버전에 유사한 적응 프로세스를 따라 부 버전을 점진적으로 출시합니다. 부 버전에는 더 중대한 변경사항이 있으므로 적응 시간이 더 늘어납니다.
  • 새 버전이 클러스터 그룹에 영향을 주면 GKE에서 자동 업그레이드를 지연시킬 수 있습니다. 예를 들어 GKE는 지원 중단된 API 또는 다음 부 버전에서 삭제될 기능에 노출됐다고 감지된 클러스터에 대한 자동 업그레이드를 일시중지합니다.
  • GKE는 비즈니스 연속성을 보장하기 위해 피크 기간(예: 주요 공휴일)에 새 버전 출시를 지연시킬 수 있습니다.

자동 업그레이드가 허용되는 경우 구성

기본적으로 인프라 보안을 유지하기 위해 자동 업그레이드가 언제든지 발생할 수 있습니다. 자동 업그레이드는 특히 리전 클러스터에 거의 영향을 주지 않습니다. 그러나 세부적으로 제어해야 하는 워크로드도 있을 수 있습니다. 유지보수 기간 및 유지보수 제외를 구성하여 자동 업그레이드가 허용되는 경우와 허용되지 않는 경우를 관리할 수 있습니다.

수동 업그레이드

클러스터 또는 노드 풀을 언제든지 사용 가능한 호환 버전으로 수동 업그레이드하도록 요청할 수 있습니다. 수동 업그레이드는 구성된 유지보수 기간 및 유지보수 제외를 무시합니다.

클러스터를 수동으로 업그레이드할 때 클러스터가 리전 클러스터인지 여부에 따라 가용성이 달라집니다.

  • 영역 클러스터의 경우 업그레이드가 진행되는 동안 제어 영역을 사용할 수 없습니다. 대부분의 경우 워크로드는 정상적으로 실행되지만 업그레이드 중에는 수정할 수 없습니다.

  • 리전 클러스터의 경우 업그레이드가 진행되는 동안 한 번에 하나의 제어 영역 복제본을 사용할 수 없지만 업그레이드 중에 클러스터의 고가용성이 유지됩니다.

제어 영역과 호환되는 버전으로의 노드 업그레이드를 수동으로 시작할 수 있습니다.

자동 업그레이드 실패에 대한 GKE 대응 방법

기본 Compute Engine 인스턴스 관련 문제 또는 Kubernetes 관련 문제로 인해 노드 풀 자동 업그레이드가 실패할 수 있습니다. 예를 들어 다음 상황에서는 자동 업그레이드가 실패할 수 있습니다.

  • 구성된 maxSurge 설정이 Compute Engine 리소스 할당량을 초과합니다.
  • 새 일시 급증 노드가 클러스터 제어 영역에 등록되지 않았습니다.
  • 노드 드레이닝 또는 삭제에 시간이 너무 오래 걸렸습니다.

개별 노드 업그레이드 관련 문제가 발생하면 각 시도 사이의 간격을 점차적으로 늘리면서 GKE가 업그레이드를 여러 번 재시도합니다. 노드 풀의 노드 업그레이드가 실패하면 GKE가 업그레이드된 노드를 롤백하지 않습니다. 대신 GKE는 모든 노드가 성공적으로 업그레이드될 때까지 노드 풀 자동 업그레이드를 다시 시도합니다.

일시 급증 노드 요청이 Compute Engine 할당량을 초과하기 때문에 노드 업그레이드가 실패할 경우 GKE는 할당량을 충족시키고 업그레이드를 계속하기 위해 시도되는 동시 일시 급증 노드 수를 줄입니다.

업그레이드 알림 받기

GKE는 버전 업그레이드 및 보안 게시판과 같은 클러스터 관련 이벤트에 대한 알림을 Pub/Sub에 게시하여 GKE에서 클러스터에 대한 정보를 수신할 수 있는 채널을 제공합니다.

자세한 내용은 클러스터 알림 수신을 참조하세요.

업그레이드 로그 확인

GKE는 기본적으로 제어 영역 및 노드 풀 업그레이드 이벤트를 Cloud Logging으로 로깅합니다. 업그레이드 이벤트 로그는 업그레이드 프로세스에 대한 가시성을 제공하며 필요한 경우 문제 해결에 중요한 정보를 포함합니다.

제어 영역 업그레이드 로그

다음 필터를 사용하여 클러스터 업그레이드 이벤트를 쿼리할 수 있습니다.

resource.type="gke_cluster"
protoPayload.metadata.operationType=~"(UPDATE_CLUSTER|UPGRADE_MASTER)"
resource.labels.cluster_name="CLUSTER_NAME"

이러한 로그는 구조화된 로깅 형식으로 기록됩니다. 다음 필드를 사용하여 업그레이드 이벤트 세부정보를 확인할 수 있습니다.



입력란 설명
protoPayload.metadata.operationType 클러스터 업그레이드 이벤트에는 UPGRADE_MASTER 및 UPDATE_CLUSTER의 두 가지 유형이 있습니다.
UPGRADE_MASTER는 Kubernetes 제어 영역 버전을 변경합니다.
UPDATE_CLUSTER는 업데이트에서 Kubernetes 제어 영역 버전을 변경하지 않음을 의미합니다.
두 클러스터 업그레이드 유형 모두로 인해 영역 클러스터의 제어 영역 가용성이 손실될 수 있습니다. 자세한 내용은 클러스터 및 노드 풀 업그레이드의 작동 방식을 참조하세요.
protoPayload.methodName 이 필드에서는 클러스터 업그레이드를 트리거한 API를 보여줍니다.
google.container.v1.ClusterManager.UpdateCluster: 수동 제어 영역 업그레이드
google.container.internal.ClusterManagerInternal.UpdateClusterInternal: 자동 제어 영역 업그레이드
google.container.v1.ClusterManager.PatchCluster: 클러스터 구성 변경
protoPayload.metadata.previousMasterVersion 이 필드는 MASTER_UPGRADE 작업 유형에만 사용되며 업그레이드 전에 사용된 이전 제어 영역 버전을 포함합니다.
protoPayload.metadata.currentMasterVersion 이 필드는 MASTER_UPGRADE 작업 유형에만 사용되며 업그레이드 후에 사용되는 새로운 제어 영역 버전 번호를 포함합니다.

노드 풀 업그레이드 로그

노드 풀 업그레이드 이벤트를 보려면 다음 쿼리를 사용합니다.

resource.type="gke_nodepool"
protoPayload.metadata.operationType="UPGRADE_NODES"
resource.labels.cluster_name="CLUSTER_NAME"

업그레이드 이벤트에 대한 세부정보를 보려면 다음 필드를 사용합니다.

protoPayload.methodName 필드에는 다음과 같이 업그레이드가 수동으로 또는 자동으로 트리거되었는지 여부가 표시됩니다.

구성요소 업그레이드

GKE는 클러스터의 특정 기능을 지원하기 위해 워커 노드에서 시스템 워크로드를 실행합니다. 예를 들어 gke-metadata-server 시스템 워크로드는 GKE용 워크로드 아이덴티티 제휴를 지원합니다. GKE는 이러한 워크로드의 상태를 담당합니다. 이러한 구성요소에 대한 자세한 내용은 관련 기능에 대한 문서를 참조하세요.

구성요소에 새로운 기능 또는 수정사항이 제공되는 경우 GKE는 해당 패치 버전이 포함된 패치 버전을 표시합니다. 최신 버전의 구성 요소를 가져오려면 관련 문서나 출시 노트를 참조하여 컨트롤 플레인 또는 노드를 적절한 버전으로 업그레이드하는 방법을 확인하세요.

다음 단계