Memecahkan masalah ComputeClass kustom

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:

  • ComputeClass Kustom: resource khusus GKE yang memungkinkan Anda menentukan daftar konfigurasi node yang diprioritaskan 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 node pool.

  • 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.

Memecahkan masalah berdasarkan gejala

Dokumen ini mengatur langkah-langkah pemecahan masalah secara berurutan, mulai dari pemeriksaan dasar hingga konfigurasi yang lebih lanjut. 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
Autoscaler cluster tidak membuat node baru yang cocok dengan ComputeClass kustom
Autoscaler cluster 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 umum
Workload GPU atau Spot VM mengalami masalah penjadwalan

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 ketidaktersediaan 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 berada dalam status Pending dan meminta ComputeClass kustom dengan benar.

  1. Cantumkan Pod dalam status Pending:

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

  2. 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 menggunakan 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 Tugas, 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.

Verifikasi node yang disediakan untuk ComputeClass kustom

Untuk memeriksa apakah ada node di cluster yang terkait dengan ComputeClass Anda, cantumkan node yang cocok dengan label ComputeClass:

kubectl get nodes -l cloud.google.com/compute-class=CUSTOM_COMPUTECLASS_NAME

Jika output-nya adalah No resources found, berarti tidak ada node yang dikaitkan dengan ComputeClass. Pastikan workload Anda benar-benar memilih ComputeClass tersebut dan periksa peristiwa penskalaan otomatis untuk melihat error peningkatan skala.

Memverifikasi konfigurasi ComputeClass kustom

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

Memeriksa status dan kondisi ComputeClass

Pastikan GKE melaporkan ComputeClass kustom sebagai responsif.

  1. Mencantumkan semua resource ComputeClass:

    kubectl get computeclass

  2. Deskripsikan 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 responsif:

    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 direferensikan ada atau update ComputeClass untuk mereferensikan node pool yang ada.
      • ReservationUnusable: periksa konfigurasi dan penggunaan pemesanan yang dirujuk.
      • Invalid machine type: update 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 mungkin berjalan pada jenis node default (seperti seri E2) jika node yang diinginkan tidak tersedia.

Mengevaluasi hasil

Efek kebijakan whenUnsatisfiable bergantung pada nilainya:

  • Jika nilainya adalah DoNotScaleUp:
    • Penafsiran: ini adalah perilaku yang diharapkan saat tidak ada aturan prioritas yang dapat dipenuhi, mungkin karena ketidaktersediaan 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 menjadi DoNotScaleUp.
  • Perilaku default: jika Anda belum menentukan nilai untuk kolom whenUnsatisfiable dan menggunakan versi GKE yang lebih lama dari 1.33, kebijakan akan ditetapkan secara default ke ScaleUpAnyway.

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

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.

  1. Dapatkan 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.

  2. 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 kolom machineType atau machineFamily. Untuk setiap jenis mesin di ComputeClass kustom, periksa spesifikasinya dalam dokumentasi jenis mesin dan pastikan apakah resource yang dapat dialokasikan lebih besar daripada permintaan Pod.

Mengevaluasi hasil

  • Resource kompatibel: Permintaan resource Pod kurang dari atau sama dengan resource yang dapat dialokasikan dari setidaknya satu jenis mesin di ComputeClass.

  • Resource melebihi kapasitas:

    • Penafsiran: 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.
    • Penyelesaian: 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.
      • Ubah ke jenis mesin yang lebih besar: jika permintaan Pod 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 terhadap taint ini agar dapat dijadwalkan pada 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:

    • Penafsiran: 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, 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

Menganalisis metrik Pod tertunda autoscaler cluster

Versi GKE yang berlaku: 1.37 dan yang lebih baru

Untuk memahami alasan Pod yang meminta ComputeClass tertentu tertunda, gunakan metrik kubernetes.io/autoscaler/cluster_pending_pods_per_ccc di Cloud Monitoring. Metrik ini membantu Anda menentukan apakah masalahnya adalah kurangnya node yang sesuai untuk ComputeClass, masalah pada penyediaan, atau sesuatu yang melekat pada konfigurasi Pod. Metrik ini menunjukkan jumlah Pod yang sedang diproses oleh autoscaler cluster, yang dikelompokkan berdasarkan ComputeClass, alasan tertunda, dan apakah Pod tersebut merupakan Pod sistem atau pengguna.

Langkah-langkah untuk membuat kueri

