Container Service for Kubernetes：Pemecahan Masalah ossfs 1.0

Versi plugin CSI 1.26.6 dan versi selanjutnya

Gejala

Saat Pod aplikasi dimulai, statusnya tetap dalam keadaan ContainerCreating dalam waktu lama.

Penyebab

Pertama, pastikan apakah kontainer ossfs berjalan sebagaimana mestinya. Jika ya, periksa apakah Pod aplikasi berada dalam keadaan ContainerCreating karena alasan lain, seperti masalah pada node.

• CSI v1.30.4 dan versi selanjutnya

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

  Karena versi ini menambahkan proses daemon ke dalam kontainer ossfs, keluaran yang diharapkan sama terlepas dari apakah proses ossfs berjalan sebagaimana mestinya:

  NAME                   READY   STATUS             RESTARTS     AGE
  csi-fuse-ossfs-xxxx    1/1     Running            0            5s

  Jika kontainer ossfs tidak dalam status `Running`, pecahkan masalah tersebut terlebih dahulu.

• Versi CSI sebelum v1.30.4

  kubectl -n kube-system get pod -l csi.alibabacloud.com/volume-id=<VOLUME_ID> -o wide | grep <NODE_NAME>

  Jika kontainer ossfs tidak berjalan sebagaimana mestinya, keluarannya sebagai berikut:

  NAME                   READY   STATUS             RESTARTS     AGE
  csi-fuse-ossfs-xxxx    0/1     CrashLoopBackOff   1 (4s ago)   5s

Penyebab event ini: Saat komponen CSI memulai kontainer ossfs, ossfs keluar secara tak terduga. Masalah ini dapat disebabkan oleh kesalahan pemeriksaan inisialisasi, seperti pemeriksaan konektivitas OSS yang gagal (misalnya, bucket tidak ada atau izin salah), jalur pemasangan OSS yang tidak ada, atau izin baca/tulis yang tidak mencukupi.

Solusi

1. Ambil log kontainer ossfs.

   • Untuk CSI v1.30.4 dan versi selanjutnya

     kubectl -n ack-csi-fuse logs csi-fuse-ossfs-xxxx 

   • Untuk versi CSI sebelum v1.30.4

     kubectl -n kube-system logs csi-fuse-ossfs-xxxx 

     Jika Pod berada dalam status `CrashLoopBackOff`, ambil log dari keluaran tak terduga sebelumnya Pod tersebut:

     kubectl -n kube-system logs -p csi-fuse-ossfs-xxxx 

2. (Opsional) Jika log kosong atau tidak memberikan informasi yang cukup untuk mengidentifikasi masalah, tingkat log mungkin terlalu tinggi. Dalam hal ini, tambahkan konfigurasi yang diperlukan sebagai berikut.

   Catatan

   Metode ini tidak mengharuskan Anda membuat ulang PV debug baru dan klaim volume persisten (PVC) yang sesuai. Namun, Anda tidak dapat langsung mengambil tanggapan permintaan REST dari OSS.

   1. Buat PV OSS untuk debugging. Berdasarkan konfigurasi PV asli, tambahkan -o dbglevel=debug -o curldbg ke bidang otherOpts. Setelah Anda memasang PV OSS baru tersebut, jalankan perintah kubectl logs untuk mengambil log debug dari Pod ossfs.

      Penting

      Log debug bisa sangat besar. Kami merekomendasikan agar Anda hanya menggunakan pengaturan ini untuk debugging.

   2. Gunakan konten berikut untuk membuat ConfigMap bernama `csi-plugin` di namespace `kube-system`. Atur tingkat log menjadi debug.

      Catatan

      Untuk plugin CSI v1.28.2 dan versi sebelumnya, Anda hanya dapat mengatur tingkat log ke `info`.

      apiVersion: v1
      kind: ConfigMap
      metadata:
        name: csi-plugin
        namespace: kube-system
      data:
        fuse-ossfs: |
          dbglevel=debug     # Tingkat log

      Mulai ulang Pod `csi-plugin` di node tempat aplikasi berada dan semua Pod `csi-provisioner` untuk menerapkan konfigurasi ConfigMap. Mulai ulang Pod aplikasi untuk memicu pemasangan ulang, dan pastikan Pod csi-fuse-ossfs-xxxx diterapkan ulang setelah pemasangan ulang.

      Penting

      ConfigMap adalah konfigurasi global. Setelah debugging, hapus ConfigMap tersebut. Kemudian, mulai ulang Pod `csi-plugin` di node dan semua Pod `csi-provisioner` lagi untuk mematikan logging debug. Terakhir, mulai ulang Pod aplikasi untuk memicu pemasangan ulang lainnya guna mencegah ossfs menghasilkan log debug berlebihan.

