全部产品
Search
文档中心

Container Service for Kubernetes:FAQ untuk volume disk

更新时间:Feb 06, 2026

Topik ini menjelaskan masalah umum dan solusinya saat menggunakan volume disk di ACK (Alibaba Cloud Container Service for Kubernetes), mencakup pembuatan, pemasangan, penggunaan, perluasan, serta pelepasan disk.

Navigasi masalah

Tipe

Masalah

Creation

Mount

Usage

Expansion

Uninstall

Others

Pembuatan disk

Gagal membuat PV secara dinamis dengan error "InvalidDataDiskCatagory.NotSupported"

Gejala

Volume persisten (PV) gagal dibuat. Event persistent volume claim (PVC) menampilkan error InvalidDataDiskCategory.NotSupported.

Penyebab

Zona saat ini tidak mendukung tipe disk yang ditentukan dalam StorageClass, atau tipe disk tersebut sedang habis stok di zona tersebut.

Solusi

Gagal membuat PV secara dinamis dengan error "The specified AZone inventory is insufficient"

Gejala

PV gagal dibuat. Event PVC menampilkan error The specified AZone inventory is insufficient.

Penyebab

Disk habis stok di zona yang ditentukan, sehingga pembuatan disk gagal.

Solusi

Gagal membuat PV secara dinamis dengan error "disk size is not supported"

Gejala

PV gagal dibuat secara dinamis. Event PVC menampilkan error disk size is not supported.

Penyebab

Kapasitas disk yang ditentukan dalam PVC tidak valid. Tipe disk yang berbeda memiliki persyaratan kapasitas minimum yang berbeda. Untuk informasi selengkapnya tentang persyaratan kapasitas disk, lihat Tipe disk.

Solusi

Sesuaikan kapasitas yang ditentukan dalam PVC agar memenuhi persyaratan.

Gagal membuat PV secara dinamis dengan error "waiting for first consumer to be created before binding"

Gejala

PV gagal dibuat saat Anda menggunakan StorageClass dengan mode WaitForFirstConsumer. Event PVC menampilkan error persistentvolume-controller waiting for first consumer to be created before binding.

Penyebab

PVC tidak mendeteksi node tempat pod dijadwalkan.

  • File YAML aplikasi secara eksplisit menentukan nodeName. Pod semacam ini melewati logika penjadwal, sehingga mencegah PVC mendeteksi node tersebut. Oleh karena itu, pod yang dijadwalkan dengan menentukan nodeName tidak dapat menggunakan StorageClass dengan mode WaitForFirstConsumer.

  • Tidak ada pod yang mereferensikan PVC saat ini.

Solusi

  • Hapus field nodeName dari file YAML aplikasi dan gunakan metode penjadwalan lain.

  • Buat pod yang menggunakan PVC tersebut.

Gagal membuat PV secara dinamis dengan error "no topology key found on CSINode node-XXXX"

Gejala

PV gagal dibuat. Event PVC menampilkan error no topology key found on CSINode node-XXXX.

Penyebab

  • csi-plugin pada node node-XXXX gagal dimulai.

  • Volume menggunakan driver yang tidak didukung sistem. Secara default, sistem mendukung Disk, NAS, dan OSS.

Solusi

  1. Periksa apakah pod berada dalam status Normal.

    kubectl get pods -n kube-system -o wide | grep node-XXXX
    • Jika statusnya abnormal, jalankan perintah kubectl logs csi-plugin-xxxx -nkube-system -c csi-plugin untuk melihat log error. Dalam kebanyakan kasus, penyebabnya adalah konflik port pada node. Anda dapat mengatasi masalah ini dengan salah satu cara berikut:

      • Hentikan proses yang menggunakan port tersebut.

      • Tambahkan variabel lingkungan SERVICE_PORT ke csi-plugin untuk menentukan port baru.

        kubectl set env -n kube-system daemonset/csi-plugin --containers="csi-plugin" SERVICE_PORT="XXX"
    • Jika statusnya Normal, lanjutkan ke langkah berikutnya.

  2. Gunakan driver sistem default untuk volume, seperti Disk, NAS, atau OSS. Untuk informasi selengkapnya, lihat dokumen di direktori Storage.

Gagal membuat PV secara dinamis dengan error "selfLink was empty, can't make reference"

Gejala

PV gagal dibuat. Event PVC menampilkan error selfLink was empty, can't make reference.

Penyebab

  1. Versi kluster dan versi komponen CSI tidak cocok.

  2. Kluster menggunakan plugin penyimpanan FlexVolume.

