Memecahkan masalah autoscaler cluster yang tidak menskalakan ke bawah

Halaman ini menunjukkan cara mendiagnosis dan menyelesaikan masalah yang mencegah penskalaan node Google Kubernetes Engine (GKE) oleh penskala otomatis cluster.

Halaman ini ditujukan untuk developer Aplikasi yang ingin menyelesaikan situasi yang tidak terduga atau negatif dengan aplikasi atau layanan mereka, serta admin dan operator Platform yang ingin mencegah gangguan pada pengiriman produk dan layanan.

Memahami kapan autoscaler cluster menurunkan skala node Anda

Sebelum melanjutkan ke langkah-langkah pemecahan masalah, sebaiknya pahami kapan penskala otomatis cluster akan mencoba menurunkan skala node Anda. Mungkin saja autoscaler cluster tidak menurunkan skala karena tidak perlu.

Autoscaler cluster menentukan apakah node kurang dimanfaatkan dan memenuhi syarat untuk penurunan skala dengan menghitung faktor pemanfaatan. Faktor pemakaian dihitung dengan membagi vCPU dan memori yang diminta oleh Pod di node dengan vCPU dan memori yang dapat dialokasikan di node.

Setiap 10 detik, autoscaler cluster memeriksa faktor pemakaian node Anda untuk melihat apakah faktor tersebut berada di bawah nilai minimum yang diperlukan. Jika Anda menggunakan balanced profil penskalaan otomatis, nilai minimum faktor pemakaian adalah 0,5. Jika Anda menggunakan profil optimize-utilization, faktor pemanfaatan akan bervariasi. Jika faktor pemakaian kurang dari nilai minimum yang diperlukan untuk vCPU dan memori, autoscaler cluster akan menganggap node kurang dimanfaatkan.

Jika pemanfaatan node kurang optimal, autoscaler cluster akan menandai node untuk dihapus dan memantau node selama 10 menit berikutnya untuk memastikan faktor pemanfaatan tetap berada di bawah nilai minimum yang diperlukan. Jika node masih kurang dimanfaatkan setelah 10 menit, autoscaler cluster akan menghapus node tersebut.

Contoh: Penghitungan faktor pemanfaatan

Anda memiliki cluster dengan autoscaler cluster yang diaktifkan dan Anda menggunakan profil penskalaan otomatis balanced. Node di cluster ini disediakan dengan jenis mesin e2-standard-4, yang menawarkan 4 vCPU dan memori 16 GB. Pod di node ini meminta 0,5 vCPU dan memori 10 GB, sehingga penskalaan otomatis cluster menghitung faktor pemanfaatan berikut:

• Faktor pemanfaatan vCPU: 0,5 vCPU / 4 vCPU = 0,125
• Faktor pemakaian memori: 10 GB / 16 GB = 0,625

Dalam skenario ini, autoscaler cluster tidak menganggap node ini kurang dimanfaatkan karena faktor pemanfaatan memori (0,625) melebihi nilai minimum 0,5. Meskipun pemakaian vCPU rendah, penggunaan memori yang lebih tinggi mencegah penurunan skala untuk memastikan resource yang memadai tetap tersedia untuk workload Pod.

Memeriksa apakah masalah disebabkan oleh batasan

Jika Anda mengamati cluster dengan pemanfaatan rendah selama lebih dari 10 menit dan cluster tersebut tidak diperkecil, pastikan masalah Anda tidak disebabkan oleh salah satu batasan untuk autoscaler cluster.

Lihat error

Jika masalah Anda tidak disebabkan oleh batasan, Anda sering kali dapat mendiagnosis penyebabnya 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 belum lebih dari 72 jam: Lihat notifikasi error di Google Cloud konsol.
  • Masalah yang sudah 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 Google Cloud . Notifikasi ini memberikan insight berharga tentang alasan penskala otomatis cluster tidak menurunkan skala dan menawarkan saran tentang cara menyelesaikan error dan melihat log yang relevan untuk penyelidikan lebih lanjut.

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

