Container Service for Kubernetes:Troubleshooting node exceptions

Diagnosa gangguan node

Jika node gagal, gunakan fitur ACK Exception Diagnosis untuk mendiagnosis node tersebut.

1. Login ke ACK console. Di panel navigasi kiri, klik Clusters.

2. Pada halaman Clusters, klik nama kluster Anda. Di panel navigasi kiri, klik Node Pools > Nodes.

3. Pada halaman Nodes, temukan node target dan pilih More > Exception Diagnosis di kolom Actions.

4. Pada panel yang muncul, klik Create Diagnosis. Lalu, lihat hasil diagnosis dan saran perbaikan di konsol.

Periksa detail node

1. Login ke ACK console. Di panel navigasi kiri, klik Clusters.

2. Pada halaman Clusters, klik nama kluster Anda. Di panel navigasi kiri, klik Node Pools > Nodes.

3. Pada halaman Nodes, klik nama node target atau klik Details di kolom Actions untuk melihat detailnya.

Periksa status node

1. Login ke ACK console. Di panel navigasi kiri, klik Clusters.

2. Pada halaman Clusters, klik nama kluster Anda. Di panel navigasi kiri, klik Node Pools > Nodes.

3. Pada halaman Nodes, lihat status node tersebut.

   • Jika status node adalah Ready, artinya node berjalan sesuai harapan.

   • Jika status node bukan Ready, klik nama node target atau klik Details di kolom Actions untuk melihat detailnya.

     Catatan

     Untuk mengumpulkan informasi tentang kondisi seperti InodesPressure, DockerOffline, dan RuntimeOffline, Anda harus menginstal node-problem-detector di kluster Anda dan membuat K8s Event Center. Opsi untuk membuat K8s Event Center dipilih secara default saat pembuatan kluster. Untuk informasi lebih lanjut, lihat Buat dan gunakan K8s Event Center.

Periksa event node

1. Login ke ACK console. Di panel navigasi kiri, klik Clusters.

2. Pada halaman Clusters, klik nama kluster Anda. Di panel navigasi kiri, klik Node Pools > Nodes.

3. Pada halaman Nodes, klik nama node target atau klik Details di kolom Actions untuk melihat detailnya.

   Event node ditampilkan di bagian bawah halaman detail.

Kumpulkan log diagnostik node

• Gunakan Container Intelligence Service di konsol untuk mengumpulkan log diagnostik. Untuk informasi lebih lanjut, lihat Diagnostik node.

• Gunakan skrip untuk mengumpulkan log diagnostik. Untuk informasi lebih lanjut, lihat Bagaimana cara mengumpulkan informasi diagnostik kluster Kubernetes?.

Periksa komponen utama node

• kubelet

  • Periksa status kubelet

    Login ke node dan jalankan perintah berikut untuk memeriksa status kubelet:

    systemctl status kubelet

    Output yang diharapkan:

    [root@iZm5eali3mx0qwqo68eobrZ ~]# systemctl status kubelet
    ● kubelet.service - kubelet: The Kubernetes Node Agent
       Loaded: loaded (/etc/systemd/system/kubelet.service; enabled; vendor preset: disabled)
      Drop-In: /etc/systemd/system/kubelet.service.d
               └─10-kubeadm.conf
       Active: active (running) since Thu 2025-06-12 13:18:45 CST; 28min ago
         Docs: http://kubernetes.io/docs/
     Main PID: 6171 (kubelet)
        Tasks: 12 (limit: 98626)
       Memory: 88.2M
       CGroup: /system.slice/kubelet.service
               └─6171 /usr/bin/kubelet --bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig=/etc/kubernetes/kubelet.conf --pod-manifest-path=/etc/kubernetes/manifests --v=3 --authorization
    Jun 12 13:47:12                kubelet[6171]: I0612 13:47:12.250117    6171 prober.go:116] "Probe succeeded" probeType="Liveness" pod="kube-system/coredns-5b97654649-jkbtq" podUID="0530c82c-a012-4f
    Jun 12 13:47:12                kubelet[6171]: I0612 13:47:12.250144    6171 prober.go:116] "Probe succeeded" probeType="Readiness" pod="kube-system/coredns-5b97654649-jkbtq" podUID="0530c82c-a012-4
    Jun 12 13:47:12                kubelet[6171]: I0612 13:47:12.716032    6171 prober.go:116] "Probe succeeded" probeType="Liveness" pod="kube-system/csi-plugin-bqdjr" podUID="33fd9325-c75d-458d-adc3-
    Jun 12 13:47:13                kubelet[6171]: I0612 13:47:13.574947    6171 kubelet_pods.go:1151] "Clean up pod workers for terminated pods"
    Jun 12 13:47:13                kubelet[6171]: I0612 13:47:13.575713    6171 kubelet_pods.go:1201] "Clean up probes for terminated pods"
    Jun 12 13:47:13                kubelet[6171]: I0612 13:47:13.575724    6171 kubelet_pods.go:1205] "Clean up orphaned pod statuses"
    Jun 12 13:47:13                kubelet[6171]: I0612 13:47:13.575731    6171 kubelet_pods.go:1209] "Clean up orphaned pod user namespace allocations"
    Jun 12 13:47:13                kubelet[6171]: I0612 13:47:13.575736    6171 kubelet_pods.go:1221] "Clean up orphaned pod directories"
    Jun 12 13:47:13                kubelet[6171]: I0612 13:47:13.575775    6171 kubelet_pods.go:1232] "Clean up mirror pods"
    Jun 12 13:47:13                kubelet[6171]: I0612 13:47:13.575807    6171 kubelet_pods.go:1374] "Clean up orphaned pod cgroups"
    lines 1-22/22 (END)

  • Periksa log kubelet

    Login ke node dan jalankan perintah berikut untuk melihat log kubelet. Untuk informasi lebih lanjut tentang melihat log kubelet, lihat Kumpulkan log diagnostik node.

    journalctl -u kubelet

  • Periksa konfigurasi kubelet

    Login ke node dan jalankan perintah berikut untuk melihat konfigurasi kubelet:

    cat /etc/systemd/system/kubelet.service.d/10-kubeadm.conf

