Memecahkan masalah ComputeClass kustom

Autopilot Standard

Dokumen ini membantu Anda memecahkan masalah saat workload GKE gagal dijadwalkan pada node yang ditentukan oleh ComputeClass kustom, atau saat autoscaler cluster tidak menyediakan jenis mesin yang diharapkan.

Dokumen ini ditujukan bagi developer Aplikasi serta admin dan operator Platform yang menggunakan ComputeClass kustom untuk mengelola penjadwalan workload dan pembuatan otomatis node pool di GKE. Untuk mengetahui informasi selengkapnya tentang peran umum dan contoh tugas yang dirujuk dalam Google Cloud konten, lihat Peran dan tugas pengguna GKE umum.

Konsep utama

Untuk membantu Anda memecahkan masalah, pastikan Anda memahami komponen dan mekanisme GKE berikut:

Custom ComputeClass: resource khusus GKE yang memungkinkan Anda menentukan daftar prioritas konfigurasi node untuk penskalaan otomatis. Untuk mengetahui informasi selengkapnya, lihat Tentang ComputeClass kustom.
Autoscaler cluster: komponen yang otomatis menambahkan atau menghapus node di cluster Anda berdasarkan permintaan workload. Untuk mengetahui informasi selengkapnya, lihat Tentang Penskalaan otomatis cluster GKE.
Pembuatan otomatis node pool: Autoscaler cluster GKE secara otomatis membuat dan mengelola node pool berdasarkan persyaratan workload. Untuk mengetahui informasi selengkapnya, lihat Tentang pembuatan otomatis kumpulan node.
Logika penggantian: mekanisme saat autoscaler cluster mencoba menyediakan node yang cocok dengan aturan prioritas tertinggi Anda terlebih dahulu. Untuk mengetahui informasi selengkapnya, lihat Memilih prioritas komputasi penggantian.

Dokumen ini mengatur langkah-langkah pemecahan masalah secara berurutan, dari pemeriksaan dasar hingga konfigurasi yang lebih canggih. Untuk diagnosis yang lebih komprehensif, sebaiknya lakukan langkah-langkah ini secara berurutan. Atau, jika Anda mengalami masalah tertentu, lihat link yang relevan dalam tabel berikut:

Gejala	Langkah pemecahan masalah
Pod yang meminta ComputeClass kustom macet dalam status `Pending`	Melakukan pemeriksaan diagnostik dasar Memeriksa batasan penjadwalan Pod Konfigurasi node pool (untuk cluster Standard)
Cluster autoscaler tidak membuat node baru yang cocok dengan ComputeClass kustom	Memverifikasi konfigurasi ComputeClass kustom Memverifikasi konfigurasi pembuatan otomatis node pool
Cluster autoscaler membuat jenis mesin default, bukan jenis khusus	Menganalisis perilaku penggantian autoscaler
Output dari perintah `kubectl describe computeclass` menampilkan status tidak responsif	Memverifikasi konfigurasi ComputeClass kustom
Workload tidak dimigrasikan ke node dengan prioritas lebih tinggi	Memverifikasi kesehatan autoscaler cluster secara umum
Workload GPU atau Spot VM mengalami masalah penjadwalan	Memeriksa batasan penjadwalan Pod Memverifikasi konfigurasi GPU atau Spot VM Menganalisis perilaku penggantian autoscaler

Masalah di luar cakupan

Dokumen ini tidak membahas masalah berikut:

Masalah jaringan GKE umum, seperti konektivitas Pod-ke-Pod atau load balancing layanan.
Masalah terkait Horizontal Pod Autoscaler (HPA) atau Vertical Pod Autoscaler (VPA).
Masalah yang tidak terkait dengan mekanisme ComputeClass kustom, seperti error tingkat aplikasi atau masalah PersistentVolume yang tidak terkait dengan batasan penjadwalan.
Masalah kuota atau ketersediaan resource yang tidak terkait langsung dengan logika penggantian ComputeClass.

Mengidentifikasi variabel placeholder

Untuk menyesuaikan perintah dalam dokumen ini, masukkan nilai spesifik Anda ke dalam kolom Variable. Nilai yang diedit akan otomatis disinkronkan di semua blok kode dan perintah.

