커스텀 ComputeClass 문제 해결

Autopilot Standard

이 문서는 GKE 워크로드가 커스텀 ComputeClass로 정의된 노드에 예약되지 않거나 클러스터 자동 확장 처리에서 예상되는 머신 유형을 프로비저닝하지 않는 문제를 해결하는 데 도움이 됩니다.

이 문서는 커스텀 ComputeClass를 사용하여 GKE에서 워크로드 스케줄링 및 노드 풀 자동 생성을 관리하는 애플리케이션 개발자, 플랫폼 관리자, 운영자를 대상으로 합니다. Google Cloud 콘텐츠에서 참조하는 일반적인 역할과 예시 태스크에 대한 자세한 내용은 일반 GKE 사용자 역할 및 태스크를 참고하세요.

주요 개념

문제 해결을 위해 다음 GKE 구성요소와 메커니즘을 숙지해야 합니다.

커스텀 ComputeClass: 자동 확장을 위한 노드 구성의 우선순위가 지정된 목록을 정의할 수 있는 GKE 전용 리소스입니다. 자세한 내용은 커스텀 ComputeClass 정보를 참고하세요.
클러스터 자동 확장 처리: 워크로드 요구에 따라 클러스터의 노드를 자동으로 추가하거나 삭제하는 구성요소입니다. 자세한 내용은 GKE 클러스터 자동 확장 정보를 참고하세요.
노드 풀 자동 생성: GKE 클러스터 자동 확장 처리기는 워크로드 요구사항에 따라 노드 풀을 자동으로 만들고 관리합니다. 자세한 내용은 노드 풀 자동 생성 정보를 참고하세요.
대체 논리: 클러스터 자동 확장 처리에서 우선순위가 가장 높은 규칙과 일치하는 노드를 먼저 프로비저닝하려고 시도하는 메커니즘입니다. 자세한 내용은 대체 컴퓨팅 우선순위 선택을 참고하세요.

이 문서에서는 기본적인 검사부터 고급 구성까지 문제 해결 단계를 순서대로 정리합니다. 더 포괄적인 진단을 위해 다음 단계를 순서대로 실행하는 것이 좋습니다. 또는 특정 문제가 발생하는 경우 다음 표의 관련 링크를 참고하세요.

증상	문제 해결 단계
커스텀 ComputeClass를 요청하는 포드가 `Pending` 상태로 멈춤	기본 진단 검사 실행하기 포드 예약 제약 조건 확인 노드 풀 구성 (Standard 클러스터의 경우)
클러스터 자동 확장 처리가 커스텀 ComputeClass와 일치하는 새 노드를 만들지 않음	커스텀 ComputeClass 구성 확인 노드 풀 자동 생성 구성 확인
클러스터 자동 확장 처리기가 특수 유형 대신 기본 머신 유형을 생성함	자동 확장 처리 대체 동작 분석
`kubectl describe computeclass` 명령어의 출력에 비정상 상태가 표시됨	커스텀 ComputeClass 구성 확인
워크로드가 우선순위가 더 높은 노드로 이전되지 않음	일반 클러스터 자동 확장 처리 도구 상태 확인
GPU 또는 스팟 VM 워크로드에 예약 문제가 있음	포드 예약 제약 조건 확인 GPU 또는 스팟 VM 구성 확인 자동 확장 처리 대체 동작 분석

지원 범위 외 문제

이 문서에서는 다음 문제를 다루지 않습니다.

포드 간 연결 또는 서비스 부하 분산과 같은 일반적인 GKE 네트워킹 문제
수평형 포드 자동 확장 처리 (HPA) 또는 수직형 포드 자동 확장 처리 (VPA)와 관련된 문제
애플리케이션 수준 오류 또는 예약 제약 조건과 관련이 없는 PersistentVolume 문제와 같은 맞춤 ComputeClass 메커니즘과 관련이 없는 문제
ComputeClass 대체 로직과 직접 관련이 없는 할당량 또는 리소스 사용 불가 문제

자리표시자 변수 식별

이 문서의 명령어를 맞춤설정하려면 Variable 열에 특정 값을 입력하세요. 수정된 값은 모든 코드 블록과 명령어에서 자동으로 동기화됩니다.

변수	설명
`PROJECT_ID`	Google Cloud 프로젝트 ID입니다.
`LOCATION`	클러스터가 위치한 Compute Engine 리전 또는 영역입니다.
`CLUSTER_NAME`	클러스터 이름입니다.
`NODE_POOL_NAME`	검사할 노드 풀의 이름입니다 (Standard 클러스터에 해당하는 경우).
`CUSTOM_COMPUTECLASS_NAME`	포드에서 요청한 맞춤 ComputeClass의 이름입니다.
`NAMESPACE`	예약되지 않는 포드의 네임스페이스입니다.
`POD_NAME`	예약에 실패한 포드의 이름입니다.

시작하기 전에

이 문서의 태스크를 수행하는 데 필요한 권한을 얻으려면 관리자에게 프로젝트에 대한 다음 IAM 역할을 부여해 달라고 요청하세요. Google Cloud