• Runtime

  • Periksa dockerd

    • Periksa status dockerd

      Login ke node dan jalankan perintah berikut untuk memeriksa status dockerd:

      systemctl status docker

      Output yang diharapkan:

      #systemctl status docker
      ● docker.service - Docker Application Container Engine
         Loaded: loaded (/etc/systemd/system/docker.service; enabled; vendor preset: disabled)
         Active: active (running) since Wed 2022-03-02 15:11:46 CST; 5 days ago
           Docs: https://docs.docker.com
       Main PID: 4330 (dockerd)
          Tasks: 75
         Memory: 8.3G
         CGroup: /system.slice/docker.service
                 └─4330 /usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock
      Mar 02 15:19:29 xxx                    dockerd[4330]: time="2022-03-02T15:19:29.418689546+08:00" level=info msg="Attempting next endpoint for pull a...eaders
      Mar 02 15:22:20 xxx                    dockerd[4330]: time="2022-03-02T15:22:20.888769038+08:00" level=warning msg="Error getting v2 registry: Get h...eaders
      Mar 02 15:22:20 xxx                    dockerd[4330]: time="2022-03-02T15:22:20.888912991+08:00" level=info msg="Attempting next endpoint for pull a...eaders
      Mar 02 15:23:25 xxx                    dockerd[4330]: time="2022-03-02T15:23:25.487947465+08:00" level=warning msg="Seccomp is not enabled in your k...rofile

    • Periksa log dockerd

      Login ke node dan jalankan perintah berikut untuk melihat log dockerd. Untuk informasi lebih lanjut tentang melihat log dockerd, lihat Kumpulkan log diagnostik node.

      journalctl -u docker

    • Periksa konfigurasi dockerd

      Login ke node dan jalankan perintah berikut untuk melihat konfigurasi dockerd:

      cat /etc/docker/daemon.json

  • Periksa containerd

    • Periksa status containerd

      Login ke node dan jalankan perintah berikut untuk memeriksa status containerd:

      systemctl status containerd

      Output yang diharapkan:

      [root@iZm5eali3mx0qwqo68eobrZ ~]# systemctl status containerd
      ● containerd.service - containerd container runtime
         Loaded: loaded (/etc/systemd/system/containerd.service; enabled; vendor preset: disabled)
         Active: active (running) since Thu 2025-06-12 13:18:44 CST; 29min ago
           Docs: https://containerd.io
       Main PID: 5994 (containerd)
          Tasks: 153
         Memory: 3.5G
         CGroup: /system.slice/containerd.service
                 ├─ 5994 /usr/bin/containerd
                 ├─ 6589 /usr/bin/containerd-shim-runc-v2 -namespace k8s.io -id b4ad8b28c61fa573e04bc641901bd64b15adb1d4a... xxx -address /run/containerd/containerd.sock
                 ├─ 6592 /usr/bin/containerd-shim-runc-v2 -namespace k8s.io -id eb828cfb114bd404d7781f72b55ed4ee1e9743b7d... xxx -address /run/containerd/containerd.sock
                 ├─ 6666 /usr/bin/containerd-shim-runc-v2 -namespace k8s.io -id 92bf24db851fcaf65ed9c3ddc9210b61169623158... xxx -address /run/containerd/containerd.sock
                 ├─ 6726 /usr/bin/containerd-shim-runc-v2 -namespace k8s.io -id 96d44ff7503b876227e7d287a730cac5b50b5183f1... xxx -address /run/containerd/containerd.sock
                 ├─ 6727 /usr/bin/containerd-shim-runc-v2 -namespace k8s.io -id 3707c088fec2d14f9ec2c78beccf5f3e1f0a18a6b... xxx -address /run/containerd/containerd.sock
                 ├─ 6766 /usr/bin/containerd-shim-runc-v2 -namespace k8s.io -id b390b71290b772958626a0cc943fb678c7fec4ef5... xxx -address /run/containerd/containerd.sock
                 ├─ 9501 /usr/bin/containerd-shim-runc-v2 -namespace k8s.io -id 40c0f850c4c003144bbc5a17bcb5b7f15ad121862... xxx -address /run/containerd/containerd.sock
                 ├─ 9567 /usr/bin/containerd-shim-runc-v2 -namespace k8s.io -id 3b07c32bf4fe84fde20177efdcffabd2cd93ac02a... xxx -address /run/containerd/containerd.sock
                 ├─ 9633 /usr/bin/containerd-shim-runc-v2 -namespace k8s.io -id d181fcabeebca990b1298072f91da4fbb251b666c... xxx -address /run/containerd/containerd.sock
                 └─11643 /usr/bin/containerd-shim-runc-v2 -namespace k8s.io -id f3744bcb95b522bc64a5a88dd4c49a231c082f5d79... xxx -address /run/containerd/containerd.sock
      Jun 12 13:19:53  containerd[5994]: time="2025-06-12T13:19:53.013508035+08:00" level=error msg="ContainerStatus for \"f3744bcb95b522bc64a5a88dd4c49a231c082f5d790e64e6f835760b83e7b280\""
      Jun 12 13:19:54  containerd[5994]: time="2025-06-12T13:19:54.708151565+08:00" level=info msg="ImageCreate event &ImageCreate{Name:registry-cn-qingdao-vpc.ack.aliyuncs.com/acs/loongcol..."
      Jun 12 13:19:54  containerd[5994]: time="2025-06-12T13:19:54.710172874+08:00" level=info msg="ImageCreate event &ImageCreate{Name:sha256:e705a85d376f9fdecd0f1b2ebce63d85f8392de70a9636..."
      Jun 12 13:19:54  containerd[5994]: time="2025-06-12T13:19:54.713591809+08:00" level=info msg="PullImage \"registry-cn-qingdao-vpc.ack.aliyuncs.com/acs/loongcollector:v3.0.11.0-915c655..."
      Jun 12 13:19:54  containerd[5994]: time="2025-06-12T13:19:54.713969883+08:00" level=info msg="ImageCreate event &ImageCreate{Name:registry-cn-qingdao-vpc.ack.aliyuncs.com/acs/loongcol..."
      Jun 12 13:19:54  containerd[5994]: time="2025-06-12T13:19:54.717628440+08:00" level=info msg="CreateContainer within sandbox \"f3744bcb95b522bc64a5a88dd4c49a231c082f5d790e64e6f835760b..."
      Jun 12 13:19:54  containerd[5994]: time="2025-06-12T13:19:54.732237135+08:00" level=info msg="CreateContainer within sandbox \"f3744bcb95b522bc64a5a88dd4c49a231c082f5d790e64e6f835760b..."
      Jun 12 13:19:54  containerd[5994]: time="2025-06-12T13:19:54.735512597+08:00" level=info msg="StartContainer for \"e7c6a20368f9c20900848fbcec81d5145d73caa8c4decaae660e0ea89dd64c28\""
      Jun 12 13:19:54  containerd[5994]: time="2025-06-12T13:19:54.771464238+08:00" level=info msg="StartContainer for \"e7c6a20368f9c20900848fbcec81d5145d73caa8c4decaae660e0ea89dd64c28\"..."
      Jun 12 13:20:47  containerd[5994]: time="2025-06-12T13:20:47.246563467+08:00" level=error msg="ContainerStatus for \"f3744bcb95b522bc64a5a88dd4c49a231c082f5d790e64e6f835760b83e7b280\""
      lines 1-30/30 (END)

    • Periksa log containerd

      Login ke node dan jalankan perintah berikut untuk melihat log containerd. Untuk informasi lebih lanjut tentang melihat log containerd, lihat Kumpulkan log diagnostik node.

      journalctl -u containerd

