Memecahkan masalah node dengan status NotReady di GKE

Status NotReady di Google Kubernetes Engine (GKE) berarti kubelet node tidak melaporkan ke bidang kontrol dengan benar. Karena Kubernetes tidak akan menjadwalkan Pod baru di node NotReady, masalah ini dapat mengurangi kapasitas aplikasi dan menyebabkan waktu non-operasional.

Gunakan dokumen ini untuk membedakan antara status NotReady yang diharapkan dan masalah sebenarnya, mendiagnosis penyebab utama, dan menemukan solusi untuk masalah umum seperti kehabisan resource, masalah jaringan, dan kegagalan runtime container.

Informasi ini ditujukan bagi admin dan operator Platform yang bertanggung jawab atas stabilitas cluster dan Developer aplikasi yang ingin memahami perilaku aplikasi terkait infrastruktur. Untuk mengetahui informasi selengkapnya tentang peran umum dan contoh tugas yang kami referensikan dalam konten, lihat Peran dan tugas pengguna GKE umum. Google Cloud

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 Anda: Google Cloud

    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.

  • Konfigurasi alat command line kubectl untuk berkomunikasi dengan cluster GKE Anda:

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

    Ganti kode berikut:

    • CLUSTER_NAME: nama cluster Anda.
    • LOCATION: region atau zona Compute Engine (misalnya, us-central1 atau us-central1-a) untuk cluster.
    • PROJECT_ID: Google Cloud Project ID Anda.

Periksa status dan kondisi node

Untuk mengonfirmasi bahwa node memiliki status NotReady dan membantu Anda mendiagnosis penyebab masalah, gunakan langkah-langkah berikut untuk memeriksa kondisi, peristiwa, log, dan metrik resource node:

  1. Melihat status node Anda. Untuk mendapatkan detail tambahan seperti alamat IP dan versi kernel, yang berguna untuk diagnosis, gunakan flag -o wide:

    kubectl get nodes -o wide

    Outputnya mirip dengan hal berikut ini:

    NAME                                STATUS     ROLES    AGE   VERSION               INTERNAL-IP  EXTERNAL-IP  OS-IMAGE                             KERNEL-VERSION   CONTAINER-RUNTIME
gke-cluster-pool-1-node-abc1        Ready      <none>   94d   v1.32.3-gke.1785003   10.128.0.1   1.2.3.4      Container-Optimized OS from Google   6.6.72+          containerd://1.7.24
gke-cluster-pool-1-node-def2        Ready      <none>   94d   v1.32.3-gke.1785003   10.128.0.2   5.6.7.8      Container-Optimized OS from Google   6.6.72+          containerd://1.7.24
gke-cluster-pool-1-node-ghi3        NotReady   <none>   94d   v1.32.3-gke.1785003   10.128.0.3   9.10.11.12   Container-Optimized OS from Google   6.6.72+          containerd://1.7.24

    Di output, cari node dengan nilai NotReady di kolom STATUS dan catat namanya.

  2. Lihat informasi selengkapnya tentang node tertentu dengan status NotReady, termasuk kondisi dan peristiwa Kubernetes terbaru:

    kubectl describe node NODE_NAME

    Ganti NODE_NAME dengan nama node yang memiliki status NotReady.

    Pada output, fokus pada bagian Conditions untuk memahami kondisi node dan bagian Events untuk melihat histori masalah terbaru. Contoh:

    Name:                   gke-cluster-pool-1-node-ghi3
...
Conditions:
Type                          Status    LastHeartbeatTime                 LastTransitionTime                Reason                   Message
----                          ------    -----------------                 ------------------                ------                   -------
NetworkUnavailable            False     Wed, 01 Oct 2025 10:29:19 +0100   Wed, 01 Oct 2025 10:29:19 +0100   RouteCreated             RouteController created a route
MemoryPressure                Unknown   Wed, 01 Oct 2025 10:31:06 +0100   Wed, 01 Oct 2025 10:31:51 +0100   NodeStatusUnknown        Kubelet stopped posting node status.
DiskPressure                  Unknown   Wed, 01 Oct 2025 10:31:06 +0100   Wed, 01 Oct 2025 10:31:51 +0100   NodeStatusUnknown        Kubelet stopped posting node status.
PIDPressure                   False     Wed, 01 Oct 2025 10:31:06 +0100   Wed, 01 Oct 2025 10:29:00 +0100   KubeletHasSufficientPID  kubelet has sufficient PID available
Ready                         Unknown   Wed, 01 Oct 2025 10:31:06 +0100   Wed, 01 Oct 2025 10:31:51 +0100   NodeStatusUnknown        Kubelet stopped posting node status.
Events:
Type     Reason                   Age                  From                                   Message
----     ------                   ----                 ----                                   -------
Normal   Starting                 32m                  kubelet, gke-cluster-pool-1-node-ghi3  Starting kubelet.
Warning  PLEGIsNotHealthy         5m1s (x15 over 29m)  kubelet, gke-cluster-pool-1-node-ghi3  PLEG is not healthy: pleg was last seen active 5m1.123456789s ago; threshold is 3m0s
Normal   NodeHasSufficientMemory  5m1s (x16 over 31m)  kubelet, gke-cluster-pool-1-node-ghi3  Node gke-cluster-pool-1-node-ghi3 status is now: NodeHasSufficientMemory

    Di bagian Conditions, status True untuk kondisi negatif, atau Unknown untuk kondisi Ready, menunjukkan adanya masalah. Perhatikan baik-baik kolom Reason dan Message untuk kondisi ini, karena kolom tersebut menjelaskan penyebab masalah.

    Berikut arti setiap jenis kondisi:

    • KernelDeadlock: True jika kernel sistem operasi node telah mendeteksi kebuntuan, yang merupakan error serius yang dapat membekukan node.
    • FrequentUnregisterNetDevice: True jika node sering membatalkan pendaftaran perangkat jaringannya, yang dapat menjadi tanda masalah driver atau hardware.
    • NetworkUnavailable: True jika jaringan untuk node tidak dikonfigurasi dengan benar.
    • OutOfDisk: True jika ruang disk yang tersedia benar-benar habis. Kondisi ini lebih parah daripada DiskPressure.
    • MemoryPressure: True jika memori node rendah.
    • DiskPressure: True jika ruang disk di node rendah.
    • PIDPressure: True jika node mengalami kehabisan ID proses (PID).
    • Ready: menunjukkan apakah node dalam kondisi baik dan siap menerima Pod.
      • True jika node berfungsi dengan baik.
      • False jika node bermasalah dan tidak menerima Pod.
      • Unknown jika pengontrol node belum menerima respons dari node selama masa tenggang (defaultnya adalah 50 detik) dan status node tidak diketahui.

    Selanjutnya, periksa bagian Events, yang memberikan log kronologis tindakan dan pengamatan tentang node. Linimasa ini sangat penting untuk memahami apa yang terjadi tepat sebelum node menjadi NotReady. Cari pesan tertentu yang dapat membantu menemukan penyebabnya, seperti peringatan pengusiran (yang menandakan tekanan sumber daya), pemeriksaan kondisi yang gagal, atau peristiwa siklus proses node seperti mengisolasi untuk perbaikan.

  3. Untuk mempelajari lebih lanjut alasan node memiliki status NotReady, lihat log dari node dan komponennya.

    1. Periksa log kubelet untuk mengetahui status NotReady.

      kubelet adalah agen utama yang melaporkan status node ke bidang kontrol, sehingga log-nya adalah tempat yang paling mungkin untuk menemukan pesan NotReady literal. Log ini adalah sumber tepercaya untuk mendiagnosis masalah terkait peristiwa siklus proses Pod, kondisi tekanan resource (seperti MemoryPressure atau DiskPressure), dan konektivitas node ke bidang kontrol Kubernetes.

    2. Di konsol Google Cloud , buka halaman Logs Explorer:

      Buka Logs Explorer

    3. Di panel kueri, masukkan kueri berikut:

      resource.type="k8s_node"
