Container Service for Kubernetes:FAQ volume penyimpanan ossfs 1.0

Pemasangan volume OSS lambat

Gejala

Memasang volume OSS memakan waktu lebih lama dari yang diharapkan.

Penyebab

Jika kedua kondisi berikut terpenuhi, kubelet melakukan operasi chmod atau chown selama pemasangan volume, yang meningkatkan waktu pemasangan.

• Atur AccessModes ke ReadWriteOnce di PV dan PVC.

• securityContext.fsgroup dikonfigurasi dalam templat aplikasi.

Solusi

• Tool pemasangan ossfs menyediakan parameter untuk memodifikasi UID, GID, dan mode file dalam titik pemasangannya.

  Parameter	Deskripsi
  uid	Menentukan UID pengguna yang memiliki subdirektori dan file dalam direktori pemasangan.
  gid	Menentukan GID grup pengguna yang memiliki subdirektori dan file dalam direktori pemasangan.
  umask	Menetapkan mask izin untuk file dan folder di titik pemasangan. Mengizinkan semua pengguna di sistem mengakses direktori titik pemasangan. Perhatikan bahwa ini hanya memengaruhi titik pemasangan itu sendiri, bukan file di dalamnya. Izin file harus dikelola secara terpisah (misalnya melalui opsi umask atau chmod). Opsi ini tidak memerlukan nilai dan cukup ditentukan sebagai -oallow_other. Secara default, hanya pengguna root yang dapat menggunakannya. Catatan Versi 1.91.*: Izin default untuk file adalah 0640, dan izin default untuk folder adalah 0750. Versi 1.80.*: Izin default untuk file dan folder adalah 0777.

  Setelah Anda mengonfigurasi parameter ini, hapus parameter fsgroup dari securityContext.

• Untuk kluster Kubernetes versi 1.20 ke atas, Anda juga dapat mengatur fsGroupChangePolicy ke OnRootMismatch. Ini memastikan bahwa operasi chmod dan chown hanya dilakukan pada startup pertama. Waktu pemasangan berikutnya akan normal. Untuk informasi lebih lanjut tentang fsGroupChangePolicy, lihat Konfigurasikan Konteks Keamanan untuk Pod atau Kontainer.

Masalah izin pemasangan volume OSS

Dalam skenario berikut, Anda mungkin mengalami kesalahan Permission Denied atau Operation not permitted.

Kegagalan pemasangan volume OSS dan event Pod aplikasi: FailedMount

Gejala

Volume OSS gagal dipasang, pod tidak dapat dimulai, dan log event menunjukkan kesalahan FailedMount.

Penyebab