3. Analisis log kontainer ossfs.

   Umumnya, kesalahan ossfs terbagi menjadi dua kategori: kesalahan dari ossfs itu sendiri dan kode kesalahan non-200 yang dikembalikan oleh server OSS setelah permintaan. Contoh berikut untuk setiap jenis kesalahan menunjukkan metode pemecahan masalah umum.

   Kesalahan dari ossfs itu sendiri

   ossfs: Direktori MOUNTPOINT /test tidak kosong. Jika Anda yakin ini aman, Anda dapat menggunakan opsi pemasangan 'nonempty'.

   Berdasarkan pesan log tersebut, kesalahan terjadi karena jalur titik pemasangan tidak kosong. Anda dapat mengatasi masalah ini dengan menambahkan item konfigurasi -o nonempty.

   Catatan

   Anda dapat menemukan solusi dalam dokumen FAQ ossfs berdasarkan log kesalahan. Jika Anda tidak dapat menemukan penyebabnya, kirim tiket.

   Kode kesalahan non-200 yang dikembalikan oleh server OSS

   Ambil log tersebut. Sebelum ossfs keluar, ia memeriksa bucket yang akan dipasang. Server OSS mengembalikan kode kesalahan 404, penyebab kesalahan adalah NoSuchBucket, dan pesan kesalahannya adalah Bucket yang ditentukan tidak ada.

   [ERROR]  2023-10-16 12:38:38:/tmp/ossfs/src/curl.cpp:CheckBucket(3420): Pemeriksaan bucket gagal, tanggapan oss: <?xml version="1.0" encoding="UTF-8"?>
   <Error>
     <Code>NoSuchBucket</Code>
     <Message>The specified bucket does not exist.</Message>
     <RequestId>652D2ECEE1159C3732F6E0EF</RequestId>
     <HostId><bucket-name>.oss-<region-id>-internal.aliyuncs.com</HostId>
     <BucketName><bucket-name></BucketName>
     <EC>0015-00000101</EC>
     <RecommendDoc>https://api.aliyun.com/troubleshoot?q=0015-00000101</RecommendDoc>
   </Error>

   Berdasarkan pesan log tersebut, kesalahan terjadi karena bucket OSS yang ditentukan tidak ada. Untuk mengatasi masalah ini, masuk ke Konsol OSS, buat bucket tersebut, lalu pasang ulang volumenya.

   Catatan

   Anda dapat menemukan solusi dalam topik Kode Kesalahan HTTP pada dokumentasi OSS menggunakan kode kesalahan dan pesan kesalahan tersebut.

   Informasi tambahan

   Instruksi tingkat log

   Jika tingkat log terlalu tinggi sehingga tidak dapat mengidentifikasi masalah, dan Anda memiliki persyaratan berikut:

   • Anda tidak ingin membuat ulang PV OSS.

   • Anda khawatir konfigurasi ConfigMap global dapat memengaruhi operasi lain, seperti pemasangan atau pencopotan pemasangan PV OSS lain selama debugging.

   Dalam kasus ini, Anda dapat memasang ossfs di latar depan dan mengambil log debug untuk mengidentifikasi masalah. Untuk langkah-langkah spesifiknya, lihat solusi untuk versi plugin CSI sebelum 1.26.6.

   Penting

   Setelah ossfs dikontainerisasi, ossfs tidak diinstal pada node secara default. Versi ossfs yang Anda instal secara manual mungkin berbeda dari versi yang berjalan di dalam Pod. Kami merekomendasikan agar Anda terlebih dahulu mencoba solusi yang dijelaskan di atas dengan mengubah parameter pemasangan PV atau konfigurasi ConfigMap global.

   Untuk memasang ossfs, lakukan langkah-langkah berikut.

   1. Instal versi terbaru ossfs.

   2. Di node, jalankan perintah berikut untuk mengambil nilai SHA-256 dari nama PV.

      echo -n "<PV_NAME>" | sha256sum

      Jika sistem Anda tidak mendukung operasi `sha256sum`, Anda juga dapat menggunakan library OpenSSL untuk mengambil nilai tersebut:

      echo -n "<PV_NAME>" | openssl sha256 -binary | xxd -p -c 256

      Untuk "pv-oss", keluaran yang diharapkan adalah:

      8f3e75e1af90a7dcc66882ec1544cb5c7c32c82c2b56b25a821ac77cea60a928

   3. Di node, jalankan perintah berikut untuk mengambil parameter pemasangan ossfs.

      ps -aux | grep <sha256-value>

      Keluarannya berisi catatan proses untuk ossfs.

   4. Di node, jalankan perintah berikut untuk menghasilkan informasi autentikasi yang diperlukan untuk memasang ossfs. Setelah debugging, segera hapus file ini.

      mkdir -p /etc/ossfs && echo "<bucket-name>:<akId>:<akSecret>" > /etc/ossfs/passwd-ossfs && chmod 600 /etc/ossfs/passwd-ossfs

   Pemecahan masalah segmentation fault

   Jika log kesalahan berisi "ossfs exited with error" err="signal: segmentation fault (core dumped) ", ini menunjukkan bahwa proses ossfs keluar secara tak terduga karena segmentation fault selama runtime.

   Untuk membantu dukungan teknis mengidentifikasi masalah, masuk ke node logon, ikuti prosedur di bawah ini untuk mendapatkan file core dump, lalu kirim tiket.

   1. Temukan catatan crash proses ossfs.

      coredumpctl list

      Keluaran yang diharapkan:

      TIME                          PID       UID   GID  SIG   COREFILE   EXE
      Mon 2025-11-17 11:21:44 CST   2108767   0     0    1     present    /usr/bin/xxx
      Tue 2025-11-18 19:35:58 CST   493791    0     0    1     present    /usr/local/bin/ossfs

      Keluaran di atas menunjukkan bahwa dua proses di node ini telah keluar karena segmentation fault.

      Temukan catatan yang akan dipecahkan berdasarkan waktu (TIME) dan nama proses (EXE), lalu catat PID-nya. Dalam contoh di atas, PID-nya adalah 493791.

   2. Ekspor file core dump. Gunakan PID dari langkah sebelumnya dan jalankan perintah berikut untuk mengekspor file core. Parameter --output menentukan nama file yang dihasilkan.

      # Ganti <PID> dengan PID yang sebenarnya
      coredumpctl dump <PID> --output ossfs.dump

   3. kirim tiket dan berikan file ossfs.dump yang dihasilkan.