1. Di konsol Google Cloud , buka halaman Kubernetes clusters.

   Buka cluster Kubernetes

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

   • Can't scale down nodes
   • Scale down blocked by pod

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

4. Opsional: Untuk melihat log acara ini, klik Log. Tindakan ini akan mengarahkan Anda ke Logs Explorer dengan kueri yang sudah terisi otomatis untuk membantu Anda menyelidiki lebih lanjut peristiwa penskalaan. Untuk mempelajari lebih lanjut cara kerja peristiwa penurunan skala, lihat Melihat peristiwa penskalaan otomatis 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 suatu peristiwa.

Untuk melihat log penskalaan otomatis cluster di konsol Google Cloud , selesaikan langkah-langkah berikut:

1. Di konsol Google Cloud , buka halaman Kubernetes clusters.

   Buka cluster Kubernetes

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 penurunan skala, lihat Melihat peristiwa autoscaler cluster. Untuk satu contoh cara menggunakan Cloud Logging, lihat contoh pemecahan masalah berikut.

Contoh: Memecahkan masalah yang sudah lebih dari 72 jam

Contoh berikut menunjukkan cara menyelidiki dan menyelesaikan masalah dengan cluster yang tidak di-scaling down.

Skenario:

Seminggu yang lalu, Anda melihat dasbor GKE Enterprise dan menyadari bahwa cluster Anda hanya menggunakan 10% CPU dan memorinya. Meskipun pemakaiannya rendah, autoscaler cluster tidak menghapus node seperti yang Anda harapkan. Saat Anda melihat dasbor sekarang, masalah tampaknya telah diselesaikan, tetapi Anda memutuskan untuk mencari tahu apa yang terjadi agar Anda dapat menghindari masalah tersebut terjadi lagi.

Penyelidikan:

1. Karena masalah terjadi lebih dari 72 jam yang lalu, Anda menyelidiki masalah tersebut menggunakan Cloud Logging, bukan melihat pesan notifikasi.
2. Di Cloud Logging, Anda dapat menemukan detail logging untuk peristiwa autoscaler cluster, seperti yang dijelaskan dalam Melihat error dalam peristiwa.
3. Anda menelusuri peristiwa scaleDown yang berisi node milik cluster yang sedang Anda selidiki di kolom nodesToBeRemoved. Anda dapat memfilter entri log, termasuk memfilter berdasarkan nilai kolom JSON tertentu. Pelajari lebih lanjut di Kueri log lanjutan.
4. Anda tidak menemukan acara scaleDown. Namun, jika menemukan peristiwa scaleDown, Anda dapat menelusuri peristiwa eventResult yang berisi eventId terkait. Kemudian, Anda dapat menelusuri error di kolom errorMsg.

5. Anda memutuskan untuk melanjutkan penyelidikan dengan menelusuri peristiwa noScaleDown yang memiliki node yang sedang Anda selidiki di kolom node.

   Anda menemukan peristiwa noScaleDown yang berisi alasan node Anda tidak diturunkan skalanya. ID pesannya adalah "no.scale.down.node.pod.not.backed.by.controller" dan terdapat satu parameter: "test-single-pod".

Penyelesaian:

Anda melihat tabel pesan error, dan menemukan bahwa pesan ini berarti Pod memblokir penurunan skala karena tidak didukung oleh pengontrol. Anda mengetahui bahwa salah satu solusinya adalah menambahkan anotasi "cluster-autoscaler.kubernetes.io/safe-to-evict": "true" ke Pod. Anda menyelidiki test-single-pod dan melihat bahwa rekan kerja menambahkan anotasi dan setelah menerapkan anotasi, autoscaler cluster menurunkan skala cluster dengan benar. Anda memutuskan untuk menambahkan anotasi ke semua Pod lainnya yang aman untuk melakukannya agar masalah ini tidak terjadi lagi.

Mengatasi error penurunan skala

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

Error ScaleDown

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

Alasan peristiwa noScaleDown