Variabel	Deskripsi
`PROJECT_ID`	ID project Google Cloud Anda.
`LOCATION`	Region atau zona Compute Engine tempat cluster berada.
`CLUSTER_NAME`	Nama cluster Anda.
`NODE_POOL_NAME`	Nama node pool yang akan diperiksa (jika berlaku untuk cluster Standar).
`CUSTOM_COMPUTECLASS_NAME`	Nama ComputeClass kustom yang diminta oleh Pod.
`NAMESPACE`	Namespace Pod yang gagal dijadwalkan.
`POD_NAME`	Nama Pod yang gagal dijadwalkan.

Sebelum memulai

Untuk mendapatkan izin yang Anda perlukan untuk melakukan tugas dalam dokumen ini, minta administrator Anda untuk memberi Anda peran IAM berikut di project Google Cloud Anda:

Untuk mengakses cluster GKE: Kubernetes Engine Cluster Viewer (roles/container.viewer).
Untuk melihat log: Logs Viewer (roles/logging.viewer).
Untuk mengelola cluster GKE: Kubernetes Engine Admin (roles/container.admin).

Untuk mengetahui informasi selengkapnya tentang pemberian peran, lihat Mengelola akses ke project, folder, dan organisasi.

Anda mungkin juga bisa mendapatkan izin yang diperlukan melalui peran khusus atau peran bawaan lainnya.

Untuk mengonfigurasi kubectl agar dapat berkomunikasi dengan cluster, jalankan perintah berikut:

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

Melakukan pemeriksaan diagnostik dasar

Pastikan komponen inti dikonfigurasi dengan benar dan cluster mendukung ComputeClass kustom.

Memverifikasi status dan pemilih Pod

Pastikan Pod dalam status Pending dan meminta ComputeClass kustom dengan benar.

Mencantumkan Pod dalam status Pending:

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

Periksa spesifikasi Pod untuk kolom nodeSelector:

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

Mengevaluasi hasil

Output menampilkan label: kolom nodeSelector dikonfigurasi dengan benar dengan label cloud.google.com/compute-class.
Output tidak menampilkan label:
- Interpretasi: mungkin ada kolom nodeSelector yang salah atau tidak ada untuk label cloud.google.com/compute-class dalam konfigurasi deployment workload Anda.
- Penyelesaian: ubah file YAML workload Anda, seperti Deployment atau Job, untuk menyertakan kolom nodeSelector di bagian spec.template.spec.

Memverifikasi kompatibilitas versi cluster

ComputeClass kustom memerlukan GKE versi 1.30.3-gke.1451000 atau yang lebih baru. Pastikan cluster Anda menjalankan versi yang mendukung ComputeClass kustom.

Periksa versi cluster Anda:

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

Mengevaluasi hasil

Versi 1.30.3-gke.1451000 atau yang lebih baru: versi cluster Anda mendukung ComputeClass kustom.
Versi sebelum 1.30.3-gke.1451000:
- Interpretasi: cluster Anda belum diupgrade ke versi yang mendukung ComputeClass kustom.
- Penyelesaian: Anda harus mengupgrade cluster untuk menggunakan ComputeClass kustom.

Memverifikasi konfigurasi ComputeClass kustom

Salah konfigurasi pada resource ComputeClass kustom dapat mencegah Pod dijadwalkan atau mencegah GKE menyediakan node dengan benar.

Memeriksa kesehatan dan status ComputeClass

Pastikan GKE melaporkan ComputeClass kustom sebagai responsif.

Mencantumkan semua resource ComputeClass:
```
kubectl get computeclass
```

Mendeskripsikan resource ComputeClass tertentu:

kubectl describe computeclass CUSTOM_COMPUTECLASS_NAME

Mengevaluasi hasil

Status kondisi menampilkan True: ComputeClass kustom dalam kondisi baik. Berikut adalah contoh ComputeClass kustom yang berfungsi dengan baik:

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

Status kesehatan menampilkan False:
- Interpretasi: ComputeClass kustom tidak berfungsi dengan baik. Tinjau kolom Message dan Reason dalam output untuk mengidentifikasi masalah.
- Penyelesaian: lakukan tindakan yang sesuai dengan kolom Reason dalam output:
  - NodePoolNotExist: pastikan node pool yang dirujuk ada atau perbarui ComputeClass untuk merujuk ke node pool yang ada.
  - ReservationUnusable: periksa konfigurasi dan penggunaan pemesanan yang dirujuk.
  - Invalid machine type: perbarui ComputeClass untuk menggunakan jenis mesin yang didukung di region atau zona cluster.

Memvalidasi kebijakan `unsatisfiable`

Kolom whenUnsatisfiable menentukan perilaku saat tidak ada aturan prioritas yang dapat dipenuhi.