Versi plugin CSI sebelum 1.26.6

Gejala

Saat Pod aplikasi dimulai, statusnya tetap dalam keadaan ContainerCreating dalam waktu lama.

Penyebab

1. Jalankan perintah berikut untuk menentukan mengapa Pod tidak dapat dimulai sebagaimana mestinya.

   Ganti variabel berikut:

   • <POD_NAMESPACE>: namespace tempat Pod aplikasi berada.

   • <POD_NAME>: nama Pod aplikasi.

     kubectl -n <POD_NAMESPACE> describe pod <POD_NAME>

2. Periksa apakah ada event dengan penyebab `FailedMount` di bagian Events dari keluaran perintah.

   Ganti variabel berikut:

   • <PV_NAME>: nama volume OSS.

   • <BUCKET>: nama bucket OSS yang dipasang.

   • <PATH>: jalur bucket OSS yang dipasang.

   • <POD_UID>: UID Pod aplikasi.

   • Warning  FailedMount  3s  kubelet  MountVolume.SetUp failed for volume "<PV_NAME>" : rpc error: code = Unknown desc = Mount is failed in host, mntCmd:systemd-run --scope -- /usr/local/bin/ossfs <BUCKET>:/<PATH> /var/lib/kubelet/pods/<POD_UID>/volumes/kubernetes.io~csi/<PV_NAME>/mount -ourl=oss-cn-beijing-internal.aliyuncs.com -o allow_other , err: ..... with error: exit status 1

     Penyebab event ini: Event ini terjadi karena ossfs keluar secara tak terduga saat komponen CSI memulainya. Akibatnya, tidak ada proses ossfs yang sesuai yang berjalan di node. Masalah ini dapat disebabkan oleh kesalahan pemeriksaan inisialisasi, seperti pemeriksaan konektivitas OSS yang gagal (misalnya, bucket tidak ada atau izin salah), jalur pemasangan yang tidak ada, atau izin baca/tulis yang tidak mencukupi.

Solusi

Langkah 1: Ambil perintah startup ossfs asli

1. Periksa event `FailedMount` untuk melihat keluaran dari kegagalan pemasangan. Untuk informasi lebih lanjut, lihat Skenario 1: Kegagalan Pemasangan.

2. Ambil perintah startup ossfs asli dari keluaran kegagalan pemasangan.

   Berikut adalah contoh keluaran kegagalan pemasangan:

   Warning  FailedMount  3s  kubelet  MountVolume.SetUp failed for volume "<PV_NAME>" : rpc error: code = Unknown desc = Mount is failed in host, mntCmd:systemd-run --scope -- /usr/local/bin/ossfs <BUCKET>:/<PATH> /var/lib/kubelet/pods/<POD_UID>/volumes/kubernetes.io~csi/<PV_NAME>/mount -ourl=oss-cn-beijing-internal.aliyuncs.com -o allow_other , err: ..... with error: exit status 1

   Dalam `mntCmd`, konten setelah systemd-run --scope -- adalah perintah startup ossfs asli. Perintah startup ossfs asli adalah sebagai berikut:

   /usr/local/bin/ossfs <BUCKET>:/<PATH> /var/lib/kubelet/pods/<POD_UID>/volumes/kubernetes.io~csi/<PV_NAME>/mount -ourl=oss-cn-beijing-internal.aliyuncs.com -o allow_other