GKE 클러스터에 액세스하려면 Kubernetes Engine 클러스터 뷰어 (roles/container.viewer)가 필요합니다.
로그 보기: 로그 뷰어 (roles/logging.viewer)
GKE 클러스터 관리: Kubernetes Engine 관리자 (roles/container.admin)

역할 부여에 대한 자세한 내용은 프로젝트, 폴더, 조직에 대한 액세스 관리를 참조하세요.

커스텀 역할이나 다른 사전 정의된 역할을 통해 필요한 권한을 얻을 수도 있습니다.

클러스터와 통신하도록 kubectl을 구성하려면 다음 명령어를 실행합니다.

  gcloud container clusters get-credentials CLUSTER_NAME
      --location LOCATION
      --project PROJECT_ID

기본 진단 검사 실행

핵심 구성요소가 올바르게 구성되어 있고 클러스터가 맞춤 ComputeClass를 지원하는지 확인합니다.

포드 상태 및 선택기 확인

포드가 Pending 상태이고 커스텀 ComputeClass를 올바르게 요청하는지 확인합니다.

Pending 상태의 포드를 나열합니다.

kubectl get pods --all-namespaces -o wide | grep Pending

포드의 사양에서 nodeSelector 필드를 검사합니다.

kubectl get pod POD_NAME
    -n NAMESPACE
    -o jsonpath='{.spec.nodeSelector}'

결과 평가

출력에 라벨이 표시됨: nodeSelector 필드가 cloud.google.com/compute-class 라벨로 올바르게 구성되어 있습니다.
출력에 라벨이 표시되지 않음:
- 해석: 워크로드의 배포 구성에 cloud.google.com/compute-class 라벨의 nodeSelector 필드가 잘못되었거나 누락되었을 수 있습니다.
- 해결 방법: spec.template.spec 섹션에 nodeSelector 필드를 포함하도록 워크로드의 YAML 파일(예: Deployment 또는 Job)을 수정합니다.

클러스터 버전 호환성 확인

커스텀 ComputeClass에는 GKE 버전 1.30.3-gke.1451000 이상이 필요합니다. 클러스터에서 맞춤 ComputeClass를 지원하는 버전을 실행하고 있는지 확인합니다.

클러스터 버전을 확인합니다.

gcloud container clusters describe CLUSTER_NAME
    --location LOCATION
    --format="value(currentMasterVersion)"

결과 평가

버전 1.30.3-gke.1451000 이상: 클러스터 버전이 맞춤 ComputeClass를 지원합니다.
1.30.3-gke.1451000 이전 버전:
- 해석: 클러스터가 맞춤 ComputeClass를 지원하는 버전으로 업그레이드되지 않았습니다.
- 해결 방법: 맞춤 ComputeClass를 사용하려면 클러스터를 업그레이드해야 합니다.

커스텀 ComputeClass 구성 확인

맞춤 ComputeClass 리소스의 구성 오류로 인해 포드가 예약되지 않거나 GKE가 노드를 올바르게 프로비저닝하지 못할 수 있습니다.

ComputeClass 상태 및 상태 확인

GKE가 커스텀 ComputeClass를 정상으로 보고하는지 확인합니다.

모든 ComputeClass 리소스를 나열합니다.
```
kubectl get computeclass
```

특정 ComputeClass 리소스를 설명합니다.

kubectl describe computeclass CUSTOM_COMPUTECLASS_NAME

결과 평가

상태에 True이 표시됨: 커스텀 ComputeClass가 정상입니다. 다음은 정상적인 맞춤 ComputeClass의 예입니다.

Status:
  Conditions:
    Last Transition Time:  2024-01-19T17:18:48Z
    Message:               CCC is healthy.
    Reason:                Health
    Status:                True
    Type:                  Health

상태가 False로 표시됨:
- 해석: 커스텀 ComputeClass가 비정상입니다. 출력에서 Message 및 Reason 필드를 검토하여 문제를 식별합니다.
- 해결 방법: 출력의 Reason 필드에 해당하는 작업을 수행합니다.
  - NodePoolNotExist: 참조된 노드 풀이 있는지 확인하거나 기존 노드 풀을 참조하도록 ComputeClass를 업데이트합니다.
  - ReservationUnusable: 참조된 예약의 구성과 사용량을 확인합니다.
  - Invalid machine type: 클러스터의 리전 또는 영역에서 지원되는 머신 유형을 사용하도록 ComputeClass를 업데이트합니다.

`unsatisfiable` 정책 확인

whenUnsatisfiable 필드는 우선순위 규칙을 충족할 수 없는 경우의 동작을 결정합니다.

정책을 확인하세요.

kubectl get computeclass CUSTOM_COMPUTECLASS_NAME -o yaml

출력에서 spec.whenUnsatisfiable 필드를 검사합니다. 이 필드는 다음 값 중 하나를 가질 수 있습니다.

DoNotScaleUp: 선호하는 노드를 만들 수 없는 경우 포드는 Pending 상태로 유지됩니다.
ScaleUpAnyway: 선호하는 노드를 사용할 수 없는 경우 포드가 기본 노드 유형 (예: E2 시리즈)에서 실행될 수 있습니다.