resource.labels.node_name="NODE_NAME"
resource.labels.cluster_name="CLUSTER_NAME"
resource.labels.location="LOCATION"
log_id("kubelet")
textPayload=~"(?i)NotReady"

      Ganti kode berikut:

      • NODE_NAME: nama node yang Anda selidiki.
      • CLUSTER_NAME: nama cluster Anda.
      • LOCATION: region atau zona Compute Engine (misalnya, us-central1 atau us-central1-a) untuk cluster.

    4. Klik Jalankan kueri dan tinjau hasilnya.

    5. Jika log kubelet tidak mengungkapkan penyebab utama, periksa log container-runtime dan node-problem-detector. Komponen ini mungkin tidak mencatat status NotReady secara langsung, tetapi sering kali mencatat masalah yang mendasarinya (seperti kegagalan runtime atau kernel panic) yang menyebabkan masalah tersebut.

    6. Di panel kueri Logs Explorer, masukkan kueri berikut:

      resource.type="k8s_node"
resource.labels.node_name="NODE_NAME"
resource.labels.cluster_name="CLUSTER_NAME"
resource.labels.location="LOCATION"
log_id("COMPONENT_NAME")

      Ganti COMPONENT_NAME dengan salah satu nilai berikut:

      • container-runtime: runtime (containerd), yang bertanggung jawab atas siklus proses container lengkap, termasuk menarik image dan mengelola eksekusi container. Meninjau log container-runtime sangat penting untuk memecahkan masalah kegagalan terkait instansiasi container, error layanan runtime, atau masalah yang disebabkan oleh konfigurasi runtime.
      • node-problem-detector: utilitas yang secara proaktif memantau dan melaporkan berbagai masalah tingkat node ke bidang kontrol. Log-nya sangat penting untuk mengidentifikasi masalah sistem mendasar yang dapat menyebabkan ketidakstabilan node, seperti kebuntuan kernel, kerusakan sistem file, atau kegagalan hardware, yang mungkin tidak tercatat oleh komponen Kubernetes lainnya.

    7. Klik Jalankan kueri dan tinjau hasilnya.

  4. Gunakan Metrics Explorer untuk mencari kelelahan resource di sekitar waktu saat node menjadi NotReady:

    1. Di konsol Google Cloud , buka halaman Metrics Explorer:

      Buka Metrics Explorer

    2. Di Metrics Explorer, periksa apakah instance Compute Engine yang mendasari node mengalami kehabisan resource. Fokus pada metrik yang terkait dengan metrik CPU, memori, dan I/O disk. Contoh:

      • Metrik node GKE: mulai dengan metrik yang diawali dengan kubernetes.io/node/, seperti kubernetes.io/node/cpu/allocatable_utilization atau kubernetes.io/node/memory/allocatable_utilization. Metrik ini menunjukkan jumlah resource yang tersedia di node yang digunakan oleh Pod Anda. Jumlah yang tersedia tidak mencakup resource yang dicadangkan Kubernetes untuk overhead sistem.
      • Metrik OS tamu: untuk tampilan dari dalam sistem operasi node, gunakan metrik yang diawali dengan compute.googleapis.com/guest/, seperti compute.googleapis.com/guest/cpu/usage atau compute.googleapis.com/guest/memory/bytes_used.
      • Metrik hypervisor: untuk melihat performa VM dari tingkat hypervisor, gunakan metrik yang diawali dengan compute.googleapis.com/instance/, seperti compute.googleapis.com/instance/cpu/utilization atau metrik I/O disk seperti compute.googleapis.com/instance/disk/read_bytes_count.

      Metrik OS tamu dan hypervisor mengharuskan Anda memfilter menurut nama instance Compute Engine yang mendasarinya, bukan nama node Kubernetes. Anda dapat menemukan nama instance untuk node dengan menjalankan perintah kubectl describe node NODE_NAME dan mencari kolom ProviderID dalam output. Nama instance adalah bagian terakhir dari nilai tersebut. Contoh:

      ...
Spec:
ProviderID: gce://my-gcp-project-123/us-central1-a/gke-my-cluster-default-pool-1234abcd-5678
...

      Dalam contoh ini, nama instance-nya adalah gke-my-cluster-default-pool-1234abcd-5678.

Mengidentifikasi penyebab berdasarkan gejala

Jika Anda telah mengidentifikasi gejala tertentu, seperti pesan log, kondisi node, atau peristiwa cluster, gunakan tabel berikut untuk menemukan saran pemecahan masalah:

Kategori Gejala atau pesan log Kemungkinan penyebab Langkah-langkah pemecahan masalah
Kondisi node NetworkUnavailable: True Masalah konektivitas node-ke-control-plane atau kegagalan plugin Container Network Interface (CNI). Memecahkan masalah konektivitas jaringan
MemoryPressure: True Node tidak memiliki memori yang cukup. Memecahkan masalah kekurangan resource node
DiskPressure: True Node tidak memiliki ruang disk yang cukup. Memecahkan masalah kekurangan resource node
PIDPressure: True Node tidak memiliki ID Proses yang tersedia dalam jumlah yang cukup. Memecahkan masalah kekurangan resource node
Peristiwa dan pesan log PLEG is not healthy Kubelet kelebihan beban karena CPU/IO tinggi atau terlalu banyak Pod. Menyelesaikan masalah PLEG
Out of memory: Kill process
sys oom event		 Memori node benar-benar habis. Menyelesaikan peristiwa OOM tingkat sistem
leases.coordination.k8s.io...is forbidden Namespace kube-node-lease terjebak saat dihentikan. Menyelesaikan masalah pada namespace kube-node-lease
Container runtime not ready
runtime is down
Error yang merujuk /run/containerd/containerd.sock atau docker.sock		 Layanan Containerd atau Docker gagal atau salah dikonfigurasi. Menyelesaikan masalah runtime container
Pod macet di Terminating
Log Kubelet menunjukkan DeadlineExceeded untuk menghentikan container
Log containerd menunjukkan pesan Kill container berulang		 Proses yang macet dalam mode tidur disk yang tidak dapat diinterupsi (status D), sering kali terkait dengan I/O. Mengatasi proses yang macet dalam status D
Gejala tingkat cluster Beberapa node gagal setelah peluncuran DaemonSet. DaemonSet mengganggu operasi node. Menyelesaikan masalah yang disebabkan oleh DaemonSet pihak ketiga
compute.instances.preempted di log audit. Spot VM di-preempt, yang merupakan perilaku yang diharapkan. Mengonfirmasi penghentian sementara node
Pod kube-system macet di Pending. Webhook penerimaan memblokir komponen penting. Menyelesaikan masalah yang disebabkan oleh webhook penerimaan
exceeded quota: gcp-critical-pods Kuota yang salah dikonfigurasi akan memblokir Pod sistem. Menyelesaikan masalah yang disebabkan oleh kuota resource

Memeriksa peristiwa NotReady yang diharapkan

Status NotReady tidak selalu menandakan adanya masalah. Hal ini dapat menjadi perilaku yang diharapkan selama operasi yang direncanakan seperti upgrade node pool, atau jika Anda menggunakan jenis virtual machine tertentu.

Mengonfirmasi operasi siklus proses node

Gejala:

Node sementara menampilkan status NotReady selama peristiwa siklus proses tertentu.

Penyebab:

Status node akan menjadi NotReady untuk sementara selama beberapa peristiwa siklus proses umum. Perilaku ini diharapkan terjadi setiap kali node dibuat atau dibuat ulang, seperti dalam skenario berikut:

  • Upgrade node pool: selama upgrade, setiap node akan dikuras dan diganti. Node baru yang diupgrade memiliki status NotReady hingga selesai diinisialisasi dan bergabung dengan cluster.
  • Perbaikan otomatis node: saat GKE mengganti node yang tidak berfungsi, node pengganti tetap NotReady selama disediakan.
  • Peningkatan skala autoscaler cluster: saat node baru ditambahkan, node tersebut dimulai dalam status NotReady dan menjadi Ready hanya setelah disediakan sepenuhnya dan bergabung dengan cluster.
  • Perubahan template instance manual: GKE membuat ulang node saat Anda menerapkan perubahan template. Node baru memiliki status NotReady selama fase startup-nya.

Resolusi:

Node hanya akan memiliki status NotReady dalam waktu singkat. Jika status tetap seperti itu selama lebih dari 10 menit, selidiki penyebab lainnya.

Konfirmasi penghentian sementara node

Jika node Anda berjalan di Spot VM atau Preemptible VM, Compute Engine dapat menghentikannya secara tiba-tiba untuk mengklaim kembali resource. Hal ini adalah perilaku yang diharapkan untuk jenis virtual machine yang berumur pendek ini dan bukan merupakan error.

Gejala:

Jika Anda mengamati gejala berikut, status NotReady node kemungkinan disebabkan oleh preemption Spot VM yang diharapkan:

  • Node tiba-tiba memasuki status NotReady sebelum dihapus dan dibuat ulang oleh autoscaler cluster.
  • Cloud Audit Logs menampilkan peristiwa compute.instances.preempted untuk instance VM yang mendasarinya.

Penyebab:

Node berjalan di instance Spot VM atau Preemptible VM dan Compute Engine mengklaim kembali resource komputasi tersebut untuk tugas lain. Spot VM dapat terganggu kapan saja, meskipun biasanya memberikan pemberitahuan penghentian 30 detik.

Resolusi:

Gunakan Spot VM atau Preemptible VM hanya untuk workload fault-tolerant, stateless, atau batch yang didesain untuk menangani penghentian yang sering dengan baik. Untuk workload produksi atau stateful yang tidak dapat mentoleransi gangguan mendadak, sediakan node pool Anda menggunakan VM on-demand standar.

Memecahkan masalah kekurangan resource node

Node sering kali menjadi NotReady karena tidak memiliki resource penting seperti CPU, memori, atau ruang disk. Jika tidak memiliki cukup resource ini, komponen penting tidak dapat berfungsi dengan benar, sehingga menyebabkan ketidakstabilan aplikasi dan node tidak responsif. Bagian berikut membahas berbagai cara munculnya kekurangan ini, mulai dari kondisi tekanan umum hingga peristiwa yang lebih parah di seluruh sistem.

Mengatasi tekanan resource node

Kelelahan resource terjadi saat node tidak memiliki CPU, memori, ruang disk, atau ID proses (PID) yang cukup untuk menjalankan workload-nya. Masalah ini dapat menyebabkan status NotReady.

Gejala:

Jika Anda mengamati kondisi dan log node berikut, kehabisan resource adalah kemungkinan penyebab status NotReady node:

  • Dalam output perintah kubectl describe node, Anda akan melihat status True untuk kondisi seperti OutOfDisk, MemoryPressure, DiskPressure, atau PIDPressure.
  • Log kubelet mungkin berisi peristiwa Out of Memory (OOM), yang menunjukkan bahwa OOM Killer sistem dipanggil.

Penyebab:

Workload pada node secara kolektif meminta lebih banyak resource daripada yang dapat disediakan oleh node.

Resolusi:

Untuk cluster Standard, coba solusi berikut:

  • Mengurangi permintaan beban kerja:
    • Kurangi jumlah Pod yang berjalan di node yang terpengaruh dengan menurunkan skala jumlah replika deployment Anda. Untuk mengetahui informasi selengkapnya, lihat Menskalakan aplikasi.
    • Tinjau dan optimalkan aplikasi Anda agar menggunakan lebih sedikit resource.
  • Meningkatkan kapasitas node:

Untuk cluster Autopilot, Anda tidak secara langsung mengontrol jenis mesin node atau ukuran disk booting. Kapasitas node dikelola secara otomatis berdasarkan permintaan Pod Anda. Pastikan permintaan resource workload Anda berada dalam batas Autopilot dan mencerminkan kebutuhan aplikasi Anda secara akurat. Masalah resource persisten mungkin menunjukkan perlunya mengoptimalkan permintaan Pod atau, dalam kasus yang jarang terjadi, masalah platform yang memerlukan bantuan dari Cloud Customer Care.

Menyelesaikan peristiwa OOM tingkat sistem