Periksa kebijakan:

kubectl get computeclass CUSTOM_COMPUTECLASS_NAME -o yaml

Periksa kolom spec.whenUnsatisfiable di output. Kolom ini dapat memiliki salah satu nilai berikut:

DoNotScaleUp: Pod tetap dalam status Pending jika tidak ada node pilihan yang dapat dibuat.
ScaleUpAnyway: Pod dapat berjalan pada jenis node default (seperti seri E2) jika node pilihan tidak tersedia.

Mengevaluasi hasil

Efek kebijakan whenUnsatisfiable bergantung pada nilainya:

Jika nilainya adalah DoNotScaleUp:
- Interpretasi: ini adalah perilaku yang diharapkan saat tidak ada aturan prioritas yang dapat dipenuhi, mungkin karena ketersediaan resource atau batas kuota. Jika Pod harus menunggu hardware tertentu, nilai ini sudah benar.
- Penyelesaian: Jika menjalankan workload lebih penting daripada menjalankan di hardware tertentu, ubah kebijakan menjadi ScaleUpAnyway.
Jika nilainya adalah ScaleUpAnyway:
- Interpretasi: ini adalah perilaku yang diharapkan. GKE kembali ke jenis node default karena node pilihan tidak tersedia.
- Penyelesaian: Jika Pod tidak boleh berjalan di jenis node default, ubah kebijakan ke DoNotScaleUp.
Perilaku default: jika Anda belum menentukan nilai untuk kolom whenUnsatisfiable dan menggunakan versi GKE yang lebih lama dari 1.33, kebijakan akan ditetapkan ke ScaleUpAnyway secara default.

Contoh berikut menunjukkan cara memperbarui kebijakan dengan mengedit kolom whenUnsatisfiable dalam manifes ComputeClass Anda:

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

Memeriksa batasan penjadwalan Pod

Pastikan spesifikasi Pod Anda kompatibel dengan atribut node yang disediakan oleh ComputeClass kustom.

Memverifikasi permintaan resource Pod

Periksa apakah permintaan CPU, memori, dan GPU Pod dapat dipenuhi oleh setidaknya salah satu jenis mesin yang ditentukan di kolom priorities ComputeClass kustom.

Mendapatkan permintaan resource Pod:

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

Periksa output untuk cpu, memory, dan permintaan GPU, seperti nvidia.com/gpu.

Bandingkan permintaan ini dengan jenis mesin yang ditentukan di kolom priorities dari ComputeClass kustom:
```
kubectl get computeclass CUSTOM_COMPUTECLASS_NAME
    -o jsonpath='{.spec.priorities}'
```
Periksa output untuk melihat kolom machineType atau machineFamily. Untuk setiap jenis mesin di ComputeClass kustom, periksa spesifikasinya dalam dokumentasi jenis mesin dan verifikasi apakah resource yang dapat dialokasikan lebih besar daripada permintaan Pod.

Mengevaluasi hasil

Kompatibel dengan resource: Permintaan resource Pod kurang dari atau sama dengan resource yang dapat dialokasikan dari setidaknya satu jenis mesin di ComputeClass.
Sumber daya melebihi kapasitas:
- Interpretasi: Pod tidak dapat dijadwalkan karena tidak ada jenis mesin di ComputeClass yang menyediakan CPU, memori, atau GPU yang memadai. Hal ini juga dapat terjadi jika kolom nodePoolAutoCreation disetel ke true dan permintaan memori Pod melebihi batas node pool yang dibuat otomatis.
- Resolusi: sesuaikan permintaan resource Pod atau jenis mesin ComputeClass kustom:
  - Kurangi permintaan resource Pod: jika permintaan resource tinggi, turunkan nilai cpu, memory, atau gpu dalam file YAML workload.
  - Beralih ke jenis mesin yang lebih besar: jika permintaan Pod dapat dibenarkan, ubah kolom spec.priorities dalam manifes ComputeClass kustom Anda untuk menyertakan opsi machineType atau machineFamily yang lebih besar yang dapat memenuhi permintaan Pod. Contoh:
```
spec:
  priorities:
  - machineType: n2d-highmem-96 # A larger machine type
    spot: true
  # ... other priorities
```

Memeriksa taint dan toleransi yang bertentangan

Node yang dibuat untuk ComputeClass kustom memiliki taint cloud.google.com/compute-class=CUSTOM_COMPUTECLASS_NAME:NoSchedule. GKE menambahkan toleransi ini ke Pod secara otomatis.