결과 평가

whenUnsatisfiable 정책의 효과는 값에 따라 달라집니다.

값이 DoNotScaleUp인 경우:
- 해석: 이는 리소스 사용 불가 또는 할당량 한도로 인해 우선순위 규칙을 충족할 수 없는 경우 예상되는 동작입니다. 포드가 특정 하드웨어를 기다려야 하는 경우 이 값이 올바릅니다.
- 해결 방법: 특정 하드웨어에서 실행하는 것보다 워크로드를 실행하는 것이 더 중요한 경우 정책을 ScaleUpAnyway로 변경합니다.
값이 ScaleUpAnyway인 경우:
- 해석: 이는 정상적인 동작입니다. 선호하는 노드를 사용할 수 없으므로 GKE가 기본 노드 유형으로 대체됩니다.
- 해결 방법: 포드가 기본 노드 유형에서 실행되면 안 되는 경우 정책을 DoNotScaleUp로 변경합니다.
기본 동작: whenUnsatisfiable 필드의 값을 지정하지 않고 1.33 이전의 GKE 버전을 사용하는 경우 정책은 기본적으로 ScaleUpAnyway로 설정됩니다.

다음 예시에서는 ComputeClass 매니페스트에서 whenUnsatisfiable 필드를 수정하여 정책을 업데이트하는 방법을 보여줍니다.

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: CUSTOM_COMPUTECLASS_NAME
spec:
  # ... other fields
  whenUnsatisfiable: DoNotScaleUp # or ScaleUpAnyway

포드 예약 제약 조건 확인

포드 사양이 커스텀 ComputeClass로 프로비저닝된 노드의 속성과 호환되는지 확인합니다.

포드 리소스 요청 확인

포드의 CPU, 메모리, GPU 요청이 커스텀 ComputeClass의 priorities 필드에 정의된 머신 유형 중 하나 이상으로 충족될 수 있는지 확인합니다.

포드 리소스 요청을 가져옵니다.

kubectl get pod POD_NAME
    -n NAMESPACE
    -o jsonpath='{.spec.containers[*].resources.requests}'

cpu, memory, GPU 요청(예: nvidia.com/gpu)의 출력을 검사합니다.

이러한 요청을 커스텀 ComputeClass의 priorities 필드에 정의된 머신 유형과 비교합니다.
```
kubectl get computeclass CUSTOM_COMPUTECLASS_NAME
    -o jsonpath='{.spec.priorities}'
```
출력에서 machineType 또는 machineFamily 필드를 검사합니다. 커스텀 ComputeClass의 각 머신 유형에 대해 머신 유형 문서에서 사양을 확인하고 할당 가능한 리소스가 포드의 요청보다 큰지 확인합니다.

결과 평가

호환되는 리소스: 포드의 리소스 요청이 ComputeClass의 하나 이상의 머신 유형에 할당 가능한 리소스보다 작거나 같습니다.
리소스가 용량을 초과함:
- 해석: ComputeClass의 머신 유형이 충분한 CPU, 메모리 또는 GPU를 제공하지 않으므로 포드를 예약할 수 없습니다. nodePoolAutoCreation 필드가 true로 설정되어 있고 포드의 메모리 요청이 자동으로 생성된 노드 풀의 한도를 초과하는 경우에도 이 문제가 발생할 수 있습니다.
- 해결 방법: 포드의 리소스 요청 또는 커스텀 ComputeClass의 머신 유형을 조정합니다.
  - Pod 리소스 요청 줄이기: 리소스 요청이 높으면 워크로드의 YAML 파일에서 cpu, memory 또는 gpu 값을 낮춥니다.
  - 더 큰 머신 유형으로 변경: 포드의 요청이 정당화되는 경우 포드 요구사항을 충족할 수 있는 더 큰 machineType 또는 machineFamily 옵션을 포함하도록 커스텀 ComputeClass 매니페스트의 spec.priorities 필드를 수정합니다. 예를 들면 다음과 같습니다.
```
spec:
  priorities:
  - machineType: n2d-highmem-96 # A larger machine type
    spot: true
  # ... other priorities
```

충돌하는 taint 및 톨러레이션 확인

커스텀 ComputeClass에 대해 생성된 노드에는 cloud.google.com/compute-class=CUSTOM_COMPUTECLASS_NAME:NoSchedule 테인트가 있습니다. GKE는 이 톨러레이션(toleration)을 포드에 자동으로 추가합니다.

하지만 GPU와 같은 특수 하드웨어에는 nvidia.com/gpu=present:NoSchedule taint와 같은 taint가 추가로 있습니다. ComputeClass가 전문화된 하드웨어가 있는 노드를 사용하는 경우 포드는 이러한 taint에 대한 톨러레이션이 있어야 해당 노드에 예약될 수 있습니다.

포드의 tolerations 필드를 확인합니다.

kubectl get pod POD_NAME
    -n NAMESPACE
    -o jsonpath='{.spec.tolerations}'

결과 평가

