All Products
Search
Document Center

Container Service for Kubernetes:Pasang volume OSS dinamis menggunakan ossfs 2.0 di kluster ACK

Last Updated:Mar 27, 2026

Pasang bucket Object Storage Service (OSS) sebagai Persistent Volume (PV) di kluster ACK menggunakan ossfs 2.0 — klien berbasis FUSE (Filesystem in Userspace) yang dioptimalkan untuk beban kerja baca dan tulis sekuensial. Dengan penyediaan dinamis, StorageClass bertindak sebagai templat yang secara otomatis membuat dan mengikat PV saat Anda membuat PersistentVolumeClaim (PVC), sehingga aplikasi Anda dapat membaca dan menulis data OSS melalui antarmuka POSIX standar tanpa perlu mengelola PV secara manual.

ossfs 2.0 unggul dalam throughput sekuensial, sehingga sangat cocok untuk pelatihan AI, inferensi, dan pemrosesan big data. Untuk tolok ukur kinerja, lihat tolok ukur kinerja klien ossfs 2.0.

Sebelum memulai

Periksa batasan berikut sebelum memulai. ossfs 2.0 tidak cocok untuk semua workload — melanjutkan tanpa memeriksa hal-hal ini akan membuang waktu Anda.

Berhenti di sini jika salah satu kondisi berikut berlaku bagi Anda:

  • Tulisan acak atau konkuren: ossfs 2.0 tidak dapat menjamin konsistensi data untuk operasi tulis acak atau konkuren. Gunakan ossfs 1.0 untuk database, pengeditan kolaboratif, atau workload apa pun yang memodifikasi konten file secara langsung.

  • Versi Kubernetes di bawah 1.26: Autentikasi RRSA memerlukan Kubernetes 1.26 atau lebih baru. Tingkatkan kluster Anda jika diperlukan.

  • Versi plugin CSI di bawah 1.33.1: Kedua metode autentikasi memerlukan plugin CSI versi 1.33.1 atau lebih baru. Perbarui csi-plugin dan csi-provisioner jika diperlukan.

Sebelum memulai, pastikan Anda telah memiliki:

  • Kluster ACK dengan plugin CSI terinstal

  • Bucket OSS dalam Akun Alibaba Cloud yang sama dengan kluster Anda. Untuk memasang bucket lintas akun, gunakan autentikasi RRSA — lihat FAQ tentang volume ossfs 2.0 untuk detailnya.

Catatan penggunaan

  • Perubahan data bersifat langsung: Setiap modifikasi atau penghapusan file di titik pemasangan ossfs — baik dari dalam pod maupun dari node host — segera disinkronkan ke bucket OSS sumber. Aktifkan versioning untuk melindungi dari kehilangan data yang tidak disengaja.

  • Pemeriksaan kesehatan: Konfigurasikan liveness probe pada pod yang menggunakan volume OSS untuk memverifikasi ketersediaan titik pemasangan. Jika pemasangan menjadi tidak sehat, Kubernetes secara otomatis me-restart pod tersebut.

  • Multipart uploads: File yang lebih besar dari 10 MB secara otomatis diunggah menggunakan multipart upload. Jika unggahan terputus, bagian yang tidak lengkap tetap berada di bucket dan menimbulkan biaya penyimpanan. Konfigurasikan lifecycle rule untuk membersihkannya secara otomatis, atau hapus secara manual.

Pilih metode autentikasi

RRSA AccessKey
Jenis kredensial Temporary, auto-rotating (via OIDC + STS) Kunci statis jangka panjang
Cakupan izin Isolasi tingkat pod Dibagikan di seluruh pod yang menggunakan Secret yang sama
Cocok untuk Lingkungan produksi dan multi-tenant Hanya untuk pengembangan dan pengujian
Risiko Eksposur Kunci Rendah — kredensial kedaluwarsa secara otomatis Tinggi — kunci harus dicabut dan diputar secara manual
Rotasi kunci Otomatis Manual; memerlukan pembaruan Secret dan restart pod

Gunakan RRSA untuk lingkungan produksi. Autentikasi AccessKey hanya dapat diterima untuk pengembangan dan pengujian — kunci statis yang terekspos atau salah konfigurasi memerlukan pencabutan manual dan menyebabkan gangguan layanan selama rotasi.

Kedua metode mengikuti alur kerja yang sama:

  1. Siapkan kredensial (peran RAM untuk RRSA, atau pengguna RAM + Secret untuk AccessKey)

  2. Buat StorageClass

  3. Buat PVC

  4. Pasang volume di aplikasi Anda

Metode 1: Autentikasi menggunakan RRSA