Namun, hardware khusus seperti GPU memiliki taint tambahan seperti taint nvidia.com/gpu=present:NoSchedule. Jika ComputeClass Anda menggunakan node dengan hardware khusus, Pod harus memiliki toleransi untuk taint ini agar dapat dijadwalkan di node tersebut.

Periksa kolom tolerations untuk Pod:

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

Mengevaluasi hasil

Toleransi yang benar: taint dan toleransi dikonfigurasi dengan benar.
Toleransi tidak ada:
- Interpretasi: toleransi yang tidak ada mencegah Pod dijadwalkan pada node dengan taint hardware khusus. Misalnya, jika ComputeClass menggunakan node GPU, Pod mungkin tidak memiliki toleransi nvidia.com/gpu=present:NoSchedule. Untuk mengetahui persyaratan khusus GPU, lihat Memverifikasi konfigurasi GPU.
- Penyelesaian: di kolom tolerations dalam spesifikasi Pod Anda, tambahkan toleransi yang diperlukan agar sesuai dengan taint pada node yang ditentukan oleh ComputeClass. Misalnya, untuk node GPU, tambahkan toleransi untuk taint nvidia.com/gpu=present:NoSchedule sebagai berikut:
```
spec:
template:
spec:
tolerations:
- key: "nvidia.com/gpu"
operator: "Exists"
effect: "NoSchedule"
# ... other tolerations and Pod spec
```

Konfigurasi node pool (Cluster Standard)

Di cluster GKE Standard, node pool yang dibuat secara manual harus diberi label dan taint agar dapat berfungsi dengan ComputeClass kustom.

Memverifikasi label dan taint node pool

Identifikasi node pool di ComputeClass kustom Anda. Jika ComputeClass kustom menggunakan kolom nodePools, catat nama node pool yang tercantum:
```
kubectl get computeclass CUSTOM_COMPUTECLASS_NAME -o yaml
```

Untuk setiap node pool yang Anda identifikasi, verifikasi konfigurasinya:

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

Mengevaluasi hasil

Node pool dikonfigurasi dengan benar: node pool memiliki label cloud.google.com/compute-class: CUSTOM_COMPUTECLASS_NAME dan taint cloud.google.com/compute-class=CUSTOM_COMPUTECLASS_NAME:NoSchedule.

Node pool salah dikonfigurasi:

Interpretasi: node pool tidak dikonfigurasi dengan label dan taint yang diperlukan untuk mengaitkannya dengan ComputeClass kustom.

Penyelesaian: perbarui node pool untuk menambahkan label dan taint:

Tambahkan atau perbarui label node:

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

Menambahkan atau memperbarui taint node:

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

Memverifikasi konfigurasi pembuatan otomatis node pool

Untuk cluster Autopilot dan Standard dengan nodePoolAutoCreation yang disetel ke true, pembuatan otomatis node pool harus dikonfigurasi dengan benar.

Memastikan pembuatan otomatis node pool diaktifkan

Periksa apakah kolom nodePoolAutoCreation.enabled di ComputeClass kustom ditetapkan ke true:
```
kubectl get computeclass CUSTOM_COMPUTECLASS_NAME -o yaml
```

Periksa apakah pembuatan otomatis node pool diaktifkan di cluster:

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

Jika salah satunya dinonaktifkan, pembuatan otomatis node pool tidak akan membuat node pool baru untuk ComputeClass kustom Anda.

Mengevaluasi hasil

Pembuatan otomatis node pool diaktifkan: di ComputeClass, kolom nodePoolAutoCreation.enabled disetel ke true, dan penyediaan otomatis node diaktifkan di tingkat cluster.
Pembuatan otomatis node pool dinonaktifkan:
- Interpretasi: pembuatan otomatis node pool dinonaktifkan jika nilai kolom nodePoolAutoCreation.enabled adalah false atau tidak ada di ComputeClass, atau jika penyediaan otomatis node tingkat cluster dinonaktifkan.
- Penyelesaian: Aktifkan pembuatan otomatis node pool:
  1. Edit file YAML ComputeClass kustom untuk menyertakan nodePoolAutoCreation: enabled: true:
```
spec:
  # ... priorities
  nodePoolAutoCreation:
    enabled: true
```
  2. Aktifkan pembuatan otomatis node pool di tingkat cluster dan konfigurasi batas resource:
```
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
```

Memeriksa batas resource untuk pembuatan otomatis node pool

