Memecahkan masalah autoscaler cluster yang tidak menurunkan skala

Jika node Google Kubernetes Engine (GKE) Anda tidak di-scale down seperti yang diharapkan, hal ini sering kali disebabkan karena penskala otomatis cluster gagal menghapusnya, yang menyebabkan biaya yang tidak perlu dan penggunaan resource yang tidak efisien.

Gunakan halaman ini untuk mendiagnosis dan menyelesaikan masalah umum yang menghalangi tindakan penskalaan cluster autoscaler. Memecahkan masalah ini akan membantu memastikan bahwa cluster Anda beroperasi secara hemat biaya dan beradaptasi dengan perubahan workload.

Informasi ini penting bagi admin dan operator Platform yang bertanggung jawab atas efisiensi cluster, pengoptimalan biaya, dan pengelolaan resource. Developer aplikasi mungkin juga memerlukan informasi ini jika konfigurasi workload mereka (seperti PodDisruptionBudgets atau pemilih node) secara tidak sengaja mencegah node dihapus. Untuk mengetahui informasi selengkapnya tentang peran umum dan contoh tugas yang kami referensikan dalam Google Cloud konten, lihat Peran dan tugas pengguna GKE umum.

Memahami kapan autoscaler cluster menurunkan skala node Anda

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

Autoscaler cluster menentukan apakah node kurang dimanfaatkan dan memenuhi syarat untuk diperkecil skalanya 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 pemanfaatan 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 pemanfaatannya bervariasi. Jika faktor pemakaian kurang dari batas yang diperlukan untuk vCPU dan memori, autoscaler cluster akan menganggap node kurang dimanfaatkan.

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

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 akan menganggap node ini kurang dimanfaatkan karena faktor penggunaan memori (0,625) melebihi nilai minimum 0,5. Meskipun penggunaan vCPU rendah, penggunaan memori yang lebih tinggi mencegah penurunan skala untuk memastikan resource yang memadai tetap tersedia untuk workload Pod.

Periksa apakah masalah disebabkan oleh batasan

Jika Anda mengamati cluster dengan pemanfaatan rendah selama lebih dari 10 menit dan cluster 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:

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 memperkecil skala dan menawarkan saran tentang cara mengatasi 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 disarankan untuk mengatasinya.

  4. Opsional: Untuk melihat log peristiwa 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 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 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.

  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 perkecil 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:

Satu minggu yang lalu, Anda melihat dasbor GKE 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, masalahnya tampaknya telah diselesaikan, tetapi Anda memutuskan untuk mencari tahu apa yang terjadi agar dapat menghindari hal itu terjadi lagi.

Penyelidikan:

  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 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 peristiwa scaleDown. Namun, jika Anda 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 lain yang aman untuk melakukannya agar masalah tidak terjadi lagi.

Mengatasi error pengecilan 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 di peristiwa eventResult yang sesuai, di kolom resultInfo.results[].errorMsg.

Pesan peristiwa Detail Parameter Mitigasi
"scale.down.error.failed.to.mark.to.be.deleted" Node tidak dapat ditandai untuk dihapus. Nama node yang gagal. Pesan ini seharusnya bersifat sementara. Jika masalah berlanjut, hubungi Cloud Customer Care untuk penyelidikan lebih lanjut.
"scale.down.error.failed.to.evict.pods" Autoscaler cluster tidak dapat memperkecil skala karena beberapa pod tidak dapat dikeluarkan dari node. Nama node yang gagal. Tinjau PodDisruptionBudget untuk Pod dan pastikan aturan mengizinkan penghapusan replika aplikasi jika dapat diterima. Untuk mempelajari lebih lanjut, lihat Menentukan Anggaran Gangguan untuk Aplikasi Anda dalam dokumentasi Kubernetes.
"scale.down.error.failed.to.delete.node.min.size.reached" Autoscaler cluster tidak dapat memperkecil skala karena sebuah node tidak dapat dihapus karena ukuran cluster sudah minimal. Nama node yang gagal. Tinjau nilai minimum yang ditetapkan untuk penskalaan otomatis node pool, lalu sesuaikan setelan jika perlu. Untuk mempelajari lebih lanjut, lihat Error: Nodes in the cluster have reached minimum size.

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.

Pesan peristiwa Detail Mitigasi
"no.scale.down.in.backoff" Autoscaler cluster tidak dapat memperkecil skala karena perkecilan skala berada dalam periode backoff (diblokir sementara).

Pesan ini seharusnya bersifat sementara, dan dapat terjadi jika baru-baru ini ada peristiwa peningkatan skala.

Jika pesan berlanjut, hubungi Cloud Customer Care untuk penyelidikan lebih lanjut.
"no.scale.down.in.progress"