Solusi

  1. Upgrade versi komponen CSI. Versi komponen umumnya harus sesuai dengan versi kluster. Misalnya, kluster dengan Kubernetes 1.20 memerlukan CSI versi 1.20 atau lebih baru.

  2. Jika kluster Anda menggunakan plugin penyimpanan FlexVolume, migrasikan dari FlexVolume ke CSI.

Gagal membuat PV secara dinamis ketika kapasitas PVC yang diminta kurang dari 20 GiB

Tipe disk yang berbeda mendukung rentang kapasitas yang berbeda. Jika Anda menggunakan StorageClass default yang disediakan oleh ACK, seperti alicloud-disk-topology-alltype atau alicloud-disk-essd, disk yang dibuat secara otomatis (misalnya, ESSD PL1) memiliki kapasitas minimum 20 GiB. Jika kebutuhan penyimpanan Anda kurang dari 20 GiB, Anda harus membuat StorageClass secara manual dan menentukan tipe disk yang mendukung kapasitas kurang dari 20 GiB, seperti disk ESSD AutoPL atau ESSD PL0.

Pemasangan disk

Pod dengan volume disk gagal dimulai dengan error "had volume node affinity conflict"

Gejala

Pod dengan volume disk gagal dimulai. Event pod menampilkan error had volume node affinity conflict.

Penyebab

Semua PV memiliki properti nodeaffinity. Error ini terjadi ketika properti nodeaffinity dari PV tidak konsisten dengan properti nodeaffinity dari pod. Penjadwal tidak dapat menjadwalkan pod karena konflik ini.

Solusi

Ubah properti nodeAffinity pada PV atau pod agar nilai nodeAffinity keduanya sesuai.

Pod dengan volume disk gagal dimulai dengan error "can't find disk"

Gejala

Pod dengan volume disk gagal dimulai. Event pod menampilkan error can't find disk.

Penyebab

  • ID disk yang salah atau ID disk dari wilayah lain dimasukkan saat Anda mengonfigurasi PV.

  • Akun Anda tidak memiliki izin untuk melakukan operasi pada disk tersebut. Disk tersebut mungkin milik akun lain.

Solusi

  • Jika disk dipasang secara statis, periksa apakah disk memenuhi persyaratan berikut:

    • Disk berada di wilayah yang sama dengan kluster.

    • ID disk disalin dengan benar.

    • Disk dan kluster dimiliki oleh akun yang sama.

  • Jika disk dipasang secara dinamis, periksa izin komponen CSI.

    Konfirmasi apakah Addon Token ada di kluster.

    • Jika ada, periksa versi komponen CSI di kluster. Lalu, upgrade ke versi terbaru dan coba lagi.

    • Jika tidak ada AccessKey yang diberikan, AccessKey yang ditentukan pengguna untuk Worker Role node digunakan secara default. Anda harus memverifikasi izin Policy yang sesuai.

Pod dengan volume disk gagal dimulai dengan error "Previous attach action is still in process"

Gejala

Saat Anda memulai pod dengan volume disk, error Previous attach action is still in process dilaporkan. Pod berhasil dimulai setelah beberapa detik.

Penyebab

ECS tidak mendukung pemasangan beberapa disk ke satu mesin virtual secara bersamaan. Oleh karena itu, ketika beberapa pod dengan volume disk dijadwalkan ke host yang sama, disk dipasang secara serial. Pesan ini menunjukkan bahwa disk lain sedang dalam proses pemasangan ke node tersebut.

Solusi

Tidak diperlukan tindakan apa pun. Sistem akan mencoba ulang secara otomatis hingga berhasil.

Pod dengan volume disk gagal dimulai dengan error "InvalidInstanceType.NotSupportDiskCategory"

Gejala

Saat Anda memulai pod dengan volume disk, error InvalidInstanceType.NotSupportDiskCategory dilaporkan.

Penyebab

Tipe disk dan tipe instans ECS tidak cocok. Node ECS tempat pod dijadwalkan tidak mendukung tipe disk ini, sehingga pemasangan gagal.

Solusi

Coba metode berikut untuk mengatasi masalah ini:

  • Periksa tipe instans node ECS. Pastikan ada node ECS yang mendukung tipe disk ini, dan pastikan penjadwalan dikonfigurasi untuk menjadwalkan pod ke node tersebut.

  • Jika tidak ada tipe instans node ECS saat ini yang mendukung tipe disk ini, gunakan tipe disk yang berbeda.

Catatan

Untuk informasi selengkapnya tentang kompatibilitas tipe disk dan instans, lihat Family instans.