Pembuatan otomatis pool node memiliki batas di seluruh cluster untuk CPU dan memori. Jika penggunaan cluster saat ini ditambah resource node baru melebihi batas ini, pembuatan otomatis node pool tidak akan menyediakan node baru.

Melihat batas resource:

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

Output mencantumkan kolom resourceType, minimum, dan maximum untuk CPU dan memori (dalam GB).

Tinjau jenis mesin dalam prioritas ComputeClass kustom Anda. Periksa spesifikasi CPU dan memori di dokumentasi jenis mesin.
Tentukan total kapasitas CPU dan memori saat ini dari semua node di cluster. Jumlah kapasitas saat ini ditambah resource node baru potensial tidak boleh melebihi batas maksimum untuk pembuatan otomatis node pool.

Mengevaluasi hasil

Kapasitas yang memadai: cluster memiliki kapasitas CPU dan memori yang memadai dalam batas resource untuk pembuatan otomatis node pool guna menyediakan node baru.
Batas terlampaui:
- Interpretasi: pembuatan otomatis node pool tidak dapat menyediakan node baru karena cluster telah mencapai batas CPU atau memori, atau batas ditetapkan terlalu rendah untuk jenis mesin di ComputeClass.
- Penyelesaian: tingkatkan batas resource untuk pembuatan otomatis node pool:
  1. Tentukan batas maksimum baru yang memperhitungkan penggunaan saat ini dan pertumbuhan di masa mendatang, termasuk jenis mesin terbesar di ComputeClass kustom.
  2. Perbarui batas resource untuk pembuatan otomatis node pool. Anda dapat menetapkan beberapa resource dalam satu perintah:
```
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
```

Menganalisis perilaku penggantian autoscaler

Bagian ini membantu Anda menyelidiki faktor eksternal untuk memahami alasan penskalaan otomatis cluster mungkin melewati opsi yang disukai dan menggunakan penggantian, atau gagal melakukan penskalaan.

ComputeClass kustom menggunakan logika penggantian yang diprioritaskan. Jika Pod tidak dijadwalkan pada node yang cocok dengan aturan prioritas tertinggi, hal ini sering kali disebabkan oleh batasan seperti tidak tersedianya resource atau kuota project. Jika GKE tidak dapat menyediakan node yang cocok dengan aturan prioritas tertentu, misalnya, karena error ZONE_RESOURCE_POOL_EXHAUSTED atau QUOTA_EXCEEDED dari Compute Engine, penskalaan otomatis cluster akan segera mencoba aturan berikutnya dalam daftar priorities. Tidak ada periode tunggu sebelum GKE melakukan penggantian ke prioritas berikutnya, kecuali saat menggunakan TPU atau model penyediaan Flex Start, yang mendukung penundaan yang dapat dikonfigurasi.

Memeriksa ketersediaan resource

Verifikasi apakah resource tidak tersedia di zona yang ditentukan dengan memeriksa log penskala otomatis cluster atau error Grup instance terkelola (MIG) Compute Engine.

Opsi 1: Periksa peristiwa visibilitas autoscaler cluster

Di konsol Google Cloud , buka Cloud Logging > Logs Explorer dan jalankan kueri berikut untuk menemukan peristiwa penskala otomatis yang mungkin menunjukkan ketersediaan resource:

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"

Opsi 2: Periksa error MIG

Anda dapat memeriksa error MIG di konsol Google Cloud atau menggunakan kueri Cloud Logging.

Menggunakan Google Cloud console:
1. Di konsol Google Cloud , buka Compute Engine > Instance groups.
2. Temukan MIG yang sesuai dengan node pool yang gagal melakukan penskalaan.
3. Klik nama MIG, lalu buka tab Errors. Cari pesan yang menunjukkan kehabisan resource.

Menggunakan kueri Cloud Logging:

Di konsol Google Cloud , buka Cloud Logging > Logs explorer.
Jalankan kueri berikut untuk memeriksa error kehabisan resource dari 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")

Mengevaluasi hasil

Sumber daya tersedia: jika log tidak menampilkan pesan ZONE_RESOURCE_POOL_EXHAUSTED, kemungkinan besar kegagalan penskalaan bukan disebabkan oleh tidak tersedianya sumber daya.
Sumber daya tidak tersedia:
- Interpretasi: penyediaan node gagal karena permintaan tinggi sementara untuk jenis mesin tertentu (terutama GPU atau VM Spot) di zona tersebut, atau karena Pod dibatasi oleh afinitas PersistentVolume ke zona yang mengalami tidak tersedianya resource.
- Penyelesaian: Ketersediaan resource bersifat sementara, tetapi Anda dapat meningkatkan ketahanan dengan menambahkan fleksibilitas pada konfigurasi:
  - Diversifikasi jenis mesin: pastikan kolom spec.priorities di ComputeClass kustom berisi beberapa jenis atau kelompok mesin sebagai penggantian:
```
spec:
  priorities:
  - machineFamily: c3  # Highest priority
  - machineFamily: n2d # Fallback option
  - machineFamily: e2  # Lowest priority
```
  - Gunakan cluster regional: jika cluster bersifat zonal, cluster rentan terhadap ketidaktersediaan resource di satu zona tersebut. Dengan menggunakan cluster regional, penskalaan otomatis cluster dapat mencoba menyediakan node di zona lain dalam region yang mungkin memiliki kapasitas.
  - Gunakan reservasi Compute Engine: untuk workload penting yang tidak dapat mentoleransi penundaan, buat reservasi Compute Engine untuk membantu memastikan kapasitas untuk jenis mesin tertentu.

Memverifikasi kuota project

Pastikan project Anda memiliki kuota yang cukup untuk resource, seperti CPU, GPU, dan alamat IP yang diperlukan oleh node baru.

Periksa log autoscaler untuk mengetahui error kuota. Gunakan Cloud Logging untuk menelusuri pesan error terkait kuota dalam peristiwa visibilitas autoscaler:

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"

Atau, gunakan kueri Cloud Logging berikut untuk memeriksa log terkait error kuota dari MIG:

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

Meninjau kuota di konsol Google Cloud :
1. Di konsol Google Cloud , buka IAM & Admin > Quotas.
2. Filter untuk layanan Compute Engine API.
3. Periksa penggunaan untuk metrik yang relevan seperti CPU, GPU (semua jenis), dan alamat IP yang sedang digunakan untuk region tempat cluster GKE Anda berada. Pastikan penggunaan saat ini tidak mencapai batas.

Mengevaluasi hasil

Kuota di bawah batas: Jika penggunaan kuota berada di bawah batas kuota dan tidak ada error QUOTA_EXCEEDED yang ditemukan dalam log, batas kuota tidak akan memblokir penskalaan.
Kuota terlampaui:
- Interpretasi: penyediaan node gagal karena kuota yang tidak mencukupi untuk resource seperti CPU, GPU, alamat IP, atau MIG.
- Penyelesaian: Jika project Anda telah mencapai batas kuota, minta peningkatan kuota.

Konfigurasi lanjutan

Konfigurasi seperti GPU, VM Spot, dan reservasi Compute Engine memiliki persyaratan khusus dan potensi titik kegagalan yang perlu diperiksa.

Memverifikasi konfigurasi GPU

Untuk ComputeClass kustom yang menyediakan node GPU, validasi konfigurasi GPU di ComputeClass kustom dan pastikan Pod memiliki toleransi nvidia.com/gpu wajib.

Periksa YAML ComputeClass kustom untuk blok gpu dalam aturan prioritas:

kubectl get computeclass CUSTOM_COMPUTECLASS_NAME -o yaml

Blok gpu harus menentukan kolom type dan kolom count, misalnya:

priorities:
- machineType: a2-highgpu-1g
  gpu:
    type: nvidia-tesla-a100
    count: 1

Periksa Pod untuk toleransi GPU. Setiap Pod yang perlu dijadwalkan di node GPU harus memiliki toleransi nvidia.com/gpu, meskipun Pod itu sendiri tidak meminta GPU.
```
kubectl get pod POD_NAME -n NAMESPACE -o jsonpath='{.spec.tolerations}'
```
Periksa toleransi di kolom spec.tolerations.

Mengevaluasi hasil

GPU dikonfigurasi dengan benar: jika ComputeClass menentukan GPU type dan count, dan Pod menyertakan toleransi nvidia.com/gpu, konfigurasi GPU sudah benar. Berikut menunjukkan toleransi yang diperlukan:
```
tolerations:
- key: "nvidia.com/gpu"
  operator: "Exists"
  effect: "NoSchedule"
```
GPU salah dikonfigurasi:
- Interpretasi: Pod mungkin tidak memiliki toleransi nvidia.com/gpu yang diperlukan, ComputeClass mungkin tidak berfungsi karena ketidakcocokan kolom GPU, atau versi GKE mungkin tidak menangani konfigurasi GPU dengan benar.
- Penyelesaian: lakukan salah satu tindakan berikut:
  - Ubah file YAML workload untuk menyertakan toleransi GPU wajib dan terapkan kembali file YAML.
  - Upgrade cluster GKE. Jika ComputeClass kustom tidak berfungsi dengan baik dan masalahnya terkait dengan kolom GPU, periksa masalah umum dan upgrade ke versi GKE yang telah di-patch, misalnya, 1.31.8-gke.1045000 atau yang lebih baru.

