GKE 클러스터 자동 확장 정보

이 페이지에서는 Google Kubernetes Engine(GKE)이 워크로드 수요에 따라 Standard 클러스터의 노드 풀 크기를 자동으로 조절하는 방법을 설명합니다. 수요가 많은 경우 클러스터 자동 확장 처리에서 노드를 노드 풀에 추가합니다. 클러스터 자동 확장 처리를 구성하는 방법은 클러스터 자동 확장을 참조하세요.

이 페이지는 용량 및 인프라 요구를 계획하고 회사 또는 사업부에서 최저 수준의 총소유비용을 얻기 위해 시스템 아키텍처 및 리소스를 최적화하는 관리자, 설계자, 운영자를 위해 작성되었습니다. Google Cloud 콘텐츠에서 참조하는 일반적인 역할 및 예시 태스크에 대해 자세히 알아보려면 일반 GKE Enterprise 사용자 역할 및 태스크를 참조하세요.

Autopilot 클러스터를 사용하면 노드 풀이 노드 자동 프로비저닝을 통해 자동으로 프로비저닝되고 워크로드 요구사항이 충족되도록 자동으로 확장되므로 노드 프로비저닝이나 노드 풀 관리에 신경을 쓰지 않아도 됩니다.

이 페이지를 읽기 전에 기본적인 Kubernetes 개념과 리소스 요청 및 한도의 작동 방식을 숙지해야 합니다.

클러스터 자동 확장 처리를 사용하는 이유

GKE의 클러스터 자동 확장 처리는 워크로드의 요구에 따라 지정된 노드 풀의 노드 수를 자동으로 조절합니다. 수요가 적은 경우 클러스터 자동 확장 처리에서 지정된 최소 크기로 축소 조정합니다. 이를 통해 필요한 경우 워크로드 가용성을 높이고 비용을 통제할 수 있습니다. 수동으로 노드를 추가, 삭제하거나 노드 풀을 과도하게 프로비저닝할 필요가 없습니다. 대신 노드 풀의 최소 및 최대 크기를 지정하면 나머지는 자동으로 지정됩니다.

클러스터를 자동 확장하는 동안 리소스가 삭제되거나 이동되면 워크로드가 일시적으로 중단될 수 있습니다. 예를 들어 워크로드가 단일 복제본이 포함된 컨트롤러로 구성되었으면, 현재 노드가 삭제된 경우 해당 복제본의 Pod를 다른 노드에서 다시 예약할 수 있습니다. 클러스터 자동 확장 처리를 사용하기 전에 워크로드가 잠재적인 중단을 견딜 수 있도록 설계하거나 중요한 포드가 중단되지 않았는지 확인합니다.

새 노드의 워크로드가 더 빠르게 시작하도록 이미지를 로컬로 동시에 캐시하는 동안 적격한 컨테이너 이미지에서 필요한 이미지 데이터를 원격으로 스트리밍하는 이미지 스트리밍을 사용해서 클러스터 자동 확장 처리 성능을 향상시킬 수 있습니다.

클러스터 자동 확장 처리 작동 방식

클러스터 자동 확장 처리는 노드풀에 따라 작동합니다. 클러스터 자동 확장 처리를 사용하여 노드 풀을 구성할 때 노드 풀의 최소 및 최대 크기를 지정합니다.

클러스터 자동 확장 처리는 노드 풀의 기본 Compute Engine 관리형 인스턴스 그룹(MIG)에서 가상 머신(VM) 인스턴스를 추가하거나 삭제하여 자동으로 노드 풀의 크기를 늘리거나 줄입니다. 클러스터 자동 확장 처리에서는 (실제 리소스 사용률이 아닌) 노드 풀의 노드에서 실행되는 포드의 리소스 요청에 따라 이러한 확장 결정을 내립니다. 주기적으로 Pod 및 노드의 상태를 확인하고 작업을 수행합니다.