Pod dengan volume disk gagal dimulai dengan error "diskplugin.csi.alibabacloud.com not found in the list of registered CSI drivers"

Gejala

Saat Anda memulai pod, peringatan berikut muncul.

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

  • Peringatan ini biasanya terjadi pada node yang baru ditambahkan. Pod CSI dimulai bersamaan dengan pod aplikasi, tetapi pendaftaran CSI memerlukan waktu. CSI belum terdaftar saat pod aplikasi memulai proses pemasangan, sehingga menyebabkan peringatan ini.

  • Komponen CSI pada node saat ini gagal mendaftar. Ini mungkin karena komponen CSI tidak dimulai dengan benar.

Solusi

  • Jika peringatan ini untuk node baru, tidak diperlukan tindakan apa pun. Tunggu sistem mencoba ulang.

  • Jika komponen CSI gagal mendaftar, periksa status dan log komponen CSI. Jika komponen CSI normal, gabung grup pengguna DingTalk (ID Grup: 35532895) untuk bantuan.

Pod dengan volume disk gagal dimulai dengan error "Multi-Attach error for volume"

Gejala

Pod dengan volume disk gagal dimulai. Event pod menampilkan peringatan warning failedAttachVolume xxx xxx Multi-Attach error for volume "xxx". Menjalankan perintah kubectl describe pvc <pvc-name> menunjukkan bahwa beberapa pod mereferensikan PVC yang sama.

Penyebab

  • Penyebab 1: Disk yang multi-attach-nya tidak diaktifkan hanya dapat dipasang ke satu pod sekaligus. Disk tersebut tidak dapat digunakan oleh beberapa pod secara bersamaan.

  • Penyebab 2: Pod yang menggunakan PVC dihapus, tetapi disk yang sesuai dengan PVC tidak dilepas dengan benar.

    Di Konsol ECS, temukan node tempat disk yang sesuai dengan PVC saat ini dipasang. Lalu, periksa log pod csi-plugin pada node tersebut untuk pesan Path is mounted, no remove: /var/lib/kubelet/plugins/kubernetes.io/csi/diskplugin.csi.alibabacloud.com/xxx/globalmount. Jalankan perintah berikut untuk mengonfirmasi apakah csi-plugin langsung memasang HostPath /var/run:

    kubectl get ds -n kube-system csi-plugin -ojsonpath='{.spec.template.spec.volumes[?(@.hostPath.path=="/var/run/")]}'

    Jika output tidak kosong, berarti ada pemasangan langsung, yang mengonfirmasi masalah ini.

Solusi

  • Solusi untuk Penyebab 1:

    Pastikan beberapa pod tidak mereferensikan PVC yang sama.

  • Solusi untuk Penyebab 2:

    Jalankan perintah berikut untuk memperbaiki file YAML csi-plugin secara manual. Hal ini akan mengatasi masalah tersebut.

    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'

Pod dengan volume disk gagal dimulai dengan error "Unable to attach or mount volumes: unmounted volumes=[xxx], unattached volumes=[xxx]: timed out waiting for the condition"

Gejala

Pod dengan volume penyimpanan gagal dimulai. Event pod menampilkan error Unable to attach or mount volumes: unmounted volumes=[xxx], unattached volumes=[xxx]: timed out waiting for the condition.

Penyebab

Pesan error ini dilaporkan oleh kubelet. Kubelet secara berkala memeriksa apakah volume yang digunakan oleh pod di semua node sudah siap. Jika volume belum siap, error ini terjadi.

Event ini tidak menunjukkan masalah spesifik. Ini hanya berarti bahwa pemasangan belum selesai pada saat itu. Kemungkinan penyebabnya sebagai berikut:

  • Penyebab 1: Terjadi error pemasangan. Karena error tersebut berlangsung lama, event terkait telah kedaluwarsa dan ditimpa. Hanya event error kubelet yang tersisa.

  • Penyebab 2: Kubelet mengalami timeout saat mencoba mengambil configmap/serviceaccount defaulttoken. Ini adalah masalah jaringan node. Satu-satunya solusi adalah mencoba node lain.

  • Penyebab 3: Jika parameter securityContext.fsGroup dikonfigurasi dalam templat pod, pemilik file dalam volume akan diubah secara otomatis saat volume disk dipasang. Bergantung pada jumlah file, hal ini dapat menghasilkan waktu persiapan yang lama.

  • Penyebab 4: Jika volume dipasang secara statis, konfirmasi bahwa field driver dalam volume sudah benar. Misalnya, periksa kesalahan penulisan. Jika field ini salah, kubelet mungkin tidak dapat menemukan dan memanggil driver yang benar, sehingga mencegah volume menjadi siap.

