Memecahkan masalah autoscaler cluster yang tidak melakukan penskalaan

Jika Pod Anda di Google Kubernetes Engine (GKE) macet dalam status Pending dan node baru tidak ditambahkan, hal ini sering kali mengindikasikan masalah pada fungsi peningkatan skala autoscaler cluster. Masalah ini dapat mencegah aplikasi Anda melakukan penskalaan untuk memenuhi permintaan, menunda deployment, dan memengaruhi ketersediaan layanan.

Gunakan halaman ini untuk mendiagnosis dan menyelesaikan masalah umum yang mencegah autoscaler cluster menambahkan node baru. Dengan memperbaiki masalah ini, penjadwal Kubernetes dapat menempatkan workload Anda dengan cepat dan membantu cluster beradaptasi dengan beban yang meningkat.

Informasi ini penting bagi Developer aplikasi, yang memerlukan aplikasi dan layanan mereka untuk dijadwalkan dan dijalankan dengan andal, serta bagi Admin dan operator platform, yang bertanggung jawab untuk memastikan cluster dapat menyediakan resource secara dinamis guna memenuhi persyaratan workload dan mempertahankan tingkat layanan. Untuk mengetahui informasi selengkapnya tentang peran umum dan contoh tugas yang kami referensikan dalam konten Cloud de Confiance by S3NS , lihat Peran dan tugas pengguna GKE umum.

Memahami kapan autoscaler cluster meningkatkan skala node Anda

Sebelum melanjutkan ke langkah-langkah pemecahan masalah, sebaiknya pahami kapan autoscaler cluster akan mencoba meningkatkan skala node Anda. Autoscaler cluster hanya menambahkan node jika resource yang ada tidak mencukupi.

Setiap 10 detik, autoscaler cluster akan memeriksa apakah ada Pod yang tidak dapat dijadwalkan. Pod menjadi tidak dapat diberi schedule jika scheduler Kubernetes tidak dapat menempatkannya di node yang ada karena resource tidak mencukupi, batasan node, atau persyaratan Pod yang tidak terpenuhi.

Saat menemukan Pod yang tidak dapat dijadwalkan, autoscaler cluster akan mengevaluasi apakah penambahan node akan memungkinkan Pod dijadwalkan. Jika penambahan node memungkinkan Pod dijadwalkan, autoscaler cluster akan menambahkan node baru ke grup instance terkelola (MIG). Scheduler Kubernetes kemudian dapat menjadwalkan Pod pada node yang baru disediakan.

Memeriksa apakah Anda memiliki Pod yang tidak dapat diberi jadwal

Untuk menentukan apakah cluster Anda perlu ditingkatkan skalanya, periksa Pod yang tidak terjadwal:

1. Di konsol Cloud de Confiance , buka halaman Workloads.

   Buka Workloads

2. Di kolom Filter filter_list, masukkan unschedulable dan tekan Enter.

   Jika ada Pod yang tercantum, berarti Anda memiliki Pod yang tidak dapat diberi schedule. Untuk memecahkan masalah Pod yang tidak dapat dijadwalkan, lihat Error: Pod tidak dapat dijadwalkan. Menyelesaikan penyebab mendasar Pod yang tidak dapat dijadwalkan sering kali dapat memungkinkan autoscaler cluster untuk meningkatkan skala. Untuk mengidentifikasi dan menyelesaikan error yang khusus untuk autoscaler cluster, pelajari bagian berikut.

   Jika tidak ada Pod yang tercantum, autoscaler cluster tidak perlu melakukan penskalaan dan berfungsi seperti yang diharapkan.

Memeriksa apakah Anda sebelumnya memiliki Pod yang tidak dapat diberi jadwal

Jika Anda sedang menyelidiki penyebab kegagalan autoscaler cluster di masa lalu, periksa pod yang sebelumnya tidak dapat diberi schedule:

1. Di konsol Cloud de Confiance , buka halaman Logs Explorer.

   Buka Logs Explorer

2. Tentukan rentang waktu untuk entri log yang ingin Anda lihat.

3. Di panel kueri, masukkan kueri berikut:

   logName="projects/PROJECT_ID/logs/events"
   jsonPayload.source.component="default-scheduler"
   jsonPayload.reason="FailedScheduling"
   

   Ganti PROJECT_ID dengan project ID Anda.

4. Klik Run query.

   Jika ada hasil yang tercantum, berarti Anda memiliki Pod yang tidak dapat dijadwalkan dalam rentang waktu yang Anda tentukan.

