全部产品
Search
文档中心

Container Service for Kubernetes:FAQ Volume Disk

更新时间:Sep 04, 2025

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

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

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 nodeName ditentukan 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 parameter nodeName yang ditentukan.

  • PVC yang relevan tidak digunakan oleh pod.

Solusi

  • Hapus parameter nodeName dari 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

  1. Periksa status pod:

    kubectl get pods -n kube-system -o wide | grep node-XXXX
    • Jika pod dalam keadaan abnormal, jalankan perintah kubectl logs csi-plugin-xxxx -nkube-system -c csi-plugin untuk 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_PORT ke 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.

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

  1. Versi Kubernetes kluster tidak sesuai dengan versi CSI.

  2. Kluster menggunakan FlexVolume.

Solusi

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

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

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.

Catatan

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 drivers

Penyebab

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

  2. Pendaftaran CSI gagal karena plug-in CSI tidak berjalan seperti yang diharapkan.

Solusi

  1. Jika peringatan muncul pada node yang baru ditambahkan, tidak diperlukan tindakan apa pun. Sistem akan otomatis mencoba kembali hingga pod dimulai.

  2. 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/run dipasang 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.fsGroup dikonfigurasikan 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 driver volume disk valid. Misalnya, periksa apakah nilai tersebut mengandung kesalahan ejaan. Jika nilainya tidak valid, kubelet mungkin gagal menemukan bidang driver. 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 fsGroupChangePolicy ke OnRootMismatch, 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 parameter fsGroupChangePolicy, lihat Konfigurasikan Konteks Keamanan untuk Pod atau Kontainer. Jika ini tidak memenuhi kebutuhan Anda, kami sarankan Anda menggunakan initContainer untuk 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.

Catatan

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.

  • Aktifkan pemasangan disk paralel.

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 error

Penyebab

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:

  1. Periksa apakah disk memenuhi persyaratan.

    • Pastikan disk hanya dipasang ke satu pod.

    • Pastikan tidak ada data yang ditulis ke disk saat Anda melepas disk.

  2. Masuk ke host pod dan jalankan perintah fsck -y /dev/xxxxx untuk memperbaiki sistem file disk.

    Kesalahan /dev/xxxxx sesuai 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_PERNODE dalam 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.

Penting
  • 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 limits

Penyebab

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_PERNODE dalam 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.

Penting
  • 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.

  1. Identifikasi PVC yang digunakan untuk memasang disk berdasarkan direktori pemasangan dan parameter VolumeMount dalam konfigurasi pod aplikasi.

  2. Jalankan perintah kubectl get pvc <pvc-name> untuk memeriksa status PVC. Catat nama PV yang di-provision menggunakan PVC.

  3. Temukan file YAML PV berdasarkan nama dan catat ID disk dalam parameter pv.VolumeHandle.

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

      Catatan

      Jika 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 konten UsedBy.

    • Jika disk tidak ditemukan, disk telah dilepaskan dan tidak dapat dipulihkan lagi.

      Penting

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

Catatan

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.

Catatan

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 adalah true. 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 storageClassName dari PVC dibiarkan kosong atau StorageClass yang ditentukan dalam konfigurasi PVC tidak tersedia di kluster.

  • Penyebab 2: Parameter allowVolumeExpansion disetel ke false dalam StorageClass yang digunakan oleh PVC. PV tidak dapat diperluas secara dinamis.

Solusi

  • Solusi untuk Penyebab 1: Periksa parameter storageClassName dari PVC dan pastikan bahwa StorageClass yang ditentukan tersedia di kluster. Jika StorageClass yang ditentukan tidak tersedia, buat StorageClass baru berdasarkan atribut volume disk dan atur allowVolumeExpansion: true dalam StorageClass tersebut.

  • Solusi untuk Penyebab 2: Modifikasi StorageClass yang ada atau buat StorageClass baru dengan menyetel parameter allowVolumeExpansion ke true. 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.sh

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

Masalah 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 orderedready atau hapus pengaturan podManagementPolicy: "Parallel".

  • Jika kluster berisi sejumlah kecil node, gunakan solusi berikut:

    1. Tambahkan label cordon ke node tempat pod diterapkan untuk menetapkan node sebagai tidak dapat dijadwalkan.

    2. Hapus pod dan tunggu hingga status pod berubah menjadi Pending.

    3. Hapus label cordon dari 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 busy

Penyebab

Disk yang dipasang ke pod sedang digunakan. Masuk ke host tempat pod berjalan dan cari proses yang menggunakan disk tersebut.

Solusi

  1. Cari disk dalam jalur pemasangan:

    mount | grep <mount-path>
    /dev/vdtest <mount-path>
  2. Cari ID proses yang menggunakan disk:

    fuser -m /dev/vdtest
  3. Hentikan 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 reclaimPolicy dari StorageClass yang digunakan untuk memasang PV disetel ke Retain. 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 reclaimPolicy dari StorageClass yang digunakan untuk memasang PV disetel ke Retain, 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 deleteTimestamp ditambahkan 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

  1. Jalankan perintah berikut untuk memeriksa pod yang menggunakan PVC:

    kubectl describe pvc <pvc-name> -n kube-system
  2. Konfirmasikan 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 Volumes > Persistent Volumes 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 yaml

    Dalam output, nilai bidang volumeHandle adalah ID disk.