Solusi

  • Solusi untuk Penyebab 1: Hapus pod untuk memulainya kembali. Lalu, temukan event error untuk mengidentifikasi masalah spesifik.

  • Solusi untuk Penyebab 2: Jadwalkan ulang pod ke node lain. Untuk informasi selengkapnya, lihat Jadwalkan aplikasi ke node tertentu.

  • Solusi untuk Penyebab 3: Untuk kluster Kubernetes versi 1.20 dan lebih baru, Anda dapat mengatur fsGroupChangePolicy ke OnRootMismatch. Ini hanya mengubah pemilik file saat pod pertama kali dimulai. Dalam skenario berikutnya, seperti upgrade atau pembuatan ulang pod, waktu pemasangan volume akan normal. Untuk informasi selengkapnya tentang parameter fsGroupChangePolicy, lihat Konfigurasikan Security Context untuk Pod atau Kontainer. Jika ini tidak memenuhi kebutuhan Anda, gunakan initContainer untuk mengimplementasikan operasi penyesuaian izin kustom.

  • Solusi untuk Penyebab 4: Masukkan nama driver yang benar. Misalnya:

    • diskplugin.csi.alibabacloud.com

    • nasplugin.csi.alibabacloud.com

    • ossplugin.csi.alibabacloud.com

Pod dengan volume disk gagal dimulai dengan error "validate error Device /dev/nvme1n1 has error format more than one digit locations"

Gejala

Pod dengan volume disk gagal dimulai. Event pod menampilkan error validate error Device /dev/nvme1n1 has error format more than one digit locations.

Penyebab

Node menggunakan tipe instans ECS generasi ke-8 seperti g7se, r7se, atau c7se, dan versi kluster serta komponen CSI terlalu lama sehingga tidak mendukung pemasangan disk pada node bertipe NVMe.

Solusi

Pastikan versi kluster ACK Anda 1.20 atau lebih baru, dan upgrade komponen CSI ke versi v1.22.9-30eb0ee5-aliyun atau lebih baru. Untuk informasi selengkapnya tentang cara mengupgrade komponen, lihat Kelola komponen.

Catatan

Komponen FlexVolume tidak didukung. Gabung grup pengguna DingTalk (ID Grup: 35532895) untuk bantuan migrasi komponen FlexVolume ke komponen CSI.

Pod dengan volume disk gagal dimulai dengan error "ecs task is conflicted"

Gejala

Pod dengan volume disk gagal dimulai. Event pod menampilkan error ecs task is conflicted.

Penyebab

Beberapa tugas ECS harus dilakukan secara serial. Saat beberapa permintaan dikirim ke ECS secara bersamaan, terjadi error konflik tugas ECS.

Solusi

Anda dapat memilih salah satu solusi berikut:

  • Tunggu beberapa saat. CSI akan mencoba ulang operasi secara otomatis. Jika tugas lain Anda selesai, CSI berhasil memasang disk saat mencoba ulang.

  • Untuk informasi selengkapnya, lihat Gunakan pemasangan disk paralel.

Pod dengan volume disk gagal dimulai dengan error "wrong fs type, bad option, bad superblock on /dev/xxxxx missing codepage or helper program, or other error"

Gejala

Pod dengan volume disk gagal dimulai. Event pod menampilkan error berikut.

wrong fs type, bad option, bad superblock on /dev/xxxxx  missing codepage or helper program, or other error

Penyebab

Sistem file pada disk rusak, sehingga mencegah pemasangan disk.

Solusi

Hal ini biasanya disebabkan oleh pelepasan disk yang tidak tepat. Ikuti langkah-langkah berikut untuk mengatasi masalah ini.

  1. Periksa apakah aplikasi memenuhi persyaratan berikut saat menggunakan disk:

    • Beberapa pod tidak dipasang ke disk yang sama.

    • Data tidak ditulis selama proses pelepasan.

  2. Login ke host tempat pod berada dan jalankan perintah fsck -y /dev/xxxxx untuk memperbaiki sistem file pada disk.

    Dalam perintah ini, /dev/xxxxx sesuai dengan pesan error di event pod. Memperbaiki sistem file disk akan mengubah metadata sistem file. Jika perbaikan gagal atau tidak dapat diselesaikan, sistem file pada disk rusak dan tidak dapat digunakan lagi.

Pod dengan volume disk gagal dimulai dengan error "exceed max volume count"

