Container Service for Kubernetes:Troubleshoot node exceptions

Node exception diagnosis

Jika node gagal, gunakan fitur Diagnosis Exception satu klik di ACK untuk mendiagnosis exception tersebut.

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

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

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

4. Di panel yang muncul, klik Start Diagnosis. Lalu, lihat hasil diagnosis dan solusi yang direkomendasikan di konsol.

Node details

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

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

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

Node status

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

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

3. Pada halaman Nodes, lihat status node.

   • Jika node berada dalam status Ready, artinya node berjalan sesuai harapan.

   • Jika node tidak berada dalam status Ready, klik nama node atau klik Details di kolom Actions untuk melihat detail node yang abnormal.

     Catatan

     Mengumpulkan informasi tentang kondisi node seperti InodesPressure, DockerOffline, dan RuntimeOffline memerlukan node-problem-detector dan event center di kluster Anda. Event center dibuat secara default saat Anda membuat kluster. Untuk informasi lebih lanjut, lihat Buat dan gunakan event center K8s.

Node events

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

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

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

   Event node tercantum di bagian bawah halaman detail node.

Node diagnostic logs

• Gunakan fitur diagnosis node dari Container Intelligence Service di konsol untuk mengumpulkan log diagnostik. Untuk informasi lebih lanjut, lihat Diagnosis node.

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

Key node components

• Kubelet:

  • Periksa status kubelet

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

    systemctl status kubelet

    Output yang diharapkan:

    

  • Periksa log kubelet

    Login ke node dan jalankan perintah berikut untuk melihat log kubelet. Untuk informasi lebih lanjut, 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:

      

    • Periksa log dockerd

      Login ke node dan jalankan perintah berikut untuk melihat log dockerd. Untuk informasi lebih lanjut, 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:

      

    • Periksa log containerd

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

      journalctl -u containerd

• NTP:

  • Periksa status layanan NTP

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

    systemctl status chronyd

    Output yang diharapkan:

    

  • Periksa log layanan NTP

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

    journalctl -u chronyd

Node monitoring

• CloudMonitor

  Kluster ACK terintegrasi dengan CloudMonitor. Anda dapat login ke Konsol CloudMonitor untuk melihat informasi pemantauan dasar untuk instans ECS yang sesuai. Untuk informasi lebih lanjut, lihat Pantau node.

• Managed Service for Prometheus

  1. Login ke Konsol ACK. 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. Di tab Nodes, pilih node untuk melihat informasi pemantauannya, seperti penggunaan CPU, memori, dan disk.

Node security groups

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

Causes

Masalah ini biasanya disebabkan oleh masalah pada proses kubelet, kegagalan runtime kontainer, atau konfigurasi kubelet yang salah.

Symptoms

Status kubelet adalah inactive.

Resolution

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

   systemctl restart kubelet

2. Setelah kubelet di-restart, login ke node dan jalankan perintah berikut untuk memverifikasi statusnya.

   systemctl status kubelet

3. Jika status kubelet tetap abnormal setelah di-restart, login ke node dan jalankan perintah berikut untuk melihat log-nya.

   journalctl -u kubelet

   • Jika log berisi pesan error spesifik, lakukan troubleshooting berdasarkan kata kunci error tersebut.

   • Jika konfigurasi kubelet salah, jalankan perintah berikut untuk memodifikasinya dan me-restart layanan.

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

Causes

Penyebab umum meliputi konfigurasi dockerd yang salah, proses dockerd yang kelebihan beban, atau beban node yang tinggi.

Symptoms

• Layanan dockerd berstatus inactive.

• Layanan dockerd berstatus active (running) tetapi tidak berfungsi dengan benar, menyebabkan node menjadi abnormal. Perintah seperti docker ps dan docker exec juga sering gagal.

• Kondisi node RuntimeOffline bernilai True.

• Jika Anda telah mengonfigurasi alert untuk exception node di kluster Anda, Anda akan menerima alert saat terjadi kegagalan dockerd. Untuk informasi lebih lanjut tentang konfigurasi aturan alert, lihat Manajemen alert ACK.

Solution

1. Jalankan perintah berikut untuk me-restart layanan dockerd:

   systemctl restart docker