Cluster autoscaler tidak dapat menurunkan skala karena penurunan skala sebelumnya masih dalam proses.

 Pesan ini seharusnya bersifat sementara, karena Pod pada akhirnya akan dihapus. Jika pesan ini sering muncul, tinjau masa tenggang penghentian untuk Pod yang memblokir penurunan skala. Untuk mempercepat resolusi, Anda juga dapat menghapus Pod jika tidak diperlukan lagi.

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.

Pesan peristiwa Detail Parameter Mitigasi
"no.scale.down.node.scale.down.disabled.annotation" Autoscaler cluster tidak dapat menghapus node dari node pool karena node tersebut diberi anotasi dengan cluster-autoscaler.kubernetes.io/scale-down-disabled: true. T/A Autoscaler cluster melewati node dengan anotasi ini tanpa mempertimbangkan pemanfaatannya dan pesan ini dicatat terlepas dari faktor pemanfaatan node. Jika Anda ingin autoscaler cluster memperkecil skala node ini, hapus anotasi.
"no.scale.down.node.node.group.min.size.reached"

Autoscaler cluster tidak dapat memperkecil skala saat ukuran grup node telah melampaui batas ukuran minimum.

Hal ini terjadi karena penghapusan node akan melanggar batas resource minimum seluruh cluster yang ditentukan dalam setelan penyediaan otomatis node Anda.

 T/A Tinjau nilai minimum yang ditetapkan untuk penskalaan otomatis node pool. Jika Anda ingin autoscaler cluster memperkecil skala node ini, sesuaikan nilai minimum.
"no.scale.down.node.minimal.resource.limits.exceeded"

Cluster autoscaler tidak dapat memperkecil skala node karena akan melanggar batas resource minimal seluruh cluster.

Ini adalah batas resource yang ditetapkan untuk node auto-provisioning.

 T/A Tinjau batas memori dan vCPU Anda dan, jika Anda ingin autoscaler cluster memperkecil skala node ini, kurangi batasnya.
"no.scale.down.node.no.place.to.move.pods" Autoscaler cluster tidak dapat memperkecil skala karena tidak ada tempat untuk memindahkan Pod. T/A Jika Anda memperkirakan bahwa Pod harus dijadwalkan ulang, tinjau persyaratan penjadwalan Pod pada node yang kurang dimanfaatkan untuk menentukan apakah Pod dapat dipindahkan ke node lain dalam cluster. Untuk mempelajari lebih lanjut, lihat Error: Tidak ada tempat untuk memindahkan Pod.
"no.scale.down.node.pod.not.backed.by.controller"

Pod memblokir perkecil skala karena tidak didukung oleh pengontrol.

Secara khusus, autoscaler cluster tidak dapat memperkecil skala node yang kurang dimanfaatkan karena Pod yang tidak memiliki pengontrol yang dikenali. Pengontrol yang diizinkan mencakup ReplicationController, DaemonSet, Job, StatefulSet, atau ReplicaSet.

 Nama Pod yang memblokir. Tetapkan anotasi "cluster-autoscaler.kubernetes.io/safe-to-evict": "true" untuk Pod atau tentukan pengontrol yang dapat diterima.
"no.scale.down.node.pod.not.safe.to.evict.annotation" Pod di node memiliki anotasi safe-to-evict=false. Nama Pod yang memblokir. Jika Pod dapat dikeluarkan dengan aman, edit manifes Pod dan update anotasi ke "cluster-autoscaler.kubernetes.io/safe-to-evict": "true".
"no.scale.down.node.pod.kube.system.unmovable" Pod memblokir perkecil skala karena merupakan Pod non-DaemonSet, tidak dicerminkan, tanpa PodDisruptionBudget dalam namespace kube-system. Nama Pod yang memblokir.

Pada versi GKE yang lebih lama dari 1.32.4-gke.1236000, autoscaler cluster tidak menghapus Pod di namespace kube-system. Mulai dari versi 1.32.4-gke.1236000, autoscaler cluster mempertimbangkan penghapusan Pod ini setelah dibuat selama satu jam.