올바른 톨러레이션: 테인트와 톨러레이션이 올바르게 구성되어 있습니다.
누락된 허용차:
- 해석: 누락된 내결함성으로 인해 포드가 특수 하드웨어 taint가 있는 노드에 예약되지 않습니다. 예를 들어 ComputeClass가 GPU 노드를 사용하는 경우 포드에 nvidia.com/gpu=present:NoSchedule 허용이 누락될 수 있습니다. GPU 관련 요구사항은 GPU 구성 확인을 참고하세요.
- 해결 방법: 포드 사양의 tolerations 필드에 ComputeClass로 정의된 노드의 taint와 일치하는 필요한 톨러레이션을 추가합니다. 예를 들어 GPU 노드의 경우 다음과 같이 nvidia.com/gpu=present:NoSchedule taint에 대한 톨러레이션을 추가합니다.
```
spec:
template:
spec:
tolerations:
- key: "nvidia.com/gpu"
operator: "Exists"
effect: "NoSchedule"
# ... other tolerations and Pod spec
```

노드 풀 구성 (Standard 클러스터)

GKE Standard 클러스터에서 수동으로 만든 노드 풀은 커스텀 ComputeClass와 함께 작동하도록 라벨이 지정되고 taint가 적용되어야 합니다.

노드 풀 라벨 및 taint 확인

커스텀 ComputeClass에서 노드 풀을 식별합니다. 커스텀 ComputeClass가 nodePools 필드를 사용하는 경우 나열된 노드 풀의 이름을 기록합니다.
```
kubectl get computeclass CUSTOM_COMPUTECLASS_NAME -o yaml
```

확인한 각 노드 풀의 구성을 확인합니다.

gcloud container node-pools describe NODE_POOL_NAME
    --cluster CLUSTER_NAME
    --location LOCATION
    --format="yaml(config.labels, config.taints)"

결과 평가

노드 풀이 올바르게 구성됨: 노드 풀에 cloud.google.com/compute-class: CUSTOM_COMPUTECLASS_NAME 라벨과 cloud.google.com/compute-class=CUSTOM_COMPUTECLASS_NAME:NoSchedule 테인트가 있습니다.

노드 풀이 잘못 구성됨:

해석: 노드 풀이 커스텀 ComputeClass와 연결하는 데 필요한 라벨과 taint로 구성되지 않았습니다.

해결 방법: 노드 풀을 업데이트하여 라벨과 taint를 추가합니다.

노드 라벨을 추가하거나 업데이트합니다.

gcloud container node-pools update NODE_POOL_NAME \
    --cluster=CLUSTER_NAME --location=LOCATION \
    --node-labels=cloud.google.com/compute-class=CUSTOM_COMPUTECLASS_NAME

노드 테인트 추가 또는 업데이트:

gcloud container node-pools update NODE_POOL_NAME \
    --cluster=CLUSTER_NAME --location=LOCATION \
    --node-taints=cloud.google.com/compute-class=CUSTOM_COMPUTECLASS_NAME:NoSchedule

노드 풀 자동 생성 구성 확인

nodePoolAutoCreation이 true로 설정된 Autopilot 및 Standard 클러스터의 경우 노드 풀 자동 생성이 올바르게 구성되어야 합니다.

노드 풀 자동 생성이 사용 설정되어 있는지 확인

커스텀 ComputeClass의 nodePoolAutoCreation.enabled 필드가 true로 설정되어 있는지 확인합니다.
```
kubectl get computeclass CUSTOM_COMPUTECLASS_NAME -o yaml
```

클러스터에서 노드 풀 자동 생성이 사용 설정되어 있는지 확인합니다.

gcloud container clusters describe CLUSTER_NAME
    --location LOCATION
    --format="value(autoscaling.enableNodeAutoprovisioning)"

둘 중 하나가 사용 중지된 경우 노드 풀 자동 생성은 커스텀 ComputeClass에 대해 새 노드 풀을 생성하지 않습니다.

결과 평가

노드 풀 자동 생성 사용 설정: ComputeClass에서 nodePoolAutoCreation.enabled 필드가 true로 설정되고 클러스터 수준에서 노드 자동 프로비저닝이 사용 설정됩니다.
노드 풀 자동 생성 사용 중지:
- 해석: ComputeClass에서 nodePoolAutoCreation.enabled 필드의 값이 false이거나 누락된 경우 또는 클러스터 수준 노드 자동 프로비저닝이 사용 중지된 경우 노드 풀 자동 생성이 사용 중지됩니다.
- 해결 방법: 노드 풀 자동 생성을 사용 설정합니다.
  1. nodePoolAutoCreation: enabled: true을 포함하도록 맞춤 ComputeClass YAML 파일을 수정합니다.
```
spec:
  # ... priorities
  nodePoolAutoCreation:
    enabled: true
```
  2. 클러스터 수준에서 노드 풀 자동 생성을 사용 설정하고 리소스 제한 구성:
```
gcloud container clusters update CLUSTER_NAME --location LOCATION \
  --enable-autoprovisioning \
  --autoprovisioning-min-cpu=MIN_CPU \
  --autoprovisioning-max-cpu=MAX_CPU \
  --autoprovisioning-min-memory=MIN_MEMORY \
  --autoprovisioning-max-memory=MAX_MEMORY
```