Untuk mengkueri metrik di konsol Google Cloud , lakukan langkah-langkah berikut:

  1. Di konsol Google Cloud , buka halaman Metrics Explorer.
  2. Pilih Resource type: k8s_entity.
  3. Pilih Metric: kubernetes.io/autoscaler/cluster_pending_pods_per_ccc.
  4. Tambahkan Filter: entity_type = ComputeClass.
  5. Tambahkan Filter untuk ComputeClass spesifik Anda: entity_name = "COMPUTECLASS_NAME".
    • Untuk melihat Pod yang tidak menggunakan ComputeClass apa pun, filter dengan entity_name = "".
  6. Kelompokkan menurut metric.labels.reason untuk melihat status autoscaler untuk Pod ini. Anda juga dapat mengelompokkan Pod menggunakan label kunci metric.labels.type key.

Contoh kueri PromQL

Untuk menemukan status Pod pengguna yang tertunda yang meminta ComputeClass "COMPUTECLASS_NAME", gunakan kueri PromQL berikut:

sum by (reason) (
  kubernetes_io:autoscaler_cluster_pending_pods_per_ccc{
    monitored_resource="k8s_entity",
    entity_type="ComputeClass",
    entity_name="COMPUTECLASS_NAME",
    type="user_pod"
  }
)

Alasan metrik

Output label kunci metric.labels.reason mungkin mencakup hal berikut:

  • unable_to_provision: Penskala otomatis cluster diblokir. Pod dalam status ini untuk ComputeClass tidak dapat dijadwalkan karena node baru tidak dapat dibuat. Periksa log autoscaler cluster di bidang kontrol untuk mengetahui detail tentang kehabisan stok, kuota, atau kesalahan konfigurasi dalam definisi ComputeClass. Tinjau juga peristiwa visibilitas autoscaler cluster.

  • provisioning_in_progress: Peningkatan skala telah dipicu untuk node yang harus sesuai dengan persyaratan ComputeClass. Jika Pod tetap berada di sini, mungkin ada penundaan dalam pembuatan atau kesiapan node.

  • unprocessed: Autoscaler cluster belum mengevaluasi Pod ini. Jumlah tinggi yang persisten mungkin mengindikasikan keterlambatan autoscaler.

  • no_action_taken: Autoscaler cluster telah memutuskan untuk tidak melakukan penskalaan untuk Pod ini. Perilaku ini mungkin disebabkan oleh batasan Pod yang tidak dapat dipenuhi oleh jenis node ComputeClass, atau batas tingkat cluster lainnya. Periksa spesifikasi Pod (kubectl describe pod) dan log autoscaler cluster.

Menganalisis kegagalan penyediaan node

Versi GKE yang berlaku: 1.37 dan yang lebih baru

Untuk memeriksa status respons ComputeClass saat ini, lihat Memverifikasi respons ComputeClass. Jika Anda mengamati bahwa Pod yang terkait dengan ComputeClass berada dalam status unable_to_provision, autoscaler cluster tidak menyediakan node baru yang sesuai dengan persyaratan ComputeClass. Anda dapat menggunakan metrik Cloud Monitoring kubernetes.io/autoscaler/cluster_node_provisioning_failed_attempts_count_per_ccc untuk mendiagnosis akar masalah.

  1. Di konsol Google Cloud , buka Monitoring, lalu Metrics Explorer.
  2. Pilih Jenis resource sebagai k8s_entity.
  3. Pilih Metric sebagai kubernetes.io/autoscaler/cluster_node_provisioning_failed_attempts_count_per_ccc.
  4. Tambahkan Filter: resource.labels.entity_type = ComputeClass.
  5. Tambahkan Filter untuk ComputeClass spesifik Anda: entity_name = "CUSTOM_COMPUTECLASS_NAME".
    • Untuk melihat Pod yang tidak menggunakan ComputeClass apa pun, filter dengan entity_name = "".
  6. Di bagian Kelompokkan Menurut, pilih metric.labels.reason dan resource.labels.entity_name.
  7. Pilih Aggregator, seperti rate atau delta.

Rasio atau perubahan kegagalan ditampilkan, yang dikelompokkan menurut alasan.

Menafsirkan alasan kegagalan

Kolom metric.labels.reason memberikan insight tentang alasan pembuatan node gagal. Dengan mengidentifikasi alasan utama kegagalan, Anda dapat mengambil tindakan korektif.

Kemungkinan alasannya meliputi:

Alasan Penjelasan Kemungkinan tindakan korektif
QUOTA_EXCEEDED Batas kuota Google Cloud telah tercapai (misalnya, CPU, disk, atau alamat IP). Tinjau kuota project Anda. Minta penambahan kuota.
RESOURCE_POOL_EXHAUSTED Compute Engine tidak tersedia; kapasitas tidak memadai untuk resource yang diminta di zona tersebut. Coba jenis atau zona mesin yang berbeda. Ubah ComputeClass untuk menyertakan jenis atau zona mesin penggantian. Gunakan reservasi.
IP_SPACE_EXHAUSTED Subnet node telah kehabisan alamat IP yang tersedia. Perluas rentang alamat IP utama subnet.
PERMISSIONS_ERROR Akun layanan GKE tidak memiliki izin IAM yang diperlukan untuk membuat resource (misalnya, instance, disk). Berikan peran yang diperlukan ke akun layanan GKE.
VM_EXTERNAL_IP_ACCESS_POLICY_CONSTRAINT Kebijakan organisasi (constraints/compute.vmExternalIpAccess) mencegah pembuatan node dengan IP eksternal seperti yang dikonfigurasi. Tinjau dan ubah kebijakan organisasi atau konfigurasi node ComputeClass.
INVALID_RESERVATION Konfigurasi reservasi Compute Engine tidak valid, salah konfigurasi, atau tidak cocok dengan permintaan node. Periksa setelan reservasi dan definisi ComputeClass.
RESERVATION_NOT_FOUND Nama pemesanan Compute Engine yang ditentukan tidak ada. Verifikasi nama pemesanan di ComputeClass.
RESERVATION_NOT_READY Pemesanan yang ditargetkan belum aktif atau masih disediakan. Tunggu hingga pemesanan menjadi aktif.
RESERVATION_CAPACITY_EXCEEDED Reservasi penuh dan tidak dapat mengakomodasi permintaan. Tingkatkan ukuran pemesanan atau gunakan jenis mesin lain.
RESERVATION_INCOMPATIBLE Konfigurasi node (misalnya, jenis mesin atau zona) tidak cocok dengan properti reservasi. Sesuaikan spesifikasi node ComputeClass dengan properti pemesanan.
AUTOMATIC_RESERVATIONS_NOT_AVAILABLE Terjadi masalah saat mencoba menggunakan pemesanan otomatis. Periksa log; Anda mungkin perlu menghubungi Cloud Customer Care.
AUTOMATIC_RESERVATIONS_NO_CAPACITY Reservasi otomatis tidak memiliki kapasitas yang memadai. Mungkin perlu beralih ke pemesanan manual atau jenis mesin lain.
UNSUPPORTED_TPU_CONFIGURATION Konfigurasi TPU yang diminta tidak valid atau tidak didukung di zona atau project yang dipilih. Periksa dokumentasi TPU dan ComputeClass.
GkePersistentOperationError Terjadi error persisten dalam bidang kontrol GKE selama proses pembuatan node. Hubungi Cloud Customer Care.
OTHER Penjelasan umum untuk kegagalan yang tidak sesuai dengan kategori lain. Untuk mengetahui detail selengkapnya, tinjau log autoscaler cluster di bidang kontrol.

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

  1. 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

  2. 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:

      1. Menambahkan atau memperbarui 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

      2. 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

  1. Periksa apakah kolom nodePoolAutoCreation.enabled di ComputeClass kustom ditetapkan ke true:

    kubectl get computeclass CUSTOM_COMPUTECLASS_NAME -o yaml

  2. 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 ditetapkan ke true, dan node auto-provisioning diaktifkan di tingkat cluster.

  • Pembuatan otomatis node pool dinonaktifkan:

    • Penafsiran: pembuatan otomatis node pool dinonaktifkan jika nilai kolom nodePoolAutoCreation.enabled adalah false atau tidak ada di ComputeClass, atau jika node auto-provisioning 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 node pool 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.

  1. Lihat 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).

  2. Tinjau jenis mesin dalam prioritas ComputeClass kustom Anda. Periksa spesifikasi CPU dan memori di dokumentasi jenis mesin.

  3. Tentukan total kapasitas CPU dan memori saat ini dari semua node dalam cluster. Jumlah kapasitas saat ini ditambah resource node baru yang 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:

    • Penafsiran: 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 autoscaler cluster mungkin melewati opsi yang diinginkan dan menggunakan penggantian, atau gagal meningkatkan skala.

ComputeClass kustom menggunakan logika fallback yang diprioritaskan. Jika Pod tidak dijadwalkan pada node yang cocok dengan aturan prioritas tertinggi, hal ini sering kali disebabkan oleh batasan seperti ketidaktersediaan 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, autoscaler cluster akan segera mencoba aturan berikutnya dalam daftar priorities. Tidak ada masa tunggu sebelum GKE beralih ke prioritas berikutnya, kecuali saat menggunakan TPU atau model penyediaan Flex Start, yang mendukung penundaan yang dapat dikonfigurasi.