RRSA (RAM Roles for Service Accounts) menyediakan isolasi izin tingkat pod menggunakan kredensial temporary dan auto-rotating melalui OpenID Connect (OIDC) dan Security Token Service (STS). Untuk latar belakang, lihat Gunakan RRSA untuk memberi otorisasi pod berbeda mengakses layanan cloud berbeda.

Catatan

Jika Anda menggunakan RRSA dengan plugin CSI versi sebelum 1.30.4, lihat \[Perubahan Produk\] Peningkatan versi dan optimalisasi proses pemasangan ossfs di CSI untuk perubahan otorisasi peran RAM yang diperlukan.

Langkah 1: Buat peran RAM

Lewati langkah ini jika Anda telah memasang volume OSS di kluster ini menggunakan RRSA.

  1. Aktifkan fitur RRSA di Konsol ACK.

  2. Buat peran RAM untuk Identity Provider OIDC. Gunakan parameter berikut untuk peran contoh demo-role-for-rrsa:

    Parameter Nilai
    Identity Provider Type Pilih OIDC
    Identity Provider Pilih provider yang terkait dengan kluster Anda, seperti ack-rrsa-<cluster_id>
    oidc:iss Pertahankan nilai default
    oidc:aud Pertahankan nilai default
    oidc:sub — Kunci Pilih oidc:sub
    oidc:sub — Operator Pilih StringEquals
    oidc:sub — Nilai Masukkan system:serviceaccount:ack-csi-fuse:csi-fuse-ossfs. Namespace ack-csi-fuse bersifat tetap dan tidak dapat dikustomisasi. Nama service account csi-fuse-ossfs dapat diubah — lihat FAQ tentang volume ossfs 2.0.
    Role Name Masukkan demo-role-for-rrsa

Langkah 2: Berikan izin OSS ke peran RAM

  1. Buat kebijakan kustom untuk memberikan akses OSS ke peran tersebut. Ganti mybucket dengan nama bucket aktual Anda.

    • Read-only access

      {
          "Statement": [
              {
                  "Action": [
                      "oss:Get*",
                      "oss:List*"
                  ],
                  "Effect": "Allow",
                  "Resource": [
                      "acs:oss:*:*:mybucket",
                      "acs:oss:*:*:mybucket/*"
                  ]
              }
          ],
          "Version": "1"
      }
    • Akses baca-tulis

      {
          "Statement": [
              {
                  "Action": "oss:*",
                  "Effect": "Allow",
                  "Resource": [
                      "acs:oss:*:*:mybucket",
                      "acs:oss:*:*:mybucket/*"
                  ]
              }
          ],
          "Version": "1"
      }
  2. (Opsional) Jika objek di bucket dienkripsi dengan customer master key (CMK) di Key Management Service (KMS), berikan juga akses KMS. Lihat Enkripsi.

  3. Berikan kebijakan kustom ke peran demo-role-for-rrsa.

    Catatan

    Untuk menggunakan kembali peran RAM yang sudah ada dan memiliki akses OSS, ubah kebijakan kepercayaannya. Lihat Gunakan peran RAM yang sudah ada dan berikan izin yang diperlukan ke peran RAM tersebut.