노드 풀 자동 생성의 리소스 한도 확인

노드 풀 자동 생성에는 클러스터 전체 CPU 및 메모리 제한이 있습니다. 클러스터의 현재 사용량과 새 노드의 리소스가 이러한 한도를 초과하면 노드 풀 자동 생성에서 새 노드를 프로비저닝하지 않습니다.

리소스 한도를 확인합니다.

gcloud container clusters describe CLUSTER_NAME
    --location LOCATION
--format="value(autoscaling.resourceLimits)"

출력에는 CPU 및 메모리 (GB)의 resourceType, minimum, maximum 필드가 나열됩니다.

커스텀 ComputeClass의 우선순위에서 머신 유형을 검토합니다. 머신 유형 문서에서 CPU 및 메모리 사양을 확인하세요.
클러스터에 있는 모든 노드의 현재 총 CPU 및 메모리 용량을 확인합니다. 현재 용량과 잠재적인 새 노드의 리소스 합계가 노드 풀 자동 생성의 최대 한도를 초과해서는 안 됩니다.

결과 평가

충분한 용량: 클러스터에 노드 풀 자동 생성의 리소스 한도 내에서 새 노드를 프로비저닝할 수 있는 충분한 CPU 및 메모리 용량이 있습니다.
한도 초과:
- 해석: 클러스터가 CPU 또는 메모리 한도에 도달했거나 ComputeClass의 머신 유형에 대해 한도가 너무 낮게 설정되어 노드 풀 자동 생성에서 새 노드를 프로비저닝할 수 없습니다.
- 해결 방법: 노드 풀 자동 생성의 리소스 한도를 늘립니다.
  1. 커스텀 ComputeClass의 가장 큰 머신 유형을 비롯하여 현재 사용량과 향후 성장을 고려한 새로운 최대 한도를 결정합니다.
  2. 노드 풀 자동 생성의 리소스 제한 업데이트 하나의 명령어에서 여러 리소스를 설정할 수 있습니다.
```
gcloud container clusters update CLUSTER_NAME --location LOCATION \
  --set-nap-resource-limits resourceType=cpu,maximum=NEW_MAX_CPU \
  --set-nap-resource-limits resourceType=memory,maximum=NEW_MAX_GB
```

자동 확장 처리 대체 동작 분석

이 섹션에서는 외부 요인을 조사하여 클러스터 자동 확장 처리가 선호하는 옵션을 건너뛰고 대체 옵션을 사용하거나 수직 확장하지 못하는 이유를 파악하는 데 도움을 줍니다.

커스텀 ComputeClass는 우선순위가 지정된 대체 로직을 사용합니다. 포드가 우선순위가 가장 높은 규칙과 일치하는 노드에 예약되지 않는 경우 리소스 사용 불가능 또는 프로젝트 할당량과 같은 제약 조건 때문인 경우가 많습니다. GKE가 Compute Engine의 ZONE_RESOURCE_POOL_EXHAUSTED 또는 QUOTA_EXCEEDED 오류로 인해 특정 우선순위 규칙과 일치하는 노드를 프로비저닝할 수 없는 경우 클러스터 자동 확장 처리기는 priorities 목록에서 다음 규칙을 즉시 시도합니다. TPU 또는 구성 가능한 지연을 지원하는 유연한 시작 프로비저닝 모델을 사용하는 경우를 제외하고 GKE가 다음 우선순위로 대체되기까지 대기 기간이 없습니다.

리소스 사용 불가능 여부 확인

클러스터 자동 확장 처리기 로그 또는 Compute Engine 관리형 인스턴스 그룹 (MIG) 오류를 확인하여 지정된 영역에서 리소스를 사용할 수 없는지 확인합니다.

옵션 1: 클러스터 자동 확장 처리 공개 상태 이벤트 확인

Google Cloud 콘솔에서 Cloud Logging > 로그 탐색기로 이동하고 다음 쿼리를 실행하여 리소스 사용 불가를 나타낼 수 있는 자동 스케일러 이벤트를 찾습니다.

resource.type="k8s_cluster"
resource.labels.location="LOCATION"
resource.labels.cluster_name="CLUSTER_NAME"
log_id("container.googleapis.com/cluster-autoscaler-visibility")
jsonPayload.noScaleUpReason.messageId="no.scale.up.nap.resource.exhausted"

옵션 2: MIG 오류 확인

Google Cloud 콘솔에서 또는 Cloud Logging 쿼리를 사용하여 MIG 오류를 확인할 수 있습니다.

Google Cloud 콘솔 사용:
1. Google Cloud 콘솔에서 Compute Engine > 인스턴스 그룹으로 이동합니다.
2. 확장되지 않는 노드 풀에 해당하는 MIG를 찾습니다.
3. MIG 이름을 클릭하고 오류 탭으로 이동합니다. 리소스 소진을 나타내는 메시지를 찾습니다.

Cloud Logging 쿼리 사용:

Google Cloud 콘솔에서 Cloud Logging > 로그 탐색기로 이동합니다.
다음 쿼리를 실행하여 MIG의 리소스 소진 오류를 확인합니다.