• 현재 노드서 포드를 예약할 수 없으면 클러스터 자동 확장 처리가 노드 풀의 최대 크기까지 노드를 추가합니다. 클러스터 자동 확장 처리가 클러스터 크기를 변경하는 시기에 대한 자세한 내용은 클러스터 자동 확장 처리가 클러스터 크기를 변경하는 경우를 참조하세요.
• GKE가 노드 풀에 새 노드를 추가하기로 결정한 경우 클러스터 자동 확장 처리는 필요에 따라 노드풀 또는 클러스터당 한도까지 노드를 추가합니다.
• 클러스터 자동 확장 처리는 다른 노드 만들기를 시작하기 전에 하나의 노드가 준비될 때까지 기다리지 않습니다. GKE에서 만들 노드 수가 결정되면 노드 만들기가 병렬로 수행됩니다. 목표는 예약할 수 없는 포드가 Active로 전환되는 데 필요한 시간을 최소화하는 것입니다.
• 할당량 소진으로 인해 일부 노드가 생성되지 않으면 리소스를 성공적으로 예약할 수 있을 때까지 클러스터 자동 확장 처리가 기다립니다.
• 노드의 사용률이 적고 노드 풀에 있는 노드 수가 적은 상태에서도 모든 포드를 예약할 수 있는 경우 클러스터 자동 확장 처리는 노드를 제거하고 노드 풀의 최소 크기까지 축소합니다. 클러스터에 있는 다른 노드로 이동할 수 없는 노드에 포드가 있으면 클러스터 자동 확장 처리가 해당 노드를 축소하려고 시도하지 않습니다. 포드를 다른 노드로 이동할 수 있지만 시간 초과 기간(현재 10분) 후에 노드를 정상적으로 드레이닝할 수 없으면 노드가 강제로 종료됩니다. 유예 기간은 GKE 클러스터에 구성할 수 없습니다. 축소 작동 방식에 대한 자세한 내용은 클러스터 자동 확장 처리 문서를 참조하세요.

예약할 수 없는 포드에 대해 클러스터 자동 확장 처리가 클러스터를 검사하는 빈도는 주로 클러스터 크기에 따라 달라집니다. 소규모 클러스터에서는 검사가 몇 초 간격으로 수행될 수 있습니다. 이 검사에 필요한 정확한 시간은 정의할 수 없습니다.

포드에서 충분하지 않은 리소스가 요청되었거나 기본값으로 설정되어서 노드에 리소스 부족 문제가 발생할 경우에 클러스터 자동 확장 처리는 이러한 상황을 해결하지 않습니다. 모든 워크로드에 명시적인 리소스 요청을 수행하여 클러스터 자동 확장 처리가 가능한 한 정확하게 작동하도록 보장할 수 있습니다.

클러스터 노드에 대해 Compute Engine 관리형 인스턴스 그룹 자동 확장을 사용 설정하지 마세요. GKE의 클러스터 자동 확장 처리는 Compute Engine 자동 확장과 구분됩니다. 이로 인해 Compute Engine 자동 확장 처리가 GKE의 클러스터 자동 확장 처리와 충돌하게 되므로 노드 풀이 확장되거나 축소되지 않을 수 있습니다.

작동 조건

노드 풀 크기를 조정할 때 클러스터 자동 확장 처리는 다음을 가정합니다.

• 복제된 모든 포드를 다른 일부 노드에서 다시 시작할 수 있으며, 결과적으로 일시적인 중단이 발생할 수 있습니다.
• 사용자 또는 관리자가 노드를 수동으로 관리하지 않습니다. 클러스터 자동 확장 처리는 사용자가 수행하는 수동 노드 관리 작업을 재정의할 수 있습니다.
• 단일 노드 풀의 모든 노드에 동일한 라벨 집합이 포함됩니다.
• 클러스터 자동 확장 처리는 여러 풀에서 인스턴스 유형의 상대적 비용을 고려하고, 가능한 한 비용이 가장 적은 노드 풀을 확장하려고 시도합니다. 그러나 클러스터 자동 확장 처리의 이 동작에는 다음 조건이 적용됩니다.
  • 클러스터 자동 확장 처리는 선점형 스팟 VM을 포함하는 노드 풀 비용 감소를 고려합니다. 하지만 클러스터 자동 확장 처리는 각 영역의 리소스 가용성도 고려하며, 비용이 더 높지만 사용 가능한 리소스를 선택할 수도 있습니다.
  • 여러 노드 풀에서 스팟 VM을 사용하는 경우 클러스터 자동 확장 처리는 가장 저렴한 옵션을 자동으로 선택하지 않습니다. 비용 효율적인 Spot VM 사용을 최적화하고 이러한 시나리오를 방지하려면 커스텀 컴퓨팅 클래스를 사용하는 것이 좋습니다.
