Container Service for Kubernetes：FAQ volume persisten ossfs 2.0

Mount volume persisten OSS gagal

Gejala

Saat memasang PV OSS menggunakan ossfs 2.0, Pod gagal dimulai dan menghasilkan error FailedMount dalam event Pod.

Penyebab

• Penyebab 1: Mount gagal karena AccessKey tidak memiliki izin yang diperlukan.

• Penyebab 2: Log event berisi pesan error 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 berjalan di node virtual (Pod ACS), jika PersistentVolumeClaim (PVC) menggunakan field nodePublishSecretRef untuk menentukan kredensial autentikasi, Secret tersebut harus berada di namespace yang sama dengan PVC.

• Penyebab 3: Log event berisi pesan error FailedMount /run/fuse.ossfs/xxxxxx/mounter.sock: connect: no such file or directory. Error ini terjadi karena Pod ossfs 2.0 tidak dimulai dengan benar atau dihapus secara tak terduga.

• Penyebab 4: Bucket OSS dikonfigurasi untuk mirroring-based back-to-origin, dan direktori mount belum disinkronkan dari origin.

• Penyebab 5: Bucket OSS dikonfigurasi untuk static website hosting. Saat ossfs 2.0 memeriksa direktori mount di OSS, permintaan dialihkan ke file seperti index.html.

Solusi

• Solusi untuk Penyebab 1

  • Verifikasi bahwa kebijakan akses Pengguna RAM yang digunakan untuk mount memenuhi persyaratan. Untuk informasi lebih lanjut, lihat Gunakan volume ossfs 2.0 yang diprovisikan secara statis.

  • Periksa apakah AccessKey yang digunakan untuk mount telah dinonaktifkan atau dirotasi.

    Penting

    Perubahan pada AccessKey dalam Secret yang ditentukan oleh field nodePublishSecretRef di PV tidak langsung berlaku. Anda harus me-restart Pod klien ossfs 2.0. Untuk informasi lebih lanjut tentang cara me-restart klien, lihat Cara me-restart proses ossfs 2.0.

• Solusi untuk Penyebab 2

  Buat Secret yang diperlukan di namespace yang sama dengan PVC. Saat membuat PV baru, atur field nodePublishSecretRef ke Secret ini. Untuk informasi lebih lanjut, lihat Metode 2: Autentikasi menggunakan AccessKey Pengguna RAM.

• Solusi untuk Penyebab 3

  1. Verifikasi bahwa Pod ossfs 2.0 ada.

     Dalam perintah berikut, PV_NAME menentukan nama PV OSS yang dipasang, dan NODE_NAME menentukan 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 keadaan abnormal, lakukan troubleshooting pada Pod tersebut untuk menyelesaikan masalah. Pastikan Pod berada dalam status Running, lalu restart Pod aplikasi untuk memicu remount.

     • Jika Pod tidak ada, lanjutkan ke langkah berikutnya.

  2. (Opsional) Periksa log audit atau catatan lain untuk menentukan apakah Pod dihapus secara tak terduga.

     Alasan umum penghapusan tak terduga meliputi skrip pembersihan, operasi drain node, dan pemulihan otomatis node. Sesuaikan konfigurasi Anda untuk mencegah masalah ini terulang.

  3. Periksa apakah ada sisa resource VolumeAttachment.

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

  4. Restart Pod aplikasi untuk memicu remount dan verifikasi bahwa Pod ossfs 2.0 berhasil dibuat.

• Solusi untuk Penyebab 4

  Anda harus menyinkronkan data dari origin sebelum memasang volume. Untuk informasi lebih lanjut, lihat Konfigurasi back-to-origin.

• Solusi untuk Penyebab 5

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

Cara memasang file tunggal dari bucket OSS menggunakan volume persisten

Tool ossfs 2.0 dapat memasang path dari bucket OSS sebagai sistem file di dalam Pod, tetapi tidak dapat memasang file tunggal secara langsung. Untuk memungkinkan Pod mengakses file tertentu di OSS, Anda dapat menggunakan opsi subpath.

Sebagai contoh, untuk memasang file a.txt dan b.txt dari direktori /subpath bucket OSS ke dua Pod berbeda pada path /path/to/file/, gunakan konfigurasi PV 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"
      fuseType: ossfs2

Setelah membuat PVC yang sesuai, konfigurasikan volumeMounts di Pod sebagai berikut:

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

Setelah dipasang, path lengkap untuk mengakses a.txt di Pod adalah /path/to/file/a.txt, yang sesuai dengan bucket:/subpath/a.txt.

Untuk informasi lebih lanjut, lihat Gunakan volume ossfs 2.0 yang diprovisikan secara statis.

Cara memasang Bucket OSS lintas akun berbeda

Anda dapat menggunakan otorisasi berbasis RRSA untuk memasang Bucket OSS lintas akun berbeda.

Pastikan versi kluster dan komponen CSI Anda memenuhi persyaratan untuk otorisasi berbasis RRSA.

Langkah-langkah berikut menjelaskan cara memasang bucket dari Akun B, tempat Bucket OSS berada, ke kluster di Akun A, tempat kluster berada. Sebelum membuat volume dengan otorisasi berbasis RRSA, Anda harus menyelesaikan prasyarat otorisasi RAM.

1. Di Akun B:

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

   2. Berikan izin roleB untuk mengakses Bucket OSS yang ingin Anda pasang.

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