resource.type="gce_instance"
log_id("cloudaudit.googleapis.com/activity")
protoPayload.status.message:("ZONE_RESOURCE_POOL_EXHAUSTED" OR "does not have enough resources available to fulfill the request" OR "resource pool exhausted" OR "does not exist in zone")

결과 평가

리소스 사용 가능: 로그에 ZONE_RESOURCE_POOL_EXHAUSTED 메시지가 표시되지 않으면 리소스 사용 불가가 스케일업 실패의 원인일 가능성이 낮습니다.
리소스를 사용할 수 없음:
- 해석: 해당 영역에서 특정 머신 유형 (특히 스팟 VM 또는 GPU)에 대한 일시적인 수요가 많거나 포드가 리소스를 사용할 수 없는 영역에 PersistentVolume 선호도에 의해 제한되어 노드 프로비저닝이 실패합니다.
- 해결 방법: 리소스 사용 불가는 일시적이지만 구성에 유연성을 추가하여 복원력을 개선할 수 있습니다.
  - 머신 유형 다각화: 커스텀 ComputeClass의 spec.priorities 필드에 여러 머신 유형 또는 계열이 대체로 포함되어 있는지 확인합니다.
```
spec:
  priorities:
  - machineFamily: c3  # Highest priority
  - machineFamily: n2d # Fallback option
  - machineFamily: e2  # Lowest priority
```
  - 리전 클러스터 사용: 클러스터가 영역별인 경우 해당 단일 영역에서 리소스를 사용할 수 없게 될 수 있습니다. 리전 클러스터를 사용하면 클러스터 자동 확장 처리에서 용량이 사용 가능할 수 있는 리전 내 다른 영역에 노드를 프로비저닝할 수 있습니다.
  - Compute Engine 예약 사용: 지연을 허용할 수 없는 중요한 워크로드의 경우 Compute Engine 예약을 만들어 특정 머신 유형의 용량을 확보하세요.

프로젝트 할당량 확인

프로젝트에 새 노드에 필요한 CPU, GPU, IP 주소와 같은 리소스의 할당량이 충분한지 확인합니다.

자동 확장 처리 로그에서 할당량 오류를 확인합니다. Cloud Logging을 사용하여 자동 확장 처리 공개 상태 이벤트에서 할당량 관련 오류 메시지를 검색합니다.

resource.type="k8s_cluster"
resource.labels.location="LOCATION"
resource.labels.cluster_name="CLUSTER_NAME"
log_id("container.googleapis.com/cluster-autoscaler-visibility")
jsonPayload.noScaleUpReason.messageId="no.scale.up.nap.quota.exceeded"

또는 다음 Cloud Logging 쿼리를 사용하여 MIG의 할당량 관련 오류 로그를 확인합니다.

resource.type="gce_instance"
protoPayload.methodName:"compute.instances.insert"
protoPayload.status.message:"QUOTA_EXCEEDED"
severity=ERROR

Google Cloud 콘솔에서 할당량을 검토합니다.
1. Google Cloud 콘솔에서 IAM 및 관리자 > 할당량으로 이동합니다.
2. Compute Engine API 서비스를 필터링합니다.
3. GKE 클러스터가 있는 리전의 CPU, GPU (모든 유형), 사용 중인 IP 주소와 같은 관련 측정항목의 사용량을 확인합니다. 현재 사용량이 한도에 도달하지 않았는지 확인합니다.

결과 평가

한도 미만의 할당량: 할당량 사용량이 할당량 한도 미만이고 로그에서 QUOTA_EXCEEDED 오류가 발견되지 않으면 할당량 한도로 인해 스케일업이 차단되지 않습니다.
할당량 초과:
- 해석: CPU, GPU, IP 주소 또는 MIG와 같은 리소스의 할당량이 부족하여 노드 프로비저닝이 실패합니다.
- 해결 방법: 프로젝트가 할당량 한도에 도달한 경우 할당량 증가를 요청하세요.

고급 구성

GPU, 스팟 VM, Compute Engine 예약과 같은 구성에는 확인해야 하는 자체적인 요구사항과 잠재적인 실패 지점이 있습니다.

GPU 구성 확인

GPU 노드를 프로비저닝하는 맞춤 ComputeClass의 경우 맞춤 ComputeClass에서 GPU 구성을 검증하고 포드에 필수 nvidia.com/gpu 허용이 있는지 확인합니다.

우선순위 규칙 내에 gpu 블록이 있는지 커스텀 ComputeClass의 YAML을 확인합니다.
```
kubectl get computeclass CUSTOM_COMPUTECLASS_NAME -o yaml
```
gpu 블록은 type 필드와 count 필드를 지정해야 합니다. 예를 들면 다음과 같습니다.
```
priorities:
- machineType: a2-highgpu-1g
  gpu:
    type: nvidia-tesla-a100
    count: 1
```
GPU 허용 오차에 대해 포드를 검사합니다. GPU 노드에 예약해야 하는 포드는 포드 자체에서 GPU를 요청하지 않더라도 nvidia.com/gpu 톨러레이션이 있어야 합니다.
```
kubectl get pod POD_NAME -n NAMESPACE -o jsonpath='{.spec.tolerations}'
```
spec.tolerations 필드에서 허용을 확인합니다.