Langkah 2: Pasang ossfs di latar depan dan ambil log debug

Secara default, hanya pengguna yang menjalankan perintah pemasangan yang dapat mengakses direktori yang dipasang oleh ossfs. Pengguna lain tidak dapat mengakses direktori tersebut. Oleh karena itu, jika perintah asli tidak menyertakan item konfigurasi -o allow_other, masalah izin mungkin terjadi pada jalur pemasangan root.

1. Pastikan apakah ada masalah izin jalur titik pemasangan.

   Jika ada masalah izin, tambahkan item konfigurasi -o allow_other saat membuat PV. Untuk informasi lebih lanjut tentang cara mengonfigurasi izin akses untuk titik pemasangan ossfs, lihat Pasang bucket. Untuk informasi lebih lanjut tentang cara menambahkan item konfigurasi, lihat Gunakan volume ossfs 1.0 yang disediakan secara statis.

2. Jalankan perintah berikut di node tempat Pod aplikasi berada untuk menjalankan ossfs di latar depan dan mengatur mode log ke Debug.

   Dalam perintah ini, /test adalah jalur titik pemasangan uji. Proses ossfs yang berjalan di latar depan memasang bucket OSS ke /test.

   mkdir /test && /usr/local/bin/ossfs <BUCKET>:/<PATH> /test -ourl=oss-cn-beijing-internal.aliyuncs.com -f -o allow_other -o dbglevel=debug -o curldbg

   Parameter	Deskripsi
   -f	Menjalankan ossfs di latar depan, bukan sebagai proses daemon. Dalam mode latar depan, log dikeluarkan ke layar terminal. Parameter ini biasanya digunakan untuk debugging.
   -o allow_other	Memberikan izin kepada pengguna lain di komputer untuk mengakses direktori yang dipasang. Ini mencegah masalah izin jalur titik pemasangan baru saat memasang ossfs di latar depan.
   -o dbglevel=debug	Mengatur tingkat log ossfs ke debug.
   -o curldbg	Mengaktifkan logging libcurl untuk memecahkan masalah kesalahan yang dikembalikan oleh server OSS.

Langkah 3: Analisis log debug

Setelah Anda menjalankan ossfs di latar depan, log dikeluarkan ke terminal. Umumnya, kesalahan ossfs terbagi menjadi dua kategori: kesalahan dari ossfs itu sendiri dan kode kesalahan non-200 yang dikembalikan oleh server OSS setelah permintaan. Contoh berikut untuk setiap jenis kesalahan menunjukkan metode pemecahan masalah umum.

Contoh berikut menunjukkan cara memecahkan masalah ketika ossfs keluar segera setelah dimulai selama kegagalan pemasangan.

ossfs: Direktori MOUNTPOINT /test tidak kosong. Jika Anda yakin ini aman, Anda dapat menggunakan opsi pemasangan 'nonempty'.

[INFO]       Jul 10 2023:13:03:47:/tmp/ossfs/src/curl.cpp:RequestPerform(2382): Kode respons HTTP 404 dikembalikan, mengembalikan ENOENT, Teks Isi: <?xml version="1.0" encoding="UTF-8"?>
<Error>
  <Code>NoSuchBucket</Code>
  <Message>The specified bucket does not exist.</Message>
  <RequestId>xxxx</RequestId>
  <HostId><BUCKET>.oss-cn-beijing-internal.aliyuncs.com</HostId>
  <BucketName><BUCKET></BucketName>
  <EC>0015-00000101</EC>
</Error>

Versi plugin CSI 1.26.6 dan versi selanjutnya

Gejala

Pod aplikasi berada dalam status `Running`, tetapi ossfs melaporkan kesalahan saat perintah POSIX, seperti perintah baca atau tulis, dijalankan.

Penyebab

