Container Service for Kubernetes:Mengelola komponen csi-plugin dan csi-provisioner

Kegagalan startup: exec /usr/bin/plugin.csi.alibabacloud.com: exec format error

Gejala

Kontainer csi-plugin dalam Pod csi-plugin gagal memulai, dan log menampilkan error: exec /usr/bin/plugin.csi.alibabacloud.com: exec format error.

Penyebab

Error ini biasanya menunjukkan ketidakcocokan arsitektur CPU. Namun, csi-plugin secara default mendukung arsitektur amd64 dan arm64. Oleh karena itu, jika error ini muncul pada node yang didukung, kemungkinan besar disebabkan oleh file image CSI yang rusak.

Hal ini dapat terjadi jika proses pull image terganggu, misalnya akibat shutdown paksa. Akibatnya, file image yang tidak lengkap tersisa di node. Meskipun metadata imagenya ada, file binary executable-nya tidak valid atau rusak, sehingga mencegah kontainer csi-plugin memulai.

Solusi

• Tambahkan node baru (scale out), lalu drain node bermasalah tersebut.

• Jika Anda harus mempertahankan node saat ini, lakukan langkah-langkah berikut:

  1. Drain node untuk mengeluarkan beban kerjanya, lalu hapus node tersebut dari kluster.

  2. Masuk ke node dan hapus semua kontainer, jika ada.

  3. Hapus semua file dari direktori /var/lib/containerd.

  4. Tambahkan kembali node ke kluster.

Masalah OOM komponen penyimpanan

Kontainer sidecar dalam pod komponen csi-provisioner menyimpan cache informasi sumber daya seperti pod, PV, dan PVC. Di kluster berskala besar, hal ini dapat mengonsumsi memori dalam jumlah signifikan dan menyebabkan kontainer mengalami error Out-of-Memory (OOM).

• csi-provisioner terkelola: Submit a ticket untuk bantuan.

• csi-provisioner tidak terkelola: Jika terjadi error OOM, sesuaikan batas sumber daya berdasarkan ukuran kluster Anda.

  1. Pada halaman Clusters, klik nama kluster Anda. Di panel navigasi kiri, klik Components and Add-ons.

  2. Temukan komponen csi-provisioner, klik ikon , lalu klik View in YAML.

  3. Edit YAML komponen untuk menyesuaikan batas sumber daya sesuai ukuran kluster Anda.

     containers:
         - name: external-disk-provisioner
           image: registry-vpc.cn-huhexxxx.yuncs.com/acs/csi-provisioner:v3.0.0-080f01e64-aliyun
           resources:
             requests:
               cpu: 10m
               memory: 16Mi
             limits:
               cpu: 500m
               memory: 1024Mi

Trafik jaringan tinggi pada csi-plugin

Gejala

Di dasbor pemantauan pod kluster, pod komponen csi-plugin menunjukkan trafik jaringan tinggi.

Penyebab

Ini merupakan perilaku yang diharapkan. Komponen csi-plugin mengelola pemasangan volume penyimpanan NAS pada node. Saat pod aplikasi membaca atau menulis data melalui titik mount NAS, trafik jaringan yang dihasilkan melewati namespace jaringan pod csi-plugin. Oleh karena itu, sistem pemantauan mengatribusikan trafik ini ke pod csi-plugin.

Solusi

Tidak perlu tindakan apa pun; Anda dapat mengabaikan hal ini dengan aman. Trafik tersebut hanya diatribusikan ke pod csi-plugin untuk keperluan pencatatan dan tidak benar-benar mengonsumsi sumber dayanya, juga tidak menyebabkan trafik ganda atau tagihan berulang. Ini merupakan artefak pemantauan yang tidak memengaruhi kinerja.

Log komponen csi-provisioner melaporkan error failed to renew lease xxx timed out waiting for the condition

Gejala

Jalankan perintah kubectl logs csi-provisioner-xxxx -n kube-system untuk melihat log CSI. Error failed to renew lease xxx timed out waiting for the condition dilaporkan.

Penyebab

Komponen csi-provisioner menggunakan model multi-replika untuk ketersediaan tinggi. Untuk memastikan hanya satu instance yang melayani permintaan pada satu waktu, replika-replika tersebut menggunakan mekanisme Lease Kubernetes untuk pemilihan leader. Mekanisme ini sangat bergantung pada komunikasi stabil dengan API server.

Error ini menunjukkan bahwa csi-provisioner tidak dapat mengakses API server, sehingga proses pemilihan leader gagal. Akibatnya, tidak ada replika yang dapat menjadi leader dan memberikan layanan.

Solusi

Periksa konektivitas jaringan kluster dan status API server. Jika masalah berlanjut, submit a ticket untuk bantuan.

Kegagalan pemeriksaan pra-peningkatan csi-plugin

kubectl -nkube-system get ds csi-plugin flexvolume

NAME         DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR            AGE
csi-plugin   4         4         4       4            4           kubernetes.io/os=linux   7d
flexvolume   4         4         4       4            4           kubernetes.io/os=linux   7d                                  

Peningkatan csi-plugin gagal setelah pemeriksaan awal