2. Setelah layanan dockerd di-restart, login ke node dan jalankan perintah berikut untuk memverifikasi statusnya:

   systemctl status docker

3. Jika layanan dockerd tetap abnormal setelah di-restart, login ke node dan jalankan perintah berikut untuk memeriksa log dockerd:

   journalctl -u docker

Causes

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

• Status containerd adalah inactive.

• Kondisi node RuntimeOffline bernilai True.

• Jika Anda telah mengonfigurasi alert untuk exception node di kluster Anda, Anda akan menerima alert saat terjadi exception containerd. Untuk informasi lebih lanjut tentang konfigurasi alert, lihat Manajemen alert ACK.

Solution

1. Jalankan perintah berikut untuk me-restart containerd.

   systemctl restart containerd

2. Setelah containerd di-restart, login ke node dan jalankan perintah berikut untuk memeriksa statusnya.

   systemctl status containerd

3. Jika status containerd masih abnormal, jalankan perintah berikut untuk melihat log-nya.

   journalctl -u containerd

Cause

Masalah ini biasanya disebabkan oleh proses NTP yang abnormal.

Symptoms

• Status chronyd adalah inactive.

• Kondisi node NTPProblem bernilai True.

• Jika Anda telah mengonfigurasi alert untuk exception node kluster, Anda akan menerima alert saat layanan waktu node abnormal. Untuk informasi tentang cara mengonfigurasi alert, lihat Manajemen alert di Container Service for Kubernetes (ACK).

Solution

1. Jalankan perintah berikut untuk me-restart chronyd:

   systemctl restart chronyd

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

   systemctl status chronyd

3. Jika status chronyd masih abnormal, login ke node dan jalankan perintah berikut untuk melihat log chronyd:

   journalctl -u chronyd

Cause

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

Symptoms

• Status node adalah NotReady.

• Log kubelet menampilkan 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 telah mengonfigurasi alert untuk exception node kluster, Anda akan menerima alert saat terjadi exception PLEG. Untuk informasi tentang cara mengonfigurasi alert, lihat Manajemen alert ACK.

Solution

1. Restart komponen utama di node secara berurutan: dockerd/containerd, lalu kubelet. Setelah restart, periksa apakah node pulih.

2. Jika node tidak pulih setelah Anda me-restart komponen utamanya, coba restart instans node. Untuk petunjuknya, lihat Restart instans.

   Peringatan

   Me-restart node dapat menyebabkan gangguan layanan. Lakukan dengan hati-hati.

3. Jika node yang terpengaruh menjalankan CentOS 7.6, lihat Apa yang harus dilakukan jika log kubelet berisi error "Reason:KubeletNotReady Message:PLEG is not healthy:" pada CentOS 7.6.

Cause

Masalah ini terjadi ketika node kluster memiliki resource yang tidak mencukupi untuk menjadwalkan pod.

Symptoms

Jika permintaan sumber daya suatu Pod melebihi sumber daya yang tersedia pada suatu node (sumber daya yang dapat dialokasikan dikurangi sumber daya yang telah dialokasikan), penjadwal tidak akan menempatkan Pod tersebut pada node tersebut.

kubectl describe node [NODE_NAME]

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

Solution

Jika resource node tidak mencukupi untuk penjadwalan, kurangi beban node atau tingkatkan kapasitas kluster dengan salah satu cara berikut:

• Kurangi beban node dengan menghapus atau menskalakan turun pod yang tidak diperlukan. Untuk informasi lebih lanjut, lihat Kelola pod.

• Sesuaikan konfigurasi resource pod Anda berdasarkan kebutuhan bisnis. Untuk informasi lebih lanjut, lihat Atur permintaan dan batas CPU serta memori kontainer.

• Tambahkan node baru ke kluster. Untuk petunjuknya, lihat Buat dan kelola kelompok node.

• Tingkatkan spesifikasi node. Untuk petunjuknya, lihat Tingkatkan atau turunkan spesifikasi node.

Untuk informasi lebih lanjut, lihat Resource CPU tidak mencukupi, Resource memori tidak mencukupi - MemoryPressure, dan Disk space tidak mencukupi - DiskPressure.

Causes