1. Pastikan apakah kontainer ossfs berjalan sebagaimana mestinya.

   Catatan

   • Dalam perintah tersebut, <NODE_NAME> adalah nama node tempat Pod aplikasi yang bermasalah berada.

   • Dalam perintah tersebut, <VOLUME_ID> biasanya merupakan nama PV aplikasi. Anda harus mengambil nilai ini dalam dua skenario berikut:

     • Jika nama PV berbeda dari nilai bidang `volumeHandle` PV, gunakan bidang `volumeHandle`. Jalankan perintah berikut untuk mengambil nilai `volumeHandle` suatu PV:

       kubectl get pv <PV_NAME> -o jsonpath='{.spec.csi.volumeHandle}'

     • Jika nama PV terlalu panjang, <VOLUME_ID> dibentuk dengan menggabungkan "h1." dengan nilai SHA-1-nya. Jalankan perintah berikut untuk mengambil nilai ini:

       echo -n "<PV_NAME>" | sha1sum | sed 's/^/h1./'

       Jika sistem Anda tidak mendukung operasi sha1sum, Anda juga dapat menggunakan library OpenSSL untuk mengambil nilai tersebut:

       echo -n "<PV_NAME>" | openssl sha1 -binary | xxd -p -c 40 | sed 's/^/h1./'

   • CSI v1.30.4 dan versi selanjutnya

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

     Karena versi ini menambahkan proses daemon ke dalam kontainer ossfs, keluaran yang diharapkan sama terlepas dari apakah proses ossfs berjalan sebagaimana mestinya:

     NAME                   READY   STATUS             RESTARTS     AGE
     csi-fuse-ossfs-xxxx    1/1     Running            0            5s

     Jika kontainer ossfs tidak dalam status `Running`, pecahkan masalah tersebut terlebih dahulu.

   • Versi CSI sebelum v1.30.4

     kubectl -n kube-system get pod -l csi.alibabacloud.com/volume-id=<VOLUME_ID> -o wide | grep <NODE_NAME>

     Jika kontainer ossfs tidak berjalan sebagaimana mestinya, keluarannya sebagai berikut:

     NAME                   READY   STATUS             RESTARTS     AGE
     csi-fuse-ossfs-xxxx    0/1     CrashLoopBackOff   1 (4s ago)   5s

2. Periksa log aplikasi untuk memastikan perintah yang menyebabkan kesalahan dan jenis kesalahan yang dikembalikan. Misalnya, I/O error dikembalikan saat Anda menjalankan perintah chmod -R 777 /mnt/path.

Penyebab event ini: Setelah komponen CSI memulai kontainer ossfs, Pod ossfs berjalan sebagaimana mestinya dan memasang bucket OSS ke jalur titik pemasangan yang ditentukan di node tempat Pod aplikasi berada. Namun, saat perintah POSIX seperti `chmod`, `read`, atau `open` dijalankan, ossfs berjalan secara abnormal, mengembalikan kesalahan, dan mencetak kesalahan yang sesuai ke log.

Solusi

1. Ambil log kontainer ossfs.

   • Untuk CSI v1.30.4 dan versi selanjutnya

     kubectl -n ack-csi-fuse logs csi-fuse-ossfs-xxxx 

   • Untuk versi CSI sebelum v1.30.4

     kubectl -n kube-system logs csi-fuse-ossfs-xxxx 

     Jika Pod berada dalam status `CrashLoopBackOff`, ambil log dari keluaran tak terduga sebelumnya Pod tersebut:

     kubectl -n kube-system logs -p csi-fuse-ossfs-xxxx 

2. (Opsional) Jika log kosong atau tidak memberikan informasi yang cukup untuk mengidentifikasi masalah, tingkat log mungkin terlalu tinggi. Dalam hal ini, tambahkan konfigurasi yang diperlukan sebagai berikut.

   Catatan

   Metode ini tidak mengharuskan Anda membuat ulang PV debug baru dan klaim volume persisten (PVC) yang sesuai. Namun, Anda tidak dapat langsung mengambil tanggapan permintaan REST dari OSS.

   1. Buat PV OSS untuk debugging. Berdasarkan konfigurasi PV asli, tambahkan -o dbglevel=debug -o curldbg ke bidang otherOpts. Setelah Anda memasang PV OSS baru tersebut, jalankan perintah kubectl logs untuk mengambil log debug dari Pod ossfs.

      Penting

      Log debug bisa sangat besar. Kami merekomendasikan agar Anda hanya menggunakan pengaturan ini untuk debugging.

   2. Gunakan konten berikut untuk membuat ConfigMap bernama `csi-plugin` di namespace `kube-system`. Atur tingkat log menjadi debug.

      Catatan

      Untuk plugin CSI v1.28.2 dan versi sebelumnya, Anda hanya dapat mengatur tingkat log ke `info`.

      apiVersion: v1
      kind: ConfigMap
      metadata:
        name: csi-plugin
        namespace: kube-system
      data:
        fuse-ossfs: |
          dbglevel=debug     # Tingkat log

      Mulai ulang Pod `csi-plugin` di node tempat aplikasi berada dan semua Pod `csi-provisioner` untuk menerapkan konfigurasi ConfigMap. Mulai ulang Pod aplikasi untuk memicu pemasangan ulang, dan pastikan Pod csi-fuse-ossfs-xxxx diterapkan ulang setelah pemasangan ulang.

      Penting

      ConfigMap adalah konfigurasi global. Setelah debugging, hapus ConfigMap tersebut. Kemudian, mulai ulang Pod `csi-plugin` di node dan semua Pod `csi-provisioner` lagi untuk mematikan logging debug. Terakhir, mulai ulang Pod aplikasi untuk memicu pemasangan ulang lainnya guna mencegah ossfs menghasilkan log debug berlebihan.