Memeriksa apakah masalah disebabkan oleh batasan

Setelah mengonfirmasi bahwa Anda memiliki Pod yang tidak terjadwal, pastikan masalah Anda dengan autoscaler cluster tidak disebabkan oleh salah satu batasan untuk autoscaler cluster.

Menganalisis metrik Cloud Monitoring untuk masalah peningkatan skala

Autoscaler cluster GKE mengekspos metrik ke Cloud Monitoring yang memberikan insight tentang keputusannya, terutama terkait ComputeClass. Metrik ini tersedia di GKE versi 1.37 dan yang lebih baru, serta mencakup hal berikut.

• Pod Tertunda: kubernetes.io/autoscaler/cluster_pending_pods_per_ccc menunjukkan Pod yang sedang dicoba dijadwalkan oleh autoscaler.
• Upaya penyediaan: kubernetes.io/autoscaler/cluster_node_provisioning_attempts_count_per_ccc melacak seberapa sering autoscaler mencoba menambahkan node.
• Kegagalan penyediaan: kubernetes.io/autoscaler/cluster_node_provisioning_failed_attempts_count_per_ccc menunjukkan upaya dan alasan pembuatan node yang gagal.

Metrik ini menggunakan jenis resource k8s_entity, dengan nilai kolom resource.labels.entity_type adalah ComputeClass. Nilai kolom resource.labels.entity_name menunjukkan nama ComputeClass. Jika kolom entity_name memiliki string kosong ("") sebagai nilainya, metrik tersebut ditujukan untuk keputusan autoscaler cluster yang tidak terkait dengan ComputeClass.

Gunakan Metrics Explorer untuk memfilter dan mengelompokkan hasil menurut kolom entity_name. Misalnya, gunakan string resource.labels.entity_name = "" untuk melihat aktivitas yang tidak terkait dengan ComputeClass, dan label metrik (seperti reason) untuk memahami apakah masalah peningkatan skala bersifat spesifik untuk ComputeClass.

Untuk contoh kueri, lihat Memantau penyediaan node dan Memantau status Pod yang tertunda.

Lihat error

Anda sering kali dapat mendiagnosis penyebab masalah peningkatan skala dengan melihat pesan error:

• Jika Anda sudah melihat pesan error, lihat tabel pesan error untuk mendapatkan saran tentang cara mengatasi error tersebut.

• Jika Anda belum melihat pesan, gunakan salah satu opsi berikut:

  • Masalah yang terjadi kurang dari 72 jam: Lihat notifikasi error di konsol Cloud de Confiance .
  • Masalah yang berusia lebih dari 72 jam: Lihat error dalam peristiwa di Cloud Logging.

Melihat error di notifikasi

Jika masalah yang Anda amati terjadi kurang dari 72 jam yang lalu, lihat notifikasi tentang error di konsol Cloud de Confiance . Notifikasi ini memberikan insight berharga tentang alasan autoscaler cluster tidak melakukan penskalaan dan menawarkan saran tentang cara menyelesaikan error dan melihat log yang relevan untuk penyelidikan lebih lanjut.

Untuk melihat notifikasi di konsol Cloud de Confiance , selesaikan langkah-langkah berikut:

1. Di konsol Cloud de Confiance , buka halaman Kubernetes clusters.

   Buka Kubernetes clusters

2. Tinjau kolom Notifikasi. Notifikasi berikut terkait dengan masalah peningkatan skala:

   • Can't scale up
   • Can't scale up pods
   • Can't scale up a node pool

3. Klik notifikasi yang relevan untuk melihat panel berisi detail tentang penyebab masalah dan tindakan yang disarankan untuk mengatasinya.

4. Opsional: Untuk melihat log peristiwa ini, klik Logs. Tindakan ini akan mengarahkan Anda ke Logs Explorer dengan kueri yang telah diisi otomatis untuk membantu Anda menyelidiki peristiwa penskalaan lebih lanjut. Untuk mempelajari lebih lanjut cara kerja peristiwa peningkatan skala, lihat Melihat peristiwa autoscaler cluster.

Jika Anda masih mengalami masalah setelah meninjau saran dalam notifikasi, lihat tabel pesan error untuk mendapatkan bantuan lebih lanjut.

Melihat error dalam peristiwa