Masalah ini biasanya terjadi ketika kontainer di node mengonsumsi CPU secara berlebihan.

Symptoms

• Resource CPU yang tidak mencukupi dapat menyebabkan node menjadi tidak stabil.

• Jika Anda telah mengonfigurasi alert untuk exception node kluster, Anda akan menerima alert saat utilisasi CPU node mencapai atau melebihi 85%. Untuk informasi tentang cara mengonfigurasi alert, lihat Manajemen alert ACK.

Solution

• Tinjau kurva penggunaan CPU dalam data pemantauan node untuk menentukan kapan exception terjadi dan identifikasi proses mana di node yang mengonsumsi CPU secara berlebihan. Untuk petunjuknya, lihat Periksa data pemantauan node.

• Kurangi beban node. Untuk petunjuknya, lihat Resource node tidak mencukupi untuk penjadwalan.

• Jika perlu, restart node yang terpengaruh. Untuk petunjuknya, lihat Restart instans.

  Peringatan

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

Cause

Masalah ini biasanya terjadi ketika kontainer di node mengonsumsi memori secara berlebihan, menyebabkan kekurangan memori di node.

Symptoms

• Saat memori yang tersedia di node turun di bawah ambang batas memory.available, kondisi node MemoryPressure menjadi True dan kontainer di node tersebut dievict. Untuk informasi lebih lanjut tentang evict karena tekanan node, lihat Evict karena tekanan node.

• Saat node kekurangan memori, Anda mungkin melihat pesan dan event berikut:

  • Kondisi node MemoryPressure menjadi True.

  • Saat kontainer dievict dari node:

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

    • Event node mencakup pesan attempting to reclaim memory.

  • Hal ini dapat menyebabkan exception System OOM (Out of Memory). Saat ini terjadi, event node mencakup pesan System OOM.

• Jika Anda telah mengonfigurasi alert untuk exception node kluster, Anda akan menerima alert saat penggunaan memori node mencapai atau melebihi 85%. Untuk informasi tentang konfigurasi alert, lihat Manajemen Alert Layanan Kontainer.

Solution

• Tinjau kurva penggunaan memori dalam data pemantauan node untuk mengidentifikasi kapan masalah terjadi dan periksa apakah ada proses di node yang mengalami kebocoran memori. Untuk petunjuknya, lihat Periksa data pemantauan node.

• Kurangi beban node. Untuk petunjuknya, lihat Resource node tidak mencukupi untuk penjadwalan.

• Jika perlu, restart node yang terpengaruh. Untuk petunjuknya, lihat Restart instans.

  Peringatan

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

Cause

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

Symptoms

• Saat inode yang tersedia di node turun di bawah ambang batas inodesFree, kondisi node InodesPressure diatur menjadi True, dan sistem mengevict kontainer dari node tersebut. Untuk informasi lebih lanjut tentang evict karena tekanan node, lihat evict karena tekanan node.

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

  • Kondisi node InodesPressure bernilai True.

  • Saat kontainer dievict dari node:

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

    • Event node mencakup pesan attempting to reclaim inodes.

• Jika Anda telah mengonfigurasi alert untuk exception node kluster, Anda akan menerima alert saat node kekurangan inode. Untuk informasi lebih lanjut tentang cara mengonfigurasi alert, lihat Manajemen alert ACK.

Solution

• Tinjau kurva pertumbuhan inode dalam data pemantauan node untuk menentukan kapan exception terjadi dan periksa proses yang mengonsumsi inode secara berlebihan. Untuk petunjuknya, lihat Periksa data pemantauan node.

• Untuk troubleshooting masalah terkait lainnya, lihat Atasi masalah "no space left" di Linux.

Cause

Masalah ini biasanya terjadi ketika kontainer di node menggunakan terlalu banyak Process ID (PID), sehingga menghabiskan pasokan PID node.

Symptoms

• Saat jumlah PID yang tersedia di node turun di bawah ambang batas pid.available, kondisi NodePIDPressure diatur menjadi True, dan kubelet mengevict pod dari node. Untuk informasi lebih lanjut tentang evict node, lihat evict karena tekanan node.