3. Analisis log kontainer ossfs.

   Umumnya, kesalahan ossfs terbagi menjadi dua kategori: kesalahan dari ossfs itu sendiri dan kode kesalahan non-200 yang dikembalikan oleh server OSS setelah permintaan. Contoh berikut untuk setiap jenis kesalahan menunjukkan metode pemecahan masalah umum.

   Kesalahan dari ossfs itu sendiri

   Bagian ini menggunakan kesalahan yang terjadi saat Anda menjalankan perintah chmod -R 777 <mount_point_path_in_application_pod> sebagai contoh untuk menunjukkan cara memecahkan masalah tersebut.

   1. Jika jalur pemasangan uji untuk ossfs adalah /test, jalankan perintah berikut.

      chmod -R 777 /test

      Setelah Anda memeriksa log, Anda menemukan bahwa operasi `chmod` berhasil untuk file di jalur titik pemasangan /test, tetapi operasi `chmod` pada /test itu sendiri menghasilkan log kesalahan berikut.

      [ERROR]  2023-10-18 06:03:24:/tmp/ossfs/src/ossfs.cpp:ossfs_chmod(1745): Tidak dapat mengubah mode untuk titik pemasangan.

      Berdasarkan pesan log tersebut, Anda tidak dapat mengubah izin jalur titik pemasangan menggunakan `chmod`. Untuk informasi lebih lanjut tentang cara memodifikasi izin titik pemasangan, lihat FAQ volume ossfs 1.0.

      Catatan

      Anda dapat menemukan solusi dalam topik FAQ ossfs pada dokumentasi OSS berdasarkan log kesalahan. Jika Anda tidak dapat menemukan penyebabnya, kirim tiket.

   Kode kesalahan non-200 yang dikembalikan oleh server OSS

   Contoh berikut menunjukkan cara memecahkan masalah ketika kesalahan dikembalikan untuk semua operasi pada objek di bucket.

   [INFO]        2023-10-18 06:05:46:/tmp/ossfs/src/curl.cpp:HeadRequest(3014): [tpath=/xxxx]
   [INFO]        2023-10-18 06:05:46:/tmp/ossfs/src/curl.cpp:PreHeadRequest(2971): [tpath=/xxxx][bpath=][save=][sseckeypos=-1]
   [INFO]        2023-10-18 06:05:46:/tmp/ossfs/src/curl.cpp:prepare_url(4660): URL adalah http://oss-cn-beijing-internal.aliyuncs.com/<bucket>/<path>/xxxxx
   [INFO]        2023-10-18 06:05:46:/tmp/ossfs/src/curl.cpp:prepare_url(4693): URL berubah menjadi http://<bucket>.oss-cn-beijing-internal.aliyuncs.com/<path>/xxxxx
   [INFO]        2023-10-18 06:05:46:/tmp/ossfs/src/curl.cpp:RequestPerform(2383): Kode respons HTTP 404 dikembalikan, mengembalikan ENOENT, Teks Isi:

   Jalankan perintah yang menyebabkan kesalahan. Kode kembalian HTTP dari server OSS yang dicetak sebelum keluar adalah 404. Penyebabnya disimpulkan karena objek tersebut tidak ada di server OSS. Untuk informasi lebih lanjut tentang penyebab masalah ini dan solusinya, lihat kesalahan 404.

   Catatan

   Anda dapat menemukan solusi dalam topik Kode Kesalahan HTTP pada dokumentasi OSS menggunakan kode kesalahan dan pesan kesalahan tersebut.

   Informasi tambahan

   Instruksi tingkat log

   Jika tingkat log terlalu tinggi sehingga tidak dapat mengidentifikasi masalah, dan Anda memiliki persyaratan berikut:

   • Anda tidak ingin membuat ulang PV OSS.

   • Anda khawatir konfigurasi ConfigMap global dapat memengaruhi operasi lain, seperti pemasangan atau pencopotan pemasangan PV OSS lain selama debugging.

   Dalam kasus ini, Anda dapat memasang ossfs di latar depan dan mengambil log debug untuk mengidentifikasi masalah. Untuk langkah-langkah spesifiknya, lihat solusi untuk versi plugin CSI sebelum 1.26.6.

   Penting

   Setelah ossfs dikontainerisasi, ossfs tidak diinstal pada node secara default. Versi ossfs yang Anda instal secara manual mungkin berbeda dari versi yang berjalan di dalam Pod. Kami merekomendasikan agar Anda terlebih dahulu mencoba solusi yang dijelaskan di atas dengan mengubah parameter pemasangan PV atau konfigurasi ConfigMap global.

   Untuk memasang ossfs, lakukan langkah-langkah berikut.

   1. Instal versi terbaru ossfs.

   2. Di node, jalankan perintah berikut untuk mengambil nilai SHA-256 dari nama PV.

      echo -n "<PV_NAME>" | sha256sum

      Jika sistem Anda tidak mendukung operasi `sha256sum`, Anda juga dapat menggunakan library OpenSSL untuk mengambil nilai tersebut:

      echo -n "<PV_NAME>" | openssl sha256 -binary | xxd -p -c 256

      Untuk "pv-oss", keluaran yang diharapkan adalah:

      8f3e75e1af90a7dcc66882ec1544cb5c7c32c82c2b56b25a821ac77cea60a928

   3. Di node, jalankan perintah berikut untuk mengambil parameter pemasangan ossfs.

      ps -aux | grep <sha256-value>

      Keluarannya berisi catatan proses untuk ossfs.

   4. Di node, jalankan perintah berikut untuk menghasilkan informasi autentikasi yang diperlukan untuk memasang ossfs. Setelah debugging, segera hapus file ini.

      mkdir -p /etc/ossfs && echo "<bucket-name>:<akId>:<akSecret>" > /etc/ossfs/passwd-ossfs && chmod 600 /etc/ossfs/passwd-ossfs

   Pemecahan masalah segmentation fault

   Jika log kesalahan berisi "ossfs exited with error" err="signal: segmentation fault (core dumped) ", ini menunjukkan bahwa proses ossfs keluar secara tak terduga karena segmentation fault selama runtime.

   Untuk membantu dukungan teknis mengidentifikasi masalah, masuk ke node logon, ikuti prosedur di bawah ini untuk mendapatkan file core dump, lalu kirim tiket.

   1. Temukan catatan crash proses ossfs.

      coredumpctl list

      Keluaran yang diharapkan:

      TIME                          PID       UID   GID  SIG   COREFILE   EXE
      Mon 2025-11-17 11:21:44 CST   2108767   0     0    1     present    /usr/bin/xxx
      Tue 2025-11-18 19:35:58 CST   493791    0     0    1     present    /usr/local/bin/ossfs

      Keluaran di atas menunjukkan bahwa dua proses di node ini telah keluar karena segmentation fault.

      Temukan catatan yang akan dipecahkan berdasarkan waktu (TIME) dan nama proses (EXE), lalu catat PID-nya. Dalam contoh di atas, PID-nya adalah 493791.

   2. Ekspor file core dump. Gunakan PID dari langkah sebelumnya dan jalankan perintah berikut untuk mengekspor file core. Parameter --output menentukan nama file yang dihasilkan.

      # Ganti <PID> dengan PID yang sebenarnya
      coredumpctl dump <PID> --output ossfs.dump

   3. kirim tiket dan berikan file ossfs.dump yang dihasilkan.