• Periksa NTP

  • Periksa status layanan NTP

    Login ke node dan jalankan perintah berikut untuk memeriksa status proses chronyd:

    systemctl status chronyd

    Output yang diharapkan:

    [root@iZm5eali3mx0qwqo68eobrZ ~]# systemctl status chronyd
    ● chronyd.service - NTP client/server
       Loaded: loaded (/usr/lib/systemd/system/chronyd.service; enabled; vendor preset: enabled)
       Active: active (running) since Thu 2025-06-12 13:18:22 CST; 20min ago
         Docs: man:chronyd(8)
               man:chrony.conf(5)
     Main PID: 1603 (chronyd)
        Tasks: 1 (limit: 98626)
       Memory: 732.0K
       CGroup: /system.slice/chronyd.service
               └─1603 /usr/sbin/chronyd
    Jun 12 13:18:22 iZm5eali3mx0qwqo68eobrZ systemd[1]: chronyd.service: Succeeded.
    Jun 12 13:18:22 iZm5eali3mx0qwqo68eobrZ systemd[1]: Stopped NTP client/server.
    Jun 12 13:18:22 iZm5eali3mx0qwqo68eobrZ systemd[1]: Starting NTP client/server...
    Jun 12 13:18:22 iZm5eali3mx0qwqo68eobrZ chronyd[1603]: chronyd version 4.5 starting (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP +SCFILTER +SIGND +ASYNCDNS +NTS +SECHASH +IPV6 +DEBUG)
    Jun 12 13:18:22 iZm5eali3mx0qwqo68eobrZ chronyd[1603]: Frequency -35.639 +/- 2.058 ppm read from /var/lib/chrony/drift
    Jun 12 13:18:22 iZm5eali3mx0qwqo68eobrZ systemd[1]: Started NTP client/server.
    Jun 12 13:18:23 iZm5eali3mx0qwqo68eobrZ chronyd[1603]: System clock was stepped by 0.000000 seconds
    Jun 12 13:18:27 iZm5eali3mx0qwqo68eobrZ chronyd[1603]: Selected source 100.100.61.88 (ntp.cloud.aliyuncs.com)
    Jun 12 13:18:27 iZm5eali3mx0qwqo68eobrZ chronyd[1603]: System clock wrong by 1.476188 seconds
    xxx

  • Periksa log layanan NTP

    Login ke node dan jalankan perintah berikut untuk melihat log NTP:

    journalctl -u chronyd