결과 평가

GPU가 올바르게 구성됨: ComputeClass가 GPU type 및 count를 정의하고 포드에 nvidia.com/gpu 허용이 포함된 경우 GPU 구성이 올바른 것입니다. 다음은 필요한 허용 오차를 보여줍니다.
```
tolerations:
- key: "nvidia.com/gpu"
  operator: "Exists"
  effect: "NoSchedule"
```
GPU가 잘못 구성됨:
- 해석: 포드에 필요한 nvidia.com/gpu 허용이 누락되었거나, GPU 필드 불일치로 인해 ComputeClass가 비정상일 수 있으며, GKE 버전이 GPU 구성을 올바르게 처리하지 못할 수 있습니다.
- 해결 방법: 다음 작업 중 하나를 수행합니다.
  - 필수 GPU 허용을 포함하도록 워크로드의 YAML 파일을 수정하고 YAML 파일을 다시 적용합니다.
  - GKE 클러스터를 업그레이드합니다. 커스텀 ComputeClass가 비정상이고 문제가 GPU 필드와 관련된 경우 알려진 문제를 확인하고 패치된 GKE 버전(예: 1.31.8-gke.1045000 이상)으로 업그레이드합니다.

스팟 VM 구성 확인

스팟 VM을 사용하는 경우 ComputeClass 매니페스트의 올바른 우선순위 규칙에 spot: true 설정이 있는지 확인하세요. 또한 클러스터 자동 확장 처리의 가격 책정 논리를 이해해야 합니다.

ComputeClass 매니페스트를 검사합니다.

kubectl get computeclass CUSTOM_COMPUTECLASS_NAME -o yaml

출력의 spec.priorities 필드에서 spot: true를 찾습니다. 예를 들면 다음과 같습니다.

priorities:
- machineFamily: n2d
  spot: true

클러스터 자동 확장 처리는 다양한 스팟 VM 유형의 비용을 비교할 때 us-central1의 가격 데이터를 기준으로 사용할 수 있으므로 다른 리전에서는 최적이 아닌 선택이 이루어질 수 있습니다. 이는 알려진 동작입니다.

결과 평가

스팟 VM이 올바르게 구성됨: spot: true 필드가 지정되고 클러스터 자동 확장 처리가 스팟 VM을 프로비저닝하는 경우 구성이 예상대로 작동합니다.
스팟 VM 예약 실패:
- 해석: Spot VM이 필요한 포드가 대상 영역에서 리소스를 사용할 수 없거나 클러스터 자동 확장 처리에서 us-central1 가격 책정 모델을 기반으로 다른 VM 유형을 선택할 수 있기 때문에 Spot VM에 예약되지 않을 수 있습니다.
- 해결 방법:
  - 리소스가 사용 불가능한 것으로 의심되면 리소스 사용 불가능 여부 확인을 참고하세요.
  - 스팟 VM 선택을 제어하려면 리전에서 가장 저렴한 것부터 가장 비싼 것까지 priorities 필드에 machineType 항목을 명시적으로 나열합니다. 이 접근 방식을 사용하면 대체 순서를 직접 제어할 수 있습니다. 예를 들면 다음과 같습니다.
```
spec:
  priorities:
  - machineType: t2d-standard-48 # Cheapest in this region
    spot: true
  - machineType: n2d-standard-48 # Fallback Spot option
    spot: true
  - machineType: n2d-standard-48 # On-demand fallback
    spot: false
```

일반 클러스터 자동 확장 처리 상태

이 섹션에서는 맞춤 ComputeClass 구성과 직접 관련이 없지만 작업에 영향을 미칠 수 있는 문제를 확인하는 데 도움이 됩니다.

동시 작업 확인

다른 클러스터 또는 노드 풀 작업이 동시에 진행되고 있지 않은지 확인합니다. GKE에서는 일반적으로 한 번에 하나의 작업만 허용하므로 자동 확장 기능이 차단될 수 있습니다.

DONE 상태가 아닌 진행 중인 작업을 나열합니다.

gcloud container operations list \
    --location=LOCATION \
    --filter='targetLink~"/clusters/CLUSTER_NAME" AND status!=DONE'

명령어에서 작업을 반환하면 클러스터 업그레이드, 노드 풀 생성 또는 기타 수정과 같은 작업이 진행 중일 수 있습니다. 이 작업이 완료될 때까지 자동 확장 이벤트가 차단될 수 있습니다.

결과 평가