Komponen csi-plugin dideploy sebagai DaemonSet, yang mengharuskan semua node berada dalam kondisi sehat. Peningkatan akan gagal jika kluster memiliki node dalam status NotReady atau tidak dalam status Running.

Anda harus memperbaiki node yang bermasalah terlebih dahulu, lalu coba lagi peningkatannya. Jika Anda tidak dapat mengidentifikasi penyebabnya, hubungi kami untuk meminta peningkatan manual berbantuan.

csi-provisioner tidak muncul di konsol

Versi csi-provisioner yang lebih lama (1.14 dan sebelumnya) dideploy sebagai StatefulSet. Jika instance StatefulSet csi-provisioner masih ada di kluster saat ini, Anda harus menghapusnya secara manual (kubectl delete sts csi-provisioner) sebelum menginstal ulang.

Jika Anda mengalami masalah selama operasi ini, hubungi kami untuk meminta peningkatan manual berbantuan.

Kegagalan pemeriksaan pra-peningkatan csi-provisioner

kubectl -nkube-system get ds csi-plugin flexvolume

NAME         DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR            AGE
csi-plugin   4         4         4       4            4           kubernetes.io/os=linux   7d
flexvolume   4         4         4       4            4           kubernetes.io/os=linux   7d                                  

Peningkatan csi-provisioner gagal setelah pemeriksaan awal

Hubungi kami untuk meminta peningkatan manual berbantuan.

Kegagalan peningkatan csi-provisioner: Jumlah node atau izin

Gejala

• Skenario 1: Pemeriksaan pra-peningkatan komponen csi-provisioner gagal, menunjukkan bahwa kluster tidak memiliki cukup node.

• Skenario 2: Pemeriksaan awal dan peningkatan komponen csi-provisioner berhasil. Namun, Pod komponen masuk ke status CrashLoopBackOff, dan log menampilkan error 403 Forbidden.

  time="2023-08-05T13:54:00+08:00" level=info msg="Use node id : <?xml version=\"1.0\" encoding=\"iso-8859-1\"?>\n<!DOCTYPE html PUBLIC \"-//W3C//DTD XHTML 1.0 Transitional//EN\"\n         \"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd\">\n<html xmlns=\"http://www.w3.org/1999/xhtml\" xml:lang=\"en\" lang=\"en\">\n <head>\n  <title>403 - Forbidden</title>\n </head>\n <body>\n  <h1>403 - Forbidden</h1>\n </body>\n</html>\n"

Penyebab dan solusi

• Skenario 1

  • Penyebab: Komponen csi-provisioner menggunakan model penyebaran aktif-standby, dan dua replikanya harus dijadwalkan ke node yang berbeda untuk memenuhi persyaratan anti-affinity. Kluster dengan satu node tidak dapat memenuhi kondisi penjadwalan ini, sehingga replika kedua tetap dalam status Pending dan mencegah peningkatan selesai dengan sukses.

  • Solusi: Tambahkan setidaknya satu node lagi ke kluster untuk memastikan replika ganda dapat dijadwalkan dengan benar.

• Skenario 2

  • Penyebab: Komponen csi-provisioner harus mengakses instance metadata node untuk mendapatkan informasi seperti ID instans dan wilayah, yang diperlukan untuk memanggil API Alibaba Cloud. Jika penguatan keamanan diaktifkan pada node atau kebijakan jaringan yang ketat dikonfigurasi, akses ke layanan metadata mungkin diblokir.

  • Solusi: Sesuaikan atau nonaktifkan kebijakan penguatan keamanan pada node untuk memastikan pod dapat mengakses layanan metadata. Periksa juga aturan grup keamanan, pengaturan firewall OS, dan skrip keamanan terkait.

Kegagalan peningkatan csi-provisioner: Modifikasi StorageClass

Gejala

Instalasi atau peningkatan csi-provisioner gagal dalam pemeriksaan awal, menunjukkan bahwa properti StorageClass tidak sesuai harapan.

Penyebab

StorageClass default yang disediakan oleh ACK memiliki konfigurasi tetap, dan bidang intinya, seperti provisioner dan parameters, tidak dapat diubah. Menghapus dan membuat ulang StorageClass secara manual dengan nama yang sama akan menyebabkan kegagalan validasi dan mengganggu proses peningkatan komponen.

Installer CSI memvalidasi integritas sumber daya ini secara ketat untuk memastikan perilaku komponen yang konsisten.

Solusi

1. Hapus objek StorageClass default dari kluster, termasuk alicloud-disk-essd, alicloud-disk-available, alicloud-disk-efficiency, alicloud-disk-ssd, dan alicloud-disk-topology.

   Operasi ini tidak memengaruhi penggunaan normal PV dan PVC yang sudah ada.

2. Setelah Anda menghapus objek StorageClass tersebut, instal ulang csi-provisioner. Installer akan secara otomatis membuat ulang objek StorageClass tersebut. Tidak diperlukan tindakan tambahan.

Jika Anda memerlukan StorageClass kustom, selalu buat yang baru dengan nama berbeda. Jangan ubah atau buat ulang objek StorageClass default.