2. Di Akun A:

   1. Buat peran RAM bernama roleA untuk otorisasi berbasis RRSA bagi aplikasi. Atur tipe entitas tepercaya ke OIDC IdP.

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

      roleA tidak memerlukan kebijakan akses untuk OSS. Namun, roleA memerlukan kebijakan akses yang mencakup tindakan API sts:AssumeRole, seperti kebijakan sistem AliyunSTSAssumeRoleAccess.

3. Konfigurasikan volume di kluster:

   Saat membuat volume, atur parameter assumeRoleArn ke ARN roleB:

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

     assumeRoleArn: <ARN of roleB>

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

     assumeRoleArn: <ARN of roleB>

Cara menggunakan ARN atau ServiceAccount tertentu untuk otorisasi berbasis RRSA

Saat menggunakan RRSA untuk autentikasi PV OSS, Anda mungkin memiliki kebutuhan yang tidak dapat dipenuhi oleh pengaturan default, seperti menggunakan OIDC IdP pihak ketiga atau ServiceAccount non-default.

Untuk mengatasi hal ini, Anda dapat menentukan nama peran RAM menggunakan item konfigurasi roleName di PV. Plugin penyimpanan CSI kemudian secara otomatis mengambil ARN peran default dan ARN penyedia OIDC default. Untuk otorisasi berbasis RRSA yang lebih disesuaikan, Anda dapat memodifikasi konfigurasi PV sebagai berikut.

Parameter roleArn dan oidcProviderArn harus dikonfigurasi bersamaan. Jika Anda mengatur parameter ini, Anda tidak perlu mengonfigurasi roleName.

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"
      authType: "rrsa"
      fuseType: "ossfs2"
      oidcProviderArn: "<oidc-provider-arn>"
      roleArn: "<role-arn>"
      #roleName: "<role-name>" # Setelah Anda mengonfigurasi roleArn dan oidcProviderArn, roleName menjadi tidak valid.
      serviceAccountName: "csi-fuse-<service-account-name>" 

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

OSS tidak membatasi kapasitas bucket atau subdirektori, juga tidak menyediakan fitur kuota kapasitas. Oleh karena itu, field .spec.capacity dari PV dan field .spec.resources.requests.storage dari 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 scale-out volume.

Cara me-restart proses ossfs 2.0

Gejala

Setelah Anda memodifikasi informasi otorisasi atau versi ossfs 2.0, proses ossfs 2.0 yang sedang berjalan tidak diperbarui secara otomatis.

Penyebab

• Setelah proses ossfs 2.0 dimulai, Anda tidak dapat mengubah konfigurasinya secara dinamis, seperti kredensial autentikasi. Memodifikasi konfigurasi memerlukan me-restart proses ossfs 2.0 (Pod bernama csi-fuse-ossfs2-* di namespace ack-csi-fuse) dan Pod aplikasi terkait, yang menyebabkan gangguan layanan. Karena alasan ini, CSI tidak menerapkan perubahan secara otomatis pada proses ossfs 2.0 yang sedang berjalan.

• Selama operasi normal, CSI sepenuhnya mengelola siklus hidup volume ossfs 2.0. Jika Anda menghentikan Pod yang menjalankan ossfs 2.0 secara manual, CSI tidak dapat memicu pemulihan atau pembuatan ulang volume secara otomatis.

Solusi

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

   1. Identifikasi Pod csi-fuse-ossfs2-* yang ingin Anda ubah.

      Ganti <pv-name> dengan nama PV dan <node-name> dengan nama node.

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

   2. Identifikasi semua Pod yang memasang PV OSS ini.

      Ganti <ns> dengan namespace dan <pvc-name> dengan nama PVC.

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

      Output yang diharapkan berisi field Used By:

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

   3. Temukan Pod aplikasi yang dipasang melalui csi-fuse-ossfs2-xxxx. Ini adalah Pod yang berjalan di node yang sama dengan csi-fuse-ossfs2-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.xx.xx    cn-beijing.192.168.xx.xx     <none>           <none>
      oss-static-94849f647-6****   1/1     Running   0          7m36s   192.168.xx.xx    cn-beijing.192.168.xx.xx     <none>           <none>

2. Restart aplikasi dan proses ossfs 2.0.

   Hapus semua Pod aplikasi (pada contoh sebelumnya, oss-static-94849f647-4**** dan oss-static-94849f647-6****) secara bersamaan menggunakan perintah seperti kubectl scale. Ketika tidak ada Pod aplikasi yang menggunakan mount, Pod csi-fuse-ossfs2-xxxx akan secara otomatis dihapus. Setelah jumlah replika dipulihkan, volume dipasang ulang dengan konfigurasi PV baru, dan CSI membuat Pod csi-fuse-ossfs2-yyyy yang baru.

   Jika Anda tidak dapat memastikan Pod tersebut dihapus secara bersamaan (misalnya, menghapus Pod yang dikelola oleh Deployment, StatefulSet, atau DaemonSet segera memicu restart), atau jika Pod dapat mentolerir kegagalan baca/tulis OSS, jalankan perintah berikut untuk menemukan resource VolumeAttachment yang sesuai dengan volume:

   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

   Hapus langsung VolumeAttachment tersebut. Pada titik ini, operasi baca/tulis ke OSS dari Pod aplikasi akan mengembalikan error disconnected.

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