• 클러스터 자동 확장 처리는 포드를 예약하기 전에 초기화 컨테이너 요청을 고려합니다 초기화 컨테이너 요청은 노드에서 사용 가능한 할당되지 않은 리소스를 사용할 수 있으므로, 포드가 예약되지 않도록 방지할 수 있습니다. 클러스터 자동 확장 처리는 Kubernetes에 사용되는 것과 동일한 요청 계산 규칙을 따릅니다. 자세한 내용은 초기화 매개변수 사용에 관한 Kubernetes 문서를 참조하세요.
• 최초 클러스터 또는 노드 풀 생성 이후 수동으로 추가된 라벨은 추적되지 않습니다. 클러스터 자동 확장 처리에서 생성된 노드에는 노드 풀 생성 시 --node-labels로 지정된 라벨이 할당됩니다.
• GKE 버전 1.21 이하에서는 클러스터 자동 확장 처리가 노드 풀의 기존 노드 taint 정보를 사용하여 전체 노드 풀을 나타냅니다. GKE 버전 1.22부터 클러스터 자동 확장 처리는 클러스터의 기존 노드와 노드 풀에 있는 정보를 결합합니다. 클러스터 자동 확장 처리는 또한 노드 및 노드 풀에 대해 수행하는 수동 변경사항을 감지합니다.

영역 간 균형 조정

노드 풀에 동일한 인스턴스 유형의 관리형 인스턴스 그룹이 여러 개 포함된 경우 수직 확장할 때 클러스터 자동 확장 처리는 이러한 관리형 인스턴스 그룹 크기의 균형을 조정합니다. 이는 노드 풀의 여러 영역에 있는 관리형 인스턴스 그룹 간에 고르지 않은 노드 분배를 차단하는 데 도움이 됩니다. GKE는 축소할 때 자동 확장 정책을 고려하지 않습니다.

클러스터 자동 확장 처리는 확장 이벤트 중에 영역 간에만 균형을 조정합니다. 클러스터 자동 확장 처리는 노드 풀의 기반 관리형 인스턴스 그룹의 상대적인 크기에 관계없이 사용량이 적은 노드를 자동으로 축소하며 이로 인해 노드가 영역 간에 균일하지 않게 분산될 수 있습니다.

위치 정책

GKE 버전 1.24.1-gke.800부터는 클러스터 자동 확장 처리의 위치 정책을 변경할 수 있습니다. 다음 값 중 하나로 location_policy 플래그를 지정하여 클러스터 자동 확장 처리 배포 정책을 제어할 수 있습니다.

• BALANCED: 자동 확장 처리가 포드 요구사항과 각 영역의 리소스 가용성을 고려합니다. 클러스터 자동 확장 처리는 특정 영역의 가용 용량 및 수직 확장을 트리거한 포드의 영역 어피니티를 포함한 여러 요소를 고려하므로 유사한 노드 그룹의 크기가 정확히 같지 않을 수도 있습니다.
• ANY: 클러스터 자동 확장 처리에서 사용되지 않은 예약의 사용률에 우선 순위를 지정하고 가용 리소스의 현재 제약조건을 고려합니다.

예약

GKE 버전 1.27부터 클러스터 자동 확장 처리는 확장 관련 결정을 내릴 때 항상 reservations을 고려합니다. 확장할 노드 풀을 선택할 때는 노드 풀이 가장 효율적인 것이 아니더라도 사용되지 않은 예약과 일치하는 노드 풀이 우선 선택됩니다. 또한 여러 영역별 확장의 균형을 조정할 때는 항상 사용되지 않은 예약이 우선 선택됩니다.

하지만 클러스터 자동 확장 처리는 자체 프로젝트에서만 예약을 확인합니다. 따라서 클러스터 자체 프로젝트 내에서 비용이 더 저렴한 노드 옵션을 사용할 수 있는 경우 자동 확장 처리가 공유 예약 대신 이 옵션을 선택할 수 있습니다. 프로젝트 간에 예약을 공유해야 하는 경우 커스텀 컴퓨팅 클래스를 사용하는 것이 좋습니다. 이 클래스를 사용하면 클러스터 자동 확장 처리가 공유 예약을 포함하여 노드를 확장하는 데 사용하는 우선순위를 구성할 수 있습니다.

