Container Service for Kubernetes：FAQ untuk volume ossfs 1.0

Waktu pemasangan volume OSS diperpanjang

Gejala

Waktu pemasangan volume OSS meningkat.

Penyebab

Jika kondisi berikut terpenuhi, kubelet menjalankan operasi chmod atau chown selama proses pemasangan volume. Hal ini meningkatkan waktu pemasangan.

• AccessModes di PV dan PVC diatur ke ReadWriteOnce.

• securityContext.fsgroup dikonfigurasi dalam templat aplikasi.

Solusi

• Alat pemasangan ossfs memungkinkan Anda menggunakan parameter untuk memodifikasi UID, GID, dan mode file dalam target pemasangannya.

  Parameter	Deskripsi
  uid	Menentukan UID pengguna yang memiliki subdirektori dan file dalam direktori pemasangan.
  gid	Menentukan GID pengguna yang memiliki subdirektori dan file dalam direktori pemasangan.
  umask	Menetapkan mask izin untuk subdirektori dan file dalam direktori pemasangan. Parameter ini digunakan dengan cara yang mirip dengan mp_umask, tetapi tidak bergantung pada item konfigurasi allow_other.

  Setelah konfigurasi selesai, hapus parameter fsgroup dari securityContext.

• Untuk kluster Kubernetes versi 1.20 atau lebih baru, selain solusi di atas, Anda juga dapat mengonfigurasi fsGroupChangePolicy ke OnRootMismatch. Hal ini memastikan bahwa operasi chmod atau chown hanya dijalankan pada startup pertama, dan waktu pemasangan berikutnya kembali normal. Untuk informasi lebih lanjut tentang fsGroupChangePolicy, lihat Mengonfigurasi Konteks Keamanan untuk Pod atau Kontainer.

Masalah izin pemasangan volume OSS

Saat melakukan operasi dalam skenario berikut, Anda mungkin menerima kesalahan Permission Denied atau Operation not permitted.

Kegagalan pemasangan volume OSS

Gejala

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

Penyebab