Gejala

Pod dengan volume disk tetap dalam status Pending untuk waktu yang lama dan tidak dapat dijadwalkan. Namun, berdasarkan tipe instans ECS, lebih banyak disk dapat dipasang ke node tersebut. Event pod menampilkan error berikut.

0/1 nodes are available: 1 node(s) exceed max volume count.

Penyebab

Penjadwalan pod dibatasi oleh angka yang ditentukan dalam variabel lingkungan MAX_VOLUMES_PERNODE.

Solusi

  • Komponen csi-plugin versi v1.26.4-e3de357-aliyun dan lebih baru mendukung konfigurasi otomatis jumlah disk yang dapat dipasang. Jalankan perintah berikut untuk menghapus secara manual variabel lingkungan MAX_VOLUMES_PERNODE dari daemonset csi-plugin di namespace kube-system. Hal ini memungkinkan sistem mengonfigurasi jumlah disk yang dapat dipasang secara otomatis 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'
  • Versi komponen csi-plugin sebelum v1.26.4-e3de357-aliyun hanya mendukung konfigurasi jumlah disk yang dapat dipasang melalui variabel lingkungan ini. Sesuaikan variabel ini secara manual berdasarkan node di kluster yang dapat memiliki jumlah disk data paling sedikit.

Penting
  • Konfigurasi otomatis hanya berlaku saat pod csi-plugin dimulai. Jika Anda menambahkan atau menghapus disk data dari node secara manual, Anda harus membuat ulang pod csi-plugin pada node tersebut untuk memicu konfigurasi otomatis lagi.

  • Fitur konfigurasi otomatis tidak mendukung volume persisten statis yang menggunakan disk. Jika volume semacam itu ada, jumlah pod yang dapat dijadwalkan lebih sedikit dari yang diharapkan.

Pod dengan volume disk gagal dimulai dengan error "The amount of the disk on instance in question reach its limits"

Gejala

Pod dengan volume disk tetap dalam status ContainerCreating untuk waktu yang lama. Event pod menampilkan error berikut.

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

Variabel lingkungan MAX_VOLUMES_PERNODE diatur terlalu tinggi.

Solusi

  • Komponen csi-plugin versi v1.26.4-e3de357-aliyun dan lebih baru mendukung konfigurasi otomatis jumlah disk yang dapat dipasang. Jalankan perintah berikut untuk menghapus secara manual variabel lingkungan MAX_VOLUMES_PERNODE dari daemonset csi-plugin di namespace kube-system. Hal ini memungkinkan sistem mengonfigurasi jumlah disk yang dapat dipasang secara otomatis 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'
  • Versi komponen csi-plugin sebelum v1.26.4-e3de357-aliyun hanya mendukung konfigurasi jumlah disk yang dapat dipasang melalui variabel lingkungan ini. Sesuaikan variabel ini secara manual berdasarkan node di kluster yang dapat memiliki jumlah disk data paling sedikit.

Penting
  • Konfigurasi otomatis hanya berlaku saat pod csi-plugin dimulai. Jika Anda menambahkan atau menghapus disk data dari node secara manual, Anda harus membuat ulang pod csi-plugin pada node tersebut untuk memicu konfigurasi otomatis lagi.

  • Fitur konfigurasi otomatis tidak mendukung volume persisten statis yang menggunakan disk. Jika volume semacam itu ada, jumlah pod yang dapat dijadwalkan lebih sedikit dari yang diharapkan.

Cara mengubah konfigurasi StorageClass disk default

StorageClass default tidak dapat diubah.

Setelah Anda menginstal komponen csi-provisioner, StorageClass seperti alicloud-disk-topology-alltype dibuat secara default di kluster. Jangan ubah StorageClass default ini. Untuk menyesuaikan konfigurasi StorageClass, seperti tipe volume atau kebijakan reclaim, buat StorageClass baru. Jumlah StorageClass tidak dibatasi. Untuk informasi selengkapnya, lihat Buat StorageClass.

Apakah beberapa aplikasi kontainer dapat menggunakan volume disk yang sama?

Disk bukan penyimpanan bersama. Disk yang multi-attach-nya tidak diaktifkan hanya dapat dipasang ke satu pod sekaligus. Untuk informasi selengkapnya tentang multi-attach, lihat Gunakan multi-attach dan reservasi untuk disk NVMe.

Penggunaan disk

Aplikasi melaporkan error "input/output error" saat membaca atau menulis ke direktori mount disk

Gejala