Memeriksa ketidaktersediaan resource

Verifikasi apakah resource tidak tersedia di zona yang ditentukan dengan memeriksa log autoscaler 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 autoscaler yang mungkin mengindikasikan ketidaktersediaan 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 konsol Google Cloud :

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

  • Menggunakan kueri Cloud Logging:

    1. Di konsol Google Cloud , buka Cloud Logging > Logs explorer.
    2. Jalankan kueri berikut untuk memeriksa error kelelahan 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.

  • Resource tidak tersedia:

    • Interpretasi: penyediaan node gagal karena permintaan tinggi sementara untuk jenis mesin tertentu (terutama Spot VM atau GPU) di zona tersebut, atau karena Pod dibatasi oleh afinitas PersistentVolume ke zona yang mengalami ketersediaan resource.

    • Penyelesaian: Ketidaktersediaan resource bersifat sementara, tetapi Anda dapat meningkatkan ketahanan dengan menambahkan fleksibilitas ke konfigurasi Anda:

      • Diversifikasi jenis mesin: pastikan kolom spec.priorities di ComputeClass kustom berisi beberapa jenis atau kelompok mesin sebagai pengganti:

        spec:
  priorities:
  - machineFamily: c3  # Highest priority
  - machineFamily: n2d # Fallback option
  - machineFamily: e2  # Lowest priority

      • Gunakan cluster regional: jika cluster bersifat zonal, cluster tersebut rentan terhadap ketidaktersediaan resource di satu zona tersebut. Dengan menggunakan cluster regional, autoscaler cluster dapat mencoba menyediakan node di zona lain dalam region tempat kapasitas mungkin tersedia.

      • Gunakan pemesanan Compute Engine: untuk workload penting yang tidak dapat menoleransi penundaan, buat pemesanan 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.

  1. 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

  2. Meninjau kuota di konsol Google Cloud :

    1. Di konsol Google Cloud , buka IAM & Admin > Quota.
    2. Filter untuk layanan Compute Engine API.
    3. Periksa penggunaan untuk metrik yang relevan seperti CPU, GPU (semua jenis), dan alamat IP yang 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 peningkatan skala.
  • 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 penambahan kuota.

Konfigurasi lanjutan

Konfigurasi seperti GPU, Spot VM, 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.

  1. 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

  2. Periksa Pod untuk toleransi GPU. Setiap Pod yang perlu dijadwalkan pada 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 type dan count GPU, dan Pod menyertakan toleransi nvidia.com/gpu, konfigurasi GPU sudah benar. Berikut ini menunjukkan toleransi yang diperlukan:

    tolerations:
- key: "nvidia.com/gpu"
  operator: "Exists"
  effect: "NoSchedule"

  • GPU salah dikonfigurasi:

    • Penafsiran: Pod mungkin tidak memiliki toleransi nvidia.com/gpu yang diperlukan, ComputeClass mungkin tidak responsif 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.
      • Mengupgrade cluster GKE. Jika ComputeClass kustom tidak berfungsi 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 Spot VM

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

Autoscaler cluster mungkin menggunakan data harga dari us-central1 sebagai dasar pengukuran 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:

    • Penafsiran: 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-nya.

    • Penyelesaian:

      • Jika Anda mencurigai ketidaktersediaan resource, lihat Memeriksa ketidaktersediaan resource.

      • Untuk mengontrol pemilihan Spot VM, cantumkan entri machineType secara eksplisit di kolom priorities dari yang termurah hingga 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 mungkin memengaruhi operasinya.

Memeriksa operasi serentak

Pastikan tidak ada operasi cluster atau node pool lain yang sedang berlangsung secara bersamaan. GKE memiliki batasan pada operasi serentak, 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 lainnya 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:

    • Penafsiran: 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, autoscaler cluster akan melanjutkan fungsi normal.

Meninjau migrasi aktif

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

  1. 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 menempatkannya di node dengan prioritas lebih rendah jika tersedia terlebih dahulu.

    kubectl get pod POD_NAME -n NAMESPACE -o jsonpath='{.spec.tolerations[*]}{"\n"}'

  2. 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 node tersebut tersedia.

  • Migrasi aktif dinonaktifkan atau tidak efektif:

    • Penafsiran: jika kolom activeMigration.optimizeRulePriority adalah false atau dihilangkan, 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 lebih 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 memilih node pool dengan prioritas lebih tinggi.

      • Edit manifes ComputeClass untuk menyetel activeMigration.optimizeRulePriority: true dan terapkan file YAML:

        spec:
  activeMigration:
    optimizeRulePriority: true

Mendapatkan dukungan

Langkah berikutnya