기본값

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 \
    --location=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 \
    --location=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 슬라이스 노드 풀을 만드는 방법에 대한 자세한 내용은 노드 풀 만들기를 참조하세요.

Spot VM 및 클러스터 자동 확장 처리

클러스터 자동 확장 처리는 비용이 가장 적은 노드 풀을 확장하는 것을 선호하므로 워크로드와 리소스 가용성이 허용하는 경우 클러스터 자동 확장 처리는 확장 시 스팟 VM을 추가합니다.

하지만 클러스터 자동 확장 처리가 스팟 VM을 추가하는 것을 선호하더라도 이 환경설정으로 인해 대부분의 포드가 이러한 유형의 VM에서 실행된다고 보장할 수는 없습니다. Spot VM은 선점될 수 있습니다. 이러한 선점으로 인해 스팟 VM의 포드가 제거될 가능성이 더 큽니다. 제거되면 15초 내에 종료해야 합니다.

예를 들어 10개의 포드와 주문형 및 스팟 VM이 혼합된 시나리오를 생각해 보세요.

• 스팟 VM을 사용할 수 없으므로 주문형 VM에서 실행되는 포드 10개로 시작합니다.
• 10개의 포드가 모두 필요하지 않으므로 클러스터 자동 확장 처리가 포드 2개를 삭제하고 추가 주문형 VM을 종료합니다.
• 포드가 다시 10개 필요하면 클러스터 자동 확장 처리가 Spot VM을 추가하고(Spot VM이 더 저렴하기 때문) 여기에 포드 2개를 예약합니다. 나머지 8개의 포드는 주문형 VM에 남아 있습니다.
• 클러스터 자동 확장 처리를 다시 축소해야 하는 경우 Spot VM이 먼저 선점되어 대부분의 포드가 주문형 VM에서 실행됩니다.

Spot VM의 우선순위를 지정하고 위의 시나리오를 방지하려면 커스텀 컴퓨팅 클래스를 사용하는 것이 좋습니다. 커스텀 컴퓨팅 클래스를 사용하면 확장 중에 주문형 노드보다 우선순위를 높여 스팟 VM에 유리하도록 하는 우선순위 규칙을 만들 수 있습니다. Spot VM이 지원되는 노드에서 포드가 실행될 가능성을 더욱 극대화하려면 활성 마이그레이션을 구성합니다.

다음 예시는 커스텀 컴퓨팅 클래스를 사용하여 스팟 VM의 우선순위를 지정하는 한 가지 방법을 보여줍니다.

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: prefer-l4-spot
spec:
  priorities:
  - machineType: g2-standard-24
    spot: true
    gpu:
      type: nvidia-l4
      count: 2
  - machineType: g2-standard-24
    spot: false
    gpu:
      type: nvidia-l4
      count: 2
  nodePoolAutoCreation:
    enabled: true
  activeMigration:
    optimizeRulePriority: true

위 예시에서는 우선순위 규칙을 통해 노드를 만드는 데 g2-standard-24 머신 유형 및 스팟 VM을 선호한다고 선언합니다. 스팟 VM을 사용할 수 없는 경우 GKE는 주문형 VM을 대체 옵션으로 사용합니다. 이 컴퓨팅 클래스는 activeMigration도 사용 설정하여 클러스터 자동 확장 처리가 용량을 사용할 수 있게 되면 워크로드를 스팟 VM으로 마이그레이션할 수 있도록 합니다.

커스텀 컴퓨팅 클래스를 사용할 수 없는 경우 노드 어피니티, taint 또는 톨러레이션(toleration)을 추가합니다. 예를 들어 다음 노드 어피니티 규칙을 통해 스팟 VM에서 지원되는 노드에서 포드를 예약하는 것을 선호한다고 선언합니다(GKE는 이러한 노드 유형에 cloud.google.com/gke-spot=true 라벨을 자동으로 추가함).

affinity:
  nodeAffinity:
    preferredDuringSchedulingIgnoredDuringExecution:
    - weight: 1
    preference:
      matchExpressions:
      - key: cloud.google.com/gke-spot
        operator: Equal
        values:
        - true