동시 작업 없음: list 명령어가 빈 목록을 반환하면 클러스터 자동 확장 처리가 작업에 의해 차단되지 않습니다.
동시 작업이 발견됨:
- 해석: 명령어가 상태가 RUNNING 또는 PENDING인 작업을 나열하는 경우 클러스터 업그레이드 또는 노드 풀 수정과 같은 동시 작업이 진행 중이며 자동 확장을 차단할 수 있습니다.
- 해결 방법: 진행 중인 작업이 완료될 때까지 기다립니다. 다음 명령어를 사용하여 작업 ID로 상태를 모니터링할 수 있습니다.
```
gcloud container operations wait OPERATION_ID --location LOCATION
```
  OPERATION_ID을 list 명령어의 출력에서 가져온 ID로 바꿉니다. 차단 작업이 완료되면 클러스터 자동 확장 처리기가 정상 기능을 재개해야 합니다.

활성 마이그레이션 검토

우선순위가 더 높은 노드를 사용할 수 있는데 워크로드가 우선순위가 낮은 노드에 유지되는 경우 활성 마이그레이션이 사용 설정되어 있는지 확인합니다. activeMigration.optimizeRulePriority 필드가 ComputeClass에서 false로 설정되거나 생략된 경우 GKE는 우선순위가 더 높은 노드를 사용할 수 있게 되더라도 워크로드를 자동으로 이동하지 않습니다.

포드 허용 오차를 확인하려면 spec.tolerations 필드를 검토하세요. 포드에 우선순위가 다른 여러 노드 풀의 테인트와 일치하는 허용이 있는 경우 스케줄러는 먼저 사용할 수 있는 경우 우선순위가 낮은 노드에 포드를 배치할 수 있습니다.
```
kubectl get pod POD_NAME -n NAMESPACE -o jsonpath='{.spec.tolerations[*]}{"\n"}'
```
활성 마이그레이션이 사용 설정되어 있는지 확인하려면 ComputeClass 매니페스트에서 spec.activeMigration.optimizeRulePriority 필드를 검사합니다.
```
kubectl get computeclass CUSTOM_COMPUTECLASS_NAME -o yaml
```

결과 평가

활성 마이그레이션 사용 설정: activeMigration.optimizeRulePriority 필드가 true인 경우 GKE는 우선순위가 더 높은 노드를 사용할 수 있게 되면 워크로드를 해당 노드로 이동하려고 시도합니다.
활성 이전이 사용 중지되었거나 효과가 없음:
- 해석: activeMigration.optimizeRulePriority 필드가 false이거나 생략된 경우 또는 포드 허용이 너무 광범위한 경우 우선순위가 높은 노드를 사용할 수 있을 때 워크로드가 우선순위가 낮은 노드에 유지됩니다. 이 접근 방식을 사용하면 먼저 사용할 수 있게 된 우선순위가 낮은 노드에 워크로드를 예약할 수 있습니다.
- 해결 방법: 워크로드가 우선순위가 더 높은 노드로 이동하도록 하려면 다음 작업 중 하나를 수행하세요.
  - nodeAffinity과 같은 더 구체적인 예약 제약 조건을 사용하여 우선순위가 높은 노드 풀을 선호합니다.
  - ComputeClass 매니페스트를 수정하여 activeMigration.optimizeRulePriority: true을 설정하고 YAML 파일을 적용합니다.
```
spec:
  activeMigration:
    optimizeRulePriority: true
```

지원 받기

문서에서 문제 해결 방법을 찾을 수 없으면 지원 받기를 참조하여 다음 주제에 대한 조언을 포함한 추가 도움을 요청하세요.
- Cloud Customer Care에 문의하여 지원 케이스를 엽니다.
- StackOverflow에서 질문하고 google-kubernetes-engine 태그를 사용하여 유사한 문제를 검색해 커뮤니티의 지원을 받습니다. #kubernetes-engine Slack 채널에 가입하여 더 많은 커뮤니티 지원을 받을 수도 있습니다.
- 공개 Issue Tracker를 사용하여 문제나 기능 요청을 엽니다.

커스텀 ComputeClass 문제 해결 컬렉션을 사용해 정리하기 내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.

주요 개념

증상별 문제 해결

지원 범위 외 문제

자리표시자 변수 식별

시작하기 전에

기본 진단 검사 실행

포드 상태 및 선택기 확인

결과 평가

클러스터 버전 호환성 확인

결과 평가

커스텀 ComputeClass 구성 확인

ComputeClass 상태 및 상태 확인

결과 평가

unsatisfiable 정책 확인

결과 평가

포드 예약 제약 조건 확인

포드 리소스 요청 확인

결과 평가

충돌하는 taint 및 톨러레이션 확인

결과 평가

노드 풀 구성 (Standard 클러스터)

노드 풀 라벨 및 taint 확인

결과 평가

노드 풀 자동 생성 구성 확인

노드 풀 자동 생성이 사용 설정되어 있는지 확인

결과 평가

노드 풀 자동 생성의 리소스 한도 확인

결과 평가

자동 확장 처리 대체 동작 분석

리소스 사용 불가능 여부 확인

결과 평가

프로젝트 할당량 확인

결과 평가

고급 구성

GPU 구성 확인

결과 평가

스팟 VM 구성 확인

결과 평가

일반 클러스터 자동 확장 처리 상태

동시 작업 확인

결과 평가

활성 마이그레이션 검토

결과 평가

지원 받기

다음 단계

커스텀 ComputeClass 문제 해결

`unsatisfiable` 정책 확인