Disk dipasang dengan benar dan aplikasi berhasil dimulai. Namun, setelah waktu singkat, aplikasi tiba-tiba melaporkan error input/output error.

Penyebab

Disk yang digunakan oleh aplikasi hilang.

Solusi

Periksa status disk dan ambil tindakan berdasarkan statusnya.

  1. Berdasarkan direktori mount disk, temukan PVC yang sesuai dari definisi VolumeMount pod.

  2. Jalankan perintah kubectl get pvc <pvc-name> untuk melihat status PVC dan catat PV yang sesuai.

  3. Berdasarkan nama PV, lihat file YAML PV dan ambil ID disk dari field pv.VolumeHandle.

  4. Di halaman Elastic Block Storage pada Konsol ECS, gunakan ID disk untuk memeriksa status disk.

    • Jika disk berada dalam status Available, disk telah dilepas. Mulai ulang pod untuk memasang kembali disk.

      Catatan

      Pod berada dalam status Running, yang berarti disk sebelumnya dipasang, lalu dilepas kemudian. Hal ini menunjukkan bahwa beberapa pod mereferensikan disk yang sama. Jalankan perintah kubectl describe pvc <pvc-name> dan periksa field UsedBy di output untuk melihat apakah beberapa pod mereferensikan PVC saat ini.

    • Jika disk tidak ditemukan, disk telah dilepas dan tidak dapat dipulihkan.

      Penting

      Saat Anda memasang enterprise SSD (ESSD), gunakan fitur snapshot otomatis untuk ESSD guna melindungi data pada volume disk. Untuk informasi selengkapnya, lihat Kehilangan data akibat penghapusan disk yang tidak terduga.

Cara mengatur izin akses pengguna untuk direktori mount volume disk

Disk tidak mendukung pengaturan izin akses pengguna secara langsung. Untuk mengatur izin akses untuk direktori mount, konfigurasikan securityContext untuk pod saat Anda membuat aplikasi untuk mengubah izin. Untuk informasi selengkapnya, lihat Konfigurasikan Kebijakan Izin dan Perubahan Kepemilikan Volume untuk Pod.

Catatan

Setelah Anda mengonfigurasi securityContext.fsgroup, pemilik file dalam volume akan diubah secara otomatis saat disk dipasang. Hal ini dapat meningkatkan waktu persiapan, tergantung pada jumlah file. Untuk kluster Kubernetes versi 1.20 atau lebih baru, Anda dapat mengatur fsGroupChangePolicy ke OnRootMismatch. Hal ini memastikan bahwa pemilik file hanya diubah saat kontainer pertama kali dimulai. Untuk upgrade atau pembuatan ulang pod berikutnya, waktu mount tidak terpengaruh. Jika ini tidak memenuhi kebutuhan Anda, kami sarankan Anda menggunakan initContainer untuk menyesuaikan izin.

Perluasan disk

Apakah volume disk diperluas secara otomatis?

Secara default, volume disk tidak diperluas secara otomatis saat kapasitasnya habis. Anda harus memperbarui deklarasi kapasitas penyimpanan di PVC secara manual untuk memperluas volume disk. Untuk informasi selengkapnya, lihat Perluasan online volume disk.

Jika Anda memerlukan perluasan otomatis, definisikan kebijakan perluasan disk otomatis menggunakan CustomResourceDefinition (CRD). Hal ini memungkinkan volume diperluas secara otomatis saat penggunaannya melebihi ambang batas tertentu. Untuk informasi selengkapnya, lihat Konfigurasikan perluasan otomatis.

Catatan

Jika versi kluster Anda sebelum 1.16 atau tidak memenuhi persyaratan untuk Perluasan online volume disk (misalnya, disk adalah disk dasar), perluas disk di sisi ECS. Hal ini melibatkan perluasan kapasitas disk dan sistem file secara manual. Setelah memperluas disk di sisi ECS, resource di kluster tidak terpengaruh. Kapasitas PVC dan PV yang Anda lihat dari sisi kluster tetap sama seperti sebelum perluasan.

Gagal memperluas disk dengan error "Waiting for user to (re-)start a pod to finish file system resize of volume on node"

Gejala

Setelah Anda memperbarui deklarasi kapasitas penyimpanan PVC, StorageCapacity di status PVC tidak berubah, dan event PVC melaporkan pesan berikut:

 Waiting for user to (re-)start a pod to finish file system resize of volume on node.

Penyebab

Memperluas disk melibatkan dua bagian: memanggil operasi API ResizeDisk untuk memperluas kapasitas disk dan memperluas sistem file. Pesan kesalahan ini menunjukkan bahwa perangkat blok yang mendasarinya telah diperluas, tetapi ekspansi sistem file gagal. Hal ini menunjukkan adanya masalah di sisi node.