Memverifikasi konfigurasi VM Spot

Jika Anda menggunakan Spot VM, pastikan setelan spot: true berada dalam aturan prioritas yang benar di manifes ComputeClass Anda. Selain itu, pastikan Anda memahami logika harga autoscaler cluster.

Periksa manifes ComputeClass:

kubectl get computeclass CUSTOM_COMPUTECLASS_NAME -o yaml

Pada output, cari spot: true di kolom spec.priorities, misalnya:

priorities:
- machineFamily: n2d
  spot: true

Cluster autoscaler dapat menggunakan data harga dari us-central1 sebagai dasar saat membandingkan biaya berbagai jenis Spot VM, yang dapat menyebabkan pilihan yang tampaknya tidak optimal di region lain. Ini adalah perilaku yang diketahui.

Mengevaluasi hasil

Spot VM dikonfigurasi dengan benar: jika kolom spot: true ditentukan dan autoscaler cluster menyediakan Spot VM, konfigurasi akan berfungsi seperti yang diharapkan.
Spot VM gagal dijadwalkan:
- Interpretasi: Pod yang memerlukan Spot VM mungkin gagal dijadwalkan di Spot VM karena resource tidak tersedia di zona target, atau karena autoscaler cluster mungkin memilih jenis VM yang berbeda berdasarkan model harga us-central1.
- Penyelesaian:
  - Jika Anda mencurigai ketersediaan resource, lihat Memeriksa ketersediaan resource.
  - Untuk mengontrol pemilihan VM Spot, cantumkan entri machineType secara eksplisit di kolom priorities dari yang termurah hingga yang termahal untuk region Anda. Pendekatan ini memberi Anda kontrol langsung atas urutan penggantian. Contoh:
```
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
```

Kesehatan umum autoscaler cluster

Bagian ini membantu Anda memeriksa masalah yang mungkin tidak terkait langsung dengan konfigurasi ComputeClass kustom, tetapi dapat memengaruhi operasinya.

Memeriksa operasi serentak

Pastikan tidak ada operasi cluster atau node pool lain yang sedang berlangsung secara bersamaan. GKE biasanya hanya mengizinkan satu operasi dalam satu waktu, yang dapat memblokir penskalaan otomatis.

Mencantumkan operasi yang sedang berlangsung dan tidak dalam status DONE:

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

Jika perintah menampilkan operasi apa pun, tindakan seperti upgrade cluster, pembuatan node pool, atau modifikasi lain mungkin sedang berlangsung. Peristiwa penskalaan otomatis mungkin diblokir hingga operasi ini selesai.

Mengevaluasi hasil

Tidak ada operasi serentak: jika perintah list menampilkan daftar kosong, penskala otomatis cluster tidak diblokir oleh operasi apa pun.
Operasi serentak ditemukan:
- Interpretasi: Jika perintah mencantumkan operasi dengan status RUNNING atau PENDING, operasi serentak, seperti upgrade cluster atau modifikasi node pool, mungkin sedang berlangsung dan memblokir penskalaan otomatis.
- Penyelesaian: tunggu hingga operasi yang sedang berlangsung selesai. Anda dapat memantau status menggunakan ID operasi dengan menggunakan:
```
gcloud container operations wait OPERATION_ID --location LOCATION
```
  Ganti OPERATION_ID dengan ID dari output perintah list. Setelah operasi pemblokiran selesai, penskala otomatis cluster akan melanjutkan fungsi normal.

Meninjau migrasi aktif

Jika Anda mengamati workload tetap berada di node berprioritas lebih rendah saat node berprioritas lebih tinggi tersedia, verifikasi apakah migrasi aktif diaktifkan. Jika kolom activeMigration.optimizeRulePriority disetel ke false atau tidak ada di ComputeClass, GKE tidak akan otomatis memindahkan workload ke node berprioritas lebih tinggi saat tersedia.

