全部产品
Search

搜索本产品

    Container Service for Kubernetes：Memecahkan masalah pengecualian node

    文档中心

    Container Service for Kubernetes：Memecahkan masalah pengecualian node

    更新时间：Aug 31, 2025

    Topik ini menjelaskan prosedur diagnosis untuk node dan cara memecahkan masalah pengecualian node. Topik ini juga memberikan jawaban atas beberapa pertanyaan yang sering diajukan (FAQ) tentang node.

    Daftar isi

    Kategori

    Konten

    Prosedur diagnosis

    Prosedur diagnosis

    Metode pemecahan masalah umum

    Masalah umum dan solusi

    Prosedur diagnosis

    1. Periksa apakah sebuah node abnormal. Untuk informasi lebih lanjut, lihat bagian Periksa status node.

    2. Jika masalah tetap ada setelah Anda melakukan operasi sebelumnya, gunakan fitur diagnosis yang disediakan oleh Container Service for Kubernetes (ACK) untuk memecahkan masalah tersebut. Untuk informasi lebih lanjut, lihat bagian Gunakan fitur diagnosis node.

    Metode pemecahan masalah umum

    Gunakan fitur diagnosis node

    Jika terjadi pengecualian pada node, Anda dapat menggunakan fitur diagnosis yang disediakan oleh ACK untuk memecahkan pengecualian tersebut.

    1. Masuk ke Konsol ACK. Di panel navigasi di sebelah kiri, klik Clusters.

    2. Di halaman Clusters, klik nama kluster yang ingin diubah. Di panel navigasi di sebelah kiri, pilih Nodes > Nodes.

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

    4. Di panel yang muncul, klik Create diagnosis, lalu lihat hasil diagnosis dan saran perbaikan yang sesuai di halaman konsol.

    Periksa detail node

    1. Masuk ke Konsol ACK. Di panel navigasi di sebelah kiri, klik Clusters.

    2. Di halaman Clusters, klik nama kluster yang ingin diubah. Di panel navigasi di sebelah kiri, pilih Nodes > Nodes.

    3. Di halaman Nodes, temukan node yang ingin diperiksa dan klik nama node atau klik Details di kolom Actions.

    Periksa status node

    1. Masuk ke Konsol ACK. Di panel navigasi di sebelah kiri, klik Clusters.

    2. Di halaman Clusters, klik nama kluster yang ingin diubah. Di panel navigasi di sebelah kiri, pilih Nodes > Nodes.

    3. Di halaman Nodes, lihat status setiap node.

      • Jika node berada dalam status Ready, maka node tersebut beroperasi dengan normal.

      • Jika sebuah node tidak berada dalam keadaan Ready, Anda dapat mengklik nama node atau klik Details di kolom Actions node untuk melihat detail node.

        Catatan

        Jika Anda ingin mengumpulkan informasi tentang kondisi node seperti InodesPressure, DockerOffline, dan RuntimeOffline, Anda harus menginstal node-problem-detector di kluster Anda dan membuat pusat event. Fitur pusat event secara otomatis diaktifkan saat Anda membuat kluster. Untuk informasi lebih lanjut, lihat Buat dan gunakan pusat event.

    Periksa event node

    1. Masuk ke Konsol ACK. Di panel navigasi di sebelah kiri, klik Clusters.

    2. Di halaman Clusters, klik nama kluster yang ingin diubah. Di panel navigasi di sebelah kiri, pilih Nodes > Nodes.

    3. Di halaman Nodes, temukan node target dan klik nama node atau klik Details di kolom Actions.

      Di bagian bawah halaman detail node, Anda dapat melihat event yang terkait dengan node.

    Kumpulkan log diagnostik node

    Periksa komponen utama node

    • kubelet:

      • Periksa status kubelet

        Masuk ke node tempat kubelet berjalan dan jalankan perintah berikut untuk memeriksa status proses kubelet:

        systemctl status kubelet

        Output yang diharapkan:

        image

      • Periksa log kubelet

        Masuk ke node tempat kubelet berjalan dan jalankan perintah berikut untuk mencetak log kubelet: Untuk informasi lebih lanjut tentang cara memeriksa log kubelet, lihat bagian Kumpulkan log diagnostik node.

        journalctl -u kubelet

      • Periksa konfigurasi kubelet

        Masuk ke node tempat kubelet berjalan dan jalankan perintah berikut untuk memeriksa konfigurasi kubelet:

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

    • Runtime:

      • Periksa dockerd

        • Periksa status dockerd

          Masuk ke node tempat dockerd berjalan dan jalankan perintah berikut untuk memeriksa status proses dockerd:

          systemctl status docker

          Output yang diharapkan:

          Docker

        • Periksa log dockerd

          Masuk ke node tempat dockerd berjalan dan jalankan perintah berikut untuk mencetak log dockerd: Untuk informasi lebih lanjut tentang cara memeriksa log dockerd, lihat bagian Kumpulkan log diagnostik node.

          journalctl -u docker

        • Periksa konfigurasi dockerd

          Masuk ke node tempat dockerd berjalan dan jalankan perintah berikut untuk memeriksa konfigurasi dockerd:

          cat /etc/docker/daemon.json

      • Periksa containerd

        • Periksa status containerd

          Masuk ke node tempat containerd berjalan dan jalankan perintah berikut untuk memeriksa status proses containerd:

          systemctl status containerd

          Output yang diharapkan:

          image

        • Periksa log containerd

          Masuk ke node tempat containerd berjalan dan jalankan perintah berikut untuk mencetak log containerd: Untuk informasi lebih lanjut tentang cara memeriksa log containerd, lihat bagian Kumpulkan log diagnostik node.

          journalctl -u containerd

    • NTP:

      • Periksa status layanan NTP

        Masuk ke node tempat layanan NTP berjalan dan jalankan perintah berikut untuk memeriksa status proses chronyd:

        systemctl status chronyd

        Output yang diharapkan:

        image

      • Periksa log layanan NTP

        Masuk ke node tempat layanan NTP berjalan dan jalankan perintah berikut untuk mencetak log layanan NTP:

        journalctl -u chronyd

    Periksa data pemantauan node

    • CloudMonitor

      ACK terintegrasi dengan CloudMonitor. Anda dapat masuk ke Konsol CloudMonitor untuk melihat data pemantauan Instance ECS yang diterapkan di kluster ACK Anda. Untuk informasi lebih lanjut tentang cara memantau node, lihat Pantau node.

    • Managed Service for Prometheus

      1. Masuk ke Konsol ACK. Di panel navigasi di sebelah kiri, klik Clusters.

      2. Di halaman Clusters, temukan kluster yang diinginkan dan klik namanya. Di panel sisi kiri, pilih Operations > Prometheus Monitoring.

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

      4. Pada tab Nodes, pilih node dari daftar drop-down untuk melihat data pemantauan, termasuk penggunaan sumber daya CPU, memori, dan disk.

    Periksa grup keamanan node

    Untuk informasi lebih lanjut, lihat Ikhtisar dan Konfigurasikan grup keamanan untuk kluster.

    Pengecualian kubelet

    Penyebab

    Pengecualian kubelet biasanya disebabkan oleh masalah pada proses kubelet itu sendiri, runtime kontainer, atau konfigurasi kubelet yang tidak valid.

    Masalah

    Status kubelet adalah inactive.

    Solusi

    1. Jalankan perintah berikut untuk me-restart kubelet. Operasi restart tidak memengaruhi kontainer yang sedang berjalan.

      systemctl restart kubelet

    2. Setelah kubelet direstart, masuk ke node tempat kubelet berjalan dan jalankan perintah berikut untuk memeriksa apakah status kubelet normal:

      systemctl status kubelet

    3. Jika status kubelet tidak normal, jalankan perintah berikut di node untuk mencetak log kubelet:

      journalctl -u kubelet

      • Jika Anda menemukan pengecualian dalam log kubelet, pecahkan masalah berdasarkan kata kunci.

      • Jika konfigurasi kubelet tidak valid, jalankan perintah berikut untuk memodifikasi konfigurasi:

        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.

    Pengecualian dockerd - RuntimeOffline

    Penyebab

    Dalam banyak kasus, pengecualian dockerd terjadi karena konfigurasi dockerd tidak valid, proses dockerd kelebihan beban, atau node kelebihan beban.

    Masalah

    • Status dockerd adalah inactive.

    • Status dockerd adalah active (running) tetapi dockerd tidak berjalan sesuai harapan. Akibatnya, terjadi pengecualian pada node. Dalam kasus ini, Anda mungkin gagal menjalankan perintah docker ps atau docker exec.

    • Nilai kondisi node RuntimeOffline adalah True.

    • Jika Anda mengaktifkan fitur peringatan untuk node kluster, Anda dapat menerima peringatan ketika terjadi pengecualian pada node tempat dockerd berjalan. Untuk informasi lebih lanjut tentang cara mengonfigurasi aturan peringatan, lihat Manajemen Peringatan.

    Solusi

    1. Jalankan perintah berikut untuk me-restart dockerd:

      systemctl restart docker

    2. Setelah dockerd direstart, masuk ke node dan jalankan perintah berikut untuk memeriksa apakah status dockerd normal:

      systemctl status docker

    3. Jika status dockerd tidak normal, jalankan perintah berikut di node untuk mencetak log dockerd:

      journalctl -u docker

    Pengecualian containerd - RuntimeOffline

    Penyebab

    Dalam banyak kasus, pengecualian containerd terjadi karena konfigurasi containerd tidak valid, proses containerd kelebihan beban, atau node kelebihan beban.

    • Status containerd adalah inactive.

    • Nilai kondisi node RuntimeOffline adalah True.

    • Jika Anda mengaktifkan fitur peringatan untuk node kluster, Anda dapat menerima peringatan ketika terjadi pengecualian pada node tempat containerd berjalan. Untuk informasi lebih lanjut tentang cara mengonfigurasi aturan peringatan, lihat Manajemen Peringatan.

    Solusi

    1. Jalankan perintah berikut untuk me-restart containerd:

      systemctl restart containerd

    2. Setelah containerd direstart, masuk ke node dan jalankan perintah berikut untuk memeriksa apakah status containerd normal:

      systemctl status containerd

    3. Jika status containerd tidak normal, jalankan perintah berikut di node untuk mencetak log containerd:

      journalctl -u containerd

    Pengecualian NTP - NTPProblem

    Penyebab

    Dalam banyak kasus, pengecualian NTP terjadi karena status proses NTP tidak normal.

    Masalah

    • Status chronyd adalah inactive.

    • Nilai kondisi node NTPProblem adalah True.

    • Jika Anda mengaktifkan fitur peringatan untuk node kluster, Anda dapat menerima peringatan ketika terjadi pengecualian pada node tempat layanan NTP berjalan. Untuk informasi lebih lanjut tentang cara mengonfigurasi aturan peringatan, lihat Manajemen Peringatan.

    Solusi

    1. Jalankan perintah berikut untuk me-restart chronyd:

      systemctl restart chronyd

    2. Setelah chronyd direstart, masuk ke node dan jalankan perintah berikut untuk memeriksa apakah status chronyd normal:

      systemctl status chronyd

    3. Jika status chronyd tidak normal, jalankan perintah berikut di node untuk mencetak log chronyd:

      journalctl -u chronyd

    Pengecualian PLEG - PLEG tidak sehat

    Penyebab

    Pod Lifecycle Event Generator (PLEG) mencatat semua event yang terjadi selama siklus hidup pod, seperti event yang terkait dengan startup atau terminasi kontainer. Dalam banyak kasus, pengecualian PLEG tidak sehat terjadi karena runtime kontainer pada node tidak normal atau node menggunakan versi systemd yang lebih lama.

    Masalah

    • Status node adalah NotReady.

    • Isi berikut ada dalam log kubelet:

      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 mengaktifkan fitur peringatan untuk node kluster, Anda dapat menerima peringatan ketika terjadi pengecualian PLEG. Untuk informasi lebih lanjut tentang cara mengonfigurasi aturan peringatan, lihat Manajemen Peringatan.

    Solusi

    1. Restart komponen utama berikut di node secara berurutan: dockerd/containerd dan kubelet. Lalu, periksa apakah status node normal.

    2. Jika status node tidak normal setelah Anda me-restart komponen utama, restart node. Untuk informasi lebih lanjut, lihat Restart instance.

      Peringatan

      Operasi restart juga akan me-restart pod di node. Lakukan dengan hati-hati.

    3. Jika node abnormal menjalankan CentOS 7.6, pecahkan masalah pengecualian dengan merujuk pada Apa yang Harus Dilakukan jika Log kubelet Mengandung Kesalahan "Reason:KubeletNotReady Message:PLEG is not healthy:" Saat Menggunakan CentOS 7.6.

    Sumber daya node tidak mencukupi untuk penjadwalan

    Penyebab

    Masalah ini biasanya terjadi ketika node di kluster memiliki sumber daya yang tidak mencukupi untuk memenuhi permintaan penjadwalan pod baru.

    Masalah

    Jika sumber daya yang disediakan oleh node di kluster Anda tidak mencukupi, penjadwalan pod gagal dan salah satu kesalahan berikut dikembalikan:

    • Sumber daya CPU tidak mencukupi: 0/2 nodes are available: 2 Insufficient cpu

    • Sumber daya memori tidak mencukupi: 0/2 nodes are available: 2 Insufficient memory

    • Sumber daya penyimpanan sementara tidak mencukupi: 0/2 nodes are available: 2 Insufficient ephemeral-storage

    Penjadwal menentukan apakah sumber daya yang disediakan oleh node tidak mencukupi berdasarkan aturan berikut:

    • Sumber daya CPU tidak mencukupi: Permintaan CPU Pod > (CPU yang dapat dialokasikan oleh Node - CPU yang sudah dialokasikan oleh Node)

    • Sumber daya memori tidak mencukupi: Permintaan memori Pod > (Memori yang dapat dialokasikan oleh Node - Memori yang sudah dialokasikan oleh Node)

    • Penyimpanan sementara tidak mencukupi: Permintaan penyimpanan sementara Pod > (Penyimpanan sementara yang dapat dialokasikan oleh Node - Penyimpanan sementara yang sudah dialokasikan oleh Node)

    Jika jumlah sumber daya yang diminta oleh pod lebih besar dari selisih antara total sumber daya yang dapat dialokasikan oleh node dan jumlah sumber daya yang sudah dialokasikan dari node, pod tidak akan dijadwalkan ke node tersebut.

    Jalankan perintah berikut untuk menanyakan informasi tentang alokasi sumber daya pada node:

    kubectl describe node [$nodeName]

    Output yang diharapkan:

    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%)

    Parameter:

    • Allocatable: jumlah CPU, memori, atau penyimpanan sementara yang dapat dialokasikan oleh node.

    • Allocated resources: jumlah CPU, memori, atau penyimpanan sementara yang sudah dialokasikan dari node.

    Solusi

    Jika sumber daya yang disediakan oleh node tidak mencukupi, Anda dapat menggunakan salah satu metode berikut untuk mengurangi beban node:

    Untuk informasi lebih lanjut, lihat bagian Sumber daya CPU tidak mencukupi, Sumber daya memori tidak mencukupi - MemoryPressure, dan Ruang disk tidak mencukupi - DiskPressure.

    Sumber daya CPU tidak mencukupi

    Penyebab

    Dalam banyak kasus, sumber daya CPU yang disediakan oleh node menjadi tidak mencukupi karena kontainer di node telah menggunakan sejumlah besar sumber daya CPU.

    Masalah

    • Ketika sebuah node tidak memiliki sumber daya CPU yang cukup, status node mungkin menjadi tidak normal.

    • Jika Anda mengaktifkan fitur peringatan untuk node kluster, Anda dapat menerima peringatan ketika penggunaan CPU node mencapai atau melebihi 85%. Untuk informasi lebih lanjut tentang cara mengonfigurasi aturan peringatan, lihat Manajemen Peringatan.

    Solusi

    • Periksa kurva penggunaan CPU di tab Pemantauan Node konsol dan identifikasi waktu terjadinya lonjakan penggunaan CPU. Lalu, periksa apakah kebocoran memori terjadi pada proses yang berjalan di node. Untuk informasi lebih lanjut, lihat bagian Periksa data pemantauan node.

    • Untuk informasi lebih lanjut tentang cara mengurangi beban node, lihat bagian Sumber daya node tidak mencukupi untuk penjadwalan.

    • Restart node. Untuk informasi lebih lanjut, lihat Restart instance.

      Peringatan

      Operasi restart juga akan me-restart pod di node. Lakukan dengan hati-hati.

    Sumber daya memori tidak mencukupi - MemoryPressure

    Penyebab

    Dalam banyak kasus, sumber daya memori yang disediakan oleh node menjadi tidak mencukupi karena kontainer di node telah menggunakan sejumlah besar sumber daya memori.

    Masalah

    • Jika jumlah memori yang tersedia di node turun di bawah ambang batas memory.available, nilai kondisi node MemoryPressure berubah menjadi True. Kontainer diusir dari node. Untuk informasi lebih lanjut tentang pengusiran kontainer, lihat Node-pressure Eviction.

    • Jika node tidak memiliki sumber daya memori yang cukup, masalah berikut terjadi:

      • Nilai kondisi node MemoryPressure berubah menjadi True.

      • Kontainer diusir dari node:

        • Anda dapat menemukan informasi The node was low on resource: memory dalam event kontainer yang diusir.

        • Anda dapat menemukan informasi attempting to reclaim memory dalam event node.

      • Kesalahan out of memory (OOM) mungkin terjadi. Ketika kesalahan OOM terjadi, Anda dapat menemukan informasi System OOM dalam event node.

    • Jika Anda mengaktifkan fitur peringatan untuk node kluster, Anda dapat menerima peringatan ketika penggunaan memori node mencapai atau melebihi 85%. Untuk informasi lebih lanjut tentang cara mengonfigurasi aturan peringatan, lihat Manajemen Peringatan.

    Solusi

    • Periksa kurva penggunaan memori di tab Pemantauan Node konsol dan identifikasi waktu terjadinya lonjakan penggunaan memori. Lalu, periksa apakah kebocoran memori terjadi pada proses yang berjalan di node. Untuk informasi lebih lanjut, lihat bagian Periksa data pemantauan node.

    • Untuk informasi lebih lanjut tentang cara mengurangi beban node, lihat bagian Sumber daya node tidak mencukupi untuk penjadwalan.

    • Restart node. Untuk informasi lebih lanjut, lihat Restart instance.

      Peringatan

      Operasi restart juga akan me-restart pod di node. Lakukan dengan hati-hati.

    Inodes tidak mencukupi - InodesPressure

    Penyebab

    Dalam banyak kasus, inodes yang disediakan oleh node menjadi tidak mencukupi karena kontainer di node telah menggunakan sejumlah besar inodes.

    Masalah

    • Jika jumlah inodes yang tersedia di node turun di bawah ambang batas inodesFree, nilai kondisi node InodesPressure berubah menjadi True. Kontainer diusir dari node. Untuk informasi lebih lanjut tentang pengusiran kontainer, lihat Node-pressure Eviction.

    • Jika inodes yang disediakan oleh node menjadi tidak mencukupi, masalah berikut terjadi:

      • Nilai kondisi node InodesPressure berubah menjadi True.

      • Kontainer diusir dari node:

        • Anda dapat menemukan informasi The node was low on resource: inodes dalam event kontainer yang diusir.

        • Anda dapat menemukan informasi attempting to reclaim inodes dalam event node.

    • Jika Anda mengaktifkan fitur peringatan untuk node kluster, Anda dapat menerima peringatan ketika node tidak memiliki inodes yang cukup. Untuk informasi lebih lanjut tentang cara mengonfigurasi aturan peringatan, lihat Manajemen Peringatan.

    Solusi

    PID tidak mencukupi - NodePIDPressure

    Penyebab

    Dalam banyak kasus, ID proses (PID) yang disediakan oleh node menjadi tidak mencukupi karena kontainer di node telah menggunakan sejumlah besar PID.

    Masalah

    • Jika jumlah PID yang tersedia di node turun di bawah ambang batas pid.available, nilai kondisi node NodePIDPressure berubah menjadi True. Kontainer diusir dari node. Untuk informasi lebih lanjut tentang pengusiran kontainer, lihat Node-pressure Eviction.

    • Jika Anda mengaktifkan fitur peringatan untuk node kluster, Anda dapat menerima peringatan ketika node tidak memiliki PID yang cukup. Untuk informasi lebih lanjut tentang cara mengonfigurasi aturan peringatan, lihat Manajemen Peringatan.

    Solusi

    1. Jalankan perintah berikut untuk menanyakan jumlah maksimum PID dan nilai PID terbesar di node.

      sysctl kernel.pid_max  #Menanyakan jumlah maksimum PID. 