Solusi

Tentukan tipe node saat ini.

  • Jika ini adalah node ECI, jalankan perintah kubectl get configmap -n kube-system eci-profile -o jsonpath="{.data.enablePVCController}" untuk mengonfirmasi bahwa konfigurasi ini diatur ke true. Untuk informasi selengkapnya, lihat Item konfigurasi eci-profile.

    Jika masalah berlanjut,kirim tiket untuk bantuan.

  • Jika ini adalah node ECS, jalankan perintah kubectl get pods -n kube-system -l app=csi-plugin --field-selector=spec.nodeName=<node-name> untuk mengambil status csi-plugin pada node saat ini.

    • Jika csi-plugin dalam status normal, gabung grup pengguna DingTalk (ID Grup: 35532895) untuk konsultasi.

    • Jika csi-plugin dalam status abnormal, mulai ulang pod csi-plugin dan coba lagi. Jika masalah berlanjut, gabung grup pengguna DingTalk (ID Grup: 35532895) untuk bantuan.

Gagal memperluas disk dengan error "only dynamically provisioned pvc can be resized and the storageclass that provisions the pvc must support resize"

Gejala

Setelah Anda memperbarui deklarasi kapasitas penyimpanan PVC, pesan error berikut dilaporkan:

only dynamically provisioned pvc can be resized and the storageclass that provisions the pvc must support resize 

Penyebab

  • Penyebab 1: PVC dan PV untuk volume disk saat ini dibuat secara manual dengan cara statis. Konfigurasi storageClassName dalam PVC kosong, atau StorageClass dengan nama yang sama tidak ada di kluster.

  • Penyebab 2: Dalam StorageClass yang direferensikan oleh PVC, konfigurasi allowVolumeExpansion diatur ke false. Artinya, perluasan tidak didukung.

Solusi

  • Solusi untuk Penyebab 1: Periksa konfigurasi storageClassName dari PVC dan pastikan StorageClass dengan nama yang sama ada di kluster. Jika tidak, Anda harus membuat StorageClass yang sesuai berdasarkan properti volume disk yang ada dan mengatur allowVolumeExpansion: true.

  • Solusi untuk Penyebab 2: Properti StorageClass tidak dapat diubah. Anda harus membuat StorageClass baru, mengatur allowVolumeExpansion ke true, lalu ubah PVC untuk mereferensikan StorageClass baru tersebut, dan akhirnya perluas PVC.

Melepas disk cloud

Pod dengan volume disk gagal dihapus dengan error "The specified disk is not a portable disk"

Gejala

Saat Anda melepas disk, error The specified disk is not a portable disk dilaporkan.

Penyebab

Metode penagihan untuk disk adalah langganan. Anda mungkin telah meminta disk langganan atau mengonversi disk yang terkait dengan instans ECS ke metode penagihan langganan saat meng-upgrade instans ECS.

Solusi

Ubah metode penagihan disk ke bayar sesuai pemakaian.

Pod dengan volume disk gagal dihapus karena disk tidak dapat dilepas dan ditemukan pod yatim di log kubelet

Gejala

Pod gagal dilepas, dan log untuk pod yang tidak dikelola oleh ACK muncul di kubelet.

Penyebab

Pod dihentikan secara abnormal, yang menyebabkan titik pemasangan volume tidak dibersihkan selama proses pelepasan. Hal ini akhirnya mencegah penghapusan pod. Sebelum Kubernetes v1.22, proses garbage collection (GC) kubelet untuk volume belum sepenuhnya diimplementasikan, sehingga memerlukan pembersihan manual atau melalui skrip untuk titik pemasangan yang menggantung.

Solusi

Jalankan skrip berikut pada node bermasalah untuk membersihkan titik pemasangan yang menggantung.

wget https://raw.githubusercontent.com/AliyunContainerService/kubernetes-issues-solution/master/kubelet/kubelet.sh
sh kubelet.sh

Setelah pod dengan volume disk dihapus, pod gagal dimulai ulang dengan kegagalan mount dan tidak dapat pulih secara otomatis

Gejala

Setelah pod dihapus, pod tidak dapat dimulai. Error berikut dilaporkan, dan pod tidak dapat pulih 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

Cakupan yang terpengaruh

  • Versi kluster ACK adalah 1.20.4-aliyun-1.

  • Aplikasi menggunakan disk cloud sebagai media penyimpanan.

  • StatefulSet digunakan dengan properti podManagementPolicy: "Parallel" yang diatur.