Periksa data pemantauan node

• Cloud Monitor

  ACK terintegrasi dengan CloudMonitor. Lihat data pemantauan dasar untuk instans ECS yang sesuai di CloudMonitor console. Untuk informasi lebih lanjut tentang pemantauan node dengan CloudMonitor, lihat Pantau node.

• Managed Service for Prometheus

  1. Login ke ACK console. Di panel navigasi kiri, klik Clusters.

  2. Pada halaman Clusters, klik nama kluster Anda. Di panel navigasi kiri, klik Operations > Prometheus Monitoring.

  3. Pada halaman Prometheus Monitoring, klik tab Node Monitoring, lalu klik tab Nodes.

  4. Pada halaman Nodes, pilih node untuk melihat metrik pemantauannya, seperti penggunaan CPU, memori, dan disk.

Periksa security group node

Untuk informasi lebih lanjut tentang memeriksa security group node, lihat Ikhtisar security group dan Konfigurasi security group kluster.

Penyebab

Penyebab umum meliputi proses Kubelet yang tidak normal, pengecualian runtime kontainer, atau konfigurasi Kubelet yang salah.

Gejala

Status Kubelet adalah inactive.

Solusi

1. Jalankan perintah berikut untuk me-restart Kubelet. Tindakan ini tidak memengaruhi kontainer yang sedang berjalan.

   systemctl restart kubelet

2. Setelah Kubelet direstart, login ke node dan jalankan perintah berikut untuk memeriksa statusnya.

   systemctl status kubelet

3. Jika status Kubelet tetap tidak normal, login ke node dan jalankan perintah berikut untuk melihat log-nya.

   journalctl -u kubelet

   • Jika log berisi pesan error spesifik, gunakan kata kunci dari pesan tersebut untuk troubleshooting.

   • Jika konfigurasi Kubelet salah, jalankan perintah berikut untuk memperbaikinya.

     vi /etc/systemd/system/kubelet.service.d/10-kubeadm.conf   # Modifikasi konfigurasi Kubelet.
     systemctl daemon-reload;systemctl restart kubelet         # Muat ulang konfigurasi dan restart Kubelet.

Penyebab

Penyebab umum meliputi konfigurasi dockerd yang tidak valid, beban proses tinggi, atau beban node tinggi.

Gejala

• Status dockerd adalah inactive.

• Status dockerd adalah active (running), tetapi daemon mengalami malfungsi sehingga menyebabkan pengecualian node. Perintah seperti docker ps dan docker exec mungkin gagal.

• Kondisi RuntimeOffline node bernilai True.

• Pengecualian dockerd memicu alert jika Anda telah mengonfigurasi alerting untuk pengecualian node kluster. Untuk informasi lebih lanjut tentang cara mengonfigurasi aturan alert, lihat Manajemen alert ACK.

Solusi

1. Jalankan perintah berikut untuk me-restart dockerd:

   systemctl restart docker

2. Login ke node dan jalankan perintah berikut untuk memeriksa status dockerd:

   systemctl status docker

3. Jika status tetap tidak normal, periksa log dockerd:

   journalctl -u docker

Penyebab

Masalah ini sering disebabkan oleh konfigurasi containerd yang tidak valid, beban proses tinggi, atau beban node tinggi.

• Status containerd adalah inactive.

• Kondisi RuntimeOffline pada node bernilai True.

• Jika alerting dikonfigurasi untuk pengecualian node kluster, Anda akan menerima notifikasi saat terjadi pengecualian containerd. Untuk informasi selengkapnya, lihat Manajemen alert ACK.

Solusi

1. Jalankan perintah berikut untuk me-restart containerd:

   systemctl restart containerd

2. Setelah containerd direstart, login ke node dan jalankan perintah berikut untuk memeriksa statusnya:

   systemctl status containerd

3. Jika status tetap tidak normal setelah restart, login ke node dan jalankan perintah berikut untuk melihat log containerd:

   journalctl -u containerd

Penyebab

Proses NTP yang tidak normal biasanya menyebabkan masalah ini.

Gejala

• Status chronyd adalah inactive.

• Kondisi node NTPProblem bernilai True.

• Jika Anda telah mengonfigurasi alert untuk pengecualian node kluster, Anda akan menerima alert ketika layanan waktu node tidak normal. Untuk informasi lebih lanjut tentang mengonfigurasi alert, lihat Manajemen alert ACK.

Solusi