Peristiwa noScaleDown akan dihasilkan secara berkala saat ada node yang diblokir agar tidak dihapus oleh autoscaler cluster. Peristiwa noScaleDown adalah upaya terbaik, dan tidak mencakup semua kasus yang memungkinkan.

Alasan tingkat atas NoScaleDown

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

Alasan tingkat node NoScaleDown

Pesan alasan tingkat node untuk peristiwa noScaleDown muncul di kolom noDecisionStatus.noScaleDown.nodes[].reason field. Pesan ini berisi alasan mengapa autoscaler cluster tidak dapat menghapus node 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 ingin menyelidiki pesan error lebih lanjut, Anda dapat melihat log yang khusus untuk error Anda:

1. Di konsol Google Cloud , 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.down.error.failed.to.delete.node.min.size.reached.

3. Klik Run query.

Men-debug beberapa error dengan gcpdiag

gcpdiag adalah alat open source yang dibuat dengan dukungan dari Google Cloud teknisi. Ini bukan produk yang didukung secara resmi Google Cloud .

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

• scale.down.error.failed.to.evict.pods
• no.scale.down.node.node.group.min.size.reached

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

Menyelesaikan error pengecilan skala yang kompleks

Bagian berikut menawarkan panduan tentang cara mengatasi error yang mitigasinya melibatkan beberapa langkah dan error yang tidak memiliki pesan peristiwa penskalaan otomatis cluster yang terkait dengannya.

Error: Node dalam cluster telah mencapai ukuran minimum

Jika Anda melihat error berikut, autoscaler cluster tidak dapat menghapus node karena jumlah node dalam cluster sudah mencapai ukuran minimum:

"scale.down.error.failed.to.delete.node.min.size.reached"

Untuk mengatasi masalah ini, tinjau dan perbarui batas minimum untuk penskalaan otomatis:

1. Di konsol Google Cloud , buka halaman Kubernetes clusters:

   Buka cluster Kubernetes

2. Klik nama cluster yang diidentifikasi dalam notifikasi atau Cloud Logging.

3. Di halaman Cluster details, buka tab Nodes.

4. Tinjau nilai di kolom Number of nodes dan bandingkan dengan jumlah minimum node yang tercantum di kolom Autoscaling. Misalnya, jika Anda melihat 4 - 6 node yang tercantum di kolom Penskalaan Otomatis, dan jumlah node dalam kumpulan node adalah 4, jumlah kumpulan node sudah sama dengan ukuran minimum, sehingga autoscaler cluster tidak dapat menurunkan skala node lebih lanjut.

5. Jika konfigurasi sudah benar dan nilai untuk jumlah node sama dengan minimum yang ditentukan untuk Penskalaan Otomatis, penskalaan otomatis cluster berfungsi sebagaimana mestinya. Jika jumlah minimum node terlalu tinggi untuk kebutuhan Anda, kurangi ukuran minimum agar node dapat diskalakan ke bawah.

Error: Tidak ada tempat untuk memindahkan Pod

Error berikut terjadi saat autoscaler cluster mencoba menurunkan skala node tetapi tidak dapat melakukannya, karena Pod di node tersebut tidak dapat dipindahkan ke node lain:

"no.scale.down.node.no.place.to.move.pods"

Jika Anda tidak ingin Pod ini dijadwalkan ulang, pesan ini sudah sesuai dan tidak ada perubahan yang diperlukan. Jika Anda ingin Pod dijadwalkan ulang, selidiki definisi berikut dalam pod.spec block di manifes Pod:

• NodeAffinity: Tinjau persyaratan penjadwalan Pod pada node yang kurang dimanfaatkan. Anda dapat meninjau persyaratan ini dengan memeriksa manifes Pod dan mencari aturan NodeAffinity atau NodeSelector. Jika Pod memiliki nodeSelector yang ditentukan dan tidak ada node lain (dari node pool lain) dalam cluster yang cocok dengan pemilih ini, autoscaler cluster tidak dapat memindahkan Pod ke node lain, yang pada gilirannya mencegahnya menghapus node yang kurang dimanfaatkan.
• maxPodConstraint: Jika maxPodConstraint dikonfigurasi ke angka lain selain angka default 110, konfirmasi apakah ini adalah perubahan yang diinginkan. Menurunkan nilai ini akan meningkatkan kemungkinan terjadinya masalah. Autoscaler cluster tidak dapat menjadwalkan ulang Pod ke node lain, jika semua node lain dalam cluster telah mencapai nilai yang ditentukan dalam maxPodConstraint, sehingga tidak ada ruang untuk menjadwalkan Pod baru. Meningkatkan nilai maxPodConstraint memungkinkan lebih banyak Pod dijadwalkan di node dan autoscaler cluster akan memiliki ruang untuk menjadwalkan ulang Pod dan menurunkan skala node yang kurang dimanfaatkan. Saat menentukan maxPodConstraint, perlu diingat bahwa ada sekitar 10 Pod sistem di setiap node.
• hostPort: Menentukan hostPort untuk Pod berarti hanya satu Pod yang dapat berjalan di node tersebut. Hal ini dapat menyulitkan autoscaler cluster untuk mengurangi jumlah node karena Pod mungkin tidak dapat dipindahkan ke node lain jika port node tersebut sudah digunakan. Ini adalah perilaku yang diharapkan.
• Penyimpanan Sementara: Pod mengandalkan penyimpanan sementara untuk data sementara. Penyimpanan sementara yang tidak memadai di node dapat menghambat penjadwalan Pod dan mencegah penurunan skala node yang kurang dimanfaatkan. Contoh: Pod yang memerlukan penyimpanan sementara 6 GB tidak dapat dijadwalkan di node dengan penyimpanan sementara gratis kurang dari 6 GB, meskipun memiliki resource CPU dan memori yang memadai. Untuk mengurangi batasan penyimpanan efemeral, tingkatkan kapasitas penyimpanan efemeral yang disediakan untuk node Anda. Hal ini memastikan kapasitas yang cukup untuk operasi penskalaan dan relokasi Pod.

Error: Pod kube-system tidak dapat dipindahkan

Error berikut terjadi saat Pod sistem mencegah penurunan skala:

"no.scale.down.node.pod.kube.system.unmovable"

Pod di namespace kube-system dianggap sebagai Pod sistem. Di GKE versi 1.32.4-gke.1236000 dan yang lebih baru, autoscaler cluster dapat menurunkan skala node dengan mengeluarkan Pod sistem yang telah berjalan setidaknya selama satu jam. Pada versi GKE sebelumnya, autoscaler cluster tidak menghapus Pod di namespace kube-system, yang dapat mencegah penurunan skala tanpa batas.

Untuk mengatasi error ini, pilih salah satu solusi berikut:

• Menambahkan PodDisruptionBudget untuk Pod kube-system. Untuk informasi selengkapnya tentang menambahkan PodDisruptionBudget secara manual untuk Pod kube-system, lihat FAQ tentang autoscaler cluster Kubernetes.

  Membuat PodDisruptionBudget dapat memengaruhi ketersediaan beban kerja sistem yang dapat menyebabkan periode nonaktif pada cluster. Autoscaler cluster menjadwalkan ulang workload sistem ini di node pekerja yang berbeda selama proses penurunan skala.

• Gunakan kombinasi taint dan toleransi node pool untuk memisahkan Pod kube-system dari Pod aplikasi Anda. Untuk informasi selengkapnya, lihat penyediaan otomatis node di GKE.

Memastikan node memiliki kube-system Pod

Jika Anda tidak yakin bahwa node Anda menjalankan Pod kube-system, dan ingin memverifikasinya, selesaikan langkah-langkah berikut:

1. Buka halaman Logs Explorer di konsol Google Cloud .

   Buka Logs Explorer

2. Klik Query builder.