Penyebab

Untuk informasi selengkapnya, lihat isu GitHub Pod gagal dimulai setelah restart cepat.

Solusi

  • Tambahkan node baru ke kluster lalu hapus node lama untuk mengganti semuanya. Pod yang bermasalah akan pulih secara otomatis. Untuk informasi selengkapnya, lihat Buat dan kelola kelompok node dan Hapus node.

  • Ubah StatefulSet ke orderedready atau hapus properti podManagementPolicy: "Parallel".

  • Jika kluster memiliki jumlah node yang sedikit, gunakan solusi berikut.

    1. Tambahkan label cordon ke node tempat pod berada untuk membuat node tidak dapat dijadwalkan.

    2. Hapus pod dan tunggu statusnya berubah menjadi Pending.

    3. Hapus label cordon dari node dan tunggu pod dimulai ulang.

  • Jika kluster memiliki banyak node, Anda dapat menjadwalkan pod ke node lain. Pod tersebut kemudian akan dimulai secara normal.

Pod dengan volume disk gagal dihapus dengan error "target is busy"

Gejala

Saat Anda menghapus pod, event pod atau log kubelet (/var/log/messages) melaporkan error berikut.

unmount failed, output <mount-path> target is busy

Penyebab

Pod gagal dihapus karena suatu proses sedang menggunakan perangkat tersebut. Anda harus login ke host tempat pod berada untuk menemukan proses tersebut.

Solusi

  1. Temukan perangkat blok di bawah path mount yang sesuai.

    mount | grep <mount-path>
    /dev/vdtest <mount-path>
  2. Temukan ID proses yang menggunakan perangkat blok tersebut.

    fuser -m /dev/vdtest
  3. Hentikan proses yang sesuai.

    Setelah proses dihentikan, disk akan dilepas secara otomatis.

Disk tetap ada setelah PVC-nya dihapus

Gejala

Setelah PVC dihapus dari kluster, disk tetap ada di Konsol ECS.

Penyebab

  • Penyebab 1: Kebijakan reclaim PV (reclaimPolicy) adalah Retain. Artinya, setelah PVC dihapus, PV dan disk dipertahankan.

  • Penyebab 2: PVC dan PV dihapus secara bersamaan, atau PV dihapus sebelum PVC.

Solusi

  • Solusi untuk Penyebab 1: Jika reclaimPolicy diatur ke Retain, CSI tidak menghapus PV dan disk saat PVC dihapus. Anda harus menghapusnya secara manual.

  • Solusi untuk Penyebab 2: Jika PV memiliki deleteTimestamp annotation, CSI tidak bertanggung jawab untuk mereklaim resource disk. Untuk informasi selengkapnya, lihat controller. Untuk menghapus resource disk, cukup hapus PVC. PV yang terikat ke PVC yang dihapus akan dibersihkan secara otomatis.

Gagal menghapus PVC, dan PVC tetap ada setelah penghapusan

Gejala

PVC di kluster gagal dihapus, bahkan dengan flag --force.

Penyebab

Pod di kluster sedang menggunakan PVC tersebut. finalizer pada PVC masih ada, sehingga mencegah penghapusan PVC.

Solusi

  1. Lihat pod yang saat ini mereferensikan PVC ini.

    kubectl describe pvc <pvc-name> -n kube-system
  2. Setelah Anda mengonfirmasi bahwa pod yang mereferensikan tidak lagi digunakan, hapus pod tersebut, lalu coba hapus PVC lagi.

Lainnya

Dapatkah disk yang digunakan sebagai volume dikonversi ke metode penagihan langganan?

Disk yang digunakan sebagai volume harus menggunakan metode penagihan bayar sesuai pemakaian. Disk tersebut tidak dapat dikonversi ke langganan.

Cara mengidentifikasi disk yang terkait dengan volume di halaman Elastic Block Storage pada Konsol ECS

Ambil ID disk yang terkait dengan volume disk (dalam format d-********). Lalu, di halaman Elastic Block Storage pada Konsol ECS, gunakan ID disk untuk mengidentifikasi disk mana yang terkait dengan volume.

  • Secara default, nama PV disk yang dibuat secara dinamis adalah ID disk. Lihat ID disk di halaman Storage > PersistentVolumes kluster.

  • Jika nama PV disk bukan ID disk, jalankan perintah kubectl get pv <pv-name> -o yaml untuk melihat detail PV disk tersebut. Nilai field volumeHandle adalah ID disk.