1. Jalankan perintah berikut untuk me-restart chronyd:

   systemctl restart chronyd

2. Setelah chronyd direstart, login ke node dan jalankan perintah berikut untuk memverifikasi bahwa statusnya normal:

   systemctl status chronyd

3. Jika status masih tidak normal setelah restart, login ke node dan jalankan perintah berikut untuk melihat log chronyd:

   journalctl -u chronyd

Penyebab

Pod Lifecycle Event Generator (PLEG) mencatat event sepanjang siklus hidup Pod, seperti startup dan terminasi kontainer. Pengecualian PLEG is not healthy biasanya disebabkan oleh masalah pada runtime kontainer di node atau cacat pada versi systemd node.

Gejala

• Status node adalah NotReady.

• Log kubelet berisi entri berikut.

  I0729 11:20:59.245243    9575 kubelet.go:1823] skipping pod synchronization - PLEG is not healthy: pleg was last seen active 3m57.138893648s ago; threshold is 3m0s.

• Jika Anda mengonfigurasi alert untuk pengecualian node kluster, Anda akan menerima alert ketika terjadi pengecualian PLEG. Untuk mengonfigurasi alert, lihat Manajemen alert ACK.

Solusi

1. Restart komponen utama node dockerd/containerd dan kubelet secara berurutan, lalu periksa apakah node telah pulih.

2. Jika me-restart komponen utama tidak menyelesaikan masalah, restart node tersebut. Lihat restart instance untuk instruksinya.

   Peringatan

   Me-restart node dapat mengganggu workload Anda. Lakukan dengan hati-hati.

3. Jika node menjalankan CentOS 7.6, lihat Error "PLEG is not healthy" pada log kubelet di CentOS 7.6Error "Reason:KubeletNotReady Message:PLEG is not healthy:" pada log kubelet di CentOS 7.6.

Penyebab

Masalah ini biasanya terjadi ketika node di kluster memiliki sumber daya yang tidak mencukupi.

Gejala

Pod tidak akan dijadwalkan ke node jika total permintaan sumber dayanya melebihi sumber daya yang tersedia di node (alokasi dikurangi yang telah dialokasikan).

kubectl describe node [$nodeName]

Allocatable:
  cpu:                3900m
  ephemeral-storage:  114022843818
  hugepages-1Gi:      0
  hugepages-2Mi:      0
  memory:             12601Mi
  pods:               60
Allocated resources:
  (Total limits may be over 100 percent, i.e., overcommitted.)
  Resource           Requests    Limits
  --------           --------    ------
  cpu                725m (18%)  6600m (169%)
  memory             977Mi (7%)  16640Mi (132%)
  ephemeral-storage  0 (0%)      0 (0%)
  hugepages-1Gi      0 (0%)      0 (0%)
  hugepages-2Mi      0 (0%)      0 (0%)

Solusi

Untuk menyelesaikan masalah ini, kurangi beban node menggunakan salah satu metode berikut:

• Hapus Pod yang tidak diperlukan untuk mengurangi beban node. Untuk informasi lebih lanjut, lihat Kelola Pod.

• Sesuaikan konfigurasi sumber daya untuk Pod Anda berdasarkan kebutuhan bisnis. Untuk informasi lebih lanjut, lihat Atur permintaan dan batas CPU serta memori untuk kontainer.

• Anda dapat menggunakan fitur profiling sumber daya yang disediakan oleh ACK untuk mendapatkan saran konfigurasi sumber daya untuk kontainer berdasarkan data historis penggunaan sumber daya. Hal ini menyederhanakan konfigurasi permintaan dan batas sumber daya untuk kontainer. Untuk informasi lebih lanjut, lihat Profiling sumber daya.

• Tambahkan node baru ke kluster. Untuk informasi lebih lanjut, lihat Buat dan kelola kelompok node.

• Tingkatkan konfigurasi node. Untuk informasi lebih lanjut, lihat Tingkatkan atau turunkan spesifikasi node pekerja.

Untuk informasi lebih lanjut, lihat CPU node tidak mencukupi, Memori node tidak mencukupi - MemoryPressure, dan Ruang disk node tidak mencukupi - DiskPressure.

Penyebab

Kontainer yang mengonsumsi sumber daya CPU berlebihan di node biasanya menyebabkan masalah ini.

Gejala

• Sumber daya CPU yang tidak mencukupi dapat menyebabkan status node menjadi tidak normal.

• Jika alert dikonfigurasi untuk pengecualian node kluster, alert dipicu ketika utilisasi CPU node mencapai atau melebihi 85%. Untuk informasi lebih lanjut tentang cara mengonfigurasi alert, lihat Manajemen alert ACK.

Solusi

• Tinjau kurva utilisasi CPU node untuk mengidentifikasi kapan pengecualian terjadi dan proses mana di node yang mengonsumsi sumber daya CPU berlebihan. Untuk informasi lebih lanjut, lihat Periksa data pemantauan node.

• Kurangi beban pada node. Untuk informasi lebih lanjut, lihat Sumber daya node tidak mencukupi untuk penjadwalan.

• Jika perlu, restart node yang terpengaruh. Untuk informasi lebih lanjut, lihat Restart instance.

  Peringatan

  Me-restart node dapat mengganggu layanan Anda. Lakukan dengan hati-hati.