노드 어피니티, taint, 톨러레이션(toleration)을 사용하여 스팟 VM을 예약하는 방법에 관한 자세한 내용은 주문형 노드를 대체로 사용하여 스팟 노드에서 GKE 애플리케이션 실행 블로그를 참조하세요.

ProvisioningRequest CRD

ProvisioningRequest는 사용자가 클러스터 자동 확장 처리에서 포드 그룹의 용량을 요청할 수 있는 네임스페이스화된 커스텀 리소스입니다. 이는 단일 단위로 함께 예약되어야 하는 상호 연결된 포드가 있는 애플리케이션에 특히 유용합니다.

지원되는 프로비저닝 클래스

지원되는 ProvisioningClasses는 세 가지입니다.

• queued-provisioning.gke.io: 이 GKE 전용 클래스는 동적 워크로드 스케줄러와 통합되므로 요청을 큐에 추가하고 리소스가 사용 가능해지면 요청을 처리할 수 있습니다. 일괄 작업 또는 지연 허용 워크로드에 적합합니다. GKE에서 대기열에 추가된 프로비저닝을 사용하는 방법은 동적 워크로드 스케줄러를 사용하여 일괄 및 AI 워크로드용 GPU 배포를 참조하세요. Standard 클러스터의 경우 GKE 버전 1.28.3-gke.1098000부터, Autopilot 클러스터의 경우 GKE 버전 1.30.3-gke.1451000부터 지원됩니다.

• check-capacity.autoscaling.x-k8s.io: 이 오픈소스 클래스는 포드를 예약하기 전에 리소스의 가용성을 확인합니다. GKE 버전 1.30.2-gke.1468000부터 지원됩니다.

• best-effort-atomic.autoscaling.x-k8s.io: 이 오픈소스 클래스는 요청의 모든 포드 리소스를 함께 프로비저닝하려고 시도합니다. 모든 포드에 충분한 리소스를 프로비저닝할 수 없는 경우 리소스가 프로비저닝되지 않고 전체 요청이 실패합니다. GKE 버전 1.31.27부터 지원됩니다.

CheckCapacity 및 BestEffortAtomicScaleUp 클래스에 관한 자세한 내용은 오픈소스 문서를 참조하세요.

ProvisioningRequest 사용 시 제한사항

• GKE 클러스터 자동 확장 처리는 ProvisioningRequest당 PodTemplate 1개만 지원합니다.
• GKE 클러스터 자동 확장 처리는 한 번에 하나의 노드 풀만 확장할 수 있습니다. ProvisioningRequest에 여러 노드 풀의 리소스가 필요한 경우 각 노드 풀에 대해 별도의 ProvisioningRequest를 만들어야 합니다.

ProvisioningRequest 사용 시 권장사항

• total-max-nodes 사용: 최대 노드 수(--max nodes)를 제한하는 대신 --total-max-nodes를 사용하여 애플리케이션에서 사용하는 총 리소스를 제한합니다.
• location-policy=ANY 사용: 이 설정을 사용하면 사용 가능한 모든 위치에 포드를 예약할 수 있으므로 프로비저닝을 신속하게 진행하고 리소스 사용을 최적화할 수 있습니다.
• (선택사항) Kueue와 통합: Kueue를 사용하면 ProvisioningRequests 생성을 자동화하여 워크플로를 간소화할 수 있습니다. 자세한 내용은 Kueue 문서를 참조하세요.

추가 정보

클러스터 자동 확장 처리에 대한 자세한 내용은 오픈소스 Kubernetes 프로젝트의 자동 확장 처리 FAQ를 참조하세요.

제한사항

클러스터 자동 확장 처리에는 다음과 같은 제한사항이 있습니다.