Versi plugin CSI sebelum 1.26.6

Gejala

Pod aplikasi berada dalam status `Running`, tetapi ossfs melaporkan kesalahan saat perintah POSIX, seperti perintah baca atau tulis, dijalankan.

Penyebab

Periksa log aplikasi untuk memastikan perintah yang menyebabkan kesalahan dan jenis kesalahan yang dikembalikan. Misalnya, I/O error dikembalikan saat Anda menjalankan perintah chmod -R 777 /mnt/path.

Anda dapat menjalankan perintah berikut untuk masuk ke Pod aplikasi dan memastikan.

kubectl -n <POD_NAMESPACE> exec -it <POD_NAME> -- /bin/bash

bash-4.4# chmod -R 777 /mnt/path
chmod: /mnt/path: I/O error

Penyebab event ini: Event ini terjadi karena setelah komponen CSI memulai ossfs, proses ossfs berjalan sebagaimana mestinya dan memasang bucket OSS ke jalur titik pemasangan yang ditentukan di node tempat Pod aplikasi berada. Namun, saat perintah POSIX seperti chmod, read, atau open dijalankan, ossfs berjalan secara abnormal dan mengembalikan kesalahan.

Solusi

Langkah 1: Ambil perintah startup ossfs asli

Karena ossfs sudah berjalan di node, Anda dapat menjalankan perintah berikut di node tempat Pod aplikasi berada untuk mengambil perintah startup ossfs asli menggunakan nama volume OSS.