Peristiwa Out of Memory (OOM) tingkat sistem terjadi saat total memori node habis, sehingga memaksa kernel Linux menghentikan proses untuk mengosongkan resource. Peristiwa ini berbeda dengan peristiwa OOM tingkat penampung, di mana satu Pod melampaui batas memorinya.

Gejala:

Jika Anda melihat gejala berikut, peristiwa OOM tingkat sistem kemungkinan menjadi penyebab ketidakstabilan node:

  • Anda melihat pesan Out of memory: Kill process di log konsol serial node.
  • Log kubelet berisi peristiwa oom_watcher, yang menunjukkan bahwa kubelet telah mendeteksi peristiwa OOM tingkat sistem.
  • Penghentian proses yang tidak terduga, termasuk daemon sistem atau Pod workload yang berpotensi penting, tidak selalu merupakan konsumen memori tertinggi.

Penyebab:

Memori keseluruhan node habis. Masalah ini dapat disebabkan oleh bug di layanan sistem, workload yang salah dikonfigurasi yang menggunakan memori dalam jumlah berlebihan, atau node yang terlalu kecil untuk permintaan memori kolektif dari semua Pod yang berjalan di dalamnya.

Resolusi:

Untuk mengatasi peristiwa OOM tingkat sistem, diagnosis penyebabnya, lalu kurangi permintaan memori atau tingkatkan kapasitas node. Untuk mengetahui informasi selengkapnya, lihat Memecahkan masalah peristiwa OOM.

Menyelesaikan masalah PLEG

Generator peristiwa siklus proses Pod (PLEG) adalah komponen dalam kubelet. Secara berkala, kubelet memeriksa status semua container di node dan melaporkan perubahan apa pun kembali ke kubelet.

Jika mengalami masalah performa, PLEG tidak dapat memberikan update tepat waktu ke kubelet, yang dapat menyebabkan node menjadi tidak stabil.

Gejala:

Jika Anda mengamati gejala berikut, PLEG mungkin tidak berfungsi dengan benar:

  • Log kubelet untuk node berisi pesan yang mirip dengan PLEG is not healthy.
  • Status node sering berubah antara Ready dan NotReady.

Penyebab:

Masalah PLEG biasanya disebabkan oleh masalah performa yang mencegah kubelet menerima update tepat waktu dari runtime penampung. Penyebab umum meliputi hal-hal berikut:

  • Beban CPU tinggi: CPU node penuh, sehingga kubelet dan runtime container tidak memiliki daya pemrosesan yang dibutuhkan.
  • Pembatasan I/O: disk booting node mengalami operasi I/O yang berat, yang dapat memperlambat semua tugas terkait disk.
  • Pod Berlebihan: terlalu banyak Pod pada satu node dapat membebani kubelet dan runtime container, sehingga menyebabkan perebutan resource.

Resolusi:

Untuk cluster Standard, kurangi tekanan pada resource node:

Untuk cluster Autopilot, meskipun Anda tidak dapat mengubah ukuran atau jenis disk node yang ada secara langsung, Anda dapat memengaruhi hardware tempat workload Anda berjalan dengan menggunakan ComputeClass kustom. Fitur ini memungkinkan Anda menentukan persyaratan dalam manifes workload, seperti jumlah CPU dan memori minimum atau seri mesin tertentu, untuk memandu tempat Pod Anda dijadwalkan.

Jika Anda tidak menggunakan ComputeClass, sesuaikan deployment workload (seperti jumlah replika dan permintaan atau batas resource) dan pastikan deployment tersebut berada dalam batasan Autopilot. Jika masalah PLEG berlanjut setelah mengoptimalkan beban kerja, hubungi Cloud Customer Care.

Menyelesaikan proses yang macet dalam status D

Proses yang macet dalam mode tidur disk yang tidak dapat diinterupsi (status D) dapat membuat node tidak responsif. Masalah ini mencegah Pod dihentikan dan dapat menyebabkan komponen kritis seperti containerd gagal, sehingga menghasilkan status NotReady.

Gejala:

  • Pod, terutama yang menggunakan penyimpanan jaringan seperti NFS, akan mengalami masalah pada status Terminating dalam waktu yang lama.
  • Log Kubelet menampilkan error DeadlineExceeded saat mencoba menghentikan penampung.
  • Log konsol serial node mungkin menampilkan pesan kernel tentang hung tasks atau tugas yang diblokir selama lebih dari 120 detik.

Penyebab:

Proses memasuki status D saat menunggu operasi I/O selesai dan tidak dapat diinterupsi. Penyebab umumnya meliputi:

  • Sistem file jarak jauh yang lambat atau tidak responsif, seperti berbagi NFS yang salah dikonfigurasi atau kelebihan beban.
  • Penurunan performa disk yang parah atau error I/O hardware pada disk lokal node.

Resolusi:

Untuk mengatasi masalah pada proses status D, identifikasi sumber I/O, lalu hapus status dengan memilih salah satu opsi berikut:

Cluster standar

  1. Temukan proses yang macet dan tentukan apa yang ditunggunya:

    1. Hubungkan ke node yang terpengaruh menggunakan SSH:

      gcloud compute ssh NODE_NAME \
    --zone ZONE \
    --project PROJECT_ID

      Ganti kode berikut:

      • NODE_NAME: nama node yang akan dihubungkan.
      • ZONE: zona Compute Engine node.
      • PROJECT_ID: Project ID Anda.

    2. Menemukan proses apa pun dalam status D:

      ps -eo state,pid,comm,wchan | grep '^D'

      Outputnya mirip dengan hal berikut ini:

      D  12345  my-app      nfs_wait
D  54321  data-writer io_schedule

      Output tidak akan memiliki header. Kolom, secara berurutan, mewakili:

      • Negara bagian/Provinsi
      • ID Proses (PID)
      • Perintah
      • Channel tunggu (wchan)

    3. Periksa kolom wchan untuk mengidentifikasi sumber I/O:

      • Jika kolom wchan mencakup istilah seperti nfs atau rpc, proses sedang menunggu berbagi NFS.
      • Jika kolom wchan menyertakan istilah seperti io_schedule, jbd2, atau ext4, proses menunggu disk boot lokal node.

    4. Untuk mengetahui detail selengkapnya tentang fungsi kernel yang ditunggu proses, periksa stack panggilan kernel proses:

      cat /proc/PID/stack

      Ganti PID dengan ID proses yang Anda temukan di langkah sebelumnya.

  2. Mulai ulang node. Mulai ulang sering kali menjadi cara paling efektif untuk menghapus proses yang macet dalam status D.

    1. Pindahkan node.
    2. Hapus instance VM pokok. GKE biasanya membuat VM baru untuk menggantikannya.

  3. Setelah masalah langsung teratasi, selidiki sistem penyimpanan yang mendasarinya untuk mencegah terulang kembali.

    • Untuk masalah penyimpanan jaringan (NFS): gunakan alat pemantauan penyedia penyimpanan Anda untuk memeriksa latensi tinggi, error sisi server, atau masalah jaringan antara node GKE dan server NFS.

    • Untuk masalah disk lokal: periksa pembatasan I/O di Cloud Monitoring dengan melihat metrik compute.googleapis.com/instance/disk/throttled_read_ops_count dan compute.googleapis.com/instance/disk/throttled_write_ops_count untuk instance Compute Engine.