• Penyebab 1: Versi ossfs sebelumnya tidak mendukung pemasangan ke direktori yang tidak ada di bucket. Pemasangan gagal karena direktori pemasangan yang ditentukan tidak ada.

  Penting

  Subdirektori yang terlihat di konsol OSS mungkin tidak benar-benar ada di server. Hasil yang dikembalikan oleh ossutil atau API OSS yang berlaku. Misalnya, jika Anda langsung membuat direktori /a/b/c/, /a/b/c/ adalah objek direktori terpisah, tetapi objek direktori /a/ dan /a/b/ tidak benar-benar ada. Demikian pula, jika Anda mengunggah file ke /a/*, /a/b dan /a/c adalah objek file terpisah, tetapi objek direktori /a/ tidak ada.

• Penyebab 2: Pemasangan gagal karena AccessKey atau informasi peran yang digunakan oleh RRSA salah atau izinnya tidak mencukupi.

• Penyebab 3: Akses dari lingkungan runtime aplikasi diblokir oleh kebijakan bucket OSS.

• Penyebab 4: Event berisi 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 di node virtual (Pod ACS), saat PVC perlu menentukan informasi autentikasi melalui bidang nodePublishSecretRef, secret harus berada di namespace yang sama dengan PVC.

• Penyebab 5: Jika versi CSI adalah 1.30.4 atau lebih baru, pod tempat ossfs berada berjalan di namespace ack-csi-fuse. Selama pemasangan, CSI pertama-tama memulai pod tempat ossfs berada, lalu mengirim permintaan RPC untuk memulai proses ossfs di pod tersebut. Jika event berisi FailedMount /run/fuse.ossfs/xxxxxx/mounter.sock: connect: no such file or directory, penyebabnya adalah pod ossfs gagal dimulai atau dihapus secara tidak terduga.

• Penyebab 6: Event berisi Failed to find executable /usr/local/bin/ossfs: No such file or directory. Penyebabnya adalah ossfs gagal diinstal di node.

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

  • Anda secara manual menginstal versi lain dari alat ossfs di node, dan alat tersebut tidak kompatibel dengan sistem operasi node saat ini.

  • Versi default OpenSSL berubah karena peningkatan sistem operasi di node, misalnya, dari Alibaba Cloud Linux 2 ke Alibaba Cloud Linux 3.

  • Saat ossfs berjalan di node, sistem operasi selain CentOS, Alibaba Cloud Linux, ContainerOS, dan Anolis OS tidak didukung.

  • Di node yang memenuhi persyaratan sistem operasi, Anda menghapus pustaka dinamis default yang diperlukan agar ossfs dapat berjalan, seperti FUSE, cURL, dan xml2, atau mengubah versi default OpenSSL.

• Penyebab 8: Saat Anda memasang subdirektori bucket OSS, AccessKey atau peran yang digunakan oleh RRSA hanya diberikan izin pada subdirektori tersebut. Hal ini menyebabkan pemasangan gagal. Log pod ossfs berisi kesalahan 403 AccessDenied dan 404 NoSuchKey.

  Saat ossfs dimulai, secara otomatis melakukan verifikasi izin dan pemeriksaan konektivitas pada bucket OSS. Saat target pemasangan adalah subdirektori OSS, versi ossfs sebelum 1.91.5 pertama-tama mencoba mengakses direktori root bucket. Jika akses gagal, ia mencoba lagi untuk mengakses subdirektori. Dengan izin baca-saja penuh pada bucket, versi ossfs yang lebih baru memungkinkan pemasangan ke subdirektori yang tidak ada di bucket OSS.

  Oleh karena itu, jika AccessKey atau peran yang digunakan oleh RRSA hanya diberikan izin pada subdirektori, kesalahan 403 AccessDenied dilaporkan selama verifikasi awal. Jika subdirektori tidak ada, kesalahan 404 NoSuchKey dilaporkan dan proses keluar secara abnormal, yang menyebabkan pemasangan gagal.

• Penyebab 9: Bucket dikonfigurasi dengan pengembalian ke sumber berbasis mirroring, dan direktori pemasangan tidak disinkronkan dari sumber.

• 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 subdirektori ada di server OSS.

  Asumsikan jalur pemasangan PV adalah sub/path/. Anda dapat menggunakan perintah stat (melihat informasi bucket dan objek) untuk mengkueri objek dengan objectname sebagai sub/path/, atau menggunakan operasi OpenAPI HeadObject untuk mengkueri objek dengan key sebagai sub/path/. Tanggapan 404 mengonfirmasi bahwa subdirektori tidak ada di server.

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

  • Versi ossfs 1.91 dan yang lebih baru tidak memerlukan direktori pemasangan untuk ada. Anda juga dapat menyelesaikan masalah ini dengan meningkatkan versi ossfs. Untuk informasi lebih lanjut, lihat Fitur baru dan pengujian stres kinerja ossfs 1.0. Jika pemasangan masih gagal setelah peningkatan, lihat Penyebab 6 dalam topik ini.

• Solusi untuk Penyebab 2:

  • Pastikan kebijakan pengguna RAM atau peran RAM yang digunakan untuk pemasangan mencakup izin yang tercantum dalam Langkah 2: Memberikan izin ke peran demo-role-for-rrsa.

  • Konfirmasi izin sistem file untuk jalur pemasangan root dan subpath. Untuk informasi lebih lanjut, lihat Skenario 2 dan 7 dalam Masalah izin pemasangan volume OSS.

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

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

    Penting

    Pemasangan volume menggunakan autentikasi RRSA hanya didukung di kluster yang menjalankan Kubernetes 1.26 atau lebih baru dan menggunakan komponen CSI versi 1.30.4 atau lebih baru. Jika Anda menggunakan fitur RRSA di versi sebelum 1.30.4, lihat [Perubahan Produk] Peningkatan versi CSI ossfs dan optimasi 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 dalam Masalah izin pemasangan volume OSS.

• Solusi untuk Penyebab 4:

  Buat secret yang diperlukan di namespace yang sama dengan PVC. Saat Anda membuat PV baru, arahkan nodePublishSecretRef ke secret ini. Untuk informasi lebih lanjut, lihat Memasang volume menggunakan autentikasi AccessKey pengguna RAM.

• 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 perlu memasang volume berada.

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

     Jika pod ada dan statusnya bukan `Running`, selesaikan penyebab ketidaknormalan tersebut. Pastikan pod berjalan normal, lalu restart pod aplikasi untuk memicu pemasangan ulang. Jika pod tidak ada, lanjutkan ke langkah berikutnya untuk melanjutkan pemecahan masalah.

  2. (Opsional) Periksa log audit atau metode lain untuk mengonfirmasi apakah pod dihapus secara tidak terduga. Alasan umum penghapusan tidak terduga termasuk pembersihan skrip aplikasi, draining node, dan self-healing node. Kami menyarankan Anda melakukan penyesuaian yang relevan untuk mencegah masalah ini terjadi lagi.

  3. Setelah Anda mengonfirmasi bahwa baik provisioner CSI maupun plugin CSI telah ditingkatkan ke versi 1.30.4 atau lebih baru:

     1. Jalankan langkah-langkah berikut untuk memeriksa apakah ada 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 proses pembuatan pod ossfs berjalan normal.

• Solusi untuk Penyebab 6:

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

  2. Jalankan perintah berikut untuk mencoba 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 tetap berlanjut setelah Anda meningkatkan atau me-restart komponen, masuk ke node dan jalankan perintah berikut.

     ls /etc/csi-tool

     Sebagian keluaran yang diharapkan:

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

     • Jika keluaran berisi paket Manajer Paket RPM (RPM) ossfs, jalankan perintah berikut untuk memeriksa apakah pod dimulai secara normal.

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

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

• Solusi untuk Penyebab 7:

  • Jika Anda secara manual menginstal alat ossfs, periksa apakah alat tersebut kompatibel dengan sistem operasi node.

  • Jika Anda telah meningkatkan sistem operasi node, Anda dapat menjalankan perintah berikut untuk me-restart csi-plugin, memperbarui versi ossfs, lalu mencoba memasang ulang.

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

  • Kami menyarankan Anda meningkatkan CSI ke versi 1.28 atau lebih baru. Saat Anda memasang volume OSS, ossfs berjalan sebagai kontainer di kluster, tanpa ketergantungan pada sistem operasi node.

  • Jika kluster Anda tidak dapat ditingkatkan ke versi CSI yang lebih baru, Anda dapat beralih ke OS yang sesuai atau menginstal secara manual pustaka dinamis yang hilang. Ambil contoh node Ubuntu:

    • Gunakan perintah which untuk mengkueri lokasi instalasi ossfs saat ini. Jalur instalasi default adalah /usr/local/bin/ossfs.

      which ossfs

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

      ldd /usr/local/bin/ossfs

    • Gunakan perintah apt-file untuk mengkueri paket tempat file pustaka dinamis yang hilang (seperti libcrypto.so.10) berada.

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

    • Gunakan perintah apt-get untuk menginstal paket yang sesuai (seperti libssl.1.0.0).

      apt-get install libssl1.0.0

• Solusi untuk Penyebab 8:

  • Solusi yang direkomendasikan: Tingkatkan versi CSI ke v1.32.1-35c87ee-aliyun atau lebih baru.

  • Solusi alternatif 1: Lihat Penyebab 1 dalam topik ini untuk mengonfirmasi apakah subdirektori ada.

  • Solusi alternatif 2: Untuk memasang subdirektori dalam jangka panjang, kami menyarankan Anda memperluas cakupan izin ke seluruh bucket.

• Solusi untuk Penyebab 9:

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

• Solusi untuk Penyebab 10:

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

Bagaimana cara memasang hanya file tertentu di OSS menggunakan volume OSS?

Volume OSS menggunakan alat ossfs untuk memasang jalur di OSS sebagai sistem file ke pod. ossfs sendiri tidak mendukung pemasangan file. Jika Anda ingin membuat hanya file tertentu dari OSS terlihat di pod, Anda dapat menggunakan metode subPath:

Asumsikan Anda perlu memasang file a.txt dan b.txt dari bucket:/subpath di OSS ke dua pod berbeda, dengan jalur penyimpanan di pod adalah /path/to/file/. Anda dapat membuat PV yang sesuai menggunakan 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 # Jalur 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 # Jalur pemasangan di pod yang sesuai dengan bucket:/subpath
      name: oss-pvc # Harus sama dengan nama di Volumes
      subPath: a.txt # Atau b.txt. Jalur relatif file di bucket:/subpath

Setelah pemasangan, jalur 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 Menggunakan volume ossfs 1.0 yang disediakan secara statis.

Bagaimana cara menggunakan ARN tertentu atau ServiceAccount untuk autentikasi RRSA?

Saat Anda menggunakan RRSA untuk mengautentikasi volume OSS, Anda mungkin menghadapi persyaratan yang tidak dapat dipenuhi oleh konfigurasi default, seperti menggunakan Penyedia Identitas OIDC pihak ketiga atau ServiceAccount non-default.

Secara default, Anda hanya perlu menentukan nama peran RAM menggunakan item konfigurasi roleName di PV. Plugin penyimpanan CSI kemudian mendapatkan Nama Sumber Daya Alibaba Cloud (ARN) Peran dan ARN Penyedia OIDC default. Untuk menerapkan autentikasi RRSA kustom, ubah 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 Anda mengonfigurasi roleArn dan oidcProviderArn, roleName menjadi tidak berlaku.
      serviceAccountName: "csi-fuse-<service-account-name>" 

Bagaimana cara memasang Bucket OSS lintas akun?

Anda dapat menggunakan autentikasi RRSA untuk memasang Bucket OSS lintas akun.

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

Langkah-langkah berikut menjelaskan cara memasang bucket milik Akun B di Akun A. Akun A adalah tempat kluster berada. Akun B adalah tempat Bucket OSS berada. Anda harus menyelesaikan persiapan otorisasi RAM sebelum membuat volume yang menggunakan autentikasi RRSA.

1. Lakukan operasi berikut di Akun B:

   1. Di Akun B, buat peran RAM bernama roleB yang entitas tepercayanya adalah Akun A. Untuk informasi lebih lanjut, lihat Membuat peran RAM untuk akun Alibaba Cloud tepercaya.

   2. Berikan izin roleB pada Bucket OSS yang perlu dipasang.

   3. Di Konsol RAM, buka halaman detail peran 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 digunakan aplikasi untuk autentikasi RRSA. Jenis entitas tepercaya adalah Penyedia Identitas OIDC.

   2. Berikan izin roleA untuk mengasumsikan roleB. Untuk informasi lebih lanjut, lihat Memasang volume menggunakan autentikasi RRSA (volume yang disediakan secara statis) atau Memasang volume menggunakan autentikasi RRSA (volume yang disediakan secara dinamis).

      Anda tidak perlu memberikan kebijakan izin terkait OSS kepada roleA, tetapi Anda harus memberikan kebijakan izin yang mencakup operasi API sts:AssumeRole, seperti kebijakan sistem AliyunSTSAssumeRoleAccess.

3. Konfigurasikan volume di kluster:

   Saat Anda membuat volume, atur parameter assumeRoleArn ke ARN roleB:

   • Volume yang disediakan secara statis (PV): Di volumeAttributes, tambahkan:

     assumeRoleArn: <ARN roleB>

   • Volume yang disediakan secara dinamis (StorageClass): Di parameters, tambahkan:

     assumeRoleArn: <ARN roleB>

Bagaimana cara mengaktifkan mode pemasangan eksklusif setelah ossfs dikontainerisasi?

Gejala

Beberapa pod di node yang sama yang memasang volume OSS yang sama berbagi target pemasangan.

Penyebab

Sebelum ossfs dikontainerisasi, secara default menggunakan mode pemasangan eksklusif. Artinya, untuk setiap pod yang memasang volume OSS, proses ossfs dimulai di node yang sesuai untuk volume tersebut. Target pemasangan yang sesuai dengan proses ossfs yang berbeda sepenuhnya independen, yang berarti pod yang berbeda yang memasang volume OSS yang sama tidak saling memengaruhi operasi baca dan tulisnya.

Setelah ossfs dikontainerisasi, proses ossfs berjalan sebagai kontainer di pod, khususnya pod bernama csi-fuse-ossfs-* di namespace kube-system atau ack-csi-fuse. Dalam skenario pemasangan ganda, mode pemasangan eksklusif akan memulai banyak pod di kluster, yang menyebabkan masalah seperti ENI tidak mencukupi. Oleh karena itu, setelah dikontainerisasi, mode pemasangan bersama digunakan secara default. Artinya, beberapa pod di node yang sama yang memasang volume OSS yang sama berbagi target pemasangan, semuanya sesuai dengan pod csi-fuse-ossfs-* yang sama, dan pemasangan sebenarnya ditangani oleh proses ossfs yang sama.

Solusi

Jika Anda ingin mengembalikan mode pemasangan eksklusif yang digunakan sebelum dikontainerisasi, tambahkan item konfigurasi useSharedPath dan atur ke "false" saat Anda membuat volume OSS. 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

Terjadi pengecualian saat Anda memasang volume OSS menggunakan subpath atau subpathExpr

Gejala

Saat Anda memasang volume OSS menggunakan subpath atau subpathExpr, pengecualian berikut terjadi:

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

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

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

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

Penyebab

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

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

Pod dikonfigurasi sebagai berikut:

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

Kemudian, 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 server OSS, dan pengguna atau peran yang digunakan oleh volume OSS tidak 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 yang tidak mencukupi.

  • Penyebab 2: Objek direktori di tingkat tertentu dari direktori pemasangan /path/subpath/in/oss/ di server OSS (kunci yang diakhiri dengan "/", seperti path/ atau path/subpath/) diurai oleh sistem file sebagai file. Hal ini mencegah Kubelet menentukan status subpath dengan benar.

• Penyebab pengecualian baca/tulis: Kontainer aplikasi yang berjalan sebagai pengguna non-root tidak memiliki izin pada file dalam direktori /path/subpath/in/oss/. Izin default adalah 640. Saat Anda memasang volume OSS menggunakan subpath, direktori sebenarnya yang dipasang oleh ossfs di server OSS adalah direktori path yang ditentukan dalam PV, yaitu /path dalam contoh di atas, bukan /path/subpath/in/oss/. Opsi pemasangan allow_other atau mp_umask hanya berlaku untuk direktori /path. Direktori /path/subpath/in/oss/, sebagai subdirektori, masih memiliki izin default 640.

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

Solusi

• Solusi untuk kegagalan pemasangan:

  • Penyebab 1:

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

    2. Jika banyak direktori perlu dibuat (misalnya, saat Anda memasang volume OSS menggunakan subpathExpr) dan tidak semuanya dapat dibuat terlebih dahulu, Anda dapat memberikan izin putObject kepada pengguna atau peran yang digunakan oleh volume OSS.

  • Penyebab 2:

    1. Lihat solusi untuk Penyebab 1 dalam Direktori ditampilkan sebagai objek file setelah dipasang untuk mengonfirmasi apakah setiap objek direktori ada di server OSS (dengan mengkueri kunci seperti path/ dan path/subpath/ tanpa tanda "/" di awal) dan memeriksa bidang content-type dan content-length. Jika kondisi berikut terpenuhi, objek direktori diidentifikasi secara abnormal sebagai file dalam sistem file:

       Objek direktori ada (dengan asumsi kode pengembalian API 20X, karena bidang content-type dan content-length tidak berarti dalam konteks ini), dan content-type-nya bukan plain, octet-stream, atau x-directory (seperti json atau tar), dan content-length-nya bukan 0.

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

• Solusi untuk pengecualian baca/tulis: Gunakan item konfigurasi umask untuk memodifikasi izin default subdirektori. Misalnya, -o umask=000 mengubah izin default menjadi 777.

• Solusi untuk kegagalan pelepasan pemasangan: Lihat solusi untuk Penyebab 2 dalam Gagal melepas pemasangan volume OSS yang disediakan secara statis dan pod tetap dalam status Terminating.

Akses ke Bucket OSS melalui volume OSS lambat

Gejala

Akses ke Bucket OSS melalui volume OSS lambat.

Penyebab

• Penyebab 1: OSS sendiri tidak memiliki batas jumlah file, tetapi saat jumlah file besar, akses FUSE ke metadata OSS menjadi berlebihan, yang menyebabkan akses bucket lambat.

• Penyebab 2: Setelah pengendalian versi diaktifkan untuk OSS, kinerja listObjectsV1 menurun saat banyak penanda hapus ada di bucket.

• Penyebab 3: kelas penyimpanan di server OSS diatur ke selain Standard. Kelas penyimpanan lain mengurangi kinerja akses data dalam berbagai tingkat.

Solusi

• Solusi untuk Penyebab 1: Kami menyarankan Anda mengakses Bucket OSS dalam mode baca-saja. Untuk bucket dengan banyak objek kecil, gunakan metode pemasangan non-sistem file seperti SDK OSS atau CLI untuk mengakses data bucket. Untuk informasi lebih lanjut, lihat Ikhtisar contoh SDK.

• Solusi untuk Penyebab 2:

  1. Tingkatkan komponen plugin CSI ke v1.26.6. ossfs mendukung mengakses bucket melalui listObjectsV2.

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

• Solusi untuk Penyebab 3: Ubah kelas penyimpanan atau pulihkan file.

Ukuran file adalah 0 di konsol OSS

Gejala

Saat volume OSS dipasang di kontainer dan data ditulis ke file, ukuran file adalah 0 di konsol OSS.

Penyebab

Kontainer memasang OSS menggunakan ossfs, yang berbasis FUSE. Konten file hanya diunggah ke server OSS saat file ditutup atau di-flush.

Solusi

Gunakan perintah `lsof + nama file` untuk memeriksa apakah file ditempati oleh proses lain. Tutup proses yang sesuai untuk melepaskan deskriptor file (fd). Untuk informasi lebih lanjut, lihat lsof.

Aplikasi melaporkan kesalahan "Transport endpoint is not connected" saat mengakses target pemasangan

Gejala

Setelah volume OSS dipasang di kontainer, akses ke target pemasangan tiba-tiba gagal, dan kesalahan "Transport endpoint is not connected" dilaporkan.

Penyebab

Kontainer memasang OSS menggunakan ossfs. Selama akses data ke OSS, proses ossfs keluar secara tidak terduga, yang menyebabkan target pemasangan terputus.

Alasan utama proses ossfs keluar secara tidak terduga adalah:

• Keluar karena sumber daya tidak mencukupi, seperti OOM Killed.

• ossfs keluar karena kesalahan segmentasi selama akses data.

Solusi

1. Konfirmasi alasan keluarnya proses ossfs secara tidak terduga.

   Penting

   Jika layanan online Anda terpengaruh oleh target pemasangan yang terputus dan ini adalah masalah sesekali, Anda dapat terlebih dahulu memperbaikinya dengan menerapkan ulang kontainer aplikasi untuk memasang ulang volume OSS.

   Pemasangan ulang volume OSS akan menyebabkan beberapa informasi yang diperlukan untuk langkah pemecahan masalah berikutnya hilang. Langkah-langkah yang relevan dicatat.

   1. Konfirmasi apakah keluar karena sumber daya tidak mencukupi.

      1. Ketidakcukupan sumber daya tingkat pod: Jika versi CSI adalah 1.28 atau lebih baru, periksa apakah pod tempat ossfs berada telah dimulai ulang, dan apakah alasan keluarnya yang tidak terduga terakhir adalah OOM Killed atau serupa. Untuk informasi tentang cara mengambil pod tempat ossfs berada, lihat Memecahkan masalah pengecualian ossfs 1.0.

      2. Ketidakcukupan sumber daya tingkat node: Jika pod yang abnormal telah dihapus karena pemasangan ulang, atau jika versi CSI lebih awal dari 1.28, Anda dapat memeriksa dasbor pemantauan ACK atau ECS untuk mengonfirmasi apakah node berada di watermark sumber daya tinggi selama pemasangan volume.

   2. Konfirmasi apakah keluar karena kesalahan segmentasi.

      1. Jika versi CSI lebih awal dari 1.28, ossfs berjalan sebagai proses di node. Anda perlu masuk ke node dan mengkueri log sistem. Periksa informasi terkait keluarnya karena kesalahan segmentasi.

         journalctl -u ossfs | grep segfault

      2. Jika versi CSI adalah 1.28 atau lebih baru, langsung kueri log pod tempat ossfs berada. Periksa informasi terkait keluarnya karena kesalahan segmentasi, seperti "signal: segmentation fault".

         Catatan

         Situasi berikut mungkin mencegah Anda mendapatkan log yang relevan. Jika Anda telah mengonfirmasi bahwa proses ossfs tidak keluar karena sumber daya tidak mencukupi, kami menyarankan Anda melanjutkan pemecahan masalah untuk kesalahan segmentasi.

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

         • Jika kontainer aplikasi telah dipasang ulang, log hilang karena pod dihapus.

2. Jika ossfs keluar karena sumber daya tidak mencukupi, sesuaikan batas sumber daya pod tempat ossfs berada, atau jadwalkan pod aplikasi yang memasang volume OSS ke node dengan sumber daya yang lebih melimpah.

   Jika Anda mengonfirmasi bahwa ossfs sendiri mengonsumsi banyak memori, penyebabnya mungkin operasi readdir aplikasi atau perangkat lunak pemindaian pihak ketiga pada target pemasangan memicu ossfs untuk mengirim banyak permintaan HeadObject ke server OSS. Anda dapat mempertimbangkan untuk mengaktifkan fitur optimasi readdir. Untuk informasi lebih lanjut, lihat Fitur optimasi readdir ditambahkan.

3. Sebagian besar masalah kesalahan segmentasi di versi ossfs lama telah diperbaiki di versi 1.91 dan yang lebih baru. Jika ossfs keluar karena kesalahan segmentasi, Anda harus terlebih dahulu mempertimbangkan untuk meningkatkan versi ossfs ke 1.91 atau lebih baru, yang berarti meningkatkan versi CSI ke 1.30.4 atau lebih baru. Untuk detail versi ossfs, lihat Panduan versi ossfs 1.0.

   Jika versi CSI Anda sudah memenuhi persyaratan, ikuti langkah-langkah di bawah ini untuk mengumpulkan lebih lanjut file coredump kesalahan segmentasi dan kirim tiket.

   • Jika sistem operasi node adalah Alibaba Cloud Linux 3, node memiliki parameter core dump default yang dikonfigurasi. Setelah terjadi kesalahan segmentasi ossfs, Anda dapat masuk ke node dan menemukan file coredump yang dikemas core.ossfs.xxx.lz4 di jalur /var/lib/systemd/coredump/.

   • Untuk node dengan sistem operasi selain Alibaba Cloud Linux 3, Anda perlu mengonfirmasi bahwa node mengizinkan proses menghasilkan file coredump. Misalnya, untuk node Alibaba Cloud Linux 2, Anda dapat masuk ke node dan melakukan operasi berikut:

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

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

Aplikasi melaporkan kesalahan "Input/output error" saat mengakses target pemasangan

Gejala

Aplikasi melaporkan kesalahan "Input/output error" saat mengakses target pemasangan.

Penyebab

• Penyebab 1: Nama objek di bawah jalur pemasangan OSS berisi karakter khusus, yang menyebabkan respons server tidak dapat diurai.

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

• Penyebab 3: Saat Resource dalam kebijakan otorisasi RAM adalah untuk satu bucket atau direktori di dalamnya, otorisasi tidak lengkap.

Solusi

• Solusi untuk Penyebab 1:

  Lihat Memecahkan masalah pengecualian ossfs 1.0 untuk mengambil log klien ossfs, yang berisi log kesalahan yang mirip dengan berikut:

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

  Di sini,  mewakili karakter Unicode yang tidak dapat diurai. xxxxxxx/ mewakili nama lengkap objek (objek direktori dalam contoh ini). Gunakan API, konsol, atau metode lain untuk mengonfirmasi bahwa objek ada di server OSS. Karakter tersebut mungkin muncul sebagai spasi di konsol OSS.

  Lihat Mengganti nama objek untuk mengganti nama objek di server OSS. Jika objek adalah direktori, kami menyarankan Anda melihat Operasi umum dan menggunakan ossbrowser 2.0 untuk mengganti nama seluruh direktori.

• Solusi untuk Penyebab 2:

  Gunakan parameter pemasangan -o allow_other dan -o mp_umask untuk mencapai efek yang mirip dengan chmod pada jalur pemasangan:

  Parameter	Deskripsi
  allow_other	Menetapkan izin direktori pemasangan ke 777.
  mp_umask	Menetapkan mask izin untuk direktori pemasangan. Opsi ini hanya berlaku ketika opsi allow_other diatur. Nilai default adalah 000. Misalnya: Untuk menetapkan izin direktori pemasangan ke 770, tambahkan -o allow_other -o mp_umask=007. Untuk menetapkan izin direktori pemasangan ke 700, tambahkan -o allow_other -o mp_umask=077.

  Gunakan parameter pemasangan -o gid dan -o uid untuk mencapai efek yang mirip dengan chown pada jalur pemasangan:

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

• Solusi untuk Penyebab 3:

  Untuk memberikan izin hanya untuk bucket tertentu atau jalur dalam bucket, lihat kebijakan otorisasi dalam Langkah 2: Memberikan izin ke peran demo-role-for-rrsa. Anda perlu memberikan izin untuk mybucket dan mybucket/* (untuk mengotorisasi bucket), atau untuk mybucket/subpath dan mybucket/subpath/* (untuk mengotorisasi jalur).

Direktori ditampilkan sebagai objek file setelah dipasang

Gejala

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

Penyebab

• Penyebab 1: Tipe konten objek direktori di server OSS bukan tipe default application/octet-stream (seperti text/html atau image/jpeg), atau ukuran objek direktori bukan 0. ossfs memperlakukannya sebagai objek file berdasarkan metadatanya.

• Penyebab 2: Masalah ini bukan disebabkan oleh alasan dalam Penyebab 1, tetapi objek direktori kehilangan metadata x-oss-meta-mode.

Solusi

• Solusi untuk Penyebab 1:

  Gunakan HeadObject atau stat (melihat informasi bucket dan objek) untuk mengambil metadata objek direktori. Objek direktori harus diakhiri dengan garis miring (/), misalnya, a/b/. Kode berikut memberikan 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: adalah application/octet-stream, yang berarti objek direktori bertipe application/octet-stream.

  • content-length: adalah 0, yang berarti ukuran objek direktori adalah 0.

  Jika kondisi ini tidak terpenuhi, Anda dapat memperbaikinya sebagai berikut:

  1. Anda dapat menggunakan GetObject atau Memulai Cepat ossutil untuk mengambil objek dan mengonfirmasi apakah datanya berguna. Jika data tersebut berguna atau Anda tidak yakin, kami menyarankan Anda mencadangkannya. Misalnya, Anda dapat mengganti nama objek (untuk objek direktori seperti xx/, jangan gunakan xx sebagai nama baru) dan mengunggahnya ke OSS.

  2. Gunakan DeleteObject atau rm (hapus) untuk menghapus objek direktori yang bermasalah, lalu konfirmasi apakah ossfs menampilkan direktori secara normal.

• Solusi untuk Penyebab 2:

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

  Catatan

  Untuk versi komponen plugin CSI v1.26.6 dan yang lebih baru, item konfigurasi ini diaktifkan secara default. Anda dapat meningkatkan komponen penyimpanan ke v1.26.6 atau lebih baru, me-restart pod aplikasi, dan memasang ulang volume OSS yang disediakan secara statis untuk menyelesaikan masalah.

Banyak permintaan abnormal dipantau di server OSS

Gejala

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

Penyebab

Saat ossfs memasang OSS, ia membuat jalur pemasangan di node. Pemindaian jalur pemasangan ini oleh proses lain di instance ECS juga dikonversi menjadi permintaan ke OSS. Banyak permintaan dapat menimbulkan biaya.

Solusi

Lacak proses yang meminta melalui audit dan atasi masalahnya. Anda dapat melakukan operasi berikut di node.

1. Instal dan mulai auditd.

   sudo yum install auditd
   sudo service auditd start

2. Tetapkan jalur pemasangan ossfs sebagai direktori yang dipantau.

   • Untuk menambahkan semua jalur pemasangan, jalankan perintah berikut.

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

   • Untuk menambahkan jalur 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. Di log audit, periksa proses mana yang mengakses jalur di Bucket OSS.

   ausearch -i 

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

   ---
   type=PROCTITLE msg=audit (September 22, 2023 15:09:26.244:291) : proctitle=updatedb
   type=PATH msg=audit (September 22, 2023 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 (September 22, 2023 15:09:26.244:291) : cwd=/subdir1/subdir2
   type=SYSCALL msg=audit (September 22, 2023 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 lebih lanjut mengonfirmasi apakah ada panggilan proses non-aplikasi dan perbaiki masalahnya.

   Sebagai contoh, jika log audit menunjukkan bahwa updatedb memindai direktori yang dipasang, Anda dapat memodifikasi /etc/updatedb.conf agar melewati direktori tersebut. Lakukan operasi berikut.

   1. Tambahkan fuse.ossfs setelah RUNEFS =.

   2. Tambahkan direktori yang dipasang setelah PRUNEPATHS =.

Metadata Content-Type objek file yang ditulis melalui volume OSS selalu application/octet-stream

Gejala

Metadata Content-Type objek file yang ditulis melalui volume OSS selalu application/octet-stream, yang mencegah browser atau klien lain mengenali dan memproses file tersebut dengan benar.

Penyebab

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

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

Solusi

1. Konfirmasi versi komponen CSI. Versi 1.26.6 dan 1.28.1 memiliki masalah kompatibilitas dengan konfigurasi Content-Type. Jika Anda menggunakan versi ini, tingkatkan 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 /etc/mime.types di node, tingkatkan versi CSI lalu pasang ulang volume OSS yang sesuai.

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

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

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

     1. Periksa apakah file konfigurasi csi-plugin ada.

        kubectl -n kube-system get cm csi-plugin

        Jika tidak ada, buat ConfigMap dengan nama yang sama seperti csi-plugin menggunakan konten berikut. Jika ada, Anda perlu menambahkan konten mime-support="true" ke data.fuse-ossfs di ConfigMap asli.

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

     2. Restart csi-plugin agar konfigurasi berlaku.

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

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

4. Pasang ulang volume OSS yang sesuai.

Kesalahan "Operation not supported" atau "Operation not permitted" dikembalikan saat Anda membuat hard link

Gejala

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

Penyebab

Volume OSS tidak mendukung operasi hard link dan akan mengembalikan kesalahan Operation not supported. Pada 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 beralih ke jenis penyimpanan yang berbeda.

Bagaimana cara melihat catatan akses ke OSS melalui volume OSS?

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

1. Masuk ke OSS konsol.

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

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

4. Di tab Real-time Log Query, masukkan pernyataan kueri 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, Anda perlu memilih bidang user_agent. Setelah Anda memperluasnya, Anda dapat memilih entri apa pun di mana user_agent berisi ossfs.

      Penting

      • Nilai bidang user-agent tergantung pada versi ossfs. Versi ossfs yang berbeda memiliki nilai bidang user-agent yang berbeda, tetapi semuanya dimulai dengan aliyun-sdk-http/1.0()/ossfs.

      • Jika Anda juga memasang melalui ossfs di instance ECS, log terkait akan digabungkan di sini.

   2. Untuk menemukan instance ECS atau kluster tertentu, Anda dapat memilih bidang client_ip lalu memilih alamat IP yang sesuai.

   Dengan menggabungkan pemilihan kedua bidang ini, contoh log yang dikueri ditunjukkan pada gambar berikut.

   Deskripsi beberapa bidang kueri log

   Bidang	Deskripsi
   operation	Jenis operasi pada OSS. Misalnya, GetObject, GetBucketStat. Untuk informasi lebih lanjut, lihat Ikhtisar API.
   object	Nama objek, yang bisa berupa direktori atau file di OSS.
   request_id	Pengidentifikasi unik permintaan. Jika Anda memiliki ID permintaan, Anda dapat melakukan kueri tepat untuk permintaan tertentu.
   http_status, error_code	Untuk mengkueri hasil permintaan. Untuk informasi lebih lanjut, lihat Kode status HTTP.

Bagaimana cara me-restart proses ossfs dalam mode pemasangan bersama?

Gejala

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

Penyebab

• Setelah ossfs berjalan, konfigurasi seperti informasi autentikasi tidak dapat diubah. Untuk mengubah konfigurasi, Anda perlu me-restart proses ossfs (yang, setelah dikontainerisasi, 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 mengubah proses ossfs yang sudah berjalan.

• Dalam alur penggunaan normal, penerapan dan penghapusan ossfs keduanya ditangani oleh CSI. Menghapus pod tempat proses ossfs berada secara manual tidak dapat memicu proses penerapan CSI.

Solusi

Jika Anda menggunakan versi CSI non-kontainer, atau telah mengaktifkan pemasangan eksklusif, Anda dapat langsung me-restart pod aplikasi yang sesuai. Setelah dikontainerisasi, mode pemasangan bersama digunakan secara default, yang berarti semua pod aplikasi di node yang sama yang memasang volume OSS yang sama berbagi proses ossfs untuk pemasangan.

1. Konfirmasi pod aplikasi mana yang menggunakan pod FUSE saat ini.

   1. Jalankan perintah berikut untuk mengonfirmasi pod csi-fuse-ossfs-* yang perlu diubah.

      Dalam perintah, <pv-name> adalah nama PV, dan <node-name> adalah nama node.

      Jika versi CSI lebih awal dari 1.30.4, lakukan operasi berikut:

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

      Jika versi CSI adalah 1.30.4 atau lebih baru, lakukan operasi berikut:

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

      Keluaran 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 mengonfirmasi semua pod yang saat ini memasang volume OSS.

      Dalam perintah, <ns> adalah nama namespace, dan <pvc-name> adalah nama PVC.

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

      Keluaran yang diharapkan (termasuk 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 

      Keluaran 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 (oss-static-94849f647-4**** dan oss-static-94849f647-6**** dalam contoh di atas) menggunakan metode seperti kubectl scale. Saat tidak ada pod aplikasi yang dipasang, pod csi-fuse-ossfs-xxxx akan secara otomatis diambil kembali. Setelah jumlah replika dipulihkan, pemasangan ulang akan dilakukan dengan konfigurasi PV baru, dan CSI akan membuat pod csi-fuse-ossfs-yyyy yang baru.

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

   • Jika versi CSI lebih awal dari 1.30.4, Anda dapat langsung menghapus pod csi-fuse-ossfs-xxxx. Pada titik ini, membaca dan menulis ke OSS dalam pod aplikasi akan mengembalikan kesalahan terputus.

   • Jika versi CSI adalah 1.30.4 atau lebih baru, Anda dapat melakukan operasi berikut:

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

     Keluaran yang diharapkan:

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

     Hapus langsung VolumeAttachment ini. Pada titik ini, membaca dan menulis ke OSS dalam pod aplikasi akan mengembalikan kesalahan terputus.

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

Bagaimana cara memeriksa versi ossfs yang digunakan untuk memasang volume OSS?

Versi ossfs sesuai dengan versi CSI. Versi ossfs yang digunakan oleh ACK didasarkan pada versi OSS publik, misalnya, 1.91.1.ack.1. Untuk informasi lebih lanjut, lihat Panduan versi. Untuk mengkueri versi publik, lihat Instal ossfs 1.0 dan Instal ossfs 2.0.

• Versi ossfs default yang digunakan untuk memasang volume OSS tergantung pada versi komponen Container Storage Interface (CSI). Anda dapat mengkueri csi-provisioner untuk menemukan versi spesifik yang digunakan.

  Catatan

  Untuk versi CSI yang lebih awal dari 1.28 tetapi bukan 1.26.6, sistem menggunakan versi ossfs yang diinstal di node. Anda perlu menggunakan metode berikut untuk mengkueri versi ossfs.

• Untuk memeriksa versi ossfs volume yang sudah dipasang, lihat Melihat versi ossfs.

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

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

Anda dapat mengkueri informasi versi dengan cara berikut:

• Korespondensi versi: Untuk memahami versi ossfs yang sesuai dengan versi CSI yang berbeda, lihat csi-provisioner.

  Untuk versi CSI lama (sebelum v1.28 dan bukan v1.26.6), ossfs 1.0 berjalan langsung di node. Versinya ditentukan oleh versi yang diinstal di node dan tidak dikontrol oleh CSI. Harap kueri versi aktual secara langsung.

• Verifikasi versi aktual: Untuk mengonfirmasi versi ossfs yang sedang berjalan untuk volume yang dipasang, lihat Melihat versi ossfs.

Apakah saya perlu melakukan scaling out volume ketika kapasitas penyimpanan aktual melebihi konfigurasi volume?

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

Jika kapasitas penyimpanan aktual melebihi konfigurasi, penggunaan normal tidak terpengaruh, dan Anda tidak perlu melakukan scaling out volume.

Gagal melepas pemasangan volume OSS yang disediakan secara statis dan pod tetap dalam status Terminating

Gejala

Gagal melepas pemasangan volume OSS yang disediakan secara statis, dan pod tetap dalam status Terminating.

Penyebab

Ada banyak alasan mengapa pod terjebak dalam status Terminating selama penghapusan. Anda dapat terlebih dahulu memeriksa log kubelet untuk mengidentifikasi penyebabnya. Alasan umum kegagalan pelepasan pemasangan volume OSS adalah sebagai berikut:

• Penyebab 1: Target pemasangan yang sesuai di node sedang ditempati. Plugin CSI tidak dapat melepas pemasangan target pemasangan.

• Penyebab 2: Bucket OSS atau direktori (jalur) yang ditentukan dalam PV dihapus. Status target pemasangan saat ini tidak dapat ditentukan.

Solusi

• Solusi untuk Penyebab 1

  1. Jalankan perintah berikut di kluster untuk mengambil UID pod.

     Ganti <ns-name> dan <pod-name> dengan nilai aktual Anda.

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

     Keluaran yang diharapkan:

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

  2. Masuk ke node tempat pod Terminating berada.

  3. Di node, jalankan perintah berikut untuk memeriksa apakah ada proses yang saat ini menempati target pemasangan.

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

     Jika ada keluaran, konfirmasi dan bersihkan proses yang relevan.

• Solusi untuk Penyebab 2

  1. Masuk ke Konsol OSS.

  2. Periksa apakah bucket atau direktori telah dihapus. Jika Anda memasang volume OSS menggunakan subpath, Anda juga perlu mengonfirmasi apakah direktori pemasangan subpath telah dihapus.

  3. Jika kegagalan pelepasan pemasangan disebabkan oleh direktori yang dihapus, lakukan operasi berikut.

     1. Jalankan perintah berikut di kluster untuk mengambil UID pod.

        Ganti <ns-name> dan <pod-name> dengan nilai aktual Anda.

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

        Keluaran yang diharapkan:

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

     2. Masuk ke node tempat pod Terminating berada. Di node, jalankan perintah berikut untuk mengkueri target pemasangan yang terkait dengan pod.

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

        Keluaran 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)

        Jalur antara ossfs on dan type adalah target pemasangan aktual di node.

     3. Lepas pemasangan target 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 secara normal saat mencoba ulang, atau hapus pod secara langsung menggunakan --force.