• 로컬 PersistentVolume은 클러스터 자동 확장 처리에서 지원되지 않습니다.
• 1.24.5-gke.600 이전 버전의 GKE 컨트롤 플레인에서 포드가 임시 스토리지를 요청하면 클러스터 자동 확장 처리는 로컬 SSD를 임시 스토리지로 사용하는 노드 풀(노드 0개)을 확장할 수 없습니다.
• 클러스터 크기 제한: 최대 15,000개 노드. 이 크기의 클러스터를 실행할 때 다른 클러스터 한도와 권장사항을 고려합니다.
• 축소할 때는 노드를 강제 종료하기 전에 노드의 Pod를 다른 노드에 재예약하기 위해 클러스터 자동 확장 처리에 10분의 유예 종료 기간을 적용합니다.
• 가끔 클러스터 자동 확장 처리가 완전히 축소되지 못하고 축소 후에 추가 노드가 존재하는 경우가 있습니다. 이 현상은 필요한 시스템 포드가 다른 노드에 예약된 경우 발생할 수 있습니다. 이러한 포드가 다른 노드로 이동하기 위한 트리거가 없기 때문입니다. 사용량이 적은 노드가 두 개 있지만 축소되지 않습니다. 이유가 무엇인가요?를 참조하세요. 포드 중단 예산을 구성하여 이 제한을 우회할 수 있습니다.
• 변경된 필터를 사용한 커스텀 예약은 지원되지 않습니다.
• 클러스터 자동 확장 처리는 대기 중인 포드에 새 노드를 프로비저닝할지 결정할 때 기본 kube-scheduler 동작을 고려합니다. 커스텀 스케줄러는 지원되지 않으며 예기치 않은 확장 동작이 발생할 수 있습니다.
• 포드의 -10 아래에 PriorityClass 값이 있으면 노드가 확장되지 않습니다. 클러스터 자동 확장 처리가 포드 우선순위 및 선점으로 작동하는 방식 자세히 알아보기
• 클러스터 자동 확장 처리에 새 노드 또는 포드를 추가하는 데 사용할 할당되지 않은 IP 주소 공간이 부족하여 확장 실패가 발생할 수 있으며, 이 경우 이유가 scale.up.error.ip.space.exhausted인 eventResult 이벤트로 표시됩니다. 기본 서브넷을 확장하여 노드에 IP 주소를 추가하거나 연속되지 않은 다중 포드 CIDR을 사용하여 포드에 새 IP 주소를 추가할 수 있습니다. 자세한 내용은 포드의 IP 여유 공간 부족을 참조하세요.
• GKE 클러스터 자동 확장 처리는 오픈소스 Kubernetes 프로젝트의 클러스터 자동 확장 처리와 다릅니다. GKE 클러스터 자동 확장 처리의 매개변수는 클러스터 구성에 따라 다르며, 변경될 수 있습니다. 자동 확장 동작을 보다 세부적으로 제어하려면 GKE 클러스터 자동 확장 처리를 사용 중지하고 오픈소스 Kubernetes의 클러스터 자동 확장 처리를 실행합니다. 하지만 오픈소스 Kubernetes에는 Google Cloud 지원이 없습니다.
• 자동 확장이 사용 설정된 GKE 노드 풀을 삭제하면 노드에 NoSchedule 플래그가 설정되고 해당 노드의 모든 포드가 즉시 제거됩니다. 사용 가능한 리소스의 갑작스러운 감소를 완화하기 위해 노드 풀의 자동 확장 처리가 동일한 노드 풀 내에 새 노드를 프로비저닝할 수 있습니다. 이렇게 새로 생성된 노드는 예약할 수 있게 되며, 제거된 포드는 다시 해당 노드에 예약됩니다. 결국 새로 프로비저닝된 노드와 해당 노드의 포드를 포함한 전체 노드 풀이 삭제되어 서비스가 중단될 수 있습니다. 해결 방법으로, 삭제 중에 자동 확장 처리가 새 노드를 프로비저닝하지 못하도록 하려면 삭제를 시작하기 전에 노드 풀에서 자동 확장을 사용 중지하세요.

알려진 문제

• GKE 컨트롤 플레인 버전 1.22 이하에서는 GKE 클러스터 자동 확장 처리가 빈(노드 0개) 클러스터에서 모든 노드 풀 수직 확장을 중지합니다. GKE 버전 1.22 이상에서는 이 동작이 발생하지 않습니다.

문제 해결

문제 해결 도움말은 다음 페이지를 참고하세요.

• 클러스터 자동 확장 처리가 축소되지 않는 문제 해결
• 클러스터 자동 확장 처리가 확장되지 않는 문제 해결

다음 단계

• 노드 자동 확장 방법을 알아봅니다.
• 노드 자동 업그레이드 방법을 알아봅니다.
• 노드 자동 복구 방법을 알아봅니다.
• 새 노드에서 이미지 가져오기 시간 감소 방법을 알아봅니다.