3. Gunakan kueri berikut untuk menemukan semua data log kebijakan jaringan:

   - resource.labels.location="CLUSTER_LOCATION"
   resource.labels.cluster_name="CLUSTER_NAME"
   logName="projects/PROJECT_ID/logs/container.googleapis.com%2Fcluster-autoscaler-visibility"
   jsonPayload.noDecisionStatus.noScaleDown.nodes.node.mig.nodepool="NODE_POOL_NAME"
   

   Ganti kode berikut:

   • CLUSTER_LOCATION: Region tempat cluster Anda berada.
   • CLUSTER_NAME: Nama cluster Anda.
   • PROJECT_ID: ID project tempat cluster Anda berada.
   • NODE_POOL_NAME: Nama node pool Anda.

   Jika ada Pod kube-system yang berjalan di node pool Anda, output-nya akan mencakup hal berikut:

   "no.scale.down.node.pod.kube.system.unmovable"
   

Error: PodDisruptionBudget tidak mencukupi

Error berikut terjadi saat PodDisruptionBudget Anda mencegah penurunan skala:

NoScaleDownNodePodNotEnoughPdb: "no.scale.down.node.pod.not.enough.pdb"

Untuk melihat apakah PodDisruptionBudget terlalu ketat, tinjau setelannya:

kubectl get pdb --all-namespaces

Outputnya mirip dengan hal berikut ini:

NAMESPACE        NAME    MIN AVAILABLE   MAX UNAVAILABLE   ALLOWED DISRUPTIONS   AGE
example-app-one  one_pdb       N/A             1                 1               12d
example-app-two  two_pdb       N/A             0                 0               12d

Dalam contoh ini, Pod apa pun yang cocok dengan pemilih label two_pdb tidak akan dikeluarkan oleh autoscaler cluster. Setelan maxUnavailable: 0 dalam PodDisruptionBudget ini menyatakan bahwa semua replika harus tetap tersedia setiap saat. Selain itu, disruptionsAllowed: 0 melarang gangguan apa pun pada Pod ini. Akibatnya, node yang menjalankan Pod ini tidak dapat diturunkan skalanya, karena tindakan tersebut akan menyebabkan gangguan dan melanggar PodDisruptionBudget.

Jika PodDisruptionBudget berfungsi seperti yang Anda inginkan, Anda tidak perlu melakukan tindakan lebih lanjut. Jika Anda ingin menyesuaikan PodDisruptionBudget agar Pod pada node yang kurang dimanfaatkan dapat dipindahkan, edit manifes PodDisruptionBudget. Misalnya, jika Anda telah menyetel maxUnavailable ke 0, Anda dapat mengubahnya menjadi 1 sehingga cluster autoscaler dapat menurunkan skala.

Masalah: Node tetap dalam status terisolasi dan tidak dihapus

Error yang mirip dengan berikut terjadi saat autoscaler cluster tidak dapat mengurangi ukuran kumpulan node karena akun layanan Google tidak memiliki peran Editor:

Required 'compute.instanceGroups.update' permission for 'INSTANCE_GROUP_NAME'.

Gejala umum masalah ini adalah saat autoscaler cluster mencoba mengurangi ukuran kumpulan node, tetapi status node tidak berubah.

Untuk mengatasi masalah ini, periksa apakah akun layanan default (PROJECT_NUMBER@cloudservices.gserviceaccount.com) memiliki peran Editor (roles/editor) pada project. Jika akun layanan tidak memiliki peran ini, tambahkan. GKE menggunakan akun layanan ini untuk mengelola resource project Anda. Untuk mempelajari cara melakukannya, lihat bagian Memberikan atau mencabut satu peran dalam dokumentasi IAM.

Langkah berikutnya

• Tinjau pertanyaan berikut di FAQ tentang autoscaler cluster Kubernetes:

  • Bagaimana cara kerja penurunan skala?
  • Apakah autoscaler cluster dapat berfungsi dengan PodDisruptionBudget saat memperkecil skala?
  • Apa saja jenis Pod yang dapat mencegah autoscaler cluster menghapus node?

• Tonton video YouTube tentang cara memecahkan masalah dan menyelesaikan masalah penskalaan.

• 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 bug atau permintaan fitur menggunakan issue tracker publik.