Cluster Autopilot

  1. Coba identifikasi sumber penyumbatan:

    Akses SSH langsung ke node dan menjalankan perintah seperti ps atau cat /proc tidak tersedia di cluster Autopilot. Anda harus mengandalkan log dan metrik.

    1. Periksa log node: di Cloud Logging, analisis log dari node yang terpengaruh. Filter menurut nama node dan jangka waktu masalah. Cari pesan kernel yang menunjukkan error I/O, waktu tunggu penyimpanan (misalnya, ke disk atau NFS), atau pesan dari driver CSI.
    2. Periksa log workload: periksa log Pod yang berjalan di node yang terpengaruh. Log aplikasi dapat mengungkapkan error terkait operasi file, panggilan database, atau akses penyimpanan jaringan.
    3. Gunakan Cloud Monitoring: meskipun Anda tidak bisa mendapatkan detail tingkat proses, periksa masalah I/O tingkat node.

  2. Picu penggantian node untuk menghapus status.

    Anda tidak dapat menghapus VM yang mendasarinya secara manual. Untuk memicu penggantian, kuras node. Tindakan ini akan mengisolasi node dan mengeluarkan Pod.

    GKE secara otomatis mendeteksi node yang tidak sehat dan memulai perbaikan, biasanya dengan mengganti VM yang mendasarinya.

    Jika node tetap macet setelah pengurasan dan tidak diganti secara otomatis, hubungi Cloud Customer Care.

  3. Setelah masalah langsung teratasi, selidiki sistem penyimpanan yang mendasarinya untuk mencegah terulang kembali.

    • Untuk masalah disk lokal: periksa throttling I/O di Cloud Monitoring dengan melihat metrik compute.googleapis.com/instance/disk/throttled_read_ops_count dan compute.googleapis.com/instance/disk/throttled_write_ops_count. Anda dapat memfilter metrik ini untuk grup instance pokok kumpulan node, meskipun instance individual dikelola oleh Google.
    • Untuk masalah penyimpanan jaringan (NFS): gunakan alat pemantauan penyedia penyimpanan Anda untuk memeriksa latensi tinggi, error sisi server, atau masalah jaringan antara node GKE dan server NFS. Periksa log dari Pod driver CSI apa pun di Cloud Logging.

Memecahkan masalah kegagalan komponen inti

Setelah Anda mengesampingkan penyebab yang diharapkan dan kekurangan resource, software node atau mekanisme Kubernetes inti mungkin menjadi penyebab masalah. Status NotReady dapat terjadi saat komponen penting, seperti runtime container, gagal. Hal ini juga dapat terjadi saat mekanisme health check Kubernetes inti, seperti sistem sewa node, rusak.

Menyelesaikan masalah runtime container

Masalah pada runtime container, seperti containerd, dapat mencegah kubelet meluncurkan Pod di node.

Gejala:

Jika Anda melihat pesan berikut di log kubelet, masalah runtime penampung adalah kemungkinan penyebab status NotReady node:

  • Container runtime not ready
  • Container runtime docker failed!
  • docker daemon exited
  • Error saat menghubungkan ke socket runtime (misalnya, unix:///var/run/docker.sock atau unix:///run/containerd/containerd.sock).

Penyebab:

Runtime penampung tidak berfungsi dengan benar, salah dikonfigurasi, atau macet dalam loop mulai ulang.

Resolusi:

Untuk mengatasi masalah runtime container, lakukan langkah-langkah berikut:

  1. Menganalisis log runtime container:

    1. Di konsol Google Cloud , buka halaman Logs Explorer.

      Buka Logs Explorer

    2. Untuk melihat semua log peringatan dan error runtime container di node yang terpengaruh, masukkan perintah berikut di panel kueri:

      resource.type="k8s_node"
resource.labels.node_name="NODE_NAME"
resource.labels.cluster_name="CLUSTER_NAME"
resource.labels.location="LOCATION"
log_id("container-runtime")
severity>=WARNING

      Ganti kode berikut:

      • NODE_NAME: nama node yang Anda selidiki.
      • CLUSTER_NAME: nama cluster Anda.
      • LOCATION: region atau zona Compute Engine (misalnya, us-central1 atau us-central1-a) untuk cluster.

    3. Klik Run query dan tinjau output untuk melihat pesan error tertentu yang menunjukkan alasan runtime gagal. Pesan seperti failed to load TOML di log containerd di Cloud Logging sering kali menunjukkan file yang salah format.

    4. Untuk memeriksa apakah runtime terjebak dalam loop mulai ulang, jalankan kueri yang menelusuri pesan saat sistem dimulai. Banyaknya pesan ini dalam jangka waktu singkat mengonfirmasi bahwa perangkat sering dimulai ulang.

      resource.type="k8s_node"
resource.labels.node_name="NODE_NAME"
resource.labels.cluster_name="CLUSTER_NAME"
resource.labels.location="LOCATION"
log_id("container-runtime")
("starting containerd" OR "Containerd cri plugin version" OR "serving..."
OR "loading plugin" OR "containerd successfully booted")

      Mulai ulang yang sering kali menunjukkan masalah mendasar, seperti file konfigurasi yang rusak atau tekanan resource, yang menyebabkan layanan error berulang kali.

  2. Tinjau konfigurasi containerd untuk melihat modifikasi: setelan yang salah dapat menyebabkan runtime container gagal. Anda dapat membuat perubahan konfigurasi melalui file konfigurasi sistem node atau melalui modifikasi langsung yang dilakukan oleh workload dengan hak istimewa yang ditingkatkan.

    1. Tentukan apakah node pool menggunakan file konfigurasi sistem node:

      gcloud container node-pools describe NODE_POOL_NAME \
    --cluster CLUSTER_NAME \
    --location LOCATION \
    --format="yaml(config.containerdConfig)"

      Ganti kode berikut:

      • NODE_POOL_NAME: nama node pool Anda.
      • CLUSTER_NAME: nama cluster Anda.
      • LOCATION: region atau zona Compute Engine cluster Anda.

      Jika output menampilkan bagian containerdConfig, berarti GKE mengelola setelan kustom ini. Untuk mengubah atau mengembalikan setelan, ikuti petunjuk di Menyesuaikan konfigurasi containerd di node GKE.

    2. Jika penyesuaian yang dikelola GKE tidak aktif, atau jika Anda mencurigai perubahan lain, cari workload yang mungkin memodifikasi sistem file node secara langsung. Cari DaemonSet dengan izin yang ditingkatkan (securityContext.privileged: true) atau volume hostPath yang memasang direktori sensitif seperti /etc.

      Untuk memeriksa konfigurasinya, cantumkan semua DaemonSet dalam format YAML:

      kubectl get daemonsets --all-namespaces -o yaml

      Tinjau output dan periksa log DaemonSet yang mencurigakan.

    3. Untuk cluster Standar, periksa file konfigurasi secara langsung. Akses SSH dan pemeriksaan file manual tidak dapat dilakukan di cluster Autopilot, karena Google mengelola konfigurasi runtime. Laporkan masalah runtime yang terus berlanjut ke Google Cloud Customer Care.

      Jika Anda menggunakan cluster Standar, periksa file:

      1. Hubungkan ke node menggunakan SSH:

        gcloud compute ssh NODE_NAME \
    --zone ZONE \
    --project PROJECT_ID

        Ganti kode berikut:

        • NODE_NAME: nama node yang akan dihubungkan.
        • ZONE: zona Compute Engine node.
        • PROJECT_ID: Project ID Anda.

      2. Tampilkan isi file konfigurasi containerd:

        sudo cat /etc/containerd/config.toml

      3. Untuk memeriksa perubahan terbaru, cantumkan detail file:

        ls -l /etc/containerd/config.toml

    4. Bandingkan konten file ini dengan output containerdConfig dari perintah gcloud node-pools describe yang Anda jalankan di langkah sebelumnya. Setelan apa pun di /etc/containerd/config.toml yang tidak ada di output gcloud adalah perubahan yang tidak dikelola.

    5. Untuk memperbaiki kesalahan konfigurasi, hapus perubahan yang tidak diterapkan melalui konfigurasi sistem node.

  3. Memecahkan masalah umum runtime: untuk mengetahui langkah-langkah pemecahan masalah lainnya, lihat Memecahkan masalah runtime container.

Menyelesaikan masalah dengan namespace kube-node-lease

Resource di namespace kube-node-lease bertanggung jawab untuk menjaga kesehatan node. Namespace ini tidak boleh dihapus. Upaya untuk menghapus namespace ini akan menyebabkan namespace terjebak dalam status Terminating. Jika namespace kube-node-lease mengalami masalah dan berstatus Terminating, kubelet tidak dapat memperpanjang masa berlaku health check-nya. Masalah ini menyebabkan bidang kontrol menganggap node tidak sehat, sehingga menyebabkan masalah di seluruh cluster yang membuat node bergantian antara status Ready dan NotReady.

Gejala:

Jika Anda mengamati gejala berikut, kemungkinan penyebab ketidakstabilan di seluruh cluster adalah masalah pada namespace kube-node-lease:

  • Log kubelet di setiap node menampilkan error persisten yang mirip dengan berikut:

    leases.coordination.k8s.io NODE_NAME is forbidden: unable to create new content in namespace kube-node-lease because it is being terminated

  • Node di seluruh cluster berulang kali berganti-ganti antara status Ready dan NotReady.

Penyebab:

Namespace kube-node-lease, yang mengelola detak jantung node, macet secara tidak normal dalam status Terminating. Error ini mencegah server API Kubernetes mengizinkan pembuatan atau modifikasi objek dalam namespace. Akibatnya, kubelet tidak dapat memperbarui objek Lease, yang penting untuk memberi sinyal keaktifannya ke bidang kontrol. Tanpa update status ini, bidang kontrol tidak dapat mengonfirmasi bahwa node dalam kondisi baik, sehingga status node bergantian antara Ready dan NotReady.

Alasan mendasar mengapa namespace kube-node-lease itu sendiri mungkin macet dalam status Terminating mencakup hal berikut:

  • Resource dengan finalizer: meskipun kurang umum untuk namespace kube-node-lease sistem (yang terutama berisi objek Lease), resource di dalamnya dapat memiliki finalizer. Finalizer Kubernetes adalah kunci yang menandakan bahwa pengontrol harus melakukan tugas pembersihan sebelum resource dapat dihapus. Jika pengontrol yang bertanggung jawab untuk menghapus finalizer tidak berfungsi dengan benar, resource tidak akan dihapus, dan proses penghapusan namespace akan dihentikan.
  • Layanan API gabungan yang tidak berfungsi atau tidak responsif: penghentian namespace dapat diblokir jika objek APIService, yang digunakan untuk mendaftarkan server API gabungan, ditautkan ke namespace dan menjadi tidak berfungsi. Bidang kontrol mungkin menunggu server API gabungan dimatikan atau dibersihkan dengan benar, yang tidak akan terjadi jika layanan tidak responsif.
  • Masalah bidang kontrol atau pengontrol: dalam kasus yang jarang terjadi, bug atau masalah dalam bidang kontrol Kubernetes, khususnya pengontrol namespace, dapat mencegah keberhasilan pengumpulan sampah dan penghapusan namespace.

Resolusi:

Ikuti panduan di Memecahkan masalah namespace yang terjebak dalam status Menghentikan.

Memecahkan masalah konektivitas jaringan

Masalah jaringan dapat mencegah node berkomunikasi dengan bidang kontrol atau mencegah komponen penting seperti plugin CNI berfungsi, sehingga menyebabkan status NotReady.

Gejala:

Jika Anda mengamati gejala berikut, masalah jaringan mungkin menjadi penyebab status NotReady node Anda:

  • Kondisi NetworkNotReady adalah True.
  • Log Kubelet di node menampilkan error yang mirip dengan berikut ini:
    • connection timeout to the control plane IP address
    • network plugin not ready
    • CNI plugin not initialized
    • Pesan connection refused atau timeout saat mencoba menjangkau alamat IP bidang kontrol.
  • Pod, terutama di namespace kube-system, macet di ContainerCreating dengan peristiwa seperti NetworkPluginNotReady.

Penyebab:

Gejala terkait jaringan biasanya menunjukkan kegagalan di salah satu area berikut:

  • Masalah konektivitas: node tidak dapat membuat koneksi jaringan yang stabil ke panel kontrol Kubernetes.
  • Kegagalan plugin CNI: plugin CNI, yang bertanggung jawab untuk mengonfigurasi jaringan Pod, tidak berjalan dengan benar atau gagal diinisialisasi.
  • Masalah webhook: webhook penerimaan yang salah dikonfigurasi dapat mengganggu resource terkait plugin CNI, sehingga mencegah jaringan dikonfigurasi dengan benar.

Resolusi:

Untuk mengatasi masalah jaringan, lakukan langkah-langkah berikut:

  1. Mengatasi status NetworkNotReady sementara: pada node yang baru dibuat, wajar jika terjadi peristiwa NetworkNotReady singkat. Status ini akan diselesaikan dalam satu atau dua menit saat plugin CNI dan komponen lainnya diinisialisasi. Jika status tetap sama, lanjutkan dengan langkah-langkah berikut.

  2. Verifikasi konektivitas node-ke-bidang kontrol dan aturan firewall: pastikan jalur jaringan antara node dan bidang kontrol terbuka dan berfungsi dengan benar:

    1. Periksa aturan firewall: pastikan aturan firewall VPC Anda mengizinkan traffic yang diperlukan antara node GKE dan panel kontrol. Untuk mengetahui informasi tentang aturan yang diperlukan GKE untuk komunikasi node-ke-bidang kontrol, lihat Aturan firewall yang dibuat secara otomatis.
    2. Uji konektivitas: gunakan Uji Konektivitas di Network Intelligence Center untuk memverifikasi jalur jaringan antara alamat IP internal node dan alamat IP endpoint bidang kontrol di port 443. Hasil Not Reachable sering kali membantu Anda mengidentifikasi aturan firewall atau masalah perutean yang memblokir komunikasi.

  3. Selidiki status dan log plugin CNI: jika jaringan node tidak siap, plugin CNI mungkin menjadi penyebabnya.

    1. Periksa status Pod CNI: identifikasi plugin CNI yang digunakan (misalnya, netd atau calico-node) dan periksa status Pod-nya di namespace kube-system. Anda dapat memfilter node tertentu dengan perintah berikut:

      kubectl get pods \
    -n kube-system \
    -o wide \
    --field-selector spec.nodeName=NODE_NAME \
    | grep -E "netd|calico|anetd"

    2. Periksa log Pod CNI: jika Pod tidak berfungsi dengan benar, periksa lognya di Cloud Logging untuk melihat pesan error mendetail. Gunakan kueri yang mirip dengan berikut untuk Pod netd di node tertentu:

      resource.type="k8s_container"
resource.labels.cluster_name="CLUSTER_NAME"
resource.labels.location="LOCATION"
resource.labels.namespace_name="kube-system"
labels."k8s-pod/app"="netd"
resource.labels.node_name="NODE_NAME"
severity>=WARNING

    3. Mengatasi error CNI tertentu:

      • Jika log menampilkan Failed to allocate IP address, rentang alamat IP Pod Anda mungkin sudah habis. Verifikasi pemanfaatan alamat IP Pod Anda dan tinjau rentang CIDR cluster Anda.
      • Jika log menampilkan NetworkPluginNotReady atau cni plugin not initialized, pastikan node memiliki resource CPU dan memori yang memadai. Anda juga dapat mencoba memulai ulang Pod CNI dengan menghapusnya, yang memungkinkan DaemonSet membuatnya kembali.
      • Jika Anda menggunakan GKE Dataplane V2 dan log menampilkan Cilium API client timeout exceeded, mulai ulang Pod anetd di node.

    4. Periksa apakah ada interferensi webhook penerimaan: webhook yang tidak berfungsi dengan baik dapat mencegah Pod CNI dimulai, sehingga membuat node dalam status NetworkNotReady.

    5. Periksa log server API: tinjau log server API di Cloud Logging untuk mengetahui error terkait panggilan webhook. Untuk mengidentifikasi apakah webhook memblokir pembuatan resource CNI, cari pesan seperti failed calling webhook.

      Jika webhook menyebabkan masalah, Anda mungkin perlu mengidentifikasi ValidatingWebhookConfiguration atau MutatingWebhookConfiguration yang bermasalah dan menonaktifkannya untuk sementara agar node siap. Untuk mengetahui informasi selengkapnya, lihat Mengatasi masalah yang disebabkan oleh webhook penerimaan.

Memecahkan masalah kesalahan konfigurasi cluster

Bagian berikut membantu Anda mengaudit beberapa konfigurasi di seluruh cluster yang mungkin mengganggu operasi node normal.

Menyelesaikan masalah yang disebabkan oleh webhook penerimaan

Webhook penerimaan yang salah dikonfigurasi, tidak tersedia, atau terlalu lambat dapat memblokir permintaan API penting, sehingga mencegah komponen penting dimulai atau node bergabung dengan cluster.

Gejala:

Jika Anda mengamati gejala berikut, webhook penerimaan yang salah dikonfigurasi atau tidak tersedia kemungkinan memblokir operasi cluster penting:

  • Pod, terutama di namespace kube-system (seperti Pod CNI atau penyimpanan), terjebak dalam status Pending atau Terminating.
  • Node baru gagal bergabung dengan cluster, sering kali kehabisan waktu dengan status NotReady status.

Penyebab:

Webhook penerimaan yang salah dikonfigurasi atau tidak responsif dapat memblokir operasi cluster penting.

Resolusi:

Tinjau konfigurasi webhook Anda untuk memastikan konfigurasi tersebut tangguh dan tercakup dengan benar. Untuk mencegah gangguan, tetapkan kolom failurePolicy ke Ignore untuk webhook non-kritis. Untuk webhook penting, pastikan layanan pendukungnya sangat tersedia dan kecualikan namespace kube-system dari pengawasan webhook dengan menggunakan namespaceSelector untuk menghindari kebuntuan bidang kontrol. Untuk informasi selengkapnya, lihat Memastikan stabilitas bidang kontrol saat menggunakan webhook.

Menyelesaikan masalah yang disebabkan oleh kuota resource

Kuota resource yang salah dihitung di namespace kube-system dapat mencegah GKE membuat Pod sistem penting. Karena komponen seperti jaringan (CNI) dan DNS diblokir, masalah ini dapat menghentikan node baru agar tidak berhasil bergabung dengan cluster.

Gejala:

  • Pod penting di namespace kube-system (misalnya, netd, konnectivity-agent, atau kube-dns) macet dalam status Pending.
  • Pesan error di log cluster atau output kubectl describe pod menunjukkan kegagalan seperti exceeded quota: gcp-critical-pods.

Penyebab:

Masalah ini terjadi saat pengontrol kuota resource Kubernetes berhenti memperbarui jumlah yang digunakan secara akurat dalam objek ResourceQuota. Penyebab umumnya adalah webhook penerimaan pihak ketiga yang tidak berfungsi dengan baik yang memblokir update pengontrol, sehingga penggunaan kuota tampak jauh lebih tinggi daripada yang sebenarnya.

Resolusi:

  1. Karena webhook yang bermasalah adalah penyebab utama yang paling mungkin, ikuti panduan di bagian Mengatasi masalah yang disebabkan oleh webhook penerimaan untuk mengidentifikasi dan memperbaiki webhook yang mungkin memblokir komponen sistem. Memperbaiki webhook sering kali menyelesaikan masalah kuota secara otomatis.

  2. Pastikan penggunaan kuota yang tercatat tidak sinkron dengan jumlah Pod yang berjalan sebenarnya. Langkah ini mengonfirmasi apakah jumlah objek ResourceQuota salah:

    1. Periksa penggunaan yang dilaporkan untuk kuota:

      kubectl get resourcequota gcp-critical-pods -n kube-system -o yaml

    2. Periksa jumlah Pod yang sebenarnya:

      kubectl get pods -n kube-system --no-headers | wc -l

  3. Jika jumlah yang digunakan di ResourceQuota tampak salah (misalnya, jauh lebih tinggi daripada jumlah Pod yang sebenarnya), hapus objek gcp-critical-pods. Bidang kontrol GKE dirancang untuk otomatis membuat ulang objek ini dengan jumlah penggunaan yang benar dan disesuaikan:

    kubectl delete resourcequota gcp-critical-pods -n kube-system

  4. Pantau namespace kube-system selama beberapa menit untuk memastikan objek dibuat ulang dan Pod yang tertunda mulai dijadwalkan.

Menyelesaikan masalah yang disebabkan oleh DaemonSet pihak ketiga

DaemonSet pihak ketiga yang baru di-deploy atau diupdate, yang sering digunakan untuk keamanan, pemantauan, atau logging, terkadang dapat menyebabkan ketidakstabilan node. Masalah ini dapat terjadi jika DaemonSet mengganggu runtime atau jaringan container node, menggunakan resource sistem yang berlebihan, atau membuat modifikasi sistem yang tidak terduga.

Gejala:

Jika Anda mengamati gejala berikut, DaemonSet pihak ketiga yang baru di-deploy atau diubah adalah kemungkinan penyebab kegagalan node:

  • Beberapa node, yang berpotensi berada di seluruh cluster, memasuki status NotReady segera setelah DaemonSet di-deploy atau diperbarui.
  • Log kubelet untuk node yang terpengaruh melaporkan error seperti berikut:
    • container runtime is down
    • Failed to create pod sandbox
    • Error saat menghubungkan ke soket runtime container (misalnya, /run/containerd/containerd.sock).
  • Pod, termasuk Pod sistem atau Pod DaemonSet itu sendiri, macet dalam status PodInitializing atau ContainerCreating.
  • Log container untuk aplikasi menampilkan error yang tidak biasa, seperti exec format error.
  • Pendeteksi Masalah Node dapat melaporkan kondisi yang terkait dengan kondisi runtime atau tekanan resource.

Penyebab:

DaemonSet pihak ketiga dapat memengaruhi stabilitas node karena alasan berikut:

  • Menggunakan CPU, memori, atau I/O disk secara berlebihan, yang memengaruhi performa komponen node penting.
  • Mengganggu operasi runtime container.
  • Menyebabkan konflik dengan konfigurasi jaringan node atau plugin Container Network Interface (CNI).
  • Mengubah konfigurasi sistem atau kebijakan keamanan dengan cara yang tidak diinginkan.

Resolusi:

Untuk menentukan apakah DaemonSet adalah penyebabnya, isolasi dan uji:

  1. Mengidentifikasi DaemonSet: mencantumkan semua DaemonSet yang berjalan di cluster Anda:

    kubectl get daemonsets --all-namespaces

    Perhatikan baik-baik DaemonSet yang bukan bagian dari penginstalan GKE default.

    Anda sering kali dapat mengidentifikasi DaemonSet ini dengan meninjau hal berikut:

    • Namespace: Komponen GKE default biasanya berjalan di namespace kube-system. DaemonSet di namespace lain kemungkinan adalah pihak ketiga atau kustom.
    • Penamaan: DaemonSet default sering kali memiliki nama seperti gke-metrics-agent, netd, atau calico-node. Agen pihak ketiga sering kali memiliki nama yang mencerminkan produk.

  2. Korelasikan waktu deployment: periksa apakah munculnya node NotReady bertepatan dengan deployment atau update DaemonSet pihak ketiga tertentu.

  3. Uji pada satu node:

    1. Pilih satu node yang terpengaruh.
    2. Halangi dan kosongkan node.
    3. Mencegah DaemonSet dijadwalkan di node ini untuk sementara waktu:
      • Terapkan label node sementara dan konfigurasi afinitas atau anti-afinitas node dalam manifes DaemonSet.
      • Hapus Pod DaemonSet di node tertentu tersebut.
    4. Mulai ulang instance virtual machine node.
    5. Amati apakah node menjadi Ready dan tetap stabil saat DaemonSet tidak berjalan di node tersebut. Jika masalah muncul kembali setelah DaemonSet diperkenalkan kembali, kemungkinan hal ini menjadi faktor penyebabnya.

  4. Hubungi vendor: jika Anda mencurigai bahwa penyebabnya adalah agen pihak ketiga, tinjau dokumentasi vendor untuk mengetahui masalah kompatibilitas yang diketahui atau praktik terbaik untuk menjalankan agen di GKE. Jika Anda memerlukan dukungan lebih lanjut, hubungi vendor software.

Pastikan node telah dipulihkan

Setelah menerapkan solusi yang mungkin, ikuti langkah-langkah berikut untuk memverifikasi bahwa node telah berhasil dipulihkan dan stabil:

  1. Periksa status node:

    kubectl get nodes -o wide

    Cari node yang terpengaruh dalam output. Kolom Status sekarang akan menampilkan nilai Ready. Status mungkin memerlukan waktu beberapa menit untuk diperbarui setelah perbaikan diterapkan. Jika status masih menampilkan NotReady atau berganti-ganti status, berarti masalah belum sepenuhnya teratasi.

  2. Periksa bagian Conditions node:

    kubectl describe node NODE_NAME

    Di bagian Conditions, verifikasi nilai berikut:

    • Kondisi Ready memiliki status True.
    • Kondisi negatif yang sebelumnya memiliki status True (misalnya, MemoryPressure atau NetworkUnavailable) kini memiliki status False. Kolom Reason dan Message untuk kondisi ini harus menunjukkan bahwa masalah telah diselesaikan.

  3. Menguji penjadwalan Pod. Jika sebelumnya node tidak dapat menjalankan workload, periksa apakah Pod baru dijadwalkan di node tersebut dan apakah Pod yang ada berjalan tanpa masalah:

    kubectl get pods --all-namespaces -o wide --field-selector spec.nodeName=NODE_NAME

    Pod di node harus memiliki status Running atau Completed. Anda tidak akan melihat Pod yang macet dalam status error Pending atau lainnya.

Langkah berikutnya