Jika masalah yang Anda amati terjadi lebih dari 72 jam yang lalu, lihat peristiwa di Cloud Logging. Jika terjadi error, error tersebut sering kali dicatat dalam peristiwa.

Untuk melihat log autoscaler cluster di konsol Cloud de Confiance , selesaikan langkah-langkah berikut:

1. Di konsol Cloud de Confiance , buka halaman Kubernetes clusters.

   Buka Kubernetes clusters

2. Pilih nama cluster yang ingin Anda selidiki untuk melihat halaman Cluster details-nya.

3. Di halaman Cluster details, klik tab Logs.

4. Di tab Logs, klik tab Autoscaler Logs untuk melihat log.

5. Opsional: Untuk menerapkan filter lanjutan guna mempersempit hasil, klik tombol dengan tanda panah di sisi kanan halaman untuk melihat log di Logs Explorer.

Untuk mempelajari lebih lanjut cara kerja peristiwa peningkatan skala, lihat Melihat peristiwa autoscaler cluster. Untuk mengetahui salah satu contoh cara menggunakan Cloud Logging, lihat contoh pemecahan masalah berikut.

Contoh: Memecahkan masalah yang sudah berlangsung lebih dari 72 jam

Contoh berikut menunjukkan cara menyelidiki dan menyelesaikan masalah cluster yang tidak melakukan penskalaan naik.

Skenario: Selama satu jam terakhir, Pod telah ditandai sebagai tidak dapat diberi schedule. Autoscaler cluster tidak menyediakan node baru untuk menjadwalkan Pod.

Solusi:

1. Karena masalah ini terjadi lebih dari 72 jam yang lalu, Anda menyelidiki masalah tersebut menggunakan Cloud Logging, bukan melihat pesan notifikasi.
2. Di Cloud Logging, Anda akan menemukan detail logging untuk peristiwa autoscaler cluster, seperti yang dijelaskan dalam Melihat error dalam peristiwa.

3. Anda menelusuri peristiwa scaleUp yang berisi Pod yang sedang Anda selidiki di kolom triggeringPods. Anda dapat memfilter entri log, termasuk memfilter berdasarkan nilai kolom JSON tertentu. Pelajari lebih lanjut di Kueri log lanjutan.

4. Anda tidak menemukan peristiwa peningkatan skala. Namun, jika Anda melakukannya, Anda dapat mencoba menemukan EventResult yang berisi eventId yang sama dengan peristiwa scaleUp. Kemudian, Anda dapat melihat kolom errorMsg dan melihat daftar kemungkinan pesan error scaleUp.

5. Karena Anda tidak menemukan peristiwa scaleUp, Anda terus menelusuri peristiwa noScaleUp dan meninjau kolom berikut:

   • unhandledPodGroups: berisi informasi tentang Pod (atau pengontrol Pod).
   • reason: memberikan alasan global yang menunjukkan peningkatan skala dapat diblokir.
   • skippedMigs: memberikan alasan mengapa beberapa MIG dapat dilewati.

6. Anda menemukan peristiwa noScaleUp untuk Pod, dan semua MIG di kolom rejectedMigs memiliki ID pesan alasan yang sama, yaitu "no.scale.up.mig.failing.predicate" dengan dua parameter: "NodeAffinity" dan "node(s) did not match node selector".

Resolusi:

Setelah melihat daftar pesan error, Anda akan mengetahui bahwa autoscaler cluster tidak dapat meningkatkan skala node pool karena predikat penjadwalan yang gagal untuk Pod yang tertunda. Parameternya adalah nama predikat yang gagal dan alasan kegagalannya.

Untuk mengatasi masalah ini, tinjau manifes Pod, dan temukan bahwa pemilih node tidak cocok dengan MIG mana pun di cluster. Anda menghapus pemilih dari manifes Pod dan membuat ulang Pod. Autoscaler cluster menambahkan node baru dan Pod dijadwalkan.

Mengatasi error peningkatan skala

Jika Anda menggunakan ComputeClass kustom dan masalah peningkatan skala terkait dengan konfigurasi node tertentu yang ditentukan di ComputeClass, lihat Memecahkan masalah ComputeClass kustom.

Setelah mengidentifikasi error, gunakan tabel berikut untuk membantu Anda memahami penyebab error dan cara mengatasinya.

Error ScaleUp

Anda dapat menemukan pesan error peristiwa untuk peristiwa scaleUp dalam peristiwa eventResult yang sesuai, di kolom resultInfo.results[].errorMsg.