• Jika Anda telah mengonfigurasi alert untuk exception node kluster, Anda akan menerima alert saat node kekurangan PID. Untuk mempelajari cara mengonfigurasi alert, lihat Manajemen alert ACK.

Solution

1. Jalankan perintah berikut untuk memeriksa batas maksimum PID dan PID tertinggi saat ini di node.

   sysctl kernel.pid_max  # Periksa batas maksimum PID.
   ps -eLf|awk '{print $2}' | sort -rn| head -n 1   # Periksa PID tertinggi saat ini.

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

   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, dan kolom kedua adalah ID proses.
   73 9743
   75 9316
   76 2812
   77 5726
   93 5691

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

4. Kurangi beban node. Untuk petunjuknya, lihat Resource node tidak mencukupi untuk penjadwalan.

5. Jika perlu, restart node yang terpengaruh. Untuk petunjuknya, lihat Restart instans.

   Peringatan

   Me-restart node dapat menyebabkan gangguan layanan. Lakukan dengan hati-hati.

Cause

Masalah ini biasanya terjadi ketika kontainer di node mengonsumsi disk space secara berlebihan atau ketika gambar kontainer besar menghabiskan penyimpanan yang tersedia.

Symptoms

• Saat disk space yang tersedia di filesystem yang digunakan runtime kontainer untuk gambar dan layer yang dapat ditulis kontainer turun di bawah ambang batas imagefs.available, kondisi node DiskPressure diatur menjadi True.

• Saat disk space yang tersedia di filesystem root node turun di bawah ambang batas nodefs.available, Pod di node tersebut dievict. Untuk informasi lebih lanjut tentang evict karena tekanan node, lihat evict karena tekanan node.

• Saat node kekurangan disk space, Anda mungkin melihat pesan error berikut:

  • Kondisi node DiskPressure diatur menjadi True.

  • Jika disk space masih di bawah ambang batas kesehatan (default 80%) setelah garbage collection gambar dipicu, muncul event node dengan pesan failed to garbage collect required amount of images.

  • Saat Pod dievict dari node:

    • Event untuk Pod yang dievict mencakup pesan The node was low on resource: [DiskPressure].

    • Event node mencakup pesan attempting to reclaim ephemeral-storage atau attempting to reclaim nodefs.

• Jika Anda telah mengonfigurasi alert untuk exception node kluster, Anda akan menerima alert saat utilisasi disk node mencapai atau melebihi 85%. Untuk informasi tentang cara mengonfigurasi alert, lihat Manajemen alert ACK.

Solution

• Tinjau data pemantauan penggunaan disk node untuk mengidentifikasi kapan exception terjadi dan proses mana yang mengonsumsi disk space secara berlebihan. Untuk petunjuknya, lihat Periksa data pemantauan node.

• Hapus file yang tidak diperlukan dari disk. Untuk petunjuknya, lihat Atasi masalah "no space left" di Linux.

• Batasi permintaan dan batas resource ephemeral-storage untuk Pod Anda berdasarkan kebutuhan bisnis. Untuk petunjuknya, lihat Atur resource CPU dan memori untuk kontainer.

• Gunakan layanan penyimpanan Alibaba Cloud dan hindari penggunaan volume hostPath bila memungkinkan. Untuk informasi lebih lanjut, lihat Penyimpanan.

• Perluas disk node.

• Kurangi beban node. Untuk petunjuknya, lihat Resource node tidak mencukupi untuk penjadwalan.

Cause

Masalah ini biasanya terjadi ketika terlalu banyak kontainer di node menghabiskan alamat IP yang tersedia.

Symptoms

• Pod gagal dimulai dan tetap dalam status ContainerCreating. Pesan error yang berisi kata kunci InvalidVSwitchId.IpNotEnough muncul di log Pod. Untuk melihat log Pod, lihat Troubleshooting 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 telah mengonfigurasi alert untuk exception node kluster, Anda akan menerima alert untuk resource IP node yang tidak mencukupi. Untuk mempelajari cara mengonfigurasi alert, lihat Manajemen alert ACK.

Solution

Kurangi jumlah kontainer di node. Untuk petunjuknya, lihat Resource node tidak mencukupi untuk penjadwalan. Untuk solusi lainnya, lihat Alamat IP tidak mencukupi dari VSwitch dalam jaringan Terway dan Troubleshoot kegagalan alokasi IP setelah memperluas VSwitch dalam mode Terway.

