이 페이지에서는 Google Kubernetes Engine(GKE)이 워크로드 수요에 따라 Standard 클러스터의 노드 풀 크기를 자동으로 조절하는 방법을 설명합니다. 수요가 많은 경우 클러스터 자동 확장 처리에서 노드를 노드 풀에 추가합니다. 클러스터 자동 확장 처리를 구성하는 방법은 클러스터 자동 확장을 참조하세요.
이 페이지는 용량 및 인프라 요구를 계획하고 회사 또는 사업부에서 최저 수준의 총소유비용을 보장하기 위해 시스템 아키텍처 및 리소스를 최적화하는 관리자, 설계자, 운영자를 위해 작성되었습니다. Google Cloud 콘텐츠에서 참조하는 일반적인 역할과 예시 태스크에 대한 자세한 내용은 일반 GKE 기업 사용자 역할 및 작업을 참조하세요.
Autopilot 클러스터를 사용하면 노드 풀이 노드 자동 프로비저닝을 통해 자동으로 프로비저닝되고 워크로드 요구사항이 충족되도록 자동으로 확장되므로 노드 프로비저닝이나 노드 풀 관리에 신경을 쓰지 않아도 됩니다.
조직의 관리자 및 설계자, 개발자 또는 애플리케이션 구현 및 유지보수를 담당하는 기타 팀과 함께 클러스터 구성을 계획하고 설계합니다.
클러스터 자동 확장 처리를 사용하는 이유
GKE의 클러스터 자동 확장 처리는 워크로드의 요구에 따라 지정된 노드 풀의 노드 수를 자동으로 조절합니다. 수요가 적은 경우 클러스터 자동 확장 처리에서 지정된 최소 크기로 축소 조정합니다. 이를 통해 필요한 경우 워크로드 가용성을 높이고 비용을 통제할 수 있습니다. 수동으로 노드를 추가, 삭제하거나 노드 풀을 과도하게 프로비저닝할 필요가 없습니다. 대신 노드 풀의 최소 및 최대 크기를 지정하면 나머지는 자동으로 지정됩니다.
클러스터를 자동 확장하는 동안 리소스가 삭제되거나 이동되면 워크로드가 일시적으로 중단될 수 있습니다. 예를 들어 워크로드가 단일 복제본이 포함된 컨트롤러로 구성되었으면, 현재 노드가 삭제된 경우 해당 복제본의 포드를 다른 노드에서 다시 예약할 수 있습니다. 클러스터 자동 확장 처리를 사용하기 전에 워크로드가 잠재적인 중단을 견딜 수 있도록 설계하거나 중요한 포드가 중단되지 않았는지 확인합니다.
워크로드의 중단 허용 범위를 늘리려면 배포와 같은 여러 복제본이 포함된 컨트롤러를 사용하여 워크로드를 배포합니다.
새 노드의 워크로드가 더 빠르게 시작하도록 이미지를 로컬로 동시에 캐시하는 동안 적격한 컨테이너 이미지에서 필요한 이미지 데이터를 원격으로 스트리밍하는 이미지 스트리밍을 사용해서 클러스터 자동 확장 처리 성능을 향상시킬 수 있습니다.
클러스터 자동 확장 처리 작동 방식
클러스터 자동 확장 처리는 노드풀에 따라 작동합니다. 클러스터 자동 확장 처리를 사용하여 노드 풀을 구성할 때 노드 풀의 최소 및 최대 크기를 지정합니다.
클러스터 자동 확장 처리는 노드 풀의 기본 Compute Engine 관리형 인스턴스 그룹(MIG)에서 가상 머신(VM) 인스턴스를 추가하거나 삭제하여 자동으로 노드 풀의 크기를 늘리거나 줄입니다. 클러스터 자동 확장 처리에서는 (실제 리소스 사용률이 아닌) 노드 풀의 노드에서 실행되는 포드의 리소스 요청에 따라 이러한 확장 결정을 내립니다. 주기적으로 포드 및 노드의 상태를 확인하고 작업을 수행합니다.
- 현재 노드서 포드를 예약할 수 없으면 클러스터 자동 확장 처리가 노드 풀의 최대 크기까지 노드를 추가합니다. 클러스터 자동 확장 처리가 클러스터 크기를 변경하는 시기에 대한 자세한 내용은 클러스터 자동 확장 처리가 클러스터 크기를 변경하는 경우를 참조하세요.
- GKE가 노드 풀에 새 노드를 추가하기로 결정한 경우 클러스터 자동 확장 처리는 필요에 따라 노드풀 또는 클러스터당 한도까지 노드를 추가합니다.
- 클러스터 자동 확장 처리는 다른 노드 만들기를 시작하기 전에 하나의 노드가 준비될 때까지 기다리지 않습니다. GKE에서 만들 노드 수가 결정되면 노드 만들기가 병렬로 수행됩니다. 목표는 예약할 수 없는 포드가
Active로 전환되는 데 필요한 시간을 최소화하는 것입니다. - 할당량 소진으로 인해 일부 노드가 생성되지 않으면 리소스를 성공적으로 예약할 수 있을 때까지 클러스터 자동 확장 처리가 기다립니다.
- 노드의 사용률이 적고 노드 풀에 있는 노드 수가 적은 상태에서도 모든 포드를 예약할 수 있는 경우 클러스터 자동 확장 처리는 노드를 제거하고 노드 풀의 최소 크기까지 축소합니다. 클러스터에 있는 다른 노드로 이동할 수 없는 노드에 포드가 있으면 클러스터 자동 확장 처리가 해당 노드를 축소하려고 시도하지 않습니다. 포드를 다른 노드로 이동할 수 있지만 시간 초과 기간(현재 10분) 후에 노드를 정상적으로 드레이닝할 수 없으면 노드가 강제로 종료됩니다. 유예 기간은 GKE 클러스터에 구성할 수 없습니다. 축소 작동 방식에 대한 자세한 내용은 클러스터 자동 확장 처리 문서를 참조하세요.
예약할 수 없는 포드에 대해 클러스터 자동 확장 처리가 클러스터를 검사하는 빈도는 주로 클러스터 크기에 따라 달라집니다. 소규모 클러스터에서는 검사가 몇 초 간격으로 수행될 수 있습니다. 이 검사에 필요한 정확한 시간은 정의할 수 없습니다.
포드에서 충분하지 않은 리소스가 요청되었거나 기본값으로 설정되어서 노드에 리소스 부족 문제가 발생할 경우에 클러스터 자동 확장 처리는 이러한 상황을 해결하지 않습니다. 모든 워크로드에 명시적인 리소스 요청을 수행하여 클러스터 자동 확장 처리가 가능한 한 정확하게 작동하도록 보장할 수 있습니다.
클러스터 노드에 대해 Compute Engine 관리형 인스턴스 그룹 자동 확장을 사용 설정하지 마세요. GKE의 클러스터 자동 확장 처리는 Compute Engine 자동 확장과 구분됩니다. 이로 인해 Compute Engine 자동 확장 처리가 GKE의 클러스터 자동 확장 처리와 충돌하게 되므로 노드 풀이 확장되거나 축소되지 않을 수 있습니다.
작동 조건
노드 풀 크기를 조정할 때 클러스터 자동 확장 처리는 다음을 가정합니다.
- 복제된 모든 포드를 다른 일부 노드에서 다시 시작할 수 있으며, 결과적으로 일시적인 중단이 발생할 수 있습니다.
- 사용자 또는 관리자가 노드를 수동으로 관리하지 않습니다. 클러스터 자동 확장 처리는 사용자가 수행하는 수동 노드 관리 작업을 재정의할 수 있습니다.
- 단일 노드 풀의 모든 노드에 동일한 라벨 집합이 포함됩니다.
- 클러스터 자동 확장 처리는 여러 풀에서 인스턴스 유형의 상대적 비용을 고려하고, 가능한 한 비용이 가장 적은 노드 풀을 확장하려고 시도합니다. 클러스터 자동 확장 처리는 선점 가능한 스팟 VM을 포함하는 노드 풀 비용 감소를 고려합니다.
- 클러스터 자동 확장 처리는 포드를 예약하기 전에 초기화 컨테이너 요청을 고려합니다 초기화 컨테이너 요청은 노드에서 사용 가능한 할당되지 않은 리소스를 사용할 수 있으므로, 포드가 예약되지 않도록 방지할 수 있습니다. 클러스터 자동 확장 처리는 Kubernetes에 사용되는 것과 동일한 요청 계산 규칙을 따릅니다. 자세한 내용은 초기화 매개변수 사용에 관한 Kubernetes 문서를 참조하세요.
- 최초 클러스터 또는 노드 풀 생성 이후 수동으로 추가된 라벨은 추적되지 않습니다. 클러스터 자동 확장 처리에서 생성된 노드에는 노드 풀 생성 시
--node-labels로 지정된 라벨이 할당됩니다. - GKE 버전 1.21 이하에서는 클러스터 자동 확장 처리가 노드 풀의 기존 노드 taint 정보를 사용하여 전체 노드 풀을 나타냅니다. GKE 버전 1.22부터 클러스터 자동 확장 처리는 클러스터의 기존 노드와 노드 풀에 있는 정보를 결합합니다. 클러스터 자동 확장 처리는 또한 노드 및 노드 풀에 대해 수행하는 수동 변경사항을 감지합니다.
애플리케이션에 중단에 대한 톨러레이션(toleration)이 없으면 클러스터 자동 확장 처리를 사용 설정하지 마세요.
영역 간 균형 조정
노드 풀에 동일한 인스턴스 유형의 관리형 인스턴스 그룹이 여러 개 포함된 경우 수직 확장할 때 클러스터 자동 확장 처리는 이러한 관리형 인스턴스 그룹 크기의 균형을 조정합니다. 이는 노드 풀의 여러 영역에 있는 관리형 인스턴스 그룹 간에 고르지 않은 노드 분배를 차단하는 데 도움이 됩니다. GKE는 축소할 때 자동 확장 정책을 고려하지 않습니다.
클러스터 자동 확장 처리는 확장 이벤트 중에 영역 간에만 균형을 조정합니다. 클러스터 자동 확장 처리는 노드 풀의 기반 관리형 인스턴스 그룹의 상대적인 크기에 관계없이 사용량이 적은 노드를 자동으로 축소하며 이로 인해 노드가 영역 간에 균일하지 않게 분산될 수 있습니다.
위치 정책
GKE 버전 1.24.1-gke.800부터는 클러스터 자동 확장 처리의 위치 정책을 변경할 수 있습니다. 다음 값 중 하나로 location_policy 플래그를 지정하여 클러스터 자동 확장 처리 배포 정책을 제어할 수 있습니다.
BALANCED: 자동 확장 처리가 포드 요구사항과 각 영역의 리소스 가용성을 고려합니다. 클러스터 자동 확장 처리는 특정 영역의 가용 용량 및 수직 확장을 트리거한 포드의 영역 어피니티를 포함한 여러 요소를 고려하므로 유사한 노드 그룹의 크기가 정확히 같지 않을 수도 있습니다.ANY: 클러스터 자동 확장 처리에서 사용되지 않은 예약의 사용률에 우선 순위를 지정하고 가용 리소스의 현재 제약조건을 고려합니다.
스팟 VM을 사용하거나 영역 간에 같지 않은 VM 예약을 사용하려는 경우에 ANY 정책을 사용합니다.
예약
GKE 버전 1.27부터 클러스터 자동 확장 처리는 확장 관련 결정을 내릴 때 항상 예약을 고려합니다. 확장할 노드 풀을 선택할 때는 노드 풀이 가장 효율적인 것이 아니더라도 사용되지 않은 예약과 일치하는 노드 풀이 우선 선택됩니다. 또한 여러 영역별 확장의 균형을 조정할 때는 항상 사용되지 않은 예약이 우선 선택됩니다.
기본값
Spot VM 노드 풀의 경우 기본 클러스터 자동 확장 처리 배포 정책은 ANY입니다. 이 정책에서 Spot VM은 선점될 위험이 낮습니다.
비선점형 노드 풀의 경우 기본 클러스터 자동 확장 처리 배포 정책은 BALANCED입니다.
최소 및 최대 노드 풀 크기
새 노드 풀을 만들 때 클러스터에 있는 각 노드 풀의 최소 및 최대 크기를 지정할 수 있으며, 클러스터 자동 확장 처리는 이러한 확장 제약조건 내에서 크기 조절을 결정합니다. 최소 크기를 업데이트하려면 새 최솟값을 지정한 후 클러스터의 크기를 새 제약조건 내의 크기로 수동 조정합니다. 그러면 클러스터 자동 확장 처리가 새 제약조건을 기준으로 크기 조절 결정을 내립니다.
| 현재 노드 풀 크기 | 클러스터 자동 확장 처리 작업 | 확장 제약조건 |
|---|---|---|
| 지정한 최솟값보다 낮음 | 클러스터 자동 확장 처리가 대기 중인 포드를 프로비저닝하도록 확장됩니다. 축소가 사용 중지되었습니다. | 노드 풀은 지정한 값 미만으로 축소되지 않습니다. |
| 지정한 최솟값 및 최댓값 이내 | 클러스터 자동 확장처리가 수요에 따라 확장 또는 축소됩니다. | 노드 풀이 지정된 크기 한도 내에 유지됩니다. |
| 지정한 최댓값보다 큼 | 클러스터 자동 확장 처리가 안전하게 삭제할 수 있는 노드만 축소합니다. 확장이 사용 중지됩니다. | 노드 풀은 지정된 값을 초과하여 확장되지 않습니다. |
Standard 클러스터에서 클러스터 자동 확장 처리는 클러스터를 0개 노드로 자동 축소하지 않습니다. 시스템 포드를 실행하려면 항상 클러스터에서 하나 이상의 노드를 사용할 수 있어야 합니다. 또한 노드를 수동 삭제하여 현재 노드 수가 0이면 클러스터 자동 확장 처리 및 노드 자동 프로비저닝이 0개 노드 클러스터에서 확장될 수 있습니다.
자동 확장 처리 결정에 대해 자세히 알아보려면 클러스터 자동 확장 처리 제한사항을 참조하세요.
자동 확장 제한
노드 풀을 확장할 때 사용할 클러스터 자동 확장 처리의 최소 및 최대 노드 수를 설정할 수 있습니다. --min-nodes 및 --max-nodes 플래그를 사용하여 영역당 최소 및 최대 노드 수를 설정합니다.
GKE 버전 1.24부터는 새 클러스터에 --total-min-nodes 및 --total-max-nodes 플래그를 사용할 수 있습니다. 이러한 플래그는 모든 영역의 노드 풀에 있는 총 노드 수의 최소 수와 최대 수를 설정합니다.
최소 및 최대 노드 예시
다음 명령어는 초기에 영역 3개 간에 노드 6개가 포함되고 영역당 최소 노드 수가 1개이고 영역당 최대 노드 수가 4개인 자동 확장 멀티 영역 클러스터를 만듭니다.
gcloud container clusters create example-cluster \
--num-nodes=2 \
--zone=us-central1-a \
--node-locations=us-central1-a,us-central1-b,us-central1-f \
--enable-autoscaling --min-nodes=1 --max-nodes=4
이 예시에서 클러스터의 총 크기는 3개 영역에 분산된 3~12개의 노드일 수 있습니다. 영역 중 하나가 실패할 경우 클러스터의 총 크기는 2~8개의 노드일 수 있습니다.
총 노드 예시
GKE 버전 1.24 이상에서 사용할 수 있는 다음 명령어는 초기에 영역 3개 간에 노드 6개가 포함되고 모든 영역에서 노드 풀의 노드 최소 수가 3개이고 최대 노드 수가 12개인 자동 확장 멀티 영역 클러스터를 만듭니다.
gcloud container clusters create example-cluster \
--num-nodes=2 \
--zone=us-central1-a \
--node-locations=us-central1-a,us-central1-b,us-central1-f \
--enable-autoscaling --total-min-nodes=3 --total-max-nodes=12
이 예시에서는 영역 간 분산에 관계없이 클러스터의 총 크기가 노드 3~12개 사이일 수 있습니다.
프로필 자동 확장
노드를 언제 제거할지 결정하기 위해서는 사용률 기준 최적화와 리소스의 가용성 사이에서 절충이 필요합니다. 사용률이 낮은 노드를 삭제하면 클러스터 사용률이 향상되지만, 리소스가 실행되기 전에 다시 프로비저닝될 때까지 새 워크로드가 기다려야 할 수 있습니다.
이러한 결정을 내릴 때 사용할 자동 확장 프로필을 지정할 수 있습니다. 사용 가능한 프로필은 다음과 같습니다.
balanced: 기본 프로필은 수신 포드에 즉시 사용 가능한 리소스를 더 많이 유지하여 표준 클러스터에 대해 활성 상태로 유지하는 데 필요한 시간을 줄여줍니다. Autopilot 클러스터에는balanced프로필을 사용할 수 없습니다.optimize-utilization: 클러스터에 예비 리소스를 유지하는 것보다 사용률 최적화에 우선순위를 둡니다. 이 프로필을 사용 설정하면 클러스터 자동 확장 처리가 클러스터를 더 공격적으로 축소합니다. GKE가 더 많은 노드를 삭제하고 더 빠르게 노드를 삭제할 수 있습니다. GKE가 이미 CPU, 메모리 또는 GPU 할당이 높은 노드에서 포드를 예약하는 것을 선호합니다. 그러나 동일한 배포, StatefulSet 또는 서비스에 속하는 포드가 노드 전체에 분산되는 등 다른 요인이 예약에 영향을 미칩니다.
optimize-utilization 자동 확장 프로필은 클러스터 자동 확장 처리가 활용률이 낮은 노드를 식별하고 삭제하는 데 도움이 됩니다. 이러한 최적화를 달성하기 위해 GKE는 포드 사양에서 스케줄러 이름을 gke.io/optimize-utilization-scheduler로 설정합니다. 커스텀 스케줄러를 지정하는 포드는 영향을 받지 않습니다.
다음 명령어는 기존 클러스터에서 optimize-utilization 자동 확장 프로필을 사용 설정합니다.
gcloud container clusters update CLUSTER_NAME \
--autoscaling-profile optimize-utilization
포드 예약 및 중단 고려
축소 시에 클러스터 자동 확장 처리는 포드에 설정된 예약 및 축출 규칙을 고려합니다. 이러한 제한에 따라 자동 확장 처리로 노드가 삭제되지 않을 수 있습니다. 다음 조건의 포드가 포함된 경우에는 노드 삭제가 방해될 수 있습니다.
- 포드의 어피니티 또는 안티어피니티 규칙에 따라 재예약이 방지됩니다.
- 포드가 배포, StatefulSet, 작업 또는 ReplicaSet와 같은 컨트롤러로 관리되지 않습니다.
- 포드에 로컬 스토리지가 포함되고 GKE 제어 영역 버전이 1.22 미만입니다. 제어 영역 버전 1.22 이상이 있는 GKE 클러스터에서 로컬 스토리지가 있는 포드는 더 이상 축소를 차단하지 않습니다.
- 포드에
"cluster-autoscaler.kubernetes.io/safe-to-evict": "false"주석이 있습니다. - 노드 삭제가 구성된 PodDisruptionBudget을 초과합니다.
클러스터 자동 확장 처리 및 장애 방지에 대한 자세한 내용은 클러스터 자동 확장 처리 FAQ에서 다음 항목을 참조하세요.
- 축소는 어떻게 작동하나요?
- 클러스터 자동 확장 처리가 축소되면 PodDisruptionBudget과 함께 작동하나요?
- 클러스터 자동 확장 처리에서 노드를 제거하지 못하게 할 수 있는 포드의 유형은 무엇입니까?
- GKE에서 클러스터 자동 확장 처리를 조정하는 방법은 무엇인가요?
GKE에서 TPU 자동 확장
GKE는 Tensor Processing Unit(TPU)을 지원하여 머신러닝 워크로드를 가속화합니다. 단일 호스트 TPU 슬라이스 노드 풀과 멀티 호스트 TPU 슬라이스 노드 풀 모두 자동 확장 및 자동 프로비저닝을 지원합니다.
GKE 클러스터에서 --enable-autoprovisioning 플래그를 사용하면 GKE는 대기 중인 워크로드의 요구사항을 충족하는 TPU 버전 및 토폴로지를 사용하여 단일 호스트 또는 멀티 호스트 TPU 슬라이스 노드 풀을 만들거나 삭제합니다.
--enable-autoscaling을 사용하는 경우 GKE는 다음과 같이 해당 유형을 기준으로 노드 풀을 확장합니다.
단일 호스트 TPU 슬라이스 노드 풀: GKE는 기존 노드 풀에서 TPU 노드를 추가하거나 삭제합니다. 노드 풀은 0부터 --max-nodes 및 --total-max-nodes 플래그에 따라 결정되는 노드 풀의 최대 크기 사이의 TPU 노드 수를 포함할 수 있습니다. 노드 풀이 확장되면 노드 풀에서 모든 TPU 노드의 머신 유형 및 토폴로지는 동일합니다. 단일 호스트 TPU 슬라이스 노드 풀을 만드는 방법에 대한 자세한 내용은 노드 풀 만들기를 참조하세요.
멀티 호스트 TPU 슬라이스 노드 풀: GKE는 노드 풀을 0부터 TPU 토폴로지를 충족하는 데 필요한 노드 수로 원자적으로 수직 확장합니다. 예를 들어, 머신 유형이
ct5lp-hightpu-4t이고 토폴로지가16x16인 TPU 노드 풀의 경우, 노드 풀에는 64개의 노드가 포함됩니다. GKE 자동 확장 처리는 이 노드 풀에 노드가 정확히 0개 또는 64개 있도록 합니다. 축소하면 GKE는 예약된 모든 포드를 제거하고 전체 노드 풀을 0으로 드레이닝합니다. 멀티 호스트 TPU 슬라이스 노드 풀을 만드는 방법에 대한 자세한 내용은 노드 풀 만들기를 참조하세요.
추가 정보
클러스터 자동 확장 처리에 대한 자세한 내용은 오픈소스 Kubernetes 프로젝트의 자동 확장 처리 FAQ를 참조하세요.
제한사항
클러스터 자동 확장 처리에는 다음과 같은 제한사항이 있습니다.
- 로컬 PersistentVolume은 클러스터 자동 확장 처리에서 지원되지 않습니다.
- 1.24.5-gke.600 이전 버전의 GKE 제어 영역에서 포드가 임시 스토리지를 요청하면 클러스터 자동 확장 처리는 로컬 SSD를 임시 스토리지로 사용하는 노드 풀(노드 0개)을 확장할 수 없습니다.
- 클러스터 크기 제한: 최대 15,000개 노드. 이 크기의 클러스터를 실행할 때 다른 클러스터 한도와 권장사항을 고려합니다.
- 축소할 때는 노드를 강제 종료하기 전에 노드의 Pod를 다른 노드에 재예약하기 위해 클러스터 자동 확장 처리에 10분의 유예 종료 기간을 적용합니다.
- 가끔 클러스터 자동 확장 처리가 완전히 축소되지 못하고 축소 후에 추가 노드가 존재하는 경우가 있습니다. 이 현상은 필요한 시스템 포드가 다른 노드에 예약된 경우 발생할 수 있습니다. 이러한 포드가 다른 노드로 이동하기 위한 트리거가 없기 때문입니다. 사용량이 적은 노드가 두 개 있지만 축소되지 않습니다. 이유가 무엇인가요?를 참조하세요. 포드 중단 예산을 구성하여 이 제한을 우회할 수 있습니다.
- 변경된 필터를 사용한 커스텀 예약은 지원되지 않습니다.
- 포드의
-10아래에PriorityClass값이 있으면 노드가 확장되지 않습니다. 클러스터 자동 확장 처리가 포드 우선순위 및 선점으로 작동하는 방식 자세히 알아보기 - 클러스터 자동 확장 처리에 새 노드 또는 포드를 추가하는 데 사용할 할당되지 않은 IP 주소 공간이 부족하여 확장 실패가 발생할 수 있으며, 이 경우 이유가
scale.up.error.ip.space.exhausted인eventResult이벤트로 표시됩니다. 기본 서브넷을 확장하여 노드에 IP 주소를 추가하거나 연속되지 않은 다중 포드 CIDR을 사용하여 포드에 새 IP 주소를 추가할 수 있습니다. 자세한 내용은 포드의 IP 여유 공간 부족을 참조하세요. - GKE 클러스터 자동 확장 처리는 오픈소스 Kubernetes 프로젝트의 클러스터 자동 확장 처리와 다릅니다. GKE 클러스터 자동 확장 처리의 매개변수는 클러스터 구성에 따라 다르며, 변경될 수 있습니다. 자동 확장 동작을 보다 세부적으로 제어하려면 GKE 클러스터 자동 확장 처리를 사용 중지하고 오픈소스 Kubernetes의 클러스터 자동 확장 처리를 실행합니다. 하지만 오픈 소스 Kubernetes에는 Google Cloud 지원이 없습니다.
알려진 문제
- GKE 제어 영역 버전 1.22 이하에서는 GKE 클러스터 자동 확장 처리가 빈(노드 0개) 클러스터에서 모든 노드 풀 수직 확장을 중지합니다. GKE 버전 1.22 이상에서는 이 동작이 발생하지 않습니다.