Penyebab

Masalah ini biasanya terjadi ketika kontainer di node mengonsumsi memori berlebihan, sehingga menyisakan memori yang tidak mencukupi di node.

Gejala

• Ketika memori yang tersedia di node turun di bawah ambang batas yang ditentukan oleh memory.available, kondisi MemoryPressure node diatur menjadi True, dan kontainer di node tersebut dievict. Untuk informasi lebih lanjut tentang eviction node, lihat Node-pressure Eviction.

• Ketika node kekurangan memori, Anda mungkin mengamati gejala umum berikut:

  • Kondisi MemoryPressure node bernilai True.

  • Ketika kontainer di node dievict:

    • Event untuk kontainer yang dievict mencakup pesan The node was low on resource: memory.

    • Event node mencakup pesan attempting to reclaim memory.

  • System OOM juga dapat terjadi, yang ditunjukkan oleh pesan System OOM dalam event node.

• Anda dapat mengonfigurasi alert untuk diberi tahu ketika penggunaan memori node mencapai atau melebihi 85%. Lihat Manajemen alert ACK untuk mempelajarinya.

Solusi

• Analisis kurva penggunaan memori dalam data pemantauan node untuk menentukan kapan masalah terjadi, dan periksa proses yang berjalan untuk kebocoran memori. Untuk informasi lebih lanjut, lihat Periksa data pemantauan node.

• Kurangi beban pada node. Untuk informasi lebih lanjut, lihat Sumber daya node tidak mencukupi untuk penjadwalan.

• Jika diperlukan, mulai ulang node yang terpengaruh. Untuk informasi selengkapnya, lihat Mulai ulang Instans.

  Peringatan

  Peringatan: Me-restart node dapat mengganggu layanan Anda.

Penyebab

Masalah ini biasanya terjadi ketika kontainer di node mengonsumsi inode berlebihan.

Gejala

• Ketika jumlah inode yang tersedia di node turun di bawah ambang batas inodesFree, kondisi InodesPressure diatur menjadi True, dan kontainer di node tersebut dievict. Untuk informasi lebih lanjut, lihat node-pressure eviction.

• Ketika node kekurangan inode, Anda mungkin melihat pesan error umum berikut:

  • Kondisi node InodesPressure bernilai True.

  • Ketika kontainer di node dievict:

    • Event untuk kontainer yang dievict berisi pesan: The node was low on resource: inodes.

    • Event node berisi pesan: attempting to reclaim inodes.

• Jika Anda telah mengonfigurasi alert untuk pengecualian node di kluster Anda, Anda akan diberi tahu ketika node kekurangan inode. Untuk informasi lebih lanjut tentang cara mengonfigurasi alert, lihat Manajemen alert ACK.

Solusi

• Periksa kurva penggunaan inode dalam data pemantauan node untuk mengidentifikasi kapan pengecualian terjadi dan identifikasi proses apa pun yang mengonsumsi inode berlebihan. Untuk informasi lebih lanjut, lihat Periksa data pemantauan node.

• Untuk troubleshooting masalah terkait lainnya, lihat Selesaikan masalah "no space left" pada Linux.

Penyebab

Masalah ini terjadi ketika kontainer di node mengonsumsi terlalu banyak PID, sehingga menghabiskan PID yang tersedia di node.

Gejala

• Ketika PID yang tersedia di node turun di bawah ambang batas pid.available, kondisi NodePIDPressure diatur menjadi True, dan Pod di node tersebut dievict. Untuk informasi lebih lanjut tentang eviction node, lihat Node-pressure Eviction.

• Jika Anda telah mengonfigurasi alert untuk pengecualian node di kluster Anda, Anda akan menerima alert ketika node kehabisan PID. Untuk informasi lebih lanjut tentang cara mengonfigurasi alert, lihat Manajemen alert ACK.

Solusi

1. Jalankan perintah berikut untuk memeriksa jumlah maksimum PID di node dan PID tertinggi yang sedang digunakan.

   sysctl kernel.pid_max  # Periksa jumlah maksimum PID.
   ps -eLf|awk '{print $2}' | sort -rn| head -n 1   # Periksa PID tertinggi yang sedang digunakan.

2. Jalankan perintah berikut untuk mengidentifikasi lima proses yang paling banyak mengonsumsi PID.

   ps -elT | awk '{print $4}' | sort | uniq -c | sort -k1 -g | tail -5

   Output yang diharapkan:

   # Kolom pertama menunjukkan jumlah PID yang digunakan oleh proses. Kolom kedua menunjukkan ID proses.
   73 9743
   75 9316
   76 2812
   77 5726
   93 5691

3. Gunakan ID proses untuk menemukan proses dan Pod yang sesuai. Analisis mengapa proses tersebut mengonsumsi terlalu banyak PID dan optimalkan kode aplikasi.

4. Kurangi beban pada node. Untuk informasi lebih lanjut, lihat Sumber daya node tidak mencukupi untuk penjadwalan.

5. Jika perlu, restart node yang terpengaruh. Untuk informasi lebih lanjut, lihat Restart instance.

   Peringatan

   Me-restart node dapat mengganggu layanan Anda. Gunakan kehati-hatian.