Untuk mengatasi masalah ini, tambahkan PodDisruptionBudget untuk Pod kube-system atau gunakan kombinasi taint dan toleransi node pool untuk memisahkan Pod kube-system dari Pod aplikasi Anda. Untuk mempelajari lebih lanjut, lihat Error: Pod kube-system tidak dapat dipindahkan.
"no.scale.down.node.pod.not.enough.pdb" Pod memblokir perkecil skala karena tidak memiliki PodDisruptionBudget yang cukup. Nama Pod yang memblokir. Tinjau PodDisruptionBudget untuk Pod dan pertimbangkan untuk membuatnya kurang ketat. Untuk mempelajari lebih lanjut, lihat Error: PodDisruptionBudget tidak mencukupi.
"no.scale.down.node.pod.controller.not.found" Pod memblokir perkecil skala karena pengontrolnya (misalnya, Deployment atau ReplicaSet) tidak dapat ditemukan. T/A Untuk mengetahui tindakan yang diambil yang membuat Pod berjalan setelah pengontrolnya dihapus, tinjau log. Untuk menyelesaikan masalah ini, hapus Pod secara manual.
"no.scale.down.node.pod.unexpected.error" Pod memblokir perkecil skala karena terjadi error yang tidak terduga. T/A Penyebab utama error ini tidak diketahui. Hubungi Cloud Customer Care untuk penyelidikan lebih lanjut.

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 lebih lanjut pesan error, Anda dapat melihat log khusus untuk error tersebut:

  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 engineer teknis Google Cloud. Produk ini bukan produk Google Cloud yang didukung secara resmi.

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 memberikan panduan tentang cara menyelesaikan error yang mitigasinya melibatkan beberapa langkah dan error yang tidak memiliki pesan peristiwa autoscaler cluster yang terkait dengannya.

Error: Node di 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:

Notifikasi

Perkecil skala node yang kurang dimanfaatkan akan diblokir karena batas resource minimum autoscaler cluster telah tercapai.

Acara

"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 di node pool adalah 4, jumlah node pool sudah sama dengan ukuran minimum, sehingga autoscaler cluster tidak dapat memperkecil skala node lebih lanjut.

  5. Jika konfigurasi sudah benar dan nilai untuk jumlah node sama dengan nilai minimum yang ditentukan untuk Autoscaling, berarti autoscaler cluster berfungsi sebagaimana mestinya. Jika jumlah minimum node terlalu tinggi untuk kebutuhan Anda, kurangi ukuran minimum agar node dapat diperkecil skalanya.

Error: Tidak ada tempat untuk memindahkan Pod

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

Notifikasi

Perkecil skala node yang kurang dimanfaatkan akan diblokir karena memiliki Pod yang tidak dapat dipindahkan ke node lain di cluster.

Acara

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

Jika Anda tidak ingin Pod ini dijadwalkan ulang, pesan ini diharapkan dan tidak ada perubahan yang diperlukan. Jika Anda ingin Pod dijadwalkan ulang, selidiki definisi berikut di pod.spec block dalam 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 merupakan perubahan yang disengaja. 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 memperkecil 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 kosong 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 perkecil skala:

Notifikasi

Pod memblokir perkecil skala karena merupakan Pod non-DaemonSet, tidak dicerminkan, tanpa PodDisruptionBudget di namespace kube-system.

Acara

"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 memperkecil 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 perkecil skala tanpa batas.

Untuk mengatasi error ini, pilih salah satu solusi berikut:

  • Menambahkan PodDisruptionBudget untuk Pod kube-system. Untuk mengetahui 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 worker node yang berbeda selama proses perkecil skala.

  • Gunakan taint dan toleransi node pool (misalnya, workload=stateful:NoSchedule) untuk memisahkan Pod kube-system dari Pod aplikasi Anda. Kami merekomendasikan pendekatan ini untuk beban kerja batch atau stateful guna mencegah masalah penundaan bertingkat dengan menonaktifkan Pod kube-system dari node tersebut. Pendekatan ini memungkinkan node diperkecil skalanya tanpa diblokir. Untuk informasi selengkapnya, lihat node auto-provisioning di GKE.

Memastikan node memiliki Pod kube-system

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 cukup

Error berikut terjadi saat PodDisruptionBudget Anda mencegah penskalaan ke bawah:

Notifikasi

Perkecil skala node yang kurang dimanfaatkan akan diblokir karena memiliki Pod yang berjalan di dalamnya yang tidak memiliki anggaran gangguan pod yang cukup untuk memungkinkan pengeluaran Pod.

Acara

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

Untuk melihat apakah PodDisruptionBudget terlalu membatasi, 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 di 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 diperkecil skalanya, karena hal itu akan menyebabkan gangguan dan melanggar PodDisruptionBudget.

Jika PodDisruptionBudget Anda 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 menetapkan maxUnavailable ke 0, Anda dapat mengubahnya menjadi 1 agar autoscaler cluster dapat memperkecil skala.

Masalah: Node tetap dalam status terisolasi dan tidak dihapus

Error yang mirip dengan berikut terjadi saat autoscaler cluster tidak dapat mengurangi ukuran node pool 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 node pool, 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