Jika operasi peningkatan skala gagal karena melebihi kuota, hal ini merupakan error pembuatan node yang memicu periode backoff sistem, yang dapat berlangsung hingga 30 menit. Untuk mengetahui informasi selengkapnya, lihat Periode backoff.

Alasan peristiwa noScaleUp

Peristiwa noScaleUp akan dihasilkan secara berkala saat ada Pod yang tidak dapat dijadwalkan di cluster dan autoscaler cluster tidak dapat meningkatkan skala cluster untuk menjadwalkan Pod. Peristiwa noScaleUp adalah upaya terbaik, dan tidak mencakup semua kasus yang memungkinkan.

Alasan tingkat atas NoScaleUp

Pesan alasan tingkat atas untuk peristiwa noScaleUp muncul di kolom noDecisionStatus.noScaleUp.reason. Pesan ini berisi alasan tingkat atas mengapa autoscaler cluster tidak dapat meningkatkan skala cluster.

Alasan node auto-provisioning tingkat atas NoScaleUp

Pesan alasan node auto-provisioning tingkat atas untuk peristiwa noScaleUp muncul di kolom noDecisionStatus.noScaleUp.napFailureReason. Pesan ini berisi alasan utama mengapa autoscaler cluster tidak dapat menyediakan node pool baru.

Alasan tingkat MIG NoScaleUp

Pesan alasan tingkat MIG untuk peristiwa noScaleUp muncul di kolom noDecisionStatus.noScaleUp.skippedMigs[].reason dan noDecisionStatus.noScaleUp.unhandledPodGroups[].rejectedMigs[].reason. Pesan ini berisi alasan mengapa autoscaler cluster tidak dapat meningkatkan ukuran MIG tertentu.

Alasan node auto-provisioning tingkat grup Pod NoScaleUp

Pesan alasan penyediaan otomatis node tingkat grup pod untuk peristiwa noScaleUp muncul di kolom noDecisionStatus.noScaleUp.unhandledPodGroups[].napFailureReasons[]. Pesan ini berisi alasan mengapa autoscaler cluster tidak dapat menyediakan node pool baru untuk menjadwalkan grup Pod tertentu.

Melakukan penyelidikan lebih lanjut

Bagian berikut memberikan panduan tentang cara menggunakan Logs Explorer dan gcpdiag untuk mendapatkan insight tambahan tentang error Anda.

Menyelidiki error di Logs Explorer

Jika Anda ingin menyelidiki pesan error lebih lanjut, lihat log khusus untuk error Anda:

1. Di konsol Cloud de Confiance , buka halaman Logs Explorer.

   Buka Logs Explorer

2. Di panel kueri, masukkan kueri berikut:

   resource.type="k8s_cluster"
   log_id("container.googleapis.com/cluster-autoscaler-visibility")
   jsonPayload.resultInfo.results.errorMsg.messageId="ERROR_MESSAGE"
   

   Ganti ERROR_MESSAGE dengan pesan yang ingin Anda selidiki. Contoh, scale.up.error.out.of.resources.

3. Klik Run query.

Men-debug beberapa error dengan gcpdiag

gcpdiag adalah alat open source yang dibuat dengan dukungan dari engineer teknis Cloud de Confiance by S3NS. Produk ini bukan produk Cloud de Confiance by S3NS yang didukung secara resmi.

Jika Anda mengalami salah satu pesan error berikut, Anda dapat menggunakan gcpdiag untuk membantu memecahkan masalah:

• scale.up.error.out.of.resources
• scale.up.error.quota.exceeded
• scale.up.error.waiting.for.instances.timeout
• scale.up.error.ip.space.exhausted
• scale.up.error.service.account.deleted

Untuk mengetahui daftar dan deskripsi semua flag alat gcpdiag, lihat petunjuk penggunaan gcpdiag.

Menyelesaikan error peningkatan skala yang kompleks

Bagian berikut membantu Anda menyelesaikan error yang memerlukan beberapa langkah atau tidak memiliki pesan peristiwa terkait dari autoscaler cluster.

Pod tidak sesuai di node

Gejala:

Pod Anda tetap dalam status Pending dengan pesan error PodUnschedulable, atau cluster Anda menampilkan pesan error Pods unschedulable, dan autoscaler cluster tidak melakukan penskalaan untuk menambahkan node.

Penyebab:

Autoscaler cluster hanya menambahkan node ke node pool jika jenis mesin menyediakan resource yang cukup, seperti CPU, GPU, memori, dan penyimpanan, untuk Pod yang tertunda. Jika permintaan resource Pod melebihi resource dari satu node, autoscaler cluster tidak akan meningkatkan skala karena Pod masih tidak dapat muat di node baru.

Selain itu, resource yang dapat dialokasikan dari sebuah node lebih sedikit daripada total resource-nya karena komponen sistem mencadangkan sebagian dari resource tersebut. Untuk mengetahui informasi selengkapnya tentang cara GKE menghitung resource yang dapat dialokasikan, lihat Resource yang dapat dialokasikan node.

Resolusi:

Untuk memeriksa apakah permintaan resource Pod melebihi resource yang disediakan oleh node Anda dan menyelesaikan masalah tersebut, selesaikan langkah-langkah berikut. Contoh ini memeriksa resource CPU, tetapi langkah yang sama berlaku untuk resource GPU, memori, dan penyimpanan:

1. Di konsol Cloud de Confiance , buka halaman Workloads.

   Buka Workloads

2. Klik pesan error PodUnschedulable.

3. Di panel Details, klik nama Pod. Jika ada beberapa Pod, mulai dengan Pod pertama dan ulangi proses berikut untuk setiap Pod.

4. Di halaman Pod details, klik tab YAML.

5. Catat permintaan resource setiap container di Pod untuk menemukan total permintaan resource. Misalnya, dalam konfigurasi Pod berikut, Pod memerlukan 2 vCPU:

   resources:
     limits:
       cpu: "3"
     requests:
       cpu: "2"
   

6. Lihat detail node pool dari cluster dengan Pod yang tidak terjadwal:

   1. Di konsol Cloud de Confiance , buka halaman Kubernetes clusters.

      Buka Kubernetes clusters

   2. Klik nama cluster yang memiliki pesan error Pods unschedulable.

   3. Di halaman Cluster details, klik tab Nodes.

   4. Di bagian Node pools, perhatikan nilai di kolom Machine type, misalnya, n1-standard-1.

7. Bandingkan permintaan resource dengan vCPU yang disediakan oleh jenis mesin. Misalnya, jika Pod meminta 2 vCPU, tetapi node yang tersedia menggunakan jenis mesin n1-standard-1, node tersebut hanya memiliki 1 vCPU. Dengan konfigurasi seperti ini, autoscaler cluster tidak akan memicu peningkatan skala karena Pod masih tidak dapat muat di node baru. Untuk mengetahui informasi selengkapnya tentang jenis mesin yang tersedia, lihat Panduan perbandingan dan resource kelompok mesin dalam dokumentasi Compute Engine.

8. Selesaikan ketidakcocokan berdasarkan kebutuhan workload Anda:

   • Jika Pod memerlukan resource yang diminta: buat node pool dengan jenis mesin yang dapat mendukung permintaan resource Pod.
   • Jika permintaan resource Pod tidak akurat: perbarui definisi Pod agar Pod dapat sesuai dengan node yang ada.

Instance MIG gagal muncul tepat waktu

Gejala:

Anda akan melihat salah satu pesan error berikut:

• Di konsol Cloud de Confiance , cluster akan menampilkan notifikasi berikut:

  Can't scale up because instances in managed instance groups hosting node pools failed to appear in time
  

• Di Logging, peristiwa eventResult untuk peningkatan skala berisi pesan error berikut:

  scale.up.error.waiting.for.instances.timeout
  

Penyebab:

Compute Engine tidak dapat membuat node di MIG, atau node baru gagal mendaftar dengan bidang kontrol sebelum waktu operasi peningkatan skala habis. Masalah ini dapat terjadi karena salah satu alasan berikut:

• Pendaftaran node gagal: Compute Engine membuat node, tetapi node tersebut tidak mendaftar ke bidang kontrol karena satu atau beberapa aturan firewall, perubahan terbaru pada akses layanan pribadi atau Peering Jaringan VPC, atau akun layanan Identity and Access Management (IAM) yang tidak ada.
• Kuota project terlampaui: instance baru di MIG tidak muncul karena project Anda melebihi kuota untuk CPU, alamat IP, atau resource lainnya.
• Alamat IP tidak tersedia: subnet tidak memiliki alamat IP kosong yang cukup untuk membuat node baru.
• Template instance tidak valid: MIG menggunakan template instance yang tidak valid, seperti template dengan image yang tidak ada, sehingga mencegah peningkatan skala.
• Resource tidak cukup: zona tidak memiliki resource Compute Engine yang cukup, seperti GPU atau CPU, untuk membuat node baru.
• API tidak dapat diakses: API yang diperlukan, seperti compute.googleapis.com, tidak dapat diakses karena aturan firewall atau perimeter Kontrol Layanan VPC.
• Latensi jaringan: latensi jaringan yang signifikan akan menunda pembuatan atau kegunaan node baru.