• Penyebab 1: Versi ossfs sebelumnya tidak mendukung pemasangan direktori yang tidak ada di bucket.

  Penting

  Path subdirektori yang terlihat di konsol OSS mungkin tidak benar-benar ada di server. Respons dari tool ossutil atau panggilan API OSS adalah sumber kebenaran. Misalnya, jika Anda langsung membuat direktori /a/b/c/, /a/b/c/ adalah objek direktori mandiri, tetapi objek direktori /a/ atau /a/b/ tidak benar-benar ada. Demikian pula, jika Anda mengunggah file seperti /a/*, /a/b dan /a/c adalah objek file individual, tetapi objek direktori /a/ tidak ada.

• Penyebab 2: Informasi AccessKey atau peran RRSA salah, atau izin terkait tidak mencukupi.

• Penyebab 3: Lingkungan runtime aplikasi diblokir oleh kebijakan bucket OSS.

• Penyebab 4: Event berisi pesan berikut: failed to get secret secrets "xxx" is forbidden: User "serverless-xxx" cannot get resource "secrets" in API group "" in the namespace "xxx". Untuk aplikasi yang dibuat pada node virtual (pod ACS), jika PVC menentukan informasi autentikasi menggunakan bidang nodePublishSecretRef, Secret harus berada di namespace yang sama dengan PVC.

• Penyebab 5: Di versi CSI 1.30.4 ke atas, pod tempat OSSFS berada berjalan di namespace ack-csi-fuse. Selama pemasangan, driver CSI pertama-tama memulai pod tempat OSSFS berada, lalu mengirim permintaan RPC untuk memulai proses OSSFS di pod tersebut. Jika event berisi pesan FailedMount /run/fuse.ossfs/xxxxxx/mounter.sock: connect: no such file or directory, ini menunjukkan bahwa pod tempat OSSFS berada gagal dimulai atau dihapus secara tak terduga.

• Penyebab 6: Event berisi pesan Failed to find executable /usr/local/bin/ossfs: No such file or directory. Ini menunjukkan bahwa OSSFS gagal diinstal pada node.

• Penyebab 7: Event berisi pesan error while loading shared libraries: xxxxx: cannot open shared object file: No such file or directory. Pemasangan gagal karena di versi CSI saat ini, ossfs berjalan langsung di node, dan sistem operasi node kekurangan pustaka dinamis yang diperlukan oleh ossfs. Kesalahan ini dapat terjadi dalam kasus berikut:

  • Anda menginstal versi ossfs di node yang tidak kompatibel dengan sistem operasi.

  • Pemutakhiran sistem operasi di node mengubah versi OpenSSL default. Misalnya, memutakhirkan dari Alibaba Cloud Linux 2 ke Alibaba Cloud Linux 3.

  • Saat ossfs berjalan di node, hanya mendukung CentOS, Alibaba Cloud Linux, ContainerOS, dan Anolis OS.

  • Di node dengan sistem operasi yang kompatibel, Anda menghapus pustaka dinamis default yang diperlukan oleh ossfs, seperti FUSE, cURL, atau xml2, atau Anda mengubah versi OpenSSL default.

• Penyebab 8: Saat memasang subdirektori OSS, pemasangan gagal jika AccessKey atau peran RRSA hanya memiliki izin untuk subdirektori tersebut. Log pod ossfs berisi kesalahan 403 AccessDenied dan 404 NoSuchKey.

  Saat ossfs dimulai, secara otomatis memeriksa izin dan konektivitas bucket OSS. Saat titik pemasangan adalah subdirektori OSS, versi ossfs sebelum 1.91.5 pertama-tama mencoba mengakses direktori root bucket. Jika akses gagal, maka mencoba lagi mengakses subdirektori. Dengan izin baca-saja penuh pada bucket, versi ossfs yang lebih baru dapat memasang subdirektori yang tidak ada di bucket OSS.

  Oleh karena itu, jika AccessKey atau peran yang digunakan RRSA hanya memiliki izin pada subdirektori, kesalahan 403 AccessDenied dilaporkan selama validasi awal. Jika subdirektori juga tidak ada, kesalahan 404 NoSuchKey dilaporkan selanjutnya dan proses keluar, menyebabkan pemasangan gagal.

• Penyebab 9: Bucket dikonfigurasi untuk pengembalian ke sumber berbasis mirroring, tetapi direktori pemasangan belum disinkronkan dari situs asal.

• Penyebab 10: Bucket dikonfigurasi untuk hosting situs web statis. Saat ossfs memeriksa direktori pemasangan di sisi OSS, permintaan diteruskan ke file seperti index.html.

Solusi

• Solusi untuk Penyebab 1:

  Periksa apakah subpath ada di server OSS.

  Anggap path pemasangan PV adalah sub/path/. Anda dapat menggunakan stat (Melihat informasi bucket dan objek) untuk mengkueri objek dengan objectname sub/path/, atau menggunakan OpenAPI HeadObject untuk mengkueri objek dengan key sub/path/. Jika kesalahan 404 dikembalikan, subdirektori tidak ada di sisi server.

  • Anda dapat menggunakan tool seperti ossutil, SDK, atau konsol OSS untuk membuat secara manual bucket atau subdirektori yang hilang, lalu pasang ulang.

  • ossfs 1.91 ke atas tidak memerlukan direktori pemasangan untuk ada. Memutakhirkan versi ossfs juga menyelesaikan masalah ini. Untuk informasi lebih lanjut, lihat Fitur baru dan pengujian kinerja ossfs 1.0. Jika pemasangan masih gagal setelah pemutakhiran, lihat Penyebab 8 dari masalah ini.

• Solusi untuk Penyebab 2:

  • Verifikasi bahwa kebijakan untuk pengguna RAM atau peran RAM yang digunakan untuk pemasangan mencakup izin yang tercantum di 2. Buat dan otorisasi peran RAM.

  • Verifikasi izin sistem file untuk path pemasangan root dan subpath. Untuk informasi lebih lanjut, lihat Skenario 2 dan 7 di Masalah izin pemasangan volume OSS.

  • Untuk volume yang dipasang menggunakan autentikasi AccessKey pengguna RAM, verifikasi apakah AccessKey yang digunakan untuk pemasangan telah dinonaktifkan atau diganti. Untuk informasi lebih lanjut, lihat Skenario 5 di Masalah izin pemasangan volume OSS.

  • Untuk volume yang dipasang menggunakan autentikasi RRSA, verifikasi bahwa kebijakan kepercayaan yang benar dikonfigurasi untuk peran RAM. Untuk informasi tentang cara mengonfigurasi kebijakan kepercayaan, lihat 1. Aktifkan RRSA untuk kluster. Secara default, ServiceAccount tepercaya adalah csi-fuse-ossfs di namespace ack-csi-fuse, bukan ServiceAccount yang digunakan oleh aplikasi.

    Penting

    Autentikasi RRSA hanya didukung untuk kluster versi 1.26 ke atas yang menggunakan komponen CSI versi 1.30.4 ke atas. Jika Anda menggunakan fitur RRSA di versi sebelum 1.30.4, lihat [Perubahan Produk] Pemutakhiran versi CSI ossfs dan optimalisasi proses pemasangan untuk menambahkan konfigurasi otorisasi peran RAM yang diperlukan.

• Solusi untuk Penyebab 3:

  Periksa dan perbaiki kebijakan bucket OSS. Untuk informasi lebih lanjut, lihat Skenario 1 di Masalah izin pemasangan volume OSS.

• Solusi untuk Penyebab 4:

  Buat Secret di namespace yang sama dengan PVC. Kemudian, saat Anda membuat PV baru, arahkan bidang nodePublishSecretRef ke Secret ini. Untuk informasi lebih lanjut, lihat Kebijakan izin baca-saja OSS.

• Solusi untuk Penyebab 5:

  1. Jalankan perintah berikut untuk mengonfirmasi bahwa pod ossfs ada. Dalam perintah, PV_NAME adalah nama PV OSS yang dipasang, dan NODE_NAME adalah nama node tempat pod aplikasi yang memerlukan volume berada.

     kubectl -n ack-csi-fuse get pod -l csi.alibabacloud.com/volume-id=<PV_NAME> -owide | grep <NODE_NAME>

     Jika pod ada tetapi dalam status abnormal, selidiki penyebab abnormalitas tersebut. Pastikan pod dalam status Running, lalu restart pod aplikasi untuk memicu pemasangan ulang. Jika pod tidak ada, lanjutkan ke langkah berikutnya.

  2. (Opsional) Periksa log audit atau sumber lain untuk mengonfirmasi apakah pod dihapus secara tak terduga. Penyebab umum penghapusan tak terduga termasuk skrip pembersihan, pengosongan node, dan pemulihan mandiri node. Kami menyarankan Anda melakukan penyesuaian untuk mencegah masalah ini terulang.

  3. Setelah Anda mengonfirmasi bahwa baik provisioner CSI maupun plugin CSI telah dimutakhirkan ke versi 1.30.4 ke atas, lakukan langkah-langkah berikut:

     1. Jalankan perintah berikut untuk memeriksa adanya sumber daya VolumeAttachment yang tersisa.

        kubectl get volumeattachment | grep <PV_NAME> | grep <NODE_NAME>

        Jika ada, hapus sumber daya VolumeAttachment tersebut.

     2. Restart pod aplikasi untuk memicu pemasangan ulang dan konfirmasi bahwa pod OSSFS dibuat seperti yang diharapkan.

• Solusi untuk Penyebab 6:

  1. Kami menyarankan Anda memutakhirkan csi-plugin ke v1.26.2 ke atas. Versi ini memperbaiki masalah di mana instalasi ossfs gagal selama inisialisasi node yang baru diskalakan.

  2. Jalankan perintah berikut untuk me-restart csi-plugin di node yang sesuai, lalu periksa apakah pod dapat dimulai secara normal.

     Dalam kode berikut, csi-plugin-**** adalah nama pod csi-plugin di node tersebut.

     kubectl -n kube-system delete pod csi-plugin-****

  3. Jika masalah berlanjut setelah Anda memutakhirkan atau me-restart komponen, login ke node dan jalankan perintah berikut:

     ls /etc/csi-tool

     Output yang diharapkan sebagian:

     ... ossfs_<ossfsVer>_<ossfsArch>_x86_64.rpm ...

     • Jika output berisi paket RPM OSSFS, jalankan perintah berikut dan periksa apakah pod dapat dimulai secara normal:

       rpm -i /etc/csi-tool/ossfs_<ossfsVer>_<ossfsArch>_x86_64.rpm

     • Jika output tidak berisi paket RPM OSSFS, lihat Instal ossfs 1.0 untuk mengunduh versi terbaru.

• Solusi untuk Penyebab 7:

  • Jika Anda menginstal tool ossfs secara manual, periksa apakah kompatibilitas OS-nya sesuai dengan OS node.

  • Jika Anda memutakhirkan sistem operasi node, Anda dapat menjalankan perintah berikut untuk me-restart csi-plugin, memperbarui versi ossfs, lalu mencoba memasang lagi:

    kubectl -n kube-system delete pod -l app=csi-plugin

  • Kami menyarankan Anda memutakhirkan driver CSI ke versi 1.28 ke atas. Saat Anda memasang volume OSS, ossfs berjalan sebagai kontainer di kluster dan tidak memiliki persyaratan untuk sistem operasi node.

  • Jika Anda tidak dapat memutakhirkan versi driver CSI, Anda dapat beralih ke OS yang kompatibel atau menginstal secara manual pustaka dinamis yang hilang. Contoh berikut menggunakan node Ubuntu:

    • Gunakan perintah which untuk menemukan lokasi instalasi ossfs saat ini (path default adalah /usr/local/bin/ossfs).

      which ossfs

    • Gunakan perintah ldd untuk mengidentifikasi file pustaka dinamis yang hilang untuk ossfs.

      ldd /usr/local/bin/ossfs

    • Gunakan perintah apt-file untuk menemukan paket yang dimiliki file pustaka dinamis yang hilang (seperti libcrypto.so.10).

      apt-get install apt-file
      apt-file update
      apt-file search libcrypto.so.10

    • Gunakan perintah apt-get untuk menginstal paket yang sesuai (seperti libssl1.0.0).

      apt-get install libssl1.0.0

• Solusi untuk Penyebab 8:

  • Solusi yang direkomendasikan: Mutakhirkan versi CSI ke v1.32.1-35c87ee-aliyun ke atas.

  • Solusi alternatif 1: Lihat solusi untuk Penyebab 1 untuk mengonfirmasi apakah subdirektori ada.

  • Solusi alternatif 2: Jika aplikasi Anda memerlukan pemasangan jangka panjang subdirektori, kami menyarankan memperluas cakupan izin ke seluruh bucket.

• Solusi untuk Penyebab 9:

  Anda harus menyinkronkan data dari situs asal sebelum memasang volume. Untuk informasi lebih lanjut, lihat Ikhtisar konfigurasi pengembalian ke sumber.

• Solusi untuk Penyebab 10:

  Anda harus menonaktifkan atau menyesuaikan konfigurasi hosting situs web statis sebelum memasang volume. Untuk informasi lebih lanjut, lihat Hosting situs web statis.

Kegagalan pemasangan volume OSS: Pod aplikasi melaporkan event:FailedAttachVolume

Gejala

Volume OSS gagal dipasang, pod tidak dapat dimulai, dan log event menunjukkan kesalahan FailedAttachVolume.

Penyebab

Event berisi pesan AttachVolume.Attach failed for volume "xxxxx" : attaching volumes from the kubelet is not supported. Kesalahan ini menunjukkan bahwa konfigurasi enable-controller-attach-detach tidak diaktifkan untuk kubelet node.

Hal ini biasanya terjadi saat Anda melakukan migrasi dari FlexVolume ke CSI. Versi CSI 1.30.4 ke atas bergantung pada parameter ini untuk melakukan operasi AttachVolume, tetapi konfigurasi kubelet node tidak diperbarui dengan benar selama migrasi.

Solusi

1. Periksa konfigurasi kubelet node

   Login ke node dan periksa parameter kubelet enable-controller-attach-detach.

   Dalam perintah, /etc/systemd/system/kubelet.service.d/10-kubeadm.conf adalah path file konfigurasi default untuk kubelet. Ganti dengan path aktual di kluster Anda.

   cat /etc/systemd/system/kubelet.service.d/10-kubeadm.conf | grep enable-controller-attach-detach

   Output yang diharapkan adalah true.

   …… --enable-controller-attach-detach=true ……

2. Perbarui konfigurasi node

   Jika konfigurasi enable-controller-attach-detach tidak diaktifkan untuk kubelet, pertama-tama pastikan semua volume FlexVolume di kluster telah dimigrasikan. Kemudian, lihat Migrasi FlexVolume ke CSI untuk kluster tanpa penyimpanan persisten dan ikuti petunjuk di Langkah 3: Modifikasi konfigurasi semua kelompok node di kluster dan Langkah 4: Modifikasi konfigurasi node yang ada untuk memperbarui konfigurasi untuk kelompok node dan node yang ada.

Memasang satu file dari volume OSS

Volume OSS menggunakan ossfs untuk memasang path OSS sebagai sistem file di pod. ossfs tidak mendukung pemasangan satu file. Jika Anda ingin pod hanya melihat satu file tertentu dari OSS, gunakan fitur subPath.

Asumsikan Anda ingin memasang file a.txt dan b.txt dari bucket:/subpath di OSS ke dua pod berbeda, dengan path target di setiap pod adalah /path/to/file/. Anda dapat membuat PV yang sesuai menggunakan templat YAML berikut:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-oss
spec:
  capacity:
    storage: 5Gi
  accessModes:
    - ReadOnlyMany
  persistentVolumeReclaimPolicy: Retain
  csi:
    driver: ossplugin.csi.alibabacloud.com
    volumeHandle: pv-oss 
    volumeAttributes:
      bucket: bucket
      path: subpath # Path induk dari a.txt dan b.txt.
      url: "oss-cn-hangzhou.aliyuncs.com"

Setelah Anda membuat PVC yang sesuai, konfigurasikan volumeMounts untuk PVC di pod sebagai berikut:

  volumeMounts:
    - mountPath: /path/to/file/a.txt # Path pemasangan di pod yang sesuai dengan bucket:/subpath.
      name: oss-pvc # Harus sesuai dengan nama di Volumes.
      subPath: a.txt # Atau b.txt. Path relatif file di bucket:/subpath.

Setelah pemasangan, path lengkap untuk mengakses a.txt di pod adalah /path/to/file/a.txt, yang sebenarnya mengakses bucket:/subpath/a.txt.

Untuk petunjuk dasar tentang cara menggunakan volume OSS, lihat Gunakan volume ossfs 1.0 yang disediakan secara statis.

Gunakan ARN atau ServiceAccount tertentu untuk RRSA

Autentikasi RRSA default untuk volume OSS mungkin tidak memenuhi persyaratan tertentu, seperti menggunakan penyedia identitas OIDC pihak ketiga atau ServiceAccount non-default.

Dalam kasus seperti itu, Anda dapat menentukan nama peran RAM di PV dengan item konfigurasi roleName. Ini memungkinkan plugin CSI untuk mendapatkan ARN Peran default dan ARN Penyedia OIDC. Jika Anda perlu menerapkan autentikasi RRSA yang disesuaikan, Anda harus memodifikasi konfigurasi PV sebagai berikut:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-oss
spec:
  capacity:
    storage: 5Gi
  accessModes:
    - ReadOnlyMany
  persistentVolumeReclaimPolicy: Retain
  csi:
    driver: ossplugin.csi.alibabacloud.com
    volumeHandle: pv-oss # Harus sama dengan nama PV.
    volumeAttributes:
      bucket: "oss"
      url: "oss-cn-hangzhou.aliyuncs.com"
      otherOpts: "-o umask=022 -o max_stat_cache_size=0 -o allow_other"
      authType: "rrsa"
      oidcProviderArn: "<oidc-provider-arn>"
      roleArn: "<role-arn>"
      #roleName: "<role-name>" # Setelah roleArn dan oidcProviderArn dikonfigurasi, roleName menjadi tidak valid.
      serviceAccountName: "csi-fuse-<service-account-name>" 

Memasang bucket OSS dari akun lain

Kami menyarankan Anda menggunakan autentikasi RRSA untuk memasang bucket OSS dari akun lain.

Pastikan versi kluster dan komponen CSI memenuhi persyaratan untuk autentikasi RRSA.

Sebelum membuat volume yang dipasang dengan autentikasi RRSA, Anda harus menyelesaikan otorisasi RAM yang diperlukan. Contoh berikut menunjukkan cara memasang bucket dari Akun B (tempat bucket OSS berada) di Akun A (tempat kluster berada).

1. Lakukan operasi berikut di Akun B:

   1. Di Akun B, buat peran RAM bernama roleB yang memercayai Akun A. Untuk informasi lebih lanjut, lihat Buat peran RAM untuk akun Alibaba Cloud tepercaya.

   2. Berikan roleB izin yang diperlukan pada bucket OSS yang ingin Anda pasang.

   3. Di Konsol RAM, buka halaman detail untuk roleB dan salin ARN-nya, seperti acs:ram::130xxxxxxxx:role/roleB.

2. Lakukan operasi berikut di Akun A:

   1. Buat peran RAM bernama roleA untuk autentikasi RRSA untuk aplikasi, dan atur jenis entitas tepercaya ke penyedia identitas OIDC.

   2. Berikan roleA izin untuk mengasumsikan roleB. Untuk informasi lebih lanjut, lihat 1. Aktifkan RRSA untuk kluster (untuk volume statis) atau Gunakan volume ossfs 1.0 yang disediakan secara dinamis (untuk volume dinamis).

      roleA tidak memerlukan kebijakan izin terkait OSS. Namun, ia memerlukan kebijakan izin yang mencakup API sts:AssumeRole, seperti kebijakan sistem AliyunSTSAssumeRoleAccess.

3. Konfigurasikan volume di kluster:

   Saat membuat volume, atur parameter assumeRoleArn ke ARN roleB:

   • Volume statis (PV): Di bidang spec.csi.volumeAttributes, tambahkan assumeRoleArn.

     assumeRoleArn: <ARN of roleB>

   • Volume dinamis (StorageClass): Tambahkan assumeRoleArn ke bidang parameters.

     assumeRoleArn: <ARN of roleB>

Gunakan CoreDNS untuk menyelesaikan titik akhir akses OSS

Untuk mengarahkan titik akhir OSS ke domain internal kluster, Anda dapat mengonfigurasi kebijakan DNS tertentu untuk pod tempat ossfs berjalan. Ini memaksanya untuk memprioritaskan CoreDNS kluster selama pemasangan.

Fitur ini hanya didukung oleh komponen CSI versi v1.34.2 ke atas. Untuk memutakhirkan, lihat Mutakhirkan komponen CSI.

• Volume statis (PV): Di bidang spec.csi.volumeAttributes, tambahkan dnsPolicy.

  dnsPolicy: ClusterFirstWithHostNet

• Volume dinamis (StorageClass): Di bidang parameters StorageClass, tambahkan dnsPolicy.

  dnsPolicy: ClusterFirstWithHostNet

Aktifkan mode pemasangan eksklusif untuk ossfs berkontainer

Gejala

Beberapa pod di node yang sama memasang volume OSS yang sama dan berbagi satu titik pemasangan.

Penyebab

Sebelum kontainerisasi, ossfs menggunakan mode pemasangan eksklusif secara default. Dalam mode ini, proses ossfs dimulai di node untuk setiap pod yang memasang volume OSS. Titik pemasangan proses ossfs yang berbeda sepenuhnya independen, sehingga operasi baca dan tulis oleh pod yang berbeda pada volume OSS yang sama tidak saling memengaruhi.

Setelah kontainerisasi, proses ossfs berjalan sebagai kontainer di pod, khususnya pod bernama csi-fuse-ossfs-* di namespace kube-system atau ack-csi-fuse. Dalam skenario multi-pemasangan, mode pemasangan eksklusif memulai banyak pod di kluster, yang dapat menyebabkan masalah seperti antarmuka jaringan elastis tidak mencukupi. Oleh karena itu, setelah kontainerisasi, mode pemasangan bersama digunakan secara default. Dalam mode ini, beberapa pod di node yang sama yang memasang volume OSS yang sama berbagi satu titik pemasangan. Mereka semua sesuai dengan pod csi-fuse-ossfs-* yang sama dan dipasang oleh proses ossfs yang sama.

Solusi

Untuk versi CSI sebelum 1.30.4, Anda dapat kembali ke perilaku pemasangan eksklusif sebelum kontainerisasi dengan menambahkan item konfigurasi useSharedPath saat membuat volume OSS dan mengaturnya ke "false". Kode berikut memberikan contoh:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: oss-pv
spec:
  accessModes:
  - ReadOnlyMany
  capacity:
    storage: 5Gi
  csi:
    driver: ossplugin.csi.alibabacloud.com
    nodePublishSecretRef:
      name: oss-secret
      namespace: default
    volumeAttributes:
      bucket: bucket-name
      otherOpts: -o max_stat_cache_size=0 -o allow_other
      url: oss-cn-zhangjiakou.aliyuncs.com
      useSharedPath: "false" 
    volumeHandle: oss-pv
  persistentVolumeReclaimPolicy: Delete
  volumeMode: Filesystem

Kesalahan dengan pemasangan subpath atau subpathExpr

Gejala

Saat Anda memasang volume OSS menggunakan metode subpath atau subpathExpr, kesalahan berikut mungkin terjadi:

• Kegagalan pemasangan: Setelah pod yang memasang volume OSS dibuat, pod tetap dalam status CreateContainerConfigError, dan muncul event serupa berikut.

  Warning  Failed          10s (x8 over 97s)  kubelet            Error: failed to create subPath directory for volumeMount "pvc-oss" of container "nginx"

• Kesalahan baca/tulis: Saat Anda melakukan operasi baca atau tulis pada volume OSS yang dipasang, kesalahan izin seperti Operation not permitted atau Permission denied dilaporkan.

• Kegagalan pelepasan pemasangan: Saat Anda menghapus pod dengan volume OSS yang dipasang, pod tetap dalam status Terminating.

Penyebab

Untuk menjelaskan penyebab dan solusi, asumsikan PV dikonfigurasi sebagai berikut:

...
    volumeAttributes:
      bucket: bucket-name
      path: /path
      ...

Dan pod dikonfigurasi sebagai berikut:

...
       volumeMounts:
      - mountPath: /path/in/container
        name: oss-pvc
        subPath: subpath/in/oss
      ...

Dalam kasus ini, direktori pemasangan subpath di server OSS adalah /path/subpath/in/oss/ di bucket.

• Penyebab kegagalan pemasangan:

  • Penyebab 1: Direktori pemasangan /path/subpath/in/oss/ tidak ada di OSS, dan pengguna atau peran volume belum diberikan izin PutObject. Misalnya, dalam skenario baca-saja, hanya izin OSS ReadOnly yang dikonfigurasi.

    Kubelet gagal membuat direktori /path/subpath/in/oss/ di server OSS karena izin tidak mencukupi.

  • Penyebab 2: Objek direktori di beberapa level direktori pemasangan /path/subpath/in/oss/ di server OSS (kunci yang diakhiri dengan /, seperti path/ atau path/subpath/) diurai sebagai file di sistem file, yang mencegah Kubelet menentukan status subpath dengan benar.

• Penyebab kesalahan baca/tulis: Kontainer aplikasi non-root tidak memiliki izin untuk file dalam direktori /path/subpath/in/oss/, yang secara default adalah 640. Saat Anda memasang volume OSS menggunakan metode subpath, ossfs sebenarnya memasang direktori path yang didefinisikan dalam PV (dalam contoh ini, /path), bukan /path/subpath/in/oss/. Opsi pemasangan allow_other hanya berlaku pada direktori /path. Subdirektori /path/subpath/in/oss/ masih memiliki izin default 640.

• Penyebab kegagalan pelepasan pemasangan: Direktori pemasangan /path/subpath/in/oss/ di server OSS dihapus, yang memblokir kubelet dari mengambil kembali subpath dan menyebabkan pelepasan pemasangan gagal.

Solusi

• Solusi untuk kegagalan pemasangan:

  • Untuk Penyebab 1:

    1. Buat sebelumnya direktori /path/subpath/in/oss/ di server OSS untuk menyediakan path pemasangan bagi kubelet.

    2. Jika Anda perlu membuat banyak direktori (misalnya, saat memasang volume OSS menggunakan metode subpathExpr) dan tidak dapat membuat semuanya sebelumnya, berikan izin PutObject kepada pengguna atau peran yang digunakan oleh volume OSS.

  • Untuk Penyebab 2:

    1. Lihat solusi untuk Penyebab 1 di Direktori ditampilkan sebagai objek file setelah pemasangan untuk memeriksa apakah setiap objek direktori di server OSS ada (dengan kunci seperti path/ dan path/subpath/; jangan mulai kunci dengan / saat mengkueri) dan periksa bidang content-type dan content-length-nya. Objek direktori mungkin salah diidentifikasi sebagai file jika kondisi berikut terpenuhi:

       Objek direktori ada (API harus mengembalikan kode 2XX untuk bidang content-type dan content-length agar bermakna), content-type-nya bukan plain, octet-stream, atau x-directory (seperti json atau tar), dan content-length-nya bukan 0.

    2. Jika kondisi ini terpenuhi, lihat solusi untuk Penyebab 1 di Direktori ditampilkan sebagai objek file setelah pemasangan untuk menghapus objek direktori yang abnormal.

• Solusi untuk kesalahan baca/tulis: Gunakan opsi umask untuk mengubah izin default subdirektori. Misalnya, -o umask=000 mengubah izin default menjadi 777.

• Solusi untuk kegagalan pelepasan pemasangan: Lihat solusi untuk Penyebab 2 di Pelepasan pemasangan volume OSS statis gagal dan pod tetap dalam status Terminating.

Akses bucket lambat dengan volume OSS

Gejala

Mengakses bucket menggunakan volume OSS lambat.

Penyebab

• Penyebab 1: Setelah pengendalian versi diaktifkan untuk OSS, kinerja listObjectsV1 menurun ketika sejumlah besar penanda hapus ada di bucket.

• Penyebab 2: kelas penyimpanan bucket diatur ke kelas penyimpanan selain Standard di server OSS. Kelas penyimpanan lain dapat menurunkan kinerja akses data.

Solusi

• Solusi untuk Penyebab 1:

  1. Mutakhirkan plugin CSI ke v1.26.6 ke atas. Versi ini memungkinkan ossfs mengakses bucket menggunakan listObjectsV2.

  2. Di bidang otherOpts PV OSS statis, tambahkan -o listobjectsv2 untuk menyelesaikan masalah.

• Solusi untuk Penyebab 2: Ubah kelas penyimpanan atau pulihkan objek.

File menunjukkan ukuran 0 di konsol OSS

Gejala

Setelah Anda memasang volume data OSS di kontainer dan menulis data ke file, konsol OSS menunjukkan ukuran file adalah 0.

Penyebab

Saat kontainer menggunakan ossfs untuk memasang bucket OSS, pemasangan adalah operasi berbasis FUSE. Oleh karena itu, konten file diunggah ke server OSS hanya saat file ditutup atau di-flush.

Solusi

Gunakan perintah lsof <file_name> untuk memeriksa apakah file sedang digunakan oleh proses lain. Jika iya, tutup proses tersebut untuk melepaskan deskriptor file (fd). Untuk informasi lebih lanjut, lihat lsof.

Kesalahan titik akhir transport tidak terhubung

Gejala

Setelah volume data OSS dipasang di kontainer, akses ke titik pemasangan tiba-tiba gagal dengan kesalahan "Transport endpoint is not connected".

Penyebab

Kontainer menggunakan ossfs untuk memasang bucket OSS. Jika proses ossfs keluar secara tak terduga saat aplikasi mengakses data di bucket OSS, titik pemasangan menjadi terputus.

Alasan utama proses ossfs keluar secara tak terduga adalah sebagai berikut:

• Sumber daya tidak mencukupi, misalnya, proses dihentikan karena kesalahan Out of Memory (OOM).

• Proses ossfs keluar karena kesalahan segmentasi saat mengakses data.

Solusi

1. Identifikasi mengapa proses ossfs keluar secara tak terduga.

   Penting

   Jika aplikasi produksi Anda terpengaruh oleh titik pemasangan yang terputus dan ini adalah masalah intermiten, Anda dapat menerapkan ulang kontainer aplikasi untuk memasang ulang volume OSS sebagai solusi cepat.

   Perhatikan bahwa pemasangan ulang volume OSS menyebabkan beberapa informasi yang diperlukan untuk langkah troubleshooting berikutnya hilang. Hal ini ditunjukkan di tempat yang berlaku.

   1. Periksa apakah proses keluar karena sumber daya tidak mencukupi.

      1. Kekurangan sumber daya tingkat Pod: Jika Anda menggunakan CSI v1.28 ke atas, periksa apakah Pod ossfs telah di-restart dan apakah keluar terakhir disebabkan oleh kesalahan OOM atau masalah serupa. Untuk informasi lebih lanjut tentang cara mendapatkan Pod ossfs, lihat Troubleshoot pengecualian ossfs 1.0.

      2. Kekurangan sumber daya tingkat Node: Jika Pod bermasalah dihapus setelah pemasangan ulang atau jika Anda menggunakan versi CSI sebelum 1.28, periksa dasbor pemantauan ACK atau ECS untuk menentukan apakah node mengalami penggunaan sumber daya tinggi saat volume dipasang.

   2. Periksa apakah proses keluar karena kesalahan segmentasi.

      1. Jika Anda menggunakan versi CSI sebelum 1.28, ossfs berjalan sebagai proses di node. Anda harus login ke node dan mengkueri log sistem untuk informasi tentang kesalahan segmentasi.

         journalctl -u ossfs | grep segfault

      2. Jika versi CSI adalah 1.28 ke atas, periksa log Pod ossfs untuk informasi terkait keluar karena kesalahan segmentasi, seperti "signal: segmentation fault".

         Catatan

         Dalam kasus berikut, log terkait tidak dapat diperoleh. Jika Anda telah mengonfirmasi bahwa proses ossfs tidak keluar karena sumber daya tidak mencukupi, kami menyarankan Anda melanjutkan troubleshooting berdasarkan asumsi kesalahan segmentasi.

         • Jika kesalahan segmentasi terjadi lama sekali, log node atau Pod mungkin telah hilang karena rotasi log.

         • Jika kontainer aplikasi dipasang ulang, log hilang saat Pod dihapus.

2. Jika proses ossfs keluar karena sumber daya tidak mencukupi, sesuaikan batas sumber daya Pod ossfs atau jadwalkan Pod aplikasi yang menggunakan volume OSS ke node dengan sumber daya yang lebih tersedia.

   Jika Anda mengonfirmasi bahwa ossfs itu sendiri mengonsumsi banyak memori, penyebabnya mungkin aplikasi atau perangkat lunak pemindaian pihak ketiga melakukan operasi readdir pada titik pemasangan. Hal ini memicu ossfs untuk mengirim banyak permintaan HeadObject ke server OSS. Dalam kasus ini, Anda dapat mengaktifkan optimalisasi readdir. Untuk informasi lebih lanjut, lihat Fitur baru: optimalisasi readdir.

3. Sebagian besar masalah kesalahan segmentasi yang terjadi di versi ossfs sebelumnya diperbaiki di versi 1.91 ke atas. Jika proses ossfs keluar karena kesalahan segmentasi, kami menyarankan Anda memutakhirkan ossfs ke 1.91.8.ack.2 ke atas, yang berarti memutakhirkan versi CSI ke 1.34.4 ke atas. Untuk informasi lebih lanjut tentang versi ossfs, lihat versi ossfs 1.0.

   Jika versi CSI Anda sudah mutakhir, ikuti langkah-langkah berikut untuk mengumpulkan file coredump kesalahan segmentasi dan kirim tiket.

   • Jika node menjalankan Alibaba Cloud Linux 3, parameter coredump-nya dikonfigurasi secara default. Setelah terjadi kesalahan segmentasi ossfs, Anda dapat login ke node dan menemukan file coredump yang dikemas core.ossfs.xxx.lz4 di path /var/lib/systemd/coredump/.

   • Untuk node yang tidak menjalankan Alibaba Cloud Linux 3, pastikan node mengizinkan proses menghasilkan file coredump. Misalnya, di node yang menjalankan Alibaba Cloud Linux 2, login ke node dan jalankan perintah berikut:

     echo "|/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h %e" > /proc/sys/kernel/core_pattern

     Setelah dikonfigurasi, mirip dengan sistem operasi Alibaba Cloud Linux 3, saat terjadi kesalahan segmentasi ossfs, Anda dapat login ke node dan menemukan file coredump yang dikemas core.ossfs.xxx.xz di path /var/lib/systemd/coredump/.

Kesalahan Input/output saat mengakses titik pemasangan

Gejala

Aplikasi melaporkan "Input/output error" saat mengakses titik pemasangan.

Penyebab

• Penyebab 1: Nama objek di path pemasangan OSS berisi karakter khusus, yang mencegah respons server diurai.

• Penyebab 2: Sistem file FUSE tidak mendukung operasi seperti chmod dan chown pada titik pemasangan root.

• Penyebab 3: Saat kebijakan RAM memberikan izin ke satu bucket atau direktori dalam bucket, otorisasi tidak lengkap.

Solusi

• Solusi untuk Penyebab 1:

  Dapatkan log klien ossfs seperti yang dijelaskan di Troubleshoot pengecualian ossfs 1.0. Log berisi pesan kesalahan serupa berikut:

  parser error : xmlParseCharRef: invalid xmlChar value 16
      <Prefix>xxx&#16;xxxx/</Prefix>

  Dalam kasus ini,  mewakili karakter Unicode yang tidak dapat diurai, dan xxxxxxx/ mewakili nama lengkap objek (objek direktori dalam contoh ini). Anda dapat menggunakan tool seperti API dan konsol untuk mengonfirmasi bahwa objek ada di server OSS. Di konsol OSS, karakter ini mungkin ditampilkan sebagai spasi.

  Ganti nama objek di server OSS seperti yang dijelaskan di Ganti nama objek. Jika objek adalah direktori, kami menyarankan Anda menggunakan ossbrowser 2.0 untuk mengganti nama seluruh direktori seperti yang dijelaskan di Operasi umum.

• Solusi untuk Penyebab 2:

  Gunakan parameter pemasangan -o allow_other dan -o umask untuk mencapai efek serupa dengan chmod pada path pemasangan:

  Parameter	Deskripsi
  allow_other	Menetapkan izin direktori pemasangan menjadi 777.

  Gunakan parameter pemasangan -o gid dan -o uid untuk mencapai efek serupa dengan chown pada path pemasangan:

  Parameter	Deskripsi
  uid	Menentukan ID pengguna (UID) pengguna yang memiliki subdirektori dan file dalam direktori pemasangan.
  gid	Menentukan ID grup (GID) pengguna yang memiliki subdirektori dan file dalam direktori pemasangan.

• Solusi untuk Penyebab 3:

  Jika Anda perlu memberikan izin hanya ke bucket tertentu atau path dalam bucket, Anda harus memberikan izin untuk mybucket dan mybucket/* untuk bucket, atau untuk mybucket/subpath dan mybucket/subpath/* untuk path. Untuk informasi lebih lanjut, lihat 2. Buat peran RAM dan berikan izin.

Direktori ditampilkan sebagai file

Gejala

Saat volume data OSS dipasang di kontainer, direktori ditampilkan sebagai file.

Penyebab

• Alasan 1: Jika content-type objek direktori di server OSS bukan tipe default application/octet-stream (seperti text/html atau image/jpeg), atau jika ukuran objek direktori bukan 0, ossfs menganggapnya sebagai objek file berdasarkan metadata-nya.

• Alasan 2: Penyebabnya bukan yang dijelaskan di Alasan 1. Objek direktori kehilangan metadata x-oss-meta-mode.

Solusi

• Solusi untuk Penyebab 1:

  Anda dapat mengambil metadata objek direktori menggunakan HeadObject atau stat (Melihat informasi bucket dan objek). Nama objek direktori harus diakhiri dengan garis miring ("/"), misalnya, a/b/. Berikut adalah contoh respons API.

  {
    "server": "AliyunOSS",
    "date": "Wed, 06 Mar 2024 02:48:16 GMT",
    "content-type": "application/octet-stream",
    "content-length": "0",
    "connection": "keep-alive",
    "x-oss-request-id": "65E7D970946A0030334xxxxx",
    "accept-ranges": "bytes",
    "etag": "\"D41D8CD98F00B204E9800998ECFxxxxx\"",
    "last-modified": "Wed, 06 Mar 2024 02:39:19 GMT",
    "x-oss-object-type": "Normal",
    "x-oss-hash-crc6xxxxx": "0",
    "x-oss-storage-class": "Standard",
    "content-md5": "1B2M2Y8AsgTpgAmY7Phxxxxx",
    "x-oss-server-time": "17"
  }

  Dalam contoh respons di atas:

  • content-type: Nilainya adalah application/octet-stream. Tipe ini digunakan untuk objek direktori.

  • content-length: Nilainya adalah 0. Ukuran objek direktori adalah 0.

  Jika kondisi ini tidak terpenuhi, Anda dapat memperbaiki masalah dengan salah satu cara berikut:

  1. Ambil objek menggunakan GetObject atau panduan cepat tool baris perintah ossutil untuk mengonfirmasi apakah datanya berguna. Jika datanya berguna atau Anda tidak yakin, kami menyarankan Anda mencadangkannya. Misalnya, Anda dapat mengubah namanya (untuk objek direktori xx/, jangan gunakan xx sebagai nama baru) dan mengunggahnya ke OSS.

  2. Gunakan DeleteObject atau rm (hapus) untuk menghapus objek direktori yang bermasalah, lalu periksa apakah ossfs menampilkan direktori dengan benar.

• Solusi untuk Penyebab 2:

  Jika solusi untuk Penyebab 1 tidak memperbaiki masalah, Anda dapat menyelesaikan masalah dengan menambahkan -o complement_stat ke bidang otherOpts PV OSS statis saat Anda memasang volume data OSS di kontainer.

  Catatan

  Opsi ini diaktifkan secara default di plugin CSI v1.26.6 ke atas. Anda dapat memutakhirkan komponen penyimpanan ke v1.26.6 atau versi yang lebih baru, lalu me-restart Pod aplikasi untuk memasang ulang volume OSS statis guna menyelesaikan masalah.

Trafik permintaan tidak normal di server OSS

Gejala

Saat volume data OSS dipasang di kontainer, jumlah permintaan yang dipantau di server OSS jauh lebih tinggi dari yang diharapkan.

Penyebab

Saat ossfs memasang OSS, path pemasangan dibuat di node. Pemindaian titik pemasangan oleh proses lain di instans ECS juga dikonversi menjadi permintaan ke OSS. Jumlah permintaan yang berlebihan dapat menimbulkan biaya.

Solusi

Audit dan lacak proses yang meminta untuk menyelesaikan masalah. Anda dapat melakukan operasi berikut di node.

1. Instal dan mulai auditd.

   sudo yum install auditd
   sudo service auditd start

2. Atur path pemasangan ossfs sebagai direktori yang akan dipantau.

   • Untuk menambahkan semua path pemasangan, jalankan perintah berikut:

     for i in $(mount | grep -i ossfs | awk '{print $3}');do auditctl -w ${i};done

   • Untuk menambahkan path pemasangan PV tertentu, jalankan perintah berikut:

     <pv-name> adalah nama PV yang ditentukan.

     for i in $(mount | grep -i ossfs | grep -i <pv-name> | awk '{print $3}');do auditctl -w ${i};done

3. Periksa log audit untuk melihat proses mana yang mengakses path di bucket OSS.

   ausearch -i 

   Contoh analisis log audit adalah sebagai berikut. Dalam contoh berikut, log audit antara pemisah --- membentuk satu grup, yang mencatat satu operasi pada titik pemasangan yang dipantau. Contoh ini menunjukkan bahwa proses updatedb melakukan operasi open pada subdirektori di titik pemasangan, dan PID-nya adalah 1636611.

   ---
   type=PROCTITLE msg=audit(2023年09月22日 15:09:26.244:291) : proctitle=updatedb
   type=PATH msg=audit(2023年09月22日 15:09:26.244:291) : item=0 name=. inode=14 dev=00:153 mode=dir,755 ouid=root ogid=root rdev=00:00 nametype=NORMAL cap_fp=none cap_fi=none cap_fe=0 cap_fver=0
   type=CWD msg=audit(2023年09月22日 15:09:26.244:291) : cwd=/subdir1/subdir2
   type=SYSCALL msg=audit(2023年09月22日 15:09:26.244:291) : arch=x86_64 syscall=open success=yes exit=9 a0=0x55f9f59da74e a1=O_RDONLY|O_DIRECTORY|O_NOATIME a2=0x7fff78c34f40 a3=0x0 items=1 ppid=1581119 pid=1636611 auid=root uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=pts1 ses=1355 comm=updatedb exe=/usr/bin/updatedb key=(null)
   ---

4. Gunakan log untuk memeriksa panggilan dari proses non-aplikasi dan selesaikan masalah apa pun.

   Misalnya, jika log audit menunjukkan bahwa updatedb telah memindai direktori yang dipasang, Anda dapat memodifikasi /etc/updatedb.conf agar melewatkannya. Prosedurnya adalah sebagai berikut.

   1. Tambahkan fuse.ossfs setelah RUNEFS =.

   2. Tambahkan direktori yang dipasang setelah PRUNEPATHS =.

Content-Type file selalu application/octet-stream

Gejala

Metadata Content-Type semua objek file yang ditulis melalui volume OSS adalah application/octet-stream. Hal ini mencegah browser atau klien lain mengidentifikasi dan memproses file-file tersebut dengan benar.

Penyebab

• Jika Content-Type tidak ditentukan, ossfs secara default memperlakukan objek file sebagai file aliran biner.

• Content-Type ditentukan dalam file konfigurasi /etc/mime.types, tetapi konfigurasi tidak berlaku.

Solusi

1. Periksa versi komponen CSI. Versi komponen CSI 1.26.6 dan 1.28.1 memiliki masalah kompatibilitas dengan konfigurasi Content-Type. Jika Anda menggunakan salah satu versi ini, mutakhirkan CSI ke versi terbaru. Untuk informasi lebih lanjut, lihat [Pengumuman Komponen] Masalah kompatibilitas dengan versi csi-plugin dan csi-provisioner 1.26.6 dan 1.28.1.

2. Jika Anda telah menentukan Content-Type menggunakan mailcap atau mime-support untuk menghasilkan file /etc/mime.types di node, pasang ulang volume OSS yang sesuai setelah Anda memutakhirkan versi CSI.

3. Jika Anda belum menentukan Content-Type, Anda dapat melakukannya dengan salah satu cara berikut:

   • Konfigurasi tingkat Node: File konfigurasi /etc/mime.types dihasilkan di node, yang berlaku untuk semua volume OSS yang baru dipasang ke node tersebut. Untuk informasi lebih lanjut, lihat FAQ.

   • Konfigurasi tingkat Kluster: Konfigurasi ini berlaku untuk semua volume OSS yang baru dipasang di kluster. Konten /etc/mime.types sesuai dengan konten default yang dihasilkan oleh mailcap.

     1. Periksa apakah file konfigurasi csi-plugin ada.

        kubectl -n kube-system get cm csi-plugin

        Jika ConfigMap csi-plugin tidak ada, buat dengan konten berikut. Jika pengaturan mime-support="true" tidak ada di bagian data.fuse-ossfs ConfigMap, tambahkan.

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: csi-plugin
          namespace: kube-system
        data:
          fuse-ossfs: |
            mime-support=true

     2. Restart csi-plugin untuk menerapkan konfigurasi.

        Me-restart csi-plugin tidak memengaruhi penggunaan volume yang saat ini dipasang.

        kubectl -n kube-system delete pod -l app=csi-plugin

4. Pasang ulang volume OSS yang sesuai.

Kesalahan membuat hard link

Gejala

Kesalahan Operation not supported atau Operation not permitted dikembalikan saat membuat hard link.

Penyebab

Volume OSS tidak mendukung operasi hard link dan akan mengembalikan kesalahan Operation not supported. Di versi CSI sebelumnya, kesalahan yang dikembalikan untuk operasi hard link adalah Operation not permitted.

Solusi

Modifikasi aplikasi Anda untuk menghindari operasi hard link saat menggunakan volume OSS. Jika aplikasi Anda harus menggunakan operasi hard link, kami menyarankan Anda menggunakan jenis penyimpanan yang berbeda.

Lihat log akses untuk volume OSS

Anda dapat melihat catatan operasi OSS di Konsol OSS. Pastikan Anda telah mengaktifkan kueri log waktu nyata.

1. Login ke OSS console.

2. Di panel navigasi kiri, klik Buckets. Di halaman Buckets, temukan dan klik bucket yang diinginkan.

3. Di panel navigasi kiri, pilih Logging > Real-time Log Query.

4. Di tab Real-time Log Query, masukkan pernyataan kueri dan analisis berdasarkan sintaks kueri dan sintaks analisis untuk menganalisis log OSS. Anda dapat menggunakan bidang user_agent dan client_ip untuk menentukan apakah log berasal dari ACK.

   1. Untuk menemukan permintaan operasi OSS yang dikirim dari ACK, pilih bidang user_agent. Informasi yang diperluas menunjukkan bahwa user_agent berisi ossfs.

      Penting

      • Nilai bidang user-agent bervariasi tergantung pada versi ossfs, tetapi selalu diawali dengan aliyun-sdk-http/1.0()/ossfs.

      • Jika Anda juga menggunakan ossfs untuk memasang volume di instans ECS, log terkait juga disertakan di sini.

   2. Untuk menemukan instans ECS atau kluster tertentu, pilih bidang client_ip lalu pilih alamat IP yang sesuai.

   Gambar berikut menunjukkan contoh log yang dikueri menggunakan kedua bidang ini.

   Deskripsi bidang kueri log

   Bidang	Deskripsi
   operation	Jenis operasi yang dilakukan pada OSS. Contoh: GetObject dan GetBucketStat. Untuk informasi lebih lanjut, lihat Operasi.
   object	Nama objek, yang bisa berupa direktori atau file di OSS.
   request_id	Pengidentifikasi unik permintaan. Anda dapat menggunakan ID permintaan untuk mengkueri permintaan tertentu.
   http_status, error_code	Digunakan untuk mengkueri hasil permintaan. Untuk informasi lebih lanjut, lihat Respons kesalahan.

Restart proses ossfs untuk pemasangan bersama

Gejala

Setelah Anda memodifikasi informasi autentikasi atau versi ossfs, proses ossfs yang berjalan tidak berubah secara otomatis.

Penyebab

• Konfigurasi seperti informasi autentikasi tidak dapat diubah setelah ossfs berjalan. Mengubah konfigurasi mengharuskan Anda me-restart proses ossfs (dalam versi berkontainer, proses adalah Pod csi-fuse-ossfs-* di namespace kube-system atau ack-csi-fuse) dan Pod aplikasi yang sesuai, yang menyebabkan gangguan layanan. Oleh karena itu, secara default, CSI tidak menerapkan perubahan ke instance ossfs yang sedang berjalan.

• Dalam kondisi normal, CSI menangani penerapan dan penghapusan ossfs. Menghapus secara manual Pod yang berisi proses ossfs tidak memicu CSI untuk menerapkan ulang ossfs atau menghapus sumber daya terkait, seperti VolumeAttachment.

Solusi

Jika Anda menggunakan versi CSI non-kontainer atau telah mengaktifkan pemasangan khusus, Anda dapat langsung me-restart Pod aplikasi yang sesuai. Versi berkontainer menggunakan pemasangan bersama secara default, artinya semua Pod aplikasi di node yang memasang volume OSS yang sama berbagi satu proses ossfs.

1. Identifikasi Pod aplikasi mana yang menggunakan Pod FUSE saat ini.

   1. Jalankan perintah berikut untuk mengidentifikasi Pod csi-fuse-ossfs-* yang perlu Anda modifikasi.

      Di mana <pv-name> adalah nama PV, dan <node-name> adalah nama node.

      Untuk versi CSI sebelum 1.30.4, jalankan perintah berikut:

      kubectl -n kube-system get pod -lcsi.alibabacloud.com/volume-id=<pv-name> -owide | grep <node-name>

      Untuk versi CSI 1.30.4 ke atas, jalankan perintah berikut:

      kubectl -n ack-csi-fuse get pod -lcsi.alibabacloud.com/volume-id=<pv-name> -owide | grep <node-name>

      Output yang diharapkan:

      csi-fuse-ossfs-xxxx   1/1     Running   0          10d     192.168.128.244   cn-beijing.192.168.XX.XX   <none>           <none>

   2. Jalankan perintah berikut untuk mengidentifikasi semua Pod yang memasang volume OSS.

      Di mana <ns> adalah nama namespace, dan <pvc-name> adalah nama PVC.

   3. kubectl -n <ns> describe pvc <pvc-name>

      Output yang diharapkan (berisi bagian "Used By"):

      Used By:       oss-static-94849f647-4****
                     oss-static-94849f647-6****
                     oss-static-94849f647-h****
                     oss-static-94849f647-v****
                     oss-static-94849f647-x****

   4. Jalankan perintah berikut untuk mengambil Pod yang dipasang oleh csi-fuse-ossfs-xxxx, yaitu Pod yang berjalan di node yang sama dengan csi-fuse-ossfs-xxxx.

      kubectl -n <ns> get pod -owide | grep cn-beijing.192.168.XX.XX 

      Output yang diharapkan:

      NAME                         READY   STATUS    RESTARTS   AGE     IP               NODE                         NOMINATED NODE   READINESS GATES
      oss-static-94849f647-4****   1/1     Running   0          10d     192.168.100.11   cn-beijing.192.168.100.3     <none>           <none>
      oss-static-94849f647-6****   1/1     Running   0          7m36s   192.168.100.18   cn-beijing.192.168.100.3     <none>           <none>

2. Restart aplikasi dan proses ossfs.

   Hapus secara simultan Pod aplikasi (dalam contoh di atas, oss-static-94849f647-4**** dan oss-static-94849f647-6****) menggunakan perintah seperti kubectl scale. Saat tidak ada Pod aplikasi yang dipasang, Pod csi-fuse-ossfs-xxxx secara otomatis diambil kembali. Setelah jumlah replika dipulihkan, PV dipasang ulang dengan konfigurasi baru, dan CSI membuat Pod csi-fuse-ossfs-yyyy baru.

   Jika Anda tidak dapat memastikan bahwa Pod ini dihapus secara simultan (misalnya, menghapus Pod yang dikelola oleh Deployment, StatefulSet, atau DaemonSet memicu restart segera), atau jika Pod dapat mentolerir kegagalan baca/tulis OSS:

   • Jika versi CSI sebelum 1.30.4, Anda dapat langsung menghapus Pod csi-fuse-ossfs-xxxx, yang menyebabkan operasi baca dan tulis ke OSS dari dalam Pod aplikasi mengembalikan kesalahan terputus.

   • Untuk versi CSI 1.30.4 ke atas, Anda dapat menjalankan perintah berikut:

     kubectl get volumeattachment | grep <pv-name> | grep cn-beijing.192.168.XX.XX 

     Output yang diharapkan:

     csi-bd463c719189f858c2394608da7feb5af8f181704b77a46bbc219b**********   ossplugin.csi.alibabacloud.com    <pv-name>                   cn-beijing.192.168.XX.XX    true       12m

     Jika Anda menghapus VolumeAttachment secara langsung, operasi baca/tulis ke OSS dalam Pod aplikasi akan mengembalikan kesalahan terputus.

   Kemudian, restart Pod aplikasi satu per satu. Pod yang di-restart akan memulihkan akses baca/tulis ke OSS melalui Pod csi-fuse-ossfs-yyyy baru yang dibuat oleh CSI.

Periksa versi ossfs

Versi ossfs diperbarui bersama versi CSI. Versi ossfs yang digunakan di ACK didasarkan pada versi publik ossfs, dengan nomor versi dalam format seperti 1.91.1.ack.1. Untuk informasi lebih lanjut, lihat Riwayat versi. Untuk informasi lebih lanjut tentang versi publik, lihat Instal ossfs 1.0 dan Instal ossfs 2.0.

• Versi ossfs default yang digunakan untuk memasang volume OSS bervariasi berdasarkan versi komponen CSI. Untuk informasi lebih lanjut, lihat csi-provisioner.

  Catatan

  Untuk versi CSI sebelum 1.28 (tidak termasuk v1.26.6), ossfs 1.0 berjalan di node, dan versi yang digunakan adalah versi yang benar-benar diinstal di node. Anda harus mengkueri versi ossfs menggunakan metode berikut.

• Untuk volume OSS yang sudah dipasang, lihat Lihat versi ossfs.

Versi komponen CSI menentukan versi default ossfs. Versi ossfs yang digunakan oleh ACK menambahkan akhiran .ack.x, seperti 1.91.1.ack.1, ke nomor versi komunitasnya. Untuk informasi lebih lanjut, lihat Catatan versi.

Untuk informasi tentang versi komunitas publik, lihat Instal ossfs 1.0 dan Instal ossfs 2.0.

Anda dapat menemukan informasi versi dengan cara berikut:

• Pemetaan versi: Untuk mengetahui versi ossfs yang sesuai dengan versi CSI tertentu, lihat csi-provisioner.

  Untuk versi CSI lama (sebelum v1.28 dan bukan v1.26.6), ossfs 1.0 berjalan langsung di node. Versi ditentukan oleh versi yang diinstal di node, bukan oleh CSI. Anda harus mengkueri versi yang benar-benar diinstal secara langsung.

• Verifikasi versi aktual: Untuk mengonfirmasi versi ossfs yang tepat yang berjalan untuk volume yang saat ini dipasang, lihat Lihat versi ossfs.

Melebihi kapasitas volume yang dikonfigurasi

OSS tidak membatasi kapasitas bucket atau subdirektori dan tidak menyediakan fitur kuota kapasitas. Oleh karena itu, pengaturan untuk bidang .spec.capacity PV dan bidang .spec.resources.requests.storage PVC diabaikan dan tidak berlaku. Anda hanya perlu memastikan bahwa nilai kapasitas PV dan PVC yang terikat sama.

Jika penggunaan penyimpanan aktual Anda melebihi kapasitas yang dikonfigurasi, volume terus beroperasi secara normal. Tidak diperlukan penskalaan.

Volume statis OSS gagal dilepas pemasangannya

Gejala

Volume statis OSS gagal dilepas pemasangannya, dan pod tetap dalam status Terminating.

Penyebab

Pod dapat macet dalam status Terminating karena beberapa alasan. Mulailah dengan memeriksa log kubelet untuk mengidentifikasi masalah. Penyebab paling umum adalah:

• Penyebab 1: Titik pemasangan volume di node sedang digunakan, mencegah plugin CSI melepas pemasangannya.

• Penyebab 2: Bucket OSS atau direktori yang ditentukan dalam PV telah dihapus, sehingga plugin CSI tidak dapat menentukan status titik pemasangan.

Solusi

• Solusi untuk Penyebab 1

  1. Jalankan perintah berikut untuk mendapatkan UID pod.

     Ganti <ns-name> dan <pod-name> dengan namespace dan nama pod Anda.

     kubectl -n <ns-name> get pod <pod-name> -ogo-template --template='{{.metadata.uid}}'

     Output yang diharapkan:

     5fe0408b-e34a-497f-a302-f77049****

  2. Login ke node tempat pod dalam status Terminating berjalan.

  3. Jalankan perintah berikut di node untuk memeriksa apakah ada proses yang menggunakan titik pemasangan.

     lsof /var/lib/kubelet/pods/<pod-uid>/volumes/kubernetes.io~csi/<pv-name>/mount/

     Jika perintah mengembalikan output apa pun, identifikasi dan hentikan proses tersebut.

• Solusi untuk Penyebab 2

  1. Login ke Konsol OSS.

  2. Periksa apakah bucket atau direktori telah dihapus. Jika Anda menggunakan subPath untuk memasang volume, periksa juga apakah subdirektori yang ditentukan oleh subPath telah dihapus.

  3. Jika Anda mengonfirmasi bahwa kegagalan pelepasan pemasangan disebabkan oleh direktori yang dihapus, lakukan langkah-langkah berikut:

     1. Jalankan perintah berikut untuk mendapatkan UID pod.

        Ganti <ns-name> dan <pod-name> dengan namespace dan nama pod Anda.

        kubectl -n <ns-name> get pod <pod-name> -ogo-template --template='{{.metadata.uid}}'

        Output yang diharapkan:

        5fe0408b-e34a-497f-a302-f77049****

     2. Login ke node tempat pod dalam status Terminating berjalan. Kemudian, jalankan perintah berikut di node untuk menemukan titik pemasangan yang digunakan oleh pod.

        mount | grep <pod-uid> | grep fuse.ossfs

        Output yang diharapkan:

        ossfs on /var/lib/kubelet/pods/<pod-uid>/volumes/kubernetes.io~csi/<pv-name>/mount type fuse.ossfs (ro,nosuid,nodev,relatime,user_id=0,group_id=0,allow_other)
        ossfs on /var/lib/kubelet/pods/<pod-uid>/volume-subpaths/<pv-name>/<container-name>/0 type fuse.ossfs (ro,relatime,user_id=0,group_id=0,allow_other)

        Path antara ossfs on dan type adalah titik pemasangan aktual di node.

     3. Lepas pemasangan titik pemasangan secara manual.

        umount /var/lib/kubelet/pods/<pod-uid>/volumes/kubernetes.io~csi/<pv-name>/mount
        umount /var/lib/kubelet/pods/<pod-uid>/volume-subpaths/<pv-name>/<container-name>/0

     4. Tunggu kubelet mengambil kembali sumber daya pada percobaan berikutnya, atau hapus paksa pod menggunakan flag --force.