Topik ini menjelaskan masalah umum dan solusi terkait volume disk.
Navigasi FAQ
Kategori | Masalah |
Pembuatan | |
Pemasangan | |
Penggunaan | |
Ekspansi | |
Pelepasan | |
Lainnya |
Pembuatan
Mengapa sistem memberi peringatan "InvalidDataDiskCatagory.NotSupported" ketika saya membuat PV yang di-provision secara dinamis?
Masalah
Anda gagal membuat PV yang di-provision secara dinamis, dan sistem menghasilkan event persistent volume claim (PVC): InvalidDataDiskCategory.NotSupported.
Penyebab
Zona tidak mendukung kategori disk yang ditentukan dalam StorageClass yang digunakan untuk membuat volume persisten (PV), atau disk dari kategori yang ditentukan tidak tersedia dalam jumlah cukup di zona tersebut.
Solusi
Tingkatkan plug-in Container Storage Interface (CSI) dan gunakan StorageClass alicloud-disk-topology-alltype untuk membuat PV. Anda juga dapat merujuk ke Gunakan volume disk yang di-provision secara dinamis untuk membuat StorageClass kustom dan tentukan beberapa kategori disk dalam StorageClass.
Tambahkan node di zona baru ke kluster. Untuk informasi lebih lanjut, lihat Konfigurasi yang direkomendasikan untuk ketersediaan tinggi volume disk.
Mengapa sistem memberi peringatan "The specified AZone inventory is insufficient" ketika saya membuat PV yang di-provision secara dinamis?
Masalah
Anda gagal membuat PV yang di-provision secara dinamis, dan sistem menghasilkan event PVC: The specified AZone inventory is insufficient.
Penyebab
Sistem gagal membuat disk karena disk tidak tersedia dalam jumlah cukup di zona yang ditentukan.
Solusi
Tingkatkan plug-in Container Storage Interface (CSI) dan gunakan StorageClass alicloud-disk-topology-alltype untuk membuat PV. Anda juga dapat merujuk ke Gunakan volume disk yang di-provision secara dinamis untuk membuat StorageClass kustom dan tentukan beberapa kategori disk dalam StorageClass.
Tambahkan node di zona baru ke kluster. Untuk informasi lebih lanjut, lihat Konfigurasi yang direkomendasikan untuk ketersediaan tinggi volume disk.
Mengapa sistem memberi peringatan "disk size is not supported" ketika saya membuat PV yang di-provision secara dinamis?
Masalah
Upaya Anda untuk memprovision PV secara dinamis gagal, dan sistem menghasilkan event PVC: disk size is not supported.
Penyebab
Ukuran disk yang ditentukan dalam PVC tidak valid. Batas ukuran disk minimum bervariasi berdasarkan kategori disk. Untuk informasi lebih lanjut, lihat Kategori disk.
Solusi
Ubah ukuran disk yang ditentukan dalam PVC agar memenuhi persyaratan.
Mengapa sistem memberi peringatan "waiting for first consumer to be created before binding" ketika saya membuat PV yang di-provision secara dinamis?
Masalah
Anda gagal membuat PV dengan menggunakan StorageClass dalam mode WaitForFirstConsumer, dan sistem menghasilkan event PVC: persistentvolume-controller waiting for first consumer to be created before binding.
Penyebab
PVC yang relevan tidak mengetahui node ke mana pod aplikasi dijadwalkan.
Parameter
nodeNameditentukan dalam file YAML aplikasi yang menggunakan PVC yang relevan. Dalam hal ini, penjadwalan pod melewati scheduler. Akibatnya, PVC tidak mengetahui node ke mana pod aplikasi dijadwalkan. Oleh karena itu, Anda tidak dapat menggunakan StorageClass dalam mode WaitForFirstConsumer untuk memprovision PV secara dinamis untuk aplikasi yang memiliki parameternodeNameyang ditentukan.PVC yang relevan tidak digunakan oleh pod.
Solusi
Hapus parameter
nodeNamedari file YAML aplikasi dan gunakan metode penjadwalan lainnya.Buat pod dan tentukan PVC dalam konfigurasi pod.
Mengapa sistem memberi peringatan "no topology key found on CSINode node-XXXX" ketika saya membuat PV yang di-provision secara dinamis?
Masalah
Anda gagal membuat PV yang di-provision secara dinamis, dan sistem menghasilkan event PVC: no topology key found on CSINode node-XXXX.
Penyebab
Penyebab 1: Plug-in CSI pada node XXXX gagal memulai.
Penyebab 2: Driver yang digunakan oleh volume tidak didukung. Secara default, hanya disk, File Storage NAS (NAS) file system, dan Object Storage Service (OSS) bucket yang didukung.
Solusi
Periksa status pod:
kubectl get pods -n kube-system -o wide | grep node-XXXXJika pod dalam keadaan abnormal, jalankan perintah
kubectl logs csi-plugin-xxxx -nkube-system -c csi-pluginuntuk mencetak log kesalahan. Dalam sebagian besar kasus, log kesalahan menunjukkan bahwa port node sedang digunakan. Dalam skenario ini, lakukan langkah-langkah berikut:Hentikan proses yang menggunakan port tersebut.
Jalankan perintah berikut untuk menambahkan parameter lingkungan
SERVICE_PORTke plug-in CSI untuk menggunakan port lain:kubectl set env -n kube-system daemonset/csi-plugin --containers="csi-plugin" SERVICE_PORT="XXX"
Jika pod dalam keadaan normal, lanjutkan ke langkah berikutnya.
Pasang volume yang menggunakan driver yang didukung, seperti disk, file system NAS, atau OSS bucket. Untuk detailnya, lihat topik terkait.
Mengapa sistem memberi peringatan "selfLink was empty, can't make reference" ketika saya membuat PV yang di-provision secara dinamis?
Masalah
Anda gagal membuat PV, dan sistem menghasilkan event PVC: selfLink was empty, can't make reference.
Penyebab
Versi Kubernetes kluster tidak sesuai dengan versi CSI.
Kluster menggunakan FlexVolume.
Solusi
Perbarui versi CSI. Pastikan versi plug-in volume sesuai dengan versi Kubernetes kluster. Misalnya, jika versi Kubernetes kluster Anda adalah 1.20, instal CSI 1.20 atau yang lebih baru.
Jika kluster Anda menggunakan FlexVolume, lihat Gunakan csi-compatible-controller untuk migrasi dari FlexVolume ke CSI untuk migrasi dari FlexVolume ke CSI.
PV yang di-provision secara dinamis gagal untuk PVC yang meminta kurang dari 20 GiB
Penyebab
Masalah ini terjadi karena jenis cloud disk yang berbeda memiliki persyaratan ukuran minimum yang berbeda. StorageClass default yang disediakan oleh Container Service for Kubernetes (ACK) (seperti alicloud-disk-topology-alltype dan alicloud-disk-essd) dikonfigurasi untuk menyediakan cloud disk ESSD PL1, yang memiliki kapasitas minimum 20 GiB. Akibatnya, setiap PVC yang meminta kurang dari jumlah tersebut akan gagal.
Solusi
Untuk menyediakan volume yang lebih kecil dari 20 GiB, buat StorageClass kustom. Dalam StorageClass baru ini, tentukan jenis cloud disk yang mendukung kapasitas yang lebih kecil, seperti ESSD AutoPL atau ESSD PL0.
Untuk instruksi tentang cara membuat dan menggunakan StorageClass kustom, lihat Gunakan volume disk yang di-provision secara dinamis.
Untuk meninjau rentang kapasitas untuk jenis cloud disk yang berbeda, lihat Performa penyimpanan blok.
Pemasangan
Mengapa sistem memberi peringatan "had volume node affinity conflict" ketika saya memulai pod yang memiliki disk terpasang?
Masalah
Anda gagal memulai pod yang memiliki disk terpasang dan sistem menghasilkan event pod: had volume node affinity conflict.
Penyebab
Anda menetapkan atribut nodeaffinity dalam konfigurasi PV ke nilai yang berbeda dari atribut nodeaffinity dalam konfigurasi pod. Oleh karena itu, pod tidak dapat dijadwalkan ke node yang sesuai. Setiap PV memiliki atribut nodeaffinity.
Solusi
Ubah atribut nodeaffinity dari PV atau pod untuk memastikan bahwa PV dan pod menggunakan nilai nodeaffinity yang sama.
Mengapa sistem memberi peringatan "can't find disk" ketika saya memulai pod yang memiliki disk terpasang?
Masalah
Anda gagal memulai pod yang memiliki disk terpasang dan sistem memberi peringatan can't find disk.
Penyebab
Anda memasukkan nilai yang tidak valid untuk parameter DiskID saat mengonfigurasi PV atau menetapkan parameter DiskID ke nilai yang sesuai dengan disk di wilayah selain wilayah tempat pod diterapkan.
Akun Anda tidak memiliki izin untuk mengelola disk. Disk yang Anda tentukan mungkin tidak termasuk dalam akun saat ini.
Solusi
Jika disk dipasang sebagai volume yang di-provision secara statis, pastikan disk memenuhi persyaratan berikut:
Disk berada di wilayah tempat pod diterapkan.
ID disk yang ditentukan valid.
Disk termasuk dalam Akun Alibaba Cloud yang sama dengan kluster.
Jika disk dipasang sebagai volume yang di-provision secara dinamis, pastikan izin plug-in CSI yang digunakan oleh kluster memenuhi persyaratan berikut:
Periksa apakah Addon Token ada di kluster.
Jika Addon Token ada di kluster, perbarui plug-in CSI ke versi terbaru dan coba lagi.
Jika Addon Token tidak ada di kluster, plug-in CSI menggunakan Pasangan Kunci Akses kustom yang dibuat untuk Peran RAM yang ditugaskan ke node pekerja. Anda harus memeriksa kebijakan RAM yang dilampirkan ke Peran RAM tersebut.
Mengapa sistem memberi peringatan "Previous attach action is still in process" ketika saya memulai pod yang memiliki disk terpasang?
Masalah
Sistem memberi peringatan Previous attach action is still in process ketika Anda memulai pod yang memiliki disk terpasang. Pod dimulai setelah beberapa detik.
Penyebab
Anda tidak dapat memasang beberapa disk ke instance ECS pada saat yang bersamaan. Ketika beberapa pod yang memiliki disk terpasang dijadwalkan ke instance ECS, hanya satu disk yang dapat dipasang pada satu waktu. Jika sistem memberi peringatan "Previous attach action is still in process", disk sedang dipasang pada node ini.
Solusi
Tidak diperlukan tindakan apa pun. Sistem akan otomatis mencoba kembali hingga pod dimulai.
Mengapa sistem memberi peringatan "InvalidInstanceType.NotSupportDiskCategory" ketika saya memulai pod yang memiliki disk terpasang?
Masalah
Anda gagal memulai pod yang memiliki disk terpasang dan sistem memberi peringatan InvalidInstanceType.NotSupportDiskCategory.
Penyebab
Kategori disk tidak didukung oleh tipe instance ECS yang menjadi host pod.
Solusi
Anda dapat menggunakan metode berikut untuk menyelesaikan masalah ini:
Pastikan pod dijadwalkan ke instance ECS yang tipe instansnya mendukung kategori disk yang dipasang ke pod.
Jika tipe instans semua instance ECS dalam kluster tidak mendukung kategori disk yang dipasang ke pod, ubah kategori disk dan coba lagi.
Untuk informasi lebih lanjut tentang aturan pencocokan antara kategori disk dan tipe instans ECS, lihat Ikhtisar keluarga instans.
Mengapa sistem memberi peringatan "diskplugin.csi.alibabacloud.com not found" dalam daftar driver CSI terdaftar ketika saya memulai pod yang memiliki disk terpasang?
Masalah
Peringatan berikut muncul ketika Anda memulai pod:
Warning FailedMount 98s (x9 over 3m45s) kubelet, cn-zhangjiakou.172.20.XX.XX MountVolume.MountDevice failed for volume "d-xxxxxxx" : kubernetes.io/csi: attacher.MountDevice failed to create newCsiDriverClient: driver name diskplugin.csi.alibabacloud.com not found in the list of registered CSI driversPenyebab
Peringatan ini biasanya muncul pada node yang baru ditambahkan. Sistem memulai pod CSI dan pod layanan pada saat yang bersamaan, dan membutuhkan waktu untuk mendaftarkan CSI. Oleh karena itu, pendaftaran CSI mungkin belum selesai ketika Anda memasang volume ke pod layanan. Ini mempicu peringatan.
Pendaftaran CSI gagal karena plug-in CSI tidak berjalan seperti yang diharapkan.
Solusi
Jika peringatan muncul pada node yang baru ditambahkan, tidak diperlukan tindakan apa pun. Sistem akan otomatis mencoba kembali hingga pod dimulai.
Jika pendaftaran CSI gagal, periksa status dan log plug-in CSI. Jika plug-in CSI berjalan seperti yang diharapkan, bergabunglah dengan grup DingTalk 35532895 untuk meminta dukungan teknis.
Mengapa sistem memberi peringatan "Multi-Attach error for volume" ketika saya memulai pod yang memiliki disk terpasang?
Masalah
Anda gagal memulai pod yang memiliki disk terpasang dan sistem menghasilkan event pod: warning failedAttachVolume xxx xxx Multi-Attach error for volume "xxx". Setelah Anda menjalankan perintah kubectl describe pvc <pvc-name>, output menunjukkan bahwa beberapa pod menggunakan PVC yang sama.
Penyebab
Penyebab 1: Jika disk memiliki fitur multi-attach dinonaktifkan, disk hanya dapat dipasang ke satu pod. Anda tidak dapat memasang disk ke beberapa pod.
Penyebab 2: Pod yang menggunakan PVC dihapus, tetapi disk yang sesuai dengan PVC tetap ada. Masuk ke Konsol ECS dan lihat node tempat disk yang sesuai dengan PVC dipasang. Cetak log pod csi-plugin pada node tersebut. Log tersebut berisi
Path is mounted, no remove: /var/lib/kubelet/plugins/kubernetes.io/csi/diskplugin.csi.alibabacloud.com/xxx/globalmount. Pada saat yang sama, jalankan perintah berikut untuk memeriksa apakah jalur host dari/var/rundipasang ke komponen csi-plugin:kubectl get ds -n kube-system csi-plugin -ojsonpath='{.spec.template.spec.volumes[?(@.hostPath.path=="/var/run/")]}'Jika output tidak kosong, jalur host dari /var/run dipasang ke plug-in CSI dan masalah terjadi.
Solusi
Solusi untuk Penyebab 1:
Pastikan bahwa PVC hanya digunakan oleh satu pod.
Solusi untuk Penyebab 2:
Jalankan skrip berikut untuk memperbaiki file YAML csi-plugin secara manual. Masalah akan diselesaikan setelah perbaikan.
kubectl patch -n kube-system daemonset csi-plugin -p '
spec:
template:
spec:
containers:
- name: csi-plugin
volumeMounts:
- mountPath: /host/var/run/efc
name: efc-metrics-dir
- mountPath: /host/var/run/ossfs
name: ossfs-metrics-dir
- mountPath: /host/var/run/
$patch: delete
volumes:
- name: ossfs-metrics-dir
hostPath:
path: /var/run/ossfs
type: DirectoryOrCreate
- name: efc-metrics-dir
hostPath:
path: /var/run/efc
type: DirectoryOrCreate
- name: fuse-metrics-dir
$patch: delete'Mengapa sistem memberi peringatan "Unable to attach or mount volumes: unmounted volumes=[xxx], unattached volumes=[xxx]: timed out waiting for the condition" ketika saya memulai pod yang menggunakan volume disk?
Masalah
Anda gagal memulai pod yang menggunakan volume disk dan sistem menghasilkan event pod: Unable to attach or mount volumes: unmounted volumes=[xxx], unattached volumes=[xxx]: timed out waiting for the condition.
Penyebab
Event pod sebelumnya dihasilkan oleh kubelet. Kubelet secara berkala memeriksa status volume yang digunakan oleh pod pada node kluster. Jika volume tidak siap, kubelet menghasilkan event tersebut.
Event ini hanya menunjukkan bahwa volume belum dipasang ke pod pada titik waktu tertentu karena salah satu penyebab berikut:
Penyebab 1: Terjadi kesalahan pemasangan dan kesalahan tersebut belum terselesaikan untuk jangka waktu yang lama. Akibatnya, event tersebut ditimpa oleh event lain. Anda hanya dapat melihat event yang sama yang dihasilkan oleh kubelet.
Penyebab 2: Kesalahan timeout terjadi ketika kubelet mendapatkan
configmmap/serviceaccount defaulttoken. Kesalahan ini disebabkan oleh jaringan node. Pilih node lain dan coba lagi.Penyebab 3: Jika parameter
securityContext.fsGroupdikonfigurasikan dalam templat pod, kepemilikan file dalam volume disk secara otomatis disesuaikan selama proses pemasangan. Waktu persiapan mungkin lama dan bergantung pada jumlah file.Penyebab 4: Jika volume disk di-provision secara statis, periksa apakah nilai bidang
drivervolume disk valid. Misalnya, periksa apakah nilai tersebut mengandung kesalahan ejaan. Jika nilainya tidak valid, kubelet mungkin gagal menemukan bidangdriver. Akibatnya, volume disk tidak siap.
Solusi
Solusi untuk Penyebab 1: Hapus pod dan tunggu sistem untuk membuat ulang pod. Kemudian, temukan event yang sesuai dengan kesalahan dan lacak penyebabnya berdasarkan isi event.
Solusi untuk Penyebab 2: Jadwalkan pod ke node lain. Untuk informasi lebih lanjut, lihat Jadwalkan pod aplikasi ke node yang ditentukan.
Solusi untuk Penyebab 3: Untuk kluster yang menjalankan Kubernetes versi 1.20 atau lebih baru, Anda dapat menyetel parameter
fsGroupChangePolicykeOnRootMismatch, yang secara otomatis menyesuaikan kepemilikan file hanya pada boot pertama. Waktu pemasangan kembali normal dalam skenario berikutnya seperti peningkatan pod dan pembuatan ulang. Untuk informasi lebih lanjut tentang parameterfsGroupChangePolicy, lihat Konfigurasikan Konteks Keamanan untuk Pod atau Kontainer. Jika ini tidak memenuhi kebutuhan Anda, kami sarankan Anda menggunakaninitContaineruntuk menyesuaikan izin berdasarkan kebutuhan bisnis Anda.Solusi untuk Penyebab 4: Tetapkan nama driver ke nilai yang valid. Contoh:
diskplugin.csi.alibabacloud.com
nasplugin.csi.alibabacloud.com
ossplugin.csi.alibabacloud.com
Mengapa sistem memberi peringatan "validate error Device /dev/nvme1n1 has error format more than one digit locations" ketika saya memulai pod yang memiliki disk terpasang?
Masalah
Anda gagal memulai pod yang menggunakan volume disk dan sistem memberi peringatan validate error Device /dev/nvme1n1 has error format more than one digit locations.
Penyebab
Tipe instans g7se, r7se, c7se, atau instans ECS generasi ke-8 digunakan dalam kluster Anda, dan versi kluster atau plug-in CSI yang digunakan oleh kluster Anda tidak mendukung disk Non-Volatile Memory Express (NVMe).
Solusi
Perbarui kluster Anda ke versi 1.20 atau lebih baru dan perbarui versi plug-in CSI yang digunakan oleh kluster Anda ke versi 1.22.9-30eb0ee5-aliyun atau lebih baru. Untuk informasi lebih lanjut tentang cara memperbarui plug-in, lihat Kelola komponen.
Plug-in FlexVolume tidak didukung. Bergabunglah dengan grup DingTalk 35532895 untuk mendapatkan bantuan migrasi dari FlexVolume ke CSI.
Mengapa sistem memberi peringatan "ecs task is conflicted" ketika saya memulai pod yang memiliki disk terpasang?
Masalah
Anda gagal memulai pod yang memiliki disk terpasang dan sistem menghasilkan event pod: ecs task is conflicted.
Penyebab
Tugas ECS tertentu harus dieksekusi satu per satu. Jika beberapa permintaan diterima oleh instance ECS pada saat yang bersamaan, konflik mungkin terjadi di antara tugas-tugas ECS.
Solusi
Gunakan salah satu solusi berikut ini:
Tunggu plug-in CSI mencoba kembali provisioning volume secara otomatis. Setelah tugas ECS yang bertentangan dieksekusi, plug-in CSI secara otomatis akan memasang disk ke pod.
Mengapa sistem memberi peringatan "wrong fs type, bad option, bad superblock on /dev/xxxxx missing codepage or helper program, or other error" ketika saya memulai pod yang memiliki disk terpasang?
Masalah
Anda gagal memulai pod yang memiliki disk terpasang dan sistem menghasilkan event pod berikut:
wrong fs type, bad option, bad superblock on /dev/xxxxx missing codepage or helper program, or other errorPenyebab
Sistem file disk rusak.
Solusi
Dalam sebagian besar kasus, masalah ini terjadi karena disk dilepas dengan tidak benar. Lakukan langkah-langkah berikut untuk menyelesaikan masalah:
Periksa apakah disk memenuhi persyaratan.
Pastikan disk hanya dipasang ke satu pod.
Pastikan tidak ada data yang ditulis ke disk saat Anda melepas disk.
Masuk ke host pod dan jalankan perintah
fsck -y /dev/xxxxxuntuk memperbaiki sistem file disk.Kesalahan
/dev/xxxxxsesuai dengan event pod. Sistem juga memulihkan metadata sistem file saat memperbaiki sistem file disk. Jika perbaikan gagal, sistem file disk sepenuhnya rusak dan tidak dapat digunakan lagi.
Mengapa sistem memberi peringatan "exceed max volume count" ketika saya memulai pod yang memiliki disk terpasang?
Masalah
Setelah Anda memulai pod yang memiliki disk terpasang, pod tetap dalam keadaan Pending untuk waktu yang lama. Akibatnya, pod tidak dapat dijadwalkan. Tipe instans ECS dari node menunjukkan bahwa lebih banyak volume disk dapat dipasang ke node. Event pod berikut dihasilkan:
0/1 nodes are available: 1 node(s) exceed max volume count.Penyebab
Penjadwalan pod dibatasi oleh variabel lingkungan MAX_VOLUMES_PERNODE.
Solusi
csi-plugin 1.26.4-e3de357-aliyun dan yang lebih baru dapat secara otomatis menentukan jumlah volume disk yang dipasang. Anda dapat menjalankan perintah berikut untuk menghapus variabel lingkungan
MAX_VOLUMES_PERNODEdalam DaemonSet csi-plugin di namespace kube-system. Kemudian, Anda dapat menentukan jumlah volume disk yang akan dipasang berdasarkan tipe instans ECS.kubectl patch -n kube-system daemonset csi-plugin -p ' spec: template: spec: containers: - name: csi-plugin env: - name: MAX_VOLUMES_PERNODE $patch: delete'Dalam csi-plugin yang versinya lebih lama dari 1.26.4-e3de357-aliyun, Anda hanya dapat menyetel variabel lingkungan untuk menentukan jumlah volume disk yang dipasang. Dalam hal ini, atur variabel lingkungan ke jumlah disk data paling sedikit yang dapat dipasang ke node di kluster.
Variabel lingkungan MAX_VOLUMES_PERNODE hanya dikonfigurasi secara otomatis ketika pod csi-plugin dimulai. Jika Anda secara manual memasang disk data ke node atau melepas disk, buat ulang pod csi-plugin pada node untuk memicu csi-plugin mengonfigurasi variabel lingkungan MAX_VOLUMES_PERNODE secara otomatis.
Konfigurasi MAX_VOLUMES_PERNODE tidak mendukung volume disk yang di-provision secara statis. Jika kluster Anda menggunakan volume disk yang di-provision secara statis, jumlah pod yang dapat dijadwalkan berkurang.
Mengapa sistem memberi peringatan "The amount of the disk on instance in question reach its limits" ketika saya memulai pod yang memiliki disk terpasang?
Masalah
Setelah Anda memulai pod yang memiliki disk terpasang, pod tetap dalam keadaan ContainerCreating untuk waktu yang lama. Event pod berikut dihasilkan:
MountVolume.MountDevice failed for volume "d-xxxx" : rpc error: code = Aborted desc = NodeStageVolume: Attach volume: d-xxxx with error: rpc error: code = Internal desc = SDK.ServerError
ErrorCode: InstanceDiskLimitExceeded
Message: The amount of the disk on instance in question reach its limitsPenyebab
Nilai variabel lingkungan MAX_VOLUMES_PERNODE terlalu besar.
Solusi
csi-plugin 1.26.4-e3de357-aliyun dan yang lebih baru dapat secara otomatis menentukan jumlah volume disk yang dipasang. Anda dapat menjalankan perintah berikut untuk menghapus variabel lingkungan
MAX_VOLUMES_PERNODEdalam DaemonSet csi-plugin di namespace kube-system. Kemudian, Anda dapat menentukan jumlah volume disk yang akan dipasang berdasarkan tipe instans ECS.kubectl patch -n kube-system daemonset csi-plugin -p ' spec: template: spec: containers: - name: csi-plugin env: - name: MAX_VOLUMES_PERNODE $patch: delete'Dalam csi-plugin yang versinya lebih lama dari 1.26.4-e3de357-aliyun, Anda hanya dapat menyetel variabel lingkungan untuk menentukan jumlah volume disk yang dipasang. Dalam hal ini, atur variabel lingkungan ke jumlah disk data paling sedikit yang dapat dipasang ke node di kluster.
Variabel lingkungan MAX_VOLUMES_PERNODE hanya dikonfigurasi secara otomatis ketika pod csi-plugin dimulai. Jika Anda secara manual memasang disk data ke node atau melepas disk, buat ulang pod csi-plugin pada node untuk memicu csi-plugin mengonfigurasi variabel lingkungan MAX_VOLUMES_PERNODE secara otomatis.
Konfigurasi MAX_VOLUMES_PERNODE tidak mendukung volume disk yang di-provision secara statis. Jika kluster Anda menggunakan volume disk yang di-provision secara statis, jumlah pod yang dapat dijadwalkan berkurang.
Bagaimana cara mengubah konfigurasi StorageClass default untuk cloud disk?
StorageClass default tidak dapat diubah.
Setelah menginstal csi-provisioner, StorageClass seperti alicloud-disk-topology-alltype dibuat secara otomatis. Jangan ubah StorageClass default ini. Untuk menyesuaikan konfigurasi (misalnya, jenis volume, kebijakan pengambilan), buat StorageClass baru (jumlah tak terbatas diperbolehkan). Untuk instruksi, lihat Buat StorageClass.
Dapatkah saya menggunakan volume disk yang sama untuk beberapa aplikasi kontainer?
Cloud disk adalah penyimpanan non-shared. Disk tanpa fitur multi-attach yang diaktifkan hanya dapat dipasang oleh satu pod. Untuk detail multi-attach, lihat Menggunakan multi-attach NVMe cloud disk dan Reservasi.
Penggunaan
Mengapa sistem memberi peringatan "input/output error" ketika aplikasi melakukan operasi baca/tulis pada direktori pemasangan volume disk?
Masalah
Anda berhasil menjalankan aplikasi dengan disk terpasang, tetapi sistem memberikan peringatan input/output error tidak lama setelah aplikasi diluncurkan.
Penyebab
Disk yang dipasang ke aplikasi hilang.
Solusi
Periksa status disk dan selesaikan masalah tersebut.
Identifikasi PVC yang digunakan untuk memasang disk berdasarkan direktori pemasangan dan parameter
VolumeMountdalam konfigurasi pod aplikasi.Jalankan perintah
kubectl get pvc <pvc-name>untuk memeriksa status PVC. Catat nama PV yang di-provision menggunakan PVC.Temukan file YAML PV berdasarkan nama dan catat ID disk dalam parameter
pv.VolumeHandle.Masuk ke Konsol ECS dan periksa status disk berdasarkan ID disk.
Jika disk berstatus Available, maka disk telah dilepas. Anda dapat memulai ulang pod untuk memasang kembali disk.
CatatanJika pod berstatus Running, disk pernah dipasang lalu dilepas. Dalam hal ini, disk mungkin digunakan oleh beberapa pod. Anda dapat menjalankan perintah
kubectl describe pvc <pvc-name>untuk memeriksa apakah PVC dirujuk oleh beberapa pod berdasarkan kontenUsedBy.Jika disk tidak ditemukan, disk telah dilepaskan dan tidak dapat dipulihkan lagi.
PentingSaat memasang Enterprise SSD (ESSD) ke aplikasi, kami menyarankan untuk mengaktifkan fitur instant access (IA) snapshot guna memastikan keamanan data untuk volume disk. Untuk informasi lebih lanjut, lihat bagian Kehilangan data akibat penghapusan ESSD secara tidak sengaja dari topik "Praktik terbaik untuk keamanan data volume disk".
Bagaimana cara menetapkan izin akses pengguna untuk direktori pemasangan cloud disk?
Cloud disk tidak mendukung penyetelan izin akses pengguna secara langsung. Untuk mengelola izin pada direktori pemasangan, konfigurasikan securityContext untuk pod Anda selama pembuatan aplikasi. Untuk detailnya, lihat Konfigurasikan kebijakan izin dan perubahan kepemilikan volume untuk Pod.
Ketika securityContext.fsgroup dikonfigurasikan, ACK secara otomatis memodifikasi kepemilikan file dalam volume saat disk dipasang ke aplikasi. Waktu yang diperlukan untuk modifikasi kepemilikan bergantung pada jumlah file dalam volume, yang dapat menyebabkan waktu pemasangan lama jika terdapat banyak file. Untuk kluster yang menjalankan Kubernetes 1.20 atau lebih baru, Anda dapat menyetel parameter fsGroupChangePolicy dalam konfigurasi pod ke OnRootMismatch. Ini memastikan bahwa ACK hanya memodifikasi kepemilikan file pada saat pertama kali pod dimulai. Saat Anda memperbarui atau membuat ulang pod setelah pembuatan, proses pemasangan volume tidak melibatkan modifikasi kepemilikan. Jika solusi ini masih kurang memadai, pertimbangkan menggunakan initContainer untuk menangani perubahan izin dengan logika kustom.
Ekspansi
Apakah volume cloud disk mendukung ekspansi otomatis?
Secara default, volume cloud disk tidak diperluas secara otomatis ketika kapasitasnya habis. Untuk memperluas volume, perbarui permintaan kapasitas penyimpanan secara manual dalam PVC yang sesuai. Untuk instruksi, lihat Perbesar volume disk tanpa gangguan layanan.
Jika Anda memerlukan ekspansi otomatis, Anda dapat menentukan kebijakan menggunakan definisi sumber daya kustom (CRD). Kebijakan ini memungkinkan volume diperluas secara otomatis ketika penggunaannya melebihi ambang batas yang telah ditentukan sebelumnya. Untuk instruksi, lihat Konfigurasikan kebijakan ekspansi disk otomatis untuk mencapai ekspansi otomatis.
Jika kluster menjalankan Kubernetes versi lebih lama dari 1.16 atau persyaratan dalam Perbesar volume disk tanpa gangguan layanan tidak terpenuhi (misalnya, jenis disk adalah disk dasar), perbesar disk dan sistem filenya langsung di Konsol ECS. Operasi ini tidak memengaruhi sumber daya dalam kluster (objek PVC dan PV tetap tidak berubah).
Mengapa sistem gagal memperluas disk dan memberi peringatan "Waiting for user to (re-)start a pod to finish file system resize of volume on node"?
Masalah
Setelah meningkatkan kapasitas penyimpanan yang diminta oleh PVC, nilai parameter StorageCapacity dalam informasi status PVC tidak berubah. Selain itu, event PVC dihasilkan:
Waiting for user to (re-)start a pod to finish file system resize of volume on node.Penyebab
Ekspansi volume disk mencakup ekspansi ukuran disk dan ekspansi sistem file. Ukuran disk diperluas dengan memanggil operasi ResizeDisk. Kesalahan ini menunjukkan bahwa ukuran disk telah diperluas tetapi sistem file gagal diperluas. Kegagalan ekspansi sistem file disebabkan oleh masalah terkait node.
Solusi
Periksa jenis node.
Jika node diterapkan pada instance kontainer elastis, jalankan perintah
kubectl get configmap -n kube-system eci-profile -o jsonpath="{.data.enablePVCController}"dan pastikan nilai parameter enablePVCController adalahtrue. Untuk informasi lebih lanjut, lihat konfigurasikan eci-profile. Jika masalah tetap ada, ajukan tiket.Jika node adalah instance ECS, jalankan perintah
kubectl get pods -n kube-system -l app=csi-plugin --field-selector=spec.nodeName=<node-name>untuk memeriksa status komponen csi-plugin yang berjalan di node.Jika komponen csi-plugin normal, bergabunglah dengan grup DingTalk 35532895.
Jika komponen csi-plugin dalam keadaan abnormal, mulai ulang pod yang menjalankan komponen csi-plugin dan coba lagi. Jika masalah tetap ada, bergabunglah dengan grup DingTalk 35532895.
Mengapa sistem gagal memperluas disk dan memberi peringatan "only dynamically provisioned pvc can be resized and the storageclass that provisions the pvc must support resize"?
Masalah
Setelah meningkatkan kapasitas penyimpanan yang diminta oleh PVC, kesalahan berikut muncul:
only dynamically provisioned pvc can be resized and the storageclass that provisions the pvc must support resize Penyebab
Penyebab 1: PV yang sesuai dengan PVC di-provision secara statis dan terikat ke PVC. Parameter
storageClassNamedari PVC dibiarkan kosong atau StorageClass yang ditentukan dalam konfigurasi PVC tidak tersedia di kluster.Penyebab 2: Parameter
allowVolumeExpansiondisetel kefalsedalam StorageClass yang digunakan oleh PVC. PV tidak dapat diperluas secara dinamis.
Solusi
Solusi untuk Penyebab 1: Periksa parameter
storageClassNamedari PVC dan pastikan bahwa StorageClass yang ditentukan tersedia di kluster. Jika StorageClass yang ditentukan tidak tersedia, buat StorageClass baru berdasarkan atribut volume disk dan aturallowVolumeExpansion: truedalam StorageClass tersebut.Solusi untuk Penyebab 2: Modifikasi StorageClass yang ada atau buat StorageClass baru dengan menyetel parameter
allowVolumeExpansionketrue. Tentukan StorageClass baru dalam PVC, lalu tingkatkan kapasitas penyimpanan yang diminta oleh PVC.
Pelepasan
Mengapa sistem memberi peringatan "The specified disk is not a portable disk" ketika saya menghapus pod yang memiliki disk terpasang?
Masalah
Sistem memberikan peringatan The specified disk is not a portable disk saat Anda mencoba melepas disk.
Penyebab
Disk menggunakan metode penagihan berlangganan. Anda mungkin telah memilih opsi berlangganan untuk disk tersebut, atau secara tidak sengaja mengubah metode penagihannya menjadi berlangganan saat meningkatkan instance ECS yang terkait dengan disk ini.
Solusi
Ubah metode penagihan disk dari berlangganan menjadi bayar sesuai penggunaan.
Mengapa sistem memberi peringatan bahwa disk tidak dapat dilepas ketika saya menghapus pod yang memiliki disk terpasang dan log kubelet menemukan pod yatim piatu yang tidak dikelola oleh ACK?
Masalah
Anda gagal menghapus pod, dan kubelet menghasilkan log yang menunjukkan adanya pod yang tidak dikelola oleh ACK.
Penyebab
Ketika pod keluar secara tidak normal, titik pemasangan tidak dihapus saat sistem melepas PersistentVolume (PV). Akibatnya, sistem gagal menghapus pod. Pada versi Kubernetes sebelum 1.22, fitur pengumpulan sampah kubelet untuk volume data belum matang. Anda perlu menjalankan skrip secara manual untuk menghapus titik pemasangan yang tidak valid.
Solusi
Jalankan skrip berikut pada node yang bermasalah untuk menghapus titik pemasangan yang tidak valid:
wget https://raw.githubusercontent.com/AliyunContainerService/kubernetes-issues-solution/master/kubelet/kubelet.sh
sh kubelet.shApa yang harus saya lakukan jika sistem gagal merecreate pod yang dihapus dan memberi peringatan bahwa pemasangan gagal?
Masalah
Pod yang dihapus tidak dapat dibuat ulang, dan sistem memberikan peringatan kesalahan berikut yang tidak dapat diperbaiki secara otomatis.
Warning FailedMount 9m53s (x23 over 40m) kubelet MountVolume.SetUp failed for volume "xxxxx" : rpc error: code = Internal desc = stat /var/lib/kubelet/plugins/kubernetes.io/csi/pv/xxxxx/globalmount: no such file or directoryMasalah ini terjadi jika kondisi berikut terpenuhi:
Versi Kubernetes kluster Anda adalah 1.20.4-aliyun-1.
Disk dipasang ke aplikasi.
Aplikasi diterapkan menggunakan StatefulSet dengan pengaturan
podManagementPolicy: "Parallel".
Penyebab
Untuk informasi lebih lanjut, lihat Pod gagal memulai setelah restart cepat.
Solusi
Tambahkan node baru ke kluster dan hapus semua node asli. Pod akan dibuat ulang secara otomatis. Untuk informasi lebih lanjut, lihat Buat dan kelola node pool dan Hapus node.
Atur StatefulSet ke
orderedreadyatau hapus pengaturanpodManagementPolicy: "Parallel".Jika kluster berisi sejumlah kecil node, gunakan solusi berikut:
Tambahkan label
cordonke node tempat pod diterapkan untuk menetapkan node sebagai tidak dapat dijadwalkan.Hapus pod dan tunggu hingga status pod berubah menjadi Pending.
Hapus label
cordondari node dan tunggu pod untuk memulai ulang.
Jika kluster berisi sejumlah besar node, jadwalkan pod ke node lain. Kemudian, pod dapat dibuat ulang.
Mengapa sistem memberi peringatan "target is busy" ketika saya menghapus pod yang memiliki disk terpasang?
Masalah
Kesalahan berikut ditampilkan dalam event pod atau log kubelet (/var/log/messages) saat Anda menghapus pod yang memiliki disk terpasang:
unmount failed, output <mount-path> target is busyPenyebab
Disk yang dipasang ke pod sedang digunakan. Masuk ke host tempat pod berjalan dan cari proses yang menggunakan disk tersebut.
Solusi
Cari disk dalam jalur pemasangan:
mount | grep <mount-path> /dev/vdtest <mount-path>Cari ID proses yang menggunakan disk:
fuser -m /dev/vdtestHentikan proses tersebut.
Setelah proses dihentikan, disk akan dilepas secara otomatis.
Mengapa disk tetap ada setelah saya menghapus PVC yang digunakan untuk memasang disk?
Masalah
Setelah Anda menghapus PVC yang digunakan untuk memasang disk, disk tetap ada di Konsol ECS.
Penyebab
Penyebab 1: Parameter
reclaimPolicydari StorageClass yang digunakan untuk memasang PV disetel keRetain. Dalam hal ini, CSI mempertahankan PV dan disk yang relevan setelah Anda menghapus PVC. Anda harus menghapus PV dan disk secara manual.Penyebab 2: PVC dan PV dihapus pada saat yang bersamaan atau PV dihapus sebelum PVC dihapus.
Solusi
Solusi untuk Penyebab 1: Jika parameter
reclaimPolicydari StorageClass yang digunakan untuk memasang PV disetel keRetain, CSI mempertahankan PV dan disk yang relevan setelah Anda menghapus PVC. Anda harus menghapus PV dan disk secara manual.Solusi untuk Penyebab 2: Jika anotasi
deleteTimestampditambahkan ke PV, CSI tidak akan mengambil kembali disk. Untuk informasi lebih lanjut, lihat controller. Untuk menghapus disk, hapus hanya PVC. Kemudian, PV yang terikat ke PVC dihapus secara otomatis.
Mengapa PVC masih ada setelah saya menghapusnya?
Masalah
Anda gagal menghapus PVC di kluster dengan menjalankan perintah --force.
Penyebab
Pod dalam kluster masih menggunakan PVC. finalizer dari PVC tidak dapat dihapus.
Solusi
Jalankan perintah berikut untuk memeriksa pod yang menggunakan PVC:
kubectl describe pvc <pvc-name> -n kube-systemKonfirmasikan bahwa pod tidak lagi digunakan. Hapus pod dan coba hapus PVC lagi.
Lainnya
Dapatkah saya mengonversi disk yang digunakan sebagai PV ke model penagihan berlangganan?
Tidak, Anda tidak dapat melakukannya. Disk yang digunakan sebagai PV harus menggunakan model penagihan bayar sesuai penggunaan dan tidak dapat dikonversi ke model penagihan berlangganan.
Bagaimana cara mengidentifikasi disk untuk PV di Konsol ECS?
Untuk mengidentifikasi disk yang terkait dengan PV di Konsol ECS, pertama-tama temukan ID disknya (berformat d-********). Selanjutnya, cari ID disk tersebut di halaman Block Storage di Konsol ECS untuk menemukan disk yang sesuai.
Secara default, nama PV yang di-provision secara dinamis sama dengan ID disknya. Nama PV dapat ditemukan di halaman di Konsol ACK.
Jika nama PV tidak sesuai dengan ID disk, Anda dapat menemukan ID disk dengan memeriksa definisi YAML PV. Jalankan perintah berikut:
kubectl get pv <pv-name> -o yamlDalam output, nilai bidang
volumeHandleadalah ID disk.