Resolusi:

1. Untuk mengidentifikasi penyebab waktu tunggu habis, cantumkan error instance di MIG, lalu periksa hasilnya:

   • MIG tidak mencantumkan error dari waktu kegagalan: Compute Engine membuat node, tetapi node tidak mendaftar dengan bidang kontrol sebelum waktu tunggu habis. Pada langkah berikutnya, mulai dengan Pendaftaran node gagal. Jika node terdaftar, tetapi memerlukan waktu terlalu lama, lihat Latensi jaringan.

   • MIG mencantumkan error dari waktu kegagalan: Compute Engine tidak dapat membuat node. Gunakan kode error dan pesan error untuk menemukan penyebabnya di langkah berikutnya. Kode error umum mencakup hal berikut:

     • QUOTA_EXCEEDED: melebihi kuota project
     • IP_SPACE_EXHAUSTED: alamat IP yang tidak tersedia
     • ZONE_RESOURCE_POOL_EXHAUSTED: resource tidak memadai

     Beberapa kode error memiliki akhiran _WITH_DETAILS dan menyertakan informasi selengkapnya dalam pesan error. Jika pesan error melaporkan resource yang tidak ada, seperti image sumber, lihat poin Template instance tidak valid.

2. Gunakan penyelesaian yang sesuai dengan penyebab masalah Anda:

   • Pendaftaran node gagal: ikuti langkah-langkah di Menemukan instance yang gagal melakukan pendaftaran node. Anda juga dapat memeriksa perubahan konfigurasi terbaru:

     • Aturan firewall: untuk memeriksa apakah aturan firewall baru saja dibuat, diperbarui, atau dihapus, jalankan kueri berikut di Logs Explorer:

       resource.type="gce_firewall_rule"
       log_id("cloudaudit.googleapis.com/activity")
       

       Jika perubahan memblokir traffic antara node dan bidang kontrol atau ke Google API, perbarui atau ganti aturan firewall. Untuk mengetahui informasi selengkapnya tentang konektivitas yang diperlukan, lihat Prasyarat untuk pendaftaran node yang berhasil.

     • Akun layanan IAM: untuk akun layanan yang tidak ada, lihat baris scale.up.error.service.account.deleted di tabel Error ScaleUp.

     • Akses layanan pribadi: untuk memeriksa perubahan terbaru dalam log audit, lihat Logging audit akses layanan pribadi.

     • Peering Jaringan VPC: untuk memeriksa apakah peering baru-baru ini ditambahkan, diperbarui, atau dihapus, jalankan kueri berikut di Logs Explorer untuk setiap project yang di-peering:

       log_id("cloudaudit.googleapis.com/activity")
       resource.type="gce_network"
       protoPayload.methodName:("compute.networks.addPeering" OR
       "compute.networks.updatePeering" OR
       "compute.networks.removePeering")
       

       Jika perubahan peering mengganggu konektivitas ke bidang kontrol, perbarui koneksi peering. Jika koneksi dihapus, lihat Koneksi Peering Jaringan VPC tidak sengaja dihapus.

   • Melebihi kuota project: lihat baris scale.up.error.quota.exceeded di tabel Error ScaleUp.

   • Alamat IP tidak tersedia: lihat baris scale.up.error.ip.space.exhausted di tabel Error ScaleUp.

   • Template instance tidak valid: lihat Template instance tidak valid dalam dokumentasi Compute Engine.

   • Resource tidak cukup: lihat baris scale.up.error.out.of.resources di tabel Error ScaleUp.

   • API yang tidak dapat diakses: di Logs Explorer, jalankan kueri untuk memeriksa aktivitas yang terkait dengan aturan firewall atau perimeter Kontrol Layanan VPC:

     • Untuk memeriksa apakah aturan firewall baru saja diubah, jalankan kueri log audit di poin Aturan firewall pada bagian Pendaftaran node gagal. Jika Anda mengaktifkan Firewall Rules Logging untuk aturan Anda, Anda juga dapat melihat koneksi yang ditolak oleh aturan Anda dengan menjalankan kueri berikut:

       resource.type="gce_subnetwork"
       log_id("compute.googleapis.com/firewall")
       jsonPayload.disposition="DENIED"
       

       Jika log menampilkan aturan firewall yang memblokir traffic ke Google API yang diperlukan, perbarui atau ganti aturan firewall untuk mengizinkan traffic. Untuk mengetahui informasi selengkapnya tentang persyaratan jaringan, lihat Prasyarat untuk koneksi jaringan ke Google API dan layanan Google.

     • Jika Anda menggunakan Kontrol Layanan VPC, pilih organisasi Anda di konsol Cloud de Confiance dan jalankan kueri berikut di Logs Explorer untuk memeriksa apakah perimeter baru saja ditambahkan atau diubah:

       logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Factivity"
       protoPayload.serviceName="accesscontextmanager.googleapis.com"
       

       Ganti ORGANIZATION_ID dengan ID organisasi Anda.

       Anda juga dapat menambahkan filter berikut untuk menemukan update atau pembuatan perimeter Kontrol Layanan VPC:

       severity=NOTICE
       protoPayload.methodName=("google.identity.accesscontextmanager.v1.AccessContextManager.CreateServicePerimeter"
       OR "google.identity.accesscontextmanager.v1.AccessContextManager.UpdateServicePerimeter")
       

       Jika perimeter baru atau yang diubah memblokir akses ke Google API yang diperlukan, ambil error Kontrol Layanan VPC dari log audit untuk mengidentifikasi layanan yang diblokir dan perbarui perimeter layanan untuk mengizinkan akses. Untuk mengetahui informasi selengkapnya tentang penggunaan autoscaler cluster dalam perimeter, lihat Autoscaler tidak berfungsi di perimeter dengan layanan yang dapat diakses dan layanan yang dibatasi diaktifkan.

   • Latensi jaringan: latensi jaringan sementara biasanya akan teratasi pada upaya peningkatan skala berikutnya. Untuk latensi persisten, lihat Memecahkan masalah jaringan umum dalam dokumentasi Compute Engine.