ps -aux | grep ossfs | grep <PV_NAME>

Keluaran yang diharapkan:

root     2097450  0.0  0.2 124268 33900 ?        Ssl  20:47   0:00 /usr/local/bin/ossfs <BUCKET> /<PATH> /var/lib/kubelet/pods/<POD_UID>/volumes/kubernetes.io~csi/<PV_NAME>/mount -ourl=oss-cn-beijing-internal.aliyuncs.com -o allow_other

Dalam perintah tersebut, ganti spasi setelah <BUCKET> dengan tanda titik dua (:). Artinya, ubah <BUCKET> /<PATH> menjadi <BUCKET>:/<PATH>. Perintah startup ossfs asli adalah sebagai berikut.

/usr/local/bin/ossfs <BUCKET>:/<PATH> /var/lib/kubelet/pods/<POD_UID>/volumes/kubernetes.io~csi/<PV_NAME>/mount -ourl=oss-cn-beijing-internal.aliyuncs.com -o allow_other

Langkah 2: Pasang ossfs di latar depan dan ambil log debug

Secara default, hanya pengguna yang menjalankan perintah pemasangan yang dapat mengakses direktori yang dipasang oleh ossfs. Pengguna lain tidak dapat mengakses direktori tersebut. Oleh karena itu, jika perintah asli tidak menyertakan item konfigurasi -o allow_other, masalah izin mungkin terjadi pada jalur pemasangan root.

1. Pastikan apakah ada masalah izin jalur titik pemasangan.

   Jika ada masalah izin, tambahkan item konfigurasi -o allow_other saat membuat PV. Untuk informasi lebih lanjut tentang cara mengonfigurasi izin akses untuk titik pemasangan ossfs, lihat Pasang bucket. Untuk informasi lebih lanjut tentang cara menambahkan item konfigurasi, lihat Gunakan volume ossfs 1.0 yang disediakan secara statis.

2. Jalankan perintah berikut di node tempat Pod aplikasi berada untuk menjalankan ossfs di latar depan dan mengatur mode log ke Debug.

   Dalam perintah ini, /test adalah jalur titik pemasangan uji. Proses ossfs yang berjalan di latar depan memasang bucket OSS ke /test.

   mkdir /test && /usr/local/bin/ossfs <BUCKET>:/<PATH> /test -ourl=oss-cn-beijing-internal.aliyuncs.com -f -o allow_other -o dbglevel=debug -o curldbg

   Parameter	Deskripsi
   -f	Menjalankan ossfs di latar depan, bukan sebagai proses daemon. Dalam mode latar depan, log dikeluarkan ke layar terminal. Parameter ini biasanya digunakan untuk debugging.
   -o allow_other	Memberikan izin kepada pengguna lain di komputer untuk mengakses direktori yang dipasang. Ini mencegah masalah izin jalur titik pemasangan baru saat memasang ossfs di latar depan.
   -o dbglevel=debug	Mengatur tingkat log ossfs ke debug.
   -o curldbg	Mengaktifkan logging libcurl untuk memecahkan masalah kesalahan yang dikembalikan oleh server OSS.

Langkah 3: Analisis log debug

Setelah Anda menjalankan ossfs di latar depan, log dikeluarkan ke terminal. Umumnya, kesalahan ossfs terbagi menjadi dua kategori: kesalahan dari ossfs itu sendiri dan kode kesalahan non-200 yang dikembalikan oleh server OSS setelah permintaan. Contoh berikut untuk setiap jenis kesalahan menunjukkan metode pemecahan masalah umum.

Jika perintah POSIX gagal, Anda perlu membuka terminal lain untuk menjalankan ulang perintah tersebut dan menganalisis log ossfs yang baru.

chmod -R 777 /test

[ERROR] Jul 10 2023:13:03:18:/tmp/ossfs/src/ossfs.cpp:ossfs_chmod(1742): Tidak dapat mengubah mode untuk titik pemasangan.

[INFO]       Aug 23 2022:11:54:11:/tmp/ossfs/src/curl.cpp:RequestPerform(2377): Kode respons HTTP 404 dikembalikan, mengembalikan ENOENT, Teks Isi: <?xml version="1.0" encoding="UTF-8"?>
<Error>
  <Code>NoSuchKey</Code>
  <Message>The specified key does not exist.</Message>
  <RequestId>xxxx</RequestId>
  <HostId><BUCKET>.oss-cn-beijing-internal.aliyuncs.com</HostId>
  <Key><object-name></Key>
  <EC>0026-00000001</EC>
</Error>