Langkah 3: Buat StorageClass

  1. Buat ossfs2-sc-rrsa.yaml:

    Parameter Wajib Deskripsi Default / perilaku jika dihilangkan
    bucket Ya Nama bucket OSS yang akan dipasang
    path Ya Path dasar di dalam bucket. Dengan volumeAs: sharepath, setiap PV mendapatkan subdirektori unik di bawah path ini, seperti /ack/<pv-name> Memasang root bucket jika dibiarkan kosong
    url Ya Titik akhir endpoint bucket OSS. Gunakan titik akhir internal (http://oss-<region>-internal.aliyuncs.com) jika kluster dan bucket berada di wilayah yang sama atau terhubung melalui Virtual Private Cloud (VPC). Gunakan titik akhir publik (http://oss-<region>.aliyuncs.com) untuk akses cross-region.
    Catatan

    Format titik akhir internal vpc100-oss-<region>.aliyuncs.com sudah tidak digunakan lagi — beralihlah ke format baru.

    fuseType Ya Harus diatur ke ossfs2 untuk menggunakan klien ossfs 2.0
    authType Ya Atur ke rrsa
    roleName Ya Peran RAM yang akan diasumsikan. Untuk memberikan izin berbeda per PV, buat peran RAM terpisah untuk setiap set izin dan tentukan di sini
    volumeAs Tidak Atur ke sharepath sehingga setiap PV membuat subdirektori terpisah di bawah path
    otherOpts Tidak Opsi pemasangan tambahan dalam format -o <flag> -o <flag>. Untuk semua opsi yang tersedia, lihat opsi pemasangan ossfs 2.0 Tidak ada opsi tambahan
    apiVersion: storage.k8s.io/v1
    kind: StorageClass
    metadata:
      name: ossfs2-sc
    parameters:
      bucket: cnfs-oss-test          # Nama bucket OSS Anda.
      path: /subpath                 # Subdirektori yang akan dipasang. Biarkan kosong untuk memasang root bucket.
      url: oss-cn-hangzhou-internal.aliyuncs.com  # Titik akhir internal (wilayah sama atau VPC); gunakan titik akhir publik untuk akses lintas wilayah.
      authType: rrsa
      roleName: demo-role-for-rrsa  # Peran RAM yang dibuat di Langkah 1.
      fuseType: ossfs2              # Harus ossfs2 untuk menggunakan klien ossfs 2.0.
      volumeAs: sharepath           # Setiap PV mendapatkan subdirektori unik di bawah path, misalnya /subpath/ack/<pv-name>.
      otherOpts: "-o close_to_open=false"  # false (default): cache metadata untuk latensi lebih rendah. true: ambil metadata segar setiap kali membuka file (meningkatkan latensi dan biaya API).
    provisioner: ossplugin.csi.alibabacloud.com  # Nilai tetap.
    reclaimPolicy: Retain           # Hanya Retain yang didukung. Menghapus PVC tidak menghapus PV atau data OSS.
    volumeBindingMode: Immediate    # Volume OSS tidak memiliki persyaratan afinitas node berbasis zona.

    Tabel berikut menjelaskan field parameters:

  2. Terapkan StorageClass:

    kubectl create -f ossfs2-sc-rrsa.yaml
  3. Verifikasi bahwa StorageClass telah dibuat:

    kubectl get sc ossfs2-sc

    Output yang diharapkan:

    NAME        PROVISIONER                      RECLAIMPOLICY   VOLUMEBINDINGMODE   ALLOWVOLUMEEXPANSION   AGE
    ossfs2-sc   ossplugin.csi.alibabacloud.com   Retain          Immediate                                  10s

Langkah 4: Buat PVC

Membuat PVC memicu penyediaan otomatis PV yang mendasarinya.

  1. Buat ossfs2-pvc-dynamic.yaml:

    kind: PersistentVolumeClaim
    apiVersion: v1
    metadata:
      name: pvc-ossfs2
      namespace: default
    spec:
      accessModes:
        - ReadWriteMany
      resources:
        requests:
          storage: 20Gi
      storageClassName: ossfs2-sc
  2. Buat PVC:

    kubectl create -f ossfs2-pvc-dynamic.yaml
  3. Verifikasi PVC terikat ke PV yang dibuat secara otomatis:

    kubectl get pvc pvc-ossfs2

    Output yang diharapkan:

    NAME        STATUS   VOLUME                   CAPACITY   ACCESS MODES   STORAGECLASS   AGE
    pvc-ossfs2  Bound    d-bp17y03tpy2b8x******   20Gi       RWX            ossfs2-sc      25s

Langkah 5: Pasang volume di aplikasi Anda

  1. Buat ossfs2-test.yaml. StatefulSet berikut memasang PVC di /data:

    apiVersion: apps/v1
    kind: StatefulSet
    metadata:
      name: ossfs2-test
      namespace: default
    spec:
      replicas: 1
      selector:
        matchLabels:
          app: ossfs2-test
      template:
        metadata:
          labels:
            app: ossfs2-test
        spec:
          containers:
          - name: nginx
            image: anolis-registry.cn-zhangjiakou.cr.aliyuncs.com/openanolis/nginx:1.14.1-8.6
            ports:
            - containerPort: 80
            volumeMounts:
            - name: pvc-ossfs2
              mountPath: /data
          volumes:
            - name: pvc-ossfs2
              persistentVolumeClaim:
                claimName: pvc-ossfs2
  2. Deploy aplikasi:

    kubectl create -f ossfs2-test.yaml
  3. Verifikasi pod sedang berjalan:

    kubectl get pod -l app=ossfs2-test

    Output yang diharapkan:

    NAME            READY   STATUS    RESTARTS   AGE
    ossfs2-test-0   1/1     Running   0          2m
  4. Verifikasi akses baca dan tulis ke titik pemasangan:

    # Tulis file uji
    kubectl exec -it ossfs2-test-0 -- touch /data/test.txt
    # Daftar file di titik pemasangan
    kubectl exec -it ossfs2-test-0 -- ls /data

    Output harus mencakup test.txt, yang mengonfirmasi volume telah dipasang dan dapat ditulis.

Metode 2: Autentikasi menggunakan AccessKey

Penting

Metode ini menggunakan kunci statis jangka panjang. Gunakan hanya untuk pengembangan dan pengujian. Untuk produksi, gunakan autentikasi RRSA sebagai gantinya.

Jika AccessKey yang dirujuk oleh PV dicabut atau izinnya diubah, setiap pod yang menggunakan volume tersebut langsung kehilangan akses. Untuk memulihkan akses: perbarui kredensial di Secret, lalu restart pod. Hal ini menyebabkan gangguan layanan singkat dan harus dilakukan selama jendela pemeliharaan.

Langkah 1: Buat pengguna RAM dan simpan kredensial di Secret

Buat pengguna RAM dan berikan izin OSS

  1. Buat pengguna RAM jika Anda belum memilikinya.

  2. Buat kebijakan kustom untuk memberikan akses OSS. Ganti mybucket dengan nama bucket aktual Anda.

    • Read-only access

      {
          "Statement": [
              {
                  "Action": [
                      "oss:Get*",
                      "oss:List*"
                  ],
                  "Effect": "Allow",
                  "Resource": [
                      "acs:oss:*:*:mybucket",
                      "acs:oss:*:*:mybucket/*"
                  ]
              }
          ],
          "Version": "1"
      }
    • Akses baca-tulis

      {
          "Statement": [
              {
                  "Action": "oss:*",
                  "Effect": "Allow",
                  "Resource": [
                      "acs:oss:*:*:mybucket",
                      "acs:oss:*:*:mybucket/*"
                  ]
              }
          ],
          "Version": "1"
      }
  3. (Opsional) Jika objek di bucket dienkripsi dengan CMK di KMS, berikan juga akses KMS. Lihat Enkripsi.

  4. Berikan kebijakan kustom ke pengguna RAM.

  5. Buat pasangan AccessKey untuk pengguna RAM tersebut.

Simpan AccessKey di Secret Kubernetes

Jalankan perintah berikut. Ganti nilai placeholder dengan ID dan Secret AccessKey Anda yang sebenarnya:

kubectl create -n default secret generic oss-secret \
  --from-literal='akId=<your-access-key-id>' \
  --from-literal='akSecret=<your-access-key-secret>'

Langkah 2: Buat StorageClass

  1. Buat ossfs2-sc.yaml:

    Konfigurasi Secret

    Parameter Wajib Deskripsi
    csi.storage.k8s.io/node-publish-secret-name Ya Nama Secret yang menyimpan AccessKey
    csi.storage.k8s.io/node-publish-secret-namespace Ya Namespace tempat Secret berada

    Konfigurasi volume

    Parameter Wajib Deskripsi Default / perilaku jika dihilangkan
    fuseType Ya Harus diatur ke ossfs2 untuk menggunakan klien ossfs 2.0
    bucket Ya Nama bucket OSS yang akan dipasang
    path Tidak Path pemasangan di dalam bucket, relatif terhadap root bucket Memasang root bucket jika dibiarkan kosong
    url Ya Titik akhir bucket OSS. Gunakan titik akhir internal (http://oss-<region>-internal.aliyuncs.com) untuk akses wilayah sama atau terhubung VPC, atau titik akhir publik (http://oss-<region>.aliyuncs.com) untuk akses lintas wilayah.
    Catatan

    Format titik akhir internal vpc100-oss-<region>.aliyuncs.com sudah tidak digunakan lagi.

    otherOpts Tidak Opsi pemasangan tambahan dalam format -o <flag> -o <flag>. Untuk semua opsi yang tersedia, lihat opsi pemasangan ossfs 2.0 Tidak ada opsi tambahan
    apiVersion: storage.k8s.io/v1
    kind: StorageClass
    metadata:
      name: ossfs2-sc
    parameters:
      csi.storage.k8s.io/node-publish-secret-name: oss-secret       # Secret yang dibuat di atas.
      csi.storage.k8s.io/node-publish-secret-namespace: default      # Namespace tempat Secret berada.
      fuseType: ossfs2              # Harus ossfs2 untuk menggunakan klien ossfs 2.0.
      bucket: cnfs-oss-test         # Nama bucket OSS Anda.
      path: /subpath                # Subdirektori yang akan dipasang. Biarkan kosong untuk memasang root bucket.
      url: oss-cn-hangzhou-internal.aliyuncs.com  # Titik akhir internal (wilayah sama atau VPC); gunakan titik akhir publik untuk akses lintas wilayah.
      otherOpts: "-o close_to_open=false"  # false (default): cache metadata untuk latensi lebih rendah. true: ambil metadata segar setiap kali membuka file (meningkatkan latensi dan biaya API).
    provisioner: ossplugin.csi.alibabacloud.com  # Nilai tetap.
    reclaimPolicy: Retain           # Hanya Retain yang didukung. Menghapus PVC tidak menghapus PV atau data OSS.
    volumeBindingMode: Immediate    # Volume OSS tidak memiliki persyaratan afinitas node berbasis zona.
  2. Buat StorageClass:

    kubectl create -f ossfs2-sc.yaml

Langkah 3: Buat PVC

  1. Buat ossfs2-pvc-dynamic.yaml:

    kind: PersistentVolumeClaim
    apiVersion: v1
    metadata:
      name: pvc-ossfs2
      namespace: default
    spec:
      accessModes:
        - ReadWriteMany
      resources:
        requests:
          storage: 20Gi
      storageClassName: ossfs2-sc
  2. Buat PVC:

    kubectl create -f ossfs2-pvc-dynamic.yaml
  3. Verifikasi PVC terikat:

    kubectl get pvc pvc-ossfs2

    Output yang diharapkan:

    NAME        STATUS   VOLUME                   CAPACITY   ACCESS MODES   STORAGECLASS   AGE
    pvc-ossfs2  Bound    d-bp17y03tpy2b8x******   20Gi       RWX            ossfs2-sc      25s

Langkah 4: Pasang volume di aplikasi Anda

  1. Buat ossfs2-test.yaml:

    apiVersion: apps/v1
    kind: StatefulSet
    metadata:
      name: ossfs2-test
      namespace: default
    spec:
      replicas: 1
      selector:
        matchLabels:
          app: ossfs2-test
      template:
        metadata:
          labels:
            app: ossfs2-test
        spec:
          containers:
          - name: nginx
            image: anolis-registry.cn-zhangjiakou.cr.aliyuncs.com/openanolis/nginx:1.14.1-8.6
            ports:
            - containerPort: 80
            volumeMounts:
            - name: pvc-ossfs2
              mountPath: /data
          volumes:
            - name: pvc-ossfs2
              persistentVolumeClaim:
                claimName: pvc-ossfs2
  2. Deploy aplikasi:

    kubectl create -f ossfs2-test.yaml
  3. Verifikasi pod sedang berjalan:

    kubectl get pod -l app=ossfs2-test

    Output yang diharapkan:

    NAME            READY   STATUS    RESTARTS   AGE
    ossfs2-test-0   1/1     Running   0          2m
  4. Verifikasi akses baca dan tulis:

    # Tulis file uji
    kubectl exec -it ossfs2-test-0 -- touch /data/test.txt
    # Daftar file di titik pemasangan
    kubectl exec -it ossfs2-test-0 -- ls /data

    Output harus mencakup test.txt, yang mengonfirmasi volume telah dipasang dan dapat ditulis.

Terapkan di produksi

Kategori Praktik terbaik
Keamanan Gunakan RRSA — menyediakan kredensial temporary dan auto-rotating serta isolasi izin tingkat pod, sehingga menghilangkan risiko eksposur kunci statis. Berikan hanya izin minimum yang diperlukan (read-only atau read-write, terbatas pada bucket tertentu).
Kinerja Gunakan titik akhir internal ketika kluster dan bucket berada di wilayah yang sama untuk menghindari biaya transfer data publik dan mengurangi latensi. Untuk workload yang membaca banyak file kecil, pertahankan close_to_open=false (default) untuk mengurangi panggilan API metadata. Atur close_to_open=true hanya jika sistem lain sering memperbarui objek di bucket dan pod Anda memerlukan visibilitas langsung. Untuk penyetelan tambahan, lihat opsi pemasangan ossfs 2.0.
Kesesuaian workload ossfs 2.0 dioptimalkan untuk workload yang banyak membaca dan hanya menambah (append-only): pelatihan AI, inferensi, pemrosesan big data, dan kendaraan otonom. Tidak cocok untuk workload tulis acak seperti database atau pengeditan kolaboratif.
Biaya Konfigurasikan lifecycle rule pada bucket OSS Anda untuk secara otomatis menghapus unggahan multipart yang tidak lengkap. Hal ini mencegah akumulasi biaya penyimpanan dari unggahan file besar yang terputus.
Operasi Konfigurasikan liveness probe di pod Anda untuk memeriksa ketersediaan titik pemasangan — Kubernetes akan me-restart pod secara otomatis jika pemasangan gagal. Siapkan pemantauan penyimpanan kontainer untuk melacak kinerja volume dan menerima peringatan sebelum masalah memengaruhi workload Anda.

FAQ