Penyebab

Biasanya, node kehabisan ruang disk karena kontainer mengonsumsi ruang disk berlebihan atau gambar kontainer terlalu besar.

Gejala

• Ketika ruang disk yang tersedia untuk gambar kontainer di node turun di bawah ambang batasimagefs.available, kondisi DiskPressure node menjadi True.

• Ketika ruang disk yang tersedia di filesystem root node turun di bawah ambang batasnodefs.available, semua Pod di node tersebut dievict. Untuk informasi lebih lanjut tentang node-pressure eviction, lihat node-pressure eviction.

• Ketika node kehabisan ruang disk, Anda biasanya melihat pesan error berikut:

  • Kondisi DiskPressure node bernilai True.

  • Setelah garbage collection gambar dijalankan, jika ruang disk tetap di bawah ambang batas kesehatan (default: 80%), Anda dapat menemukan kata kunci failed to garbage collect required amount of images dalam event node.

  • Ketika Pod dievict dari node:

    • Dalam event untuk Pod yang dievict, Anda dapat menemukan kata kunci The node was low on resource: [DiskPressure].

    • Dalam event node, Anda dapat menemukan kata kunci seperti attempting to reclaim ephemeral-storage atau attempting to reclaim nodefs.

• Jika Anda telah mengonfigurasi alert untuk pengecualian node, Anda akan menerima alert jika penggunaan disk node mencapai 85% atau lebih. Untuk informasi lebih lanjut tentang cara mengonfigurasi alert, lihat Manajemen alert ACK.

Solusi

• Periksa data pemantauan node untuk melihat kurva penggunaan disk. Hal ini membantu Anda mengidentifikasi kapan penggunaan melonjak dan menentukan apakah ada proses yang mengonsumsi ruang disk berlebihan. Untuk informasi lebih lanjut, lihat Periksa data pemantauan node.

• Hapus file yang tidak diperlukan dari disk untuk membebaskan ruang. Untuk instruksinya, lihat Selesaikan masalah "no space left" pada Linux.

• Berdasarkan kebutuhan workload Anda, atur permintaan dan batas sumber daya untukephemeral-storage dalam spesifikasi Pod Anda. Untuk informasi lebih lanjut, lihat Atur batas sumber daya CPU dan memori untuk kontainer.

• Gunakan layanan penyimpanan Alibaba Cloud alih-alih volume hostPath. Untuk informasi lebih lanjut, lihat Penyimpanan.

• Tingkatkan ukuran disk node.

• Kurangi beban node. Untuk informasi lebih lanjut, lihat Sumber daya node tidak mencukupi untuk penjadwalan.

Penyebab

Masalah ini terjadi ketika jumlah kontainer yang berlebihan di node menghabiskan alamat IP yang tersedia.

Gejala

• Pod gagal dimulai dan terjebak dalam status ContainerCreating. Log Pod menunjukkan pesan error yang berisi kata kunci InvalidVSwitchId.IpNotEnough. Untuk informasi lebih lanjut tentang cara melihat log Pod, lihat Troubleshoot pengecualian Pod.

  time="2020-03-17T07:03:40Z" level=warning msg="Assign private ip address failed: Aliyun API Error: RequestId: 2095E971-E473-4BA0-853F-0C41CF52651D Status Code: 403 Code: InvalidVSwitchId.IpNotEnough Message: The specified VSwitch \"vsw-AAA\" has not enough IpAddress., retrying"

• Jika Anda mengonfigurasi alert untuk kluster Anda, Anda akan menerima alert ketika node kehabisan alamat IP. Untuk informasi lebih lanjut tentang cara mengonfigurasi alert, lihat Manajemen alert ACK.

Solusi

Kurangi jumlah kontainer di node. Untuk informasi lebih lanjut, lihat Sumber daya node tidak mencukupi untuk penjadwalan. Untuk solusi terkait lainnya, lihat Alamat IP VSwitch tidak mencukupi di lingkungan jaringan TerwayApa yang harus dilakukan jika VSwitch menyediakan alamat IP yang tidak mencukupi di kluster Terway dan Saya telah memperluas Blok CIDR VSwitch dalam mode Terway tetapi masih tidak dapat mengalokasikan IP Pod. Apa yang harus saya lakukan?.

Penyebab

Masalah ini biasanya disebabkan oleh status node yang tidak normal, konfigurasi security group yang salah, atau beban jaringan tinggi.

Gejala

• Anda tidak dapat login ke node.

• Status node adalah Unknown.

• Jika Anda mengonfigurasi alert untuk pengecualian node kluster, Anda akan menerima alert ketika utilisasi bandwidth Internet outbound node mencapai 85% atau lebih. Untuk informasi lebih lanjut, lihat Manajemen alert ACK.

Solusi

• Jika Anda tidak dapat login ke node, ikuti langkah-langkah berikut:

  • Periksa apakah instans node berada dalam status Running.

  • Periksa konfigurasi security group node. Untuk informasi lebih lanjut, lihat Periksa security group node.