Untuk memeriksa toleransi Pod, tinjau kolom spec.tolerations. Jika Pod memiliki toleransi yang cocok dengan taint pada beberapa node pool dengan prioritas berbeda, penjadwal mungkin akan menempatkannya di node dengan prioritas lebih rendah jika tersedia terlebih dahulu.
```
kubectl get pod POD_NAME -n NAMESPACE -o jsonpath='{.spec.tolerations[*]}{"\n"}'
```
Untuk memeriksa apakah migrasi aktif diaktifkan, periksa manifes ComputeClass untuk kolom spec.activeMigration.optimizeRulePriority.
```
kubectl get computeclass CUSTOM_COMPUTECLASS_NAME -o yaml
```

Mengevaluasi hasil

Migrasi aktif diaktifkan: jika kolom activeMigration.optimizeRulePriority adalah true, GKE akan mencoba memindahkan workload ke node dengan prioritas lebih tinggi saat tersedia.
Migrasi aktif dinonaktifkan atau tidak efektif:
- Interpretasi: jika kolom activeMigration.optimizeRulePriority adalah false atau tidak ada, atau jika toleransi Pod terlalu luas, workload akan tetap berada di node berprioritas lebih rendah saat node berprioritas lebih tinggi tersedia. Pendekatan ini memungkinkan workload dijadwalkan pada node berprioritas rendah yang tersedia terlebih dahulu.
- Penyelesaian: Jika Anda ingin workload dipindahkan ke node dengan prioritas lebih tinggi, lakukan salah satu tindakan berikut:
  - Gunakan batasan penjadwalan yang lebih spesifik seperti nodeAffinity untuk memprioritaskan node pool dengan prioritas yang lebih tinggi.
  - Edit manifes ComputeClass untuk menyetel activeMigration.optimizeRulePriority: true dan terapkan file YAML:
```
spec:
  activeMigration:
    optimizeRulePriority: true
```

Mendapatkan dukungan

Jika Anda tidak dapat menemukan solusi untuk masalah Anda dalam dokumentasi, lihat Mendapatkan dukungan untuk mendapatkan bantuan lebih lanjut, termasuk saran tentang topik berikut:
- Membuka kasus dukungan dengan menghubungi Layanan Pelanggan Cloud.
- Mendapatkan dukungan dari komunitas dengan mengajukan pertanyaan di StackOverflow dan menggunakan tag google-kubernetes-engine untuk menelusuri masalah serupa. Anda juga dapat bergabung ke #kubernetes-engine channel Slack untuk mendapatkan dukungan komunitas lainnya.
- Membuka masalah atau permintaan fitur menggunakan issue tracker publik.

Memecahkan masalah ComputeClass kustom Tetap teratur dengan koleksi Simpan dan kategorikan konten berdasarkan preferensi Anda.

Konsep utama

Memecahkan masalah berdasarkan gejala

Masalah di luar cakupan

Mengidentifikasi variabel placeholder

Sebelum memulai

Melakukan pemeriksaan diagnostik dasar

Memverifikasi status dan pemilih Pod

Mengevaluasi hasil

Memverifikasi kompatibilitas versi cluster

Mengevaluasi hasil

Memverifikasi konfigurasi ComputeClass kustom

Memeriksa kesehatan dan status ComputeClass

Mengevaluasi hasil

Memvalidasi kebijakan unsatisfiable

Mengevaluasi hasil

Memeriksa batasan penjadwalan Pod

Memverifikasi permintaan resource Pod

Mengevaluasi hasil

Memeriksa taint dan toleransi yang bertentangan

Mengevaluasi hasil

Konfigurasi node pool (Cluster Standard)

Memverifikasi label dan taint node pool

Mengevaluasi hasil

Memverifikasi konfigurasi pembuatan otomatis node pool

Memastikan pembuatan otomatis node pool diaktifkan

Mengevaluasi hasil

Memeriksa batas resource untuk pembuatan otomatis node pool

Mengevaluasi hasil

Menganalisis perilaku penggantian autoscaler

Memeriksa ketersediaan resource

Mengevaluasi hasil

Memverifikasi kuota project

Mengevaluasi hasil

Konfigurasi lanjutan

Memverifikasi konfigurasi GPU

Mengevaluasi hasil

Memverifikasi konfigurasi VM Spot

Mengevaluasi hasil

Kesehatan umum autoscaler cluster

Memeriksa operasi serentak

Mengevaluasi hasil

Meninjau migrasi aktif

Mengevaluasi hasil

Mendapatkan dukungan

Langkah berikutnya

Memecahkan masalah ComputeClass kustom

Memvalidasi kebijakan `unsatisfiable`