Cluster yang tidak responsif mencegah peningkatan skala

Gejala:

Autoscaler cluster menghentikan semua operasi penskalaan, dan ConfigMap cluster-autoscaler-status berisi peristiwa dengan jenis Warning dan ClusterUnhealthy yang tercantum sebagai alasannya.

Untuk melihat ConfigMap cluster-autoscaler-status, jalankan perintah berikut:

kubectl describe configmap cluster-autoscaler-status -n kube-system

Penyebab:

Autoscaler cluster tidak akan meningkatkan skala jika menganggap cluster tidak responsif. Autoscaler cluster menentukan kondisi cluster berdasarkan rasio node yang responsif dan siap, bukan berdasarkan kondisi bidang kontrol. Jika 45% node dalam cluster tidak responsif atau tidak siap, autoscaler cluster akan menghentikan semua operasi.

Autoscaler cluster juga menganggap node yang siap sebagai NotReady jika node tersebut memiliki taint dengan awalan ignore-taint.cluster-autoscaler.kubernetes.io/. Autoscaler cluster memperlakukan node sebagai NotReady selama taint tersebut ada.

Resolusi:

Untuk mengatasi masalah ini, kurangi jumlah node yang tidak responsif dengan melakukan salah satu atau kedua tindakan berikut:

• Selidiki dan perbaiki node yang tidak responsif atau NotReady sehingga kurang dari 45% node dalam cluster tidak responsif.
• Jika node yang siap memiliki taint dengan awalan ignore-taint.cluster-autoscaler.kubernetes.io/, hapus taint tersebut.

Langkah berikutnya

• Tinjau FAQ autoscaler cluster Kubernetes.
• Tonton video YouTube tentang memecahkan masalah dan menyelesaikan masalah penskalaan.

• Memecahkan masalah ComputeClass kustom.

• 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 Cloud Customer Care.
  • Mendapatkan dukungan dari komunitas dengan mengajukan pertanyaan di StackOverflow dan menggunakan tag google-kubernetes-engine untuk menelusuri masalah serupa. Anda juga dapat bergabung ke saluran Slack #kubernetes-engine untuk mendapatkan dukungan komunitas lainnya.
  • Membuka laporan masalah atau permintaan fitur menggunakan issue tracker publik.