ps -eLf|awk '{print $2}' | sort -rn| head -n 1   #Menanyakan nilai PID terbesar.

    2. Jalankan perintah berikut untuk menanyakan lima proses teratas yang menggunakan jumlah PID paling banyak:

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

      Output yang diharapkan:

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

    3. Anda dapat menggunakan ID proses untuk menemukan proses dan pod yang sesuai, mendiagnosis masalah, dan mengoptimalkan kode.

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

    5. Restart node. Untuk informasi lebih lanjut, lihat Restart instance.

      Peringatan

      Operasi restart juga akan me-restart pod di node. Lakukan dengan hati-hati.

    Ruang disk tidak mencukupi - DiskPressure

    Penyebab

    Dalam banyak kasus, ruang disk yang disediakan oleh node menjadi tidak mencukupi karena kontainer di node telah menggunakan sejumlah besar ruang disk atau ukuran gambar kontainer terlalu besar.

    Masalah

    • Jika jumlah ruang disk yang tersedia di node turun di bawah ambang batas imagefs.available, nilai kondisi node DiskPressure berubah menjadi True.

    • Jika jumlah ruang disk yang tersedia turun di bawah ambang batas nodefs.available, semua kontainer di node diusir. Untuk informasi lebih lanjut tentang pengusiran kontainer, lihat Node-pressure Eviction.

    • Jika ruang disk node menjadi tidak mencukupi, masalah berikut terjadi:

      • Nilai kondisi node DiskPressure berubah menjadi True.

      • Jika jumlah ruang disk yang tersedia tetap lebih rendah dari ambang batas kesehatan setelah kebijakan pengumpulan gambar dipicu, Anda dapat menemukan informasi failed to garbage collect required amount of images dalam event node. Nilai default ambang batas kesehatan adalah 80%.

      • Kontainer diusir dari node:

        • Anda dapat menemukan informasi The node was low on resource: [DiskPressure] dalam event kontainer yang diusir.

        • Anda dapat menemukan informasi attempting to reclaim ephemeral-storage atau attempting to reclaim nodefs dalam event node.

    • Jika Anda mengaktifkan fitur peringatan untuk node kluster, Anda dapat menerima peringatan ketika penggunaan disk node mencapai atau melebihi 85%. Untuk informasi lebih lanjut tentang cara mengonfigurasi aturan peringatan, lihat Manajemen Peringatan.

    Solusi

    Alamat IP tidak mencukupi - InvalidVSwitchId.IpNotEnough

    Penyebab

    Dalam banyak kasus, alamat IP yang disediakan oleh node menjadi tidak mencukupi karena kontainer di node telah menggunakan sejumlah besar alamat IP.

    Masalah

    • Pod gagal dimulai. Status pod ini adalah ContainerCreating. Anda dapat menemukan informasi InvalidVSwitchId.IpNotEnough dalam log pod. Untuk informasi lebih lanjut tentang cara memeriksa log pod, lihat bagian Memecahkan masalah pod dari topik "Pemecahan Masalah Pod".

      time="2020-03-17T07:03:40Z" level=warning msg="Gagal menetapkan alamat ip privat: Error API Aliyun: RequestId: 2095E971-E473-4BA0-853F-0C41CF52651D Status Code: 403 Code: InvalidVSwitchId.IpNotEnough Message: VSwitch \"vsw-AAA\" yang ditentukan tidak memiliki cukup IpAddress., mencoba lagi"

    • Jika Anda mengaktifkan fitur peringatan untuk node kluster, Anda dapat menerima peringatan ketika node tidak dapat menyediakan alamat IP yang cukup. Untuk informasi lebih lanjut tentang cara mengonfigurasi aturan peringatan, lihat Manajemen Peringatan.

    Solusi

    Kurangi jumlah kontainer di node. Untuk informasi lebih lanjut, lihat bagian Sumber daya node tidak mencukupi untuk penjadwalan. Untuk informasi lebih lanjut tentang operasi terkait lainnya, lihat Apa yang Harus Dilakukan jika Alamat IP yang Tersedia Tidak Mencukupi Disediakan oleh vSwitch dalam Kluster yang Menggunakan Terway? dan Apa yang Harus Dilakukan jika Pod IP Masih Tidak Dapat Ditugaskan dalam Mode Jaringan Terway Setelah vSwitch Diperluas?.

    Pengecualian jaringan

    Penyebab

    Dalam banyak kasus, pengecualian jaringan terjadi karena status node tidak normal, konfigurasi grup keamanan node tidak valid, atau jaringan kelebihan beban.

    Masalah

    • Anda gagal masuk ke node.

    • Status node adalah Unknown.

    • Jika Anda mengaktifkan fitur peringatan untuk node kluster, Anda dapat menerima peringatan ketika penggunaan bandwidth Internet keluar node mencapai atau melebihi 85%. Untuk informasi lebih lanjut tentang cara mengonfigurasi aturan peringatan, lihat Manajemen Peringatan.

    Solusi

    • Jika Anda gagal masuk ke node, lakukan langkah-langkah berikut untuk memecahkan masalah:

      • Periksa apakah node berada dalam keadaan Running.

      • Periksa konfigurasi grup keamanan node. Untuk informasi lebih lanjut, lihat bagian Periksa grup keamanan node.

    • Jika jaringan node kelebihan beban, lakukan langkah-langkah berikut untuk memecahkan masalah:

    Restart node yang tidak terduga

    Penyebab

    Dalam banyak kasus, node secara tidak terduga restart karena node kelebihan beban.

    Masalah

    • Selama proses restart node, status node adalah NotReady.

    • Jika Anda mengaktifkan fitur peringatan untuk node kluster, Anda dapat menerima peringatan ketika node secara tidak terduga restart. Untuk informasi lebih lanjut tentang cara mengonfigurasi aturan peringatan, lihat Manajemen Peringatan.

    Solusi

    1. Jalankan perintah berikut untuk menanyakan waktu node direstart:

      last reboot

      Output yang diharapkan:output

    2. Periksa data pemantauan node dan pecahkan masalah penggunaan sumber daya abnormal berdasarkan waktu node direstart. Untuk informasi lebih lanjut, lihat bagian Periksa data pemantauan node.

    3. Periksa log kernel node dan pecahkan masalah berdasarkan waktu node direstart. Untuk informasi lebih lanjut, lihat bagian Kumpulkan log diagnostik node.

    Bagaimana cara menyelesaikan utilisasi I/O disk tinggi yang disebabkan oleh auditd atau pesan kesalahan berikut muncul dalam log sistem: audit: backlog limit exceeded?

    Penyebab

    Beberapa node yang ada di kluster dikonfigurasikan dengan aturan audit auditd untuk Docker secara default. Jika node menjalankan Docker, sistem akan menghasilkan log audit untuk Docker berdasarkan aturan audit auditd. Sejumlah besar log audit dapat dihasilkan ketika sejumlah besar kontainer berulang kali restart pada saat yang sama, sejumlah besar data ditulis ke dalam kontainer, atau bug kernel terjadi. Dalam kasus-kasus ini, utilisasi I/O disk dari proses auditd mungkin tinggi dan pesan kesalahan berikut mungkin muncul dalam log sistem: audit: backlog limit exceeded.

    Masalah

    Masalah ini hanya memengaruhi node yang menjalankan Docker. Situasi berikut terjadi setelah Anda menjalankan perintah tertentu di node:

    • Setelah Anda menjalankan perintah iotop -o -d 1, hasilnya menunjukkan bahwa nilai DISK WRITE tetap pada 1MB/s atau lebih tinggi.

    • Setelah Anda menjalankan perintah dmesg -d, hasilnya termasuk log yang berisi kata kunci berikut: audit_printk_skb. Contoh: audit_printk_skb: 100 callbacks suppressed.

    • Setelah Anda menjalankan perintah dmesg -d, hasilnya berisi kata kunci berikut: audit: backlog limit exceeded.

    Solusi

    Lakukan operasi berikut untuk memeriksa apakah masalah di atas disebabkan oleh aturan audit auditd:

    1. Masuk ke node.

    2. Jalankan perintah berikut untuk menanyakan aturan auditd:

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

      Jika output berikut dikembalikan, masalah tersebut disebabkan oleh aturan audit auditd.

      -w /var/lib/docker -k docker

    Untuk menyelesaikan masalah ini, gunakan salah satu solusi berikut:

    • Tingkatkan kluster

      Tingkatkan versi Kubernetes kluster. Untuk informasi lebih lanjut, lihat Tingkatkan kluster secara manual.

    • Ubah runtime kontainer menjadi containerd

      Jika versi Kubernetes kluster tidak dapat diperbarui, Anda dapat mengubah runtime kontainer menjadi containerd untuk mencegah masalah ini. Lakukan operasi berikut pada pool node yang menggunakan Docker sebagai runtime kontainer:

      1. Buat pool node baru dengan menyalin pool node yang menjalankan Docker. Pool node baru menggunakan containerd sebagai runtime kontainer. Pastikan konfigurasi pool node baru sama dengan konfigurasi pool node yang disalin kecuali untuk runtime kontainer.

      2. Keluarkan node satu per satu dari pool node yang menjalankan Docker selama jam-jam sepi hingga semua pod aplikasi diusir dari pool node.

    • Perbarui konfigurasi auditd

      Jika solusi di atas tidak berlaku, Anda dapat memperbarui konfigurasi auditd di node secara manual untuk menyelesaikan masalah ini. Lakukan operasi berikut pada node yang menggunakan Docker sebagai runtime kontainer:

      1. Masuk ke node.

      2. Jalankan perintah berikut untuk menghapus aturan auditd untuk 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 auditd 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