Causes

Penyebab umum meliputi status node yang abnormal, konfigurasi security group yang salah, atau beban jaringan yang tinggi.

Symptoms

• Anda tidak dapat login ke node.

• Status node adalah Unknown.

• Jika Anda telah mengonfigurasi alert untuk exception node kluster, alert dipicu saat penggunaan bandwidth outbound Internet node mencapai atau melebihi 85%. Untuk mempelajari cara mengonfigurasi alert, lihat Manajemen alert ACK.

Solution

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

  • Verifikasi bahwa instans node berstatus Running.

  • Periksa konfigurasi security group node. Untuk mempelajarinya, lihat Periksa security group node.

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

  • Gunakan data pemantauan node untuk melihat kurva penggunaan jaringan dan periksa pod yang mengonsumsi bandwidth jaringan secara berlebihan. Untuk mempelajarinya, lihat Periksa data pemantauan node.

  • Gunakan kebijakan jaringan untuk mengontrol lalu lintas jaringan pod. Untuk mempelajarinya, lihat Gunakan kebijakan jaringan di kluster ACK.

Cause

Node yang kelebihan beban biasanya menyebabkan masalah ini.

Symptoms

• Node memasuki status NotReady selama restart.

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

Solution

1. Jalankan perintah berikut untuk memeriksa kapan node terakhir kali di-restart.

   last reboot

   Output yang diharapkan:

2. Tinjau data pemantauan node sekitar waktu restart untuk mengidentifikasi anomali resource apa pun. Untuk informasi lebih lanjut, lihat Periksa data pemantauan node.

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

Cause

Secara default, beberapa node di kluster memiliki aturan auditd yang dikonfigurasi untuk Docker. Saat node menggunakan runtime kontainer Docker, aturan audit ini memicu sistem untuk mencatat log audit untuk operasi Docker. Dalam kasus jarang, seperti saat kontainer berulang kali restart, aplikasi menulis banyak file dalam waktu singkat, atau terjadi bug kernel, sistem dapat menghasilkan volume besar log audit. Hal ini meningkatkan disk I/O node, menyebabkan penggunaan disk I/O tinggi oleh proses auditd atau memicu error audit: backlog limit exceeded di log sistem.

Symptoms

Masalah ini hanya memengaruhi node yang menggunakan runtime kontainer Docker. Gejalanya meliputi:

• Metrik DISK WRITE untuk proses auditd konsisten 1 MB/detik atau lebih tinggi dalam output perintah iotop -o -d 1.

• Output perintah dmesg -d berisi log dengan kata kunci audit_printk_skb, seperti audit_printk_skb: 100 callbacks suppressed.

• Output perintah dmesg -d berisi kata kunci audit: backlog limit exceeded.

Solution

Untuk memeriksa apakah masalah terkait dengan konfigurasi auditd, lakukan langkah-langkah berikut:

1. Login ke node kluster.

2. Jalankan perintah berikut untuk memeriksa aturan auditd.

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

   Jika output mencakup baris berikut, masalah terkait dengan konfigurasi auditd.

   -w /var/lib/docker -k docker

Jika pemeriksaan mengonfirmasi masalah tersebut, atasi dengan salah satu solusi berikut.

• Upgrade the cluster version

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

• Use the containerd container runtime

  Sebagai solusi sementara untuk kluster yang tidak dapat ditingkatkan, ganti runtime kontainer dari Docker ke containerd. Pada setiap kelompok node yang menggunakan runtime kontainer Docker, lakukan langkah-langkah berikut:

  1. Klon kelompok node target untuk membuat kelompok node baru yang menggunakan containerd sebagai runtime kontainer. Pastikan semua konfigurasi lain dari kelompok node baru sesuai dengan aslinya.

  2. Saat jam sepi, drain node di kelompok node target satu per satu hingga kelompok node kosong.

• Update the auditd configuration on the node

  Jika Anda tidak dapat meningkatkan kluster atau menggunakan runtime kontainer containerd, perbarui secara manual konfigurasi auditd di node yang terpengaruh.

  1. Login ke node kluster.

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