• Jika beban jaringan node tinggi, ikuti langkah-langkah berikut:

  • Periksa kurva penggunaan jaringan node dalam data pemantauan untuk mengidentifikasi Pod yang mengonsumsi bandwidth jaringan berlebihan. Untuk informasi lebih lanjut, lihat Periksa data pemantauan node.

  • Gunakan kebijakan jaringan untuk mengontrol trafik Pod. Untuk informasi lebih lanjut, lihat Kebijakan jaringan di kluster ACK.

Penyebab

Masalah ini biasanya disebabkan oleh beban node yang tidak normal.

Gejala

• Saat node sedang restart, statusnya adalah NotReady.

• Jika Anda mengonfigurasi alert untuk pengecualian node kluster, Anda akan menerima alert ketika node restart secara tidak terduga. Untuk informasi lebih lanjut, lihat Manajemen alert ACK.

Solusi

1. Jalankan perintah berikut untuk memeriksa waktu restart node.

   last reboot

   Output yang diharapkan:

   [root@iZoj203tgmxxx /root]
   #last reboot
   reboot   system boot  xxx  Tue Mar 22 06:26 - 11:49 (1+05:22)
   reboot   system boot  xxx  Fri Oct 15 05:27 - 11:49 (159+06:22)
   wtmp begins Fri Oct 15 05:27:03 2021

2. Periksa data pemantauan node dan selidiki anomali sumber daya berdasarkan waktu restart. Untuk informasi lebih lanjut, lihat Periksa data pemantauan node.

3. Periksa log kernel node dan cari log error yang sesuai dengan waktu restart. Untuk informasi lebih lanjut, lihat Kumpulkan log diagnostik node.

Penyebab

Secara default, beberapa node yang ada di kluster dikonfigurasi dengan aturan auditd yang memantau operasi Docker. Ketika node ini menggunakan runtime kontainer Docker, aturan tersebut memicu sistem untuk mencatat log audit untuk aktivitas terkait Docker. Dalam kondisi tertentu, seperti restart kontainer yang sering, aplikasi yang menulis volume file besar dalam waktu singkat, atau bug kernel, sistem dapat menghasilkan jumlah log audit yang berlebihan. Hal ini kadang-kadang menyebabkan I/O disk tinggi dari proses auditd atau error audit: backlog limit exceeded dalam log sistem.

Gejala

Masalah ini hanya memengaruhi node yang menggunakan runtime kontainer Docker. Node yang terpengaruh mungkin menunjukkan gejala berikut:

• Ketika Anda menjalankan perintah iotop -o -d 1, output menunjukkan bahwa nilai DISK WRITE untuk proses auditd secara konsisten tetap pada 1 MB/detik atau lebih tinggi.

• Ketika Anda menjalankan perintah dmesg -d, output berisi log dengan kata kunci audit_printk_skb, seperti audit_printk_skb: 100 callbacks suppressed.

• Ketika Anda menjalankan perintah dmesg -d, output berisi kata kunci audit: backlog limit exceeded.

Solusi

Ikuti langkah-langkah berikut untuk memverifikasi bahwa konfigurasi auditd adalah penyebabnya:

1. Login ke node kluster.

2. Jalankan perintah berikut untuk memeriksa aturan audit.

   sudo auditctl -l | grep -- ' -k docker'

   Jika output berisi baris berikut, konfigurasi auditd adalah penyebabnya.

   -w /var/lib/docker -k docker

Jika pemeriksaan mengonfirmasi bahwa masalah ini memengaruhi node kluster Anda, pilih salah satu solusi berikut.

• Tingkatkan kluster

  Tingkatkan kluster Anda untuk memperbaiki masalah ini. Untuk informasi lebih lanjut, lihat Tingkatkan kluster secara manual.

• Gunakan runtime kontainer containerd

  Untuk kluster yang tidak dapat Anda tingkatkan, Anda dapat mengatasi masalah ini dengan mengubah runtime kontainer node dari Docker ke containerd. Lakukan langkah-langkah berikut untuk setiap kelompok node yang menggunakan runtime kontainer Docker:

  1. Buat kelompok node baru yang menggunakan containerd dengan mengkloning kelompok node yang ada. Konfigurasi kelompok node baru harus identik dengan aslinya, kecuali untuk runtime kontainer.

  2. Selama jam sepi, drain node di kelompok node asli satu per satu.

• Perbarui konfigurasi auditd di node

  Jika Anda tidak dapat meningkatkan kluster atau beralih ke containerd, atasi masalah ini dengan memperbarui konfigurasi auditd secara manual di setiap node yang terpengaruh.

  1. Login ke node yang terpengaruh.

  2. Jalankan perintah berikut untuk menghapus aturan audit terkait Docker.

     sudo test -f /etc/audit/rules.d/audit.rules && sudo sed -i.bak '/ -k docker/d' /etc/audit/rules.d/audit.rules
     sudo test -f /etc/audit/audit.rules && sudo sed -i.bak '/ -k docker/d' /etc/audit/audit.rules

  3. Jalankan perintah berikut untuk menerapkan aturan audit baru.

     if service auditd status |grep running || systemctl status auditd |grep running; then
         sudo service auditd restart || sudo systemctl restart auditd
         sudo service auditd status || sudo systemctl status auditd
     fi