Tüm Ürünler
Search
Belge Merkezi

Container Service for Kubernetes:Mount a dynamic OSS volume using ossfs 2.0 in an ACK cluster

Son Güncelleme:Oct 06, 2026

Sıralı okuma ve yazma iş yükleri için optimize edilmiş FUSE (Filesystem in Userspace) tabanlı istemci olan ossfs 2.0'ı kullanarak ACK kümesinde Object Storage Service (OSS) paketini kalıcı birim (PV) olarak bağlayın. Dinamik sağlama ile StorageClass, PersistentVolumeClaim (PVC) oluşturduğunuzda otomatik olarak PV oluşturan ve bağlayan bir şablon olarak çalışır; bu sayede uygulamanız PV'leri manuel olarak yönetmeden standart POSIX arayüzleri üzerinden OSS verilerini okuyup yazabilir.

ossfs 2.0, sıralı aktarım hızında mükemmel performans gösterir ve yapay zeka eğitimi, çıkarım ve büyük veri işleme için idealdir. Performans kıyaslamaları için bkz. ossfs 2.0 istemci performans kıyaslamaları.

Başlamadan önce

Başlamadan önce aşağıdaki zorunlu kısıtlamaları kontrol edin. ossfs 2.0 tüm iş yükleri için uygun değildir; bu kontrolleri yapmadan devam etmek zaman kaybına neden olur.

Aşağıdaki durumlardan herhangi biri sizin için geçerliyse burada durun:

  • Rastgele veya eşzamanlı yazma: ossfs 2.0, rastgele veya eşzamanlı yazma işlemleri için veri tutarlılığını garanti edemez. Veritabanları, ortak düzenleme veya dosya içeriğini yerinde değiştiren herhangi bir iş yükü için ossfs 1.0 kullanın.

  • Kubernetes sürümü 1.26'dan düşük: RRSA kimlik doğrulaması Kubernetes 1.26 veya üzerini gerektirir. Gerekirse kümenizi yükseltin.

  • CSI eklenti sürümü 1.33.1'den düşük: Her iki kimlik doğrulama yöntemi de CSI eklenti sürümü 1.33.1 veya üzerini gerektirir. Gerekirse csi-plugin ve csi-provisioner'ı güncelleyin.

Başlamadan önce şunlara sahip olduğunuzdan emin olun:

  • CSI eklentisi yüklü bir ACK kümesi

  • Kümenizle aynı Alibaba Cloud hesabında bulunan bir OSS paketi. Paketler arası hesaplarda bağlantı kurmak için RRSA kimlik doğrulamasını kullanın — ayrıntılar için bkz. ossfs 2.0 birimleri hakkında SSS

Kullanım notları

  • Veri değişiklikleri anında yansır: Bir ossfs bağlantı noktasındaki dosya değişikliği veya silme işlemi — pod içinden veya ana bilgisayar düğümünden yapılsa bile — kaynak OSS paketine hemen senkronize edilir. Kazara veri kaybına karşı koruma sağlamak için sürüm oluşturmayı etkinleştirin.

  • Sağlık kontrolleri: OSS birimleri kullanan podlarda bağlantı noktası kullanılabilirliğini doğrulamak için bir liveness probe yapılandırın. Bağlantı noktası sağlıksız duruma gelirse Kubernetes pod'u otomatik olarak yeniden başlatır.

  • Parçalı yüklemeler: 10 MB'tan büyük dosyalar otomatik olarak parçalı yükleme kullanılarak yüklenir. Yükleme kesintiye uğrarsa tamamlanmamış parçalar pakette kalır ve depolama maliyetine neden olur. Bunları otomatik olarak temizlemek için bir yaşam döngüsü kuralı yapılandırın veya manuel olarak silin.

Kimlik doğrulama yöntemi seçme

RRSA AccessKey
Kimlik bilgisi türü Geçici, otomatik döndürülen (OIDC + STS aracılığıyla) Uzun ömürlü statik anahtar
İzin kapsamı Pod düzeyinde yalıtım Aynı Secret'ı kullanan tüm pod'lar arasında paylaşılır
Uygun olduğu durumlar Üretim, çok kiracılı ortamlar Yalnızca geliştirme ve test amaçlı
Anahtar ifşa riski Düşük — kimlik bilgileri otomatik olarak süresi doler Yüksek — anahtarın manuel olarak iptal edilmesi ve döndürülmesi gerekir
Anahtar döndürme Otomatik Manuel; Secret'ın güncellenmesini ve pod'ların yeniden başlatılmasını gerektirir

Üretim ortamları için RRSA kullanın. AccessKey kimlik doğrulaması yalnızca geliştirme ve test amaçlı kabul edilebilir; ifşa edilen veya yanlış yapılandırılmış statik bir anahtar, manuel iptal gerektirir ve döndürme sırasında hizmet kesintisine neden olur.

Her iki yöntem de aynı genel iş akışını izler:

  1. Kimlik bilgilerini ayarlayın (RRSA için RAM rolü veya AccessKey için RAM kullanıcısı + Secret)

  2. StorageClass oluşturun

  3. PVC oluşturun

  4. Birimi uygulamanıza bağlayın

Yöntem 1: RRSA kullanarak kimlik doğrulama

RRSA (RAM Roles for Service Accounts), OpenID Connect (OIDC) ve Security Token Service (STS) aracılığıyla geçici, otomatik döndürülen kimlik bilgileri kullanarak pod düzeyinde izin yalıtımı sağlar. Arka plan bilgisi için bkz. Farklı bulut hizmetlerine erişmek üzere farklı pod'lara yetki vermek için RRSA kullanma.

Not

Daha önce 1.30.4'ten eski bir CSI eklenti sürümüyle RRSA kullandıysanız gerekli RAM rolü yetkilendirme değişiklikleri için bkz. [\[Ürün Değişiklikleri\] CSI'daki ossfs sürüm yükseltmesi ve bağlama işlemi optimizasyonu](https://www.alibabacloud.com/help/en/document_detail/2842828.html).

Adım 1: RAM rolü oluşturma

Bu kümede daha önce RRSA kullanarak bir OSS birimi bağladıysanız bu adımı atlayın.

  1. RRSA özelliğini etkinleştirin ACK konsolunda.

  2. OIDC Kimlik Sağlayıcısı için RAM rolü oluşturun. Örnek rol demo-role-for-rrsa için aşağıdaki parametreleri kullanın:

    Parametre Değer
    Identity Provider Type OIDC öğesini seçin
    Identity Provider Kümenizle ilişkili sağlayıcıyı seçin, örneğin ack-rrsa-<cluster_id>
    oidc:iss Varsayılan değeri koruyun
    oidc:aud Varsayılan değeri koruyun
    oidc:sub — Anahtar oidc:sub öğesini seçin
    oidc:sub — İşleç StringEquals öğesini seçin
    oidc:sub — Değer system:serviceaccount:ack-csi-fuse:csi-fuse-ossfs girin. Ad alanı ack-csi-fuse sabittir ve özelleştirilemez. Hizmet hesabı adı csi-fuse-ossfs değiştirilebilir — bkz. ossfs 2.0 birimleri hakkında SSS.
    Role Name demo-role-for-rrsa girin

Adım 2: RAM rolüne OSS izinleri verme

  1. Role OSS erişimi vermek için özel ilke oluşturun. mybucket değerini gerçek paket adınızla değiştirin.

    • Yalnızca okuma erişimi

      {
          "Statement": [
              {
                  "Action": [
                      "oss:Get*",
                      "oss:List*"
                  ],
                  "Effect": "Allow",
                  "Resource": [
                      "acs:oss:*:*:mybucket",
                      "acs:oss:*:*:mybucket/*"
                  ]
              }
          ],
          "Version": "1"
      }
    • Okuma-yazma erişimi

      {
          "Statement": [
              {
                  "Action": "oss:*",
                  "Effect": "Allow",
                  "Resource": [
                      "acs:oss:*:*:mybucket",
                      "acs:oss:*:*:mybucket/*"
                  ]
              }
          ],
          "Version": "1"
      }
  2. (İsteğe bağlı) Paketteki nesneler Key Management Service (KMS) içindeki bir müşteri anahtarı (CMK) ile şifrelenmişse KMS erişimi de verin. Bkz. Şifreleme.

  3. Özel ilkeyi demo-role-for-rrsa rolüne atayın.

    Not

    Zaten OSS erişimi olan mevcut bir RAM rolünü yeniden kullanmak için bunun yerine güven ilkesini değiştirin. Bkz. Mevcut RAM rolü kullanma ve RAM rolüne gerekli izinleri verme.

Adım 3: StorageClass oluşturma

  1. ossfs2-sc-rrsa.yaml dosyasını oluşturun:

    Parametre Zorunlu Açıklama Varsayılan / Atlanırsa davranış
    bucket Evet Bağlanacak OSS paketinin adı —
    path Evet Paket içindeki temel yol. volumeAs: sharepath ile her PV, bu yol altında /ack/<pv-name> gibi benzersiz bir alt dizin alır Boş bırakılırsa paket kökünü bağlar
    url Evet OSS paketi uç noktası. Küme ve paket aynı bölgedeyse veya Virtual Private Cloud (VPC) üzerinden bağlıysa dahili uç nokta (http://oss-<region>-internal.aliyuncs.com) kullanın. Bölge dışı erişim için genel uç nokta (http://oss-<region>.aliyuncs.com) kullanın.
    Not

    vpc100-oss-<region>.aliyuncs.com dahili uç nokta biçimi kullanımdan kaldırılmıştır — yeni biçime geçiş yapın.

    —
    fuseType Evet ossfs 2.0 istemcisini kullanmak için ossfs2 olarak ayarlanmalıdır —
    authType Evet rrsa olarak ayarlayın —
    roleName Evet Üstlenilecek RAM rolü. PV başına farklı izinler atamak için her izin kümesi için ayrı bir RAM rolü oluşturun ve burada belirtin —
    volumeAs Hayır Her PV'nin path altında ayrı bir alt dizin oluşturması için sharepath olarak ayarlayın —
    otherOpts Hayır -o <flag> -o <flag> biçiminde ek bağlama seçenekleri. Tüm mevcut seçenekler için bkz. ossfs 2.0 bağlama seçenekleri Ek seçenek yok
    apiVersion: storage.k8s.io/v1
    kind: StorageClass
    metadata:
      name: ossfs2-sc
    parameters:
      bucket: cnfs-oss-test          # The name of your OSS bucket.
      path: /subpath                 # The subdirectory to mount. Leave blank to mount the bucket root.
      url: oss-cn-hangzhou-internal.aliyuncs.com  # Internal endpoint (same region or VPC); use public endpoint for cross-region.
      authType: rrsa
      roleName: demo-role-for-rrsa  # The RAM role created in Step 1.
      fuseType: ossfs2              # Must be ossfs2 to use the ossfs 2.0 client.
      volumeAs: sharepath           # Each PV gets a unique subdirectory under path, e.g., /subpath/ack/<pv-name>.
      otherOpts: "-o close_to_open=false"  # false (default): cache metadata for lower latency. true: fetch fresh metadata on every file open (increases latency and API costs).
    provisioner: ossplugin.csi.alibabacloud.com  # Fixed value.
    reclaimPolicy: Retain           # Only Retain is supported. Deleting the PVC does not delete the PV or OSS data.
    volumeBindingMode: Immediate    # OSS volumes have no zone-based node affinity requirements.

    Aşağıdaki tabloda parameters alanları açıklanmaktadır:

  2. StorageClass'ı uygulayın:

    kubectl create -f ossfs2-sc-rrsa.yaml
  3. StorageClass'ın oluşturulduğunu doğrulayın:

    kubectl get sc ossfs2-sc

    Beklenen çıktı:

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

Adım 4: PVC oluşturma

PVC'yi oluşturmak, altta yatan PV'nin otomatik olarak sağlanmasını tetikler.

  1. ossfs2-pvc-dynamic.yaml dosyasını oluşturun:

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

    kubectl create -f ossfs2-pvc-dynamic.yaml
  3. PVC'nin otomatik olarak oluşturulan PV'ye bağlandığını doğrulayın:

    kubectl get pvc pvc-ossfs2

    Beklenen çıktı:

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

Adım 5: Birimi uygulamanıza bağlama

  1. ossfs2-test.yaml dosyasını oluşturun. Aşağıdaki StatefulSet, PVC'yi /data konumuna bağlar:

    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. Uygulamayı dağıtın:

    kubectl create -f ossfs2-test.yaml
  3. Pod'un çalıştığını doğrulayın:

    kubectl get pod -l app=ossfs2-test

    Beklenen çıktı:

    NAME            READY   STATUS    RESTARTS   AGE
    ossfs2-test-0   1/1     Running   0          2m
  4. Bağlantı noktasına okuma ve yazma erişimini doğrulayın:

    # Write a test file
    kubectl exec -it ossfs2-test-0 -- touch /data/test.txt
    # List files at the mount point
    kubectl exec -it ossfs2-test-0 -- ls /data

    Çıktı test.txt içermeli olup birimin bağlandığını ve yazılabilir olduğunu onaylar.

Yöntem 2: AccessKey kullanarak kimlik doğrulama

Önemli

Bu yöntem uzun ömürlü statik bir anahtar kullanır. Yalnızca geliştirme ve test amaçlı kullanın. Üretim ortamı için bunun yerine RRSA kimlik doğrulamasını kullanın.

Bir PV tarafından başvurulan AccessKey iptal edilirse veya izinleri değişirse, bu birimi kullanan her pod derhal erişimi kaybeder. Erişimi geri yüklemek için: Secret'taki kimlik bilgilerini güncelleyin ve ardından pod'ları yeniden başlatın. Bu işlem kısa bir hizmet kesintisine neden olur ve bakım penceresi sırasında gerçekleştirilmelidir.

Adım 1: RAM kullanıcısı oluşturma ve kimlik bilgilerini Secret'ta saklama

RAM kullanıcısı oluşturma ve OSS izinleri verme

  1. Henüz yoksa RAM kullanıcısı oluşturun.

  2. OSS erişimi vermek için özel ilke oluşturun. mybucket değerini gerçek paket adınızla değiştirin.

    • Yalnızca okuma erişimi

      {
          "Statement": [
              {
                  "Action": [
                      "oss:Get*",
                      "oss:List*"
                  ],
                  "Effect": "Allow",
                  "Resource": [
                      "acs:oss:*:*:mybucket",
                      "acs:oss:*:*:mybucket/*"
                  ]
              }
          ],
          "Version": "1"
      }
    • Okuma-yazma erişimi

      {
          "Statement": [
              {
                  "Action": "oss:*",
                  "Effect": "Allow",
                  "Resource": [
                      "acs:oss:*:*:mybucket",
                      "acs:oss:*:*:mybucket/*"
                  ]
              }
          ],
          "Version": "1"
      }
  3. (İsteğe bağlı) Paketteki nesneler KMS içindeki bir CMK ile şifrelenmişse KMS erişimi de verin. Bkz. Şifreleme.

  4. Özel ilkeyi RAM kullanıcısına atayın.

  5. RAM kullanıcısı için AccessKey çifti oluşturun.

AccessKey'i Kubernetes Secret'ında saklama

Aşağıdaki komutu çalıştırın. Yer tutucu değerleri gerçek AccessKey ID'niz ve Secret'ınızla değiştirin:

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

Adım 2: StorageClass oluşturma

  1. ossfs2-sc.yaml dosyasını oluşturun:

    Secret yapılandırması

    Parametre Zorunlu Açıklama
    csi.storage.k8s.io/node-publish-secret-name Evet AccessKey'i saklayan Secret'ın adı
    csi.storage.k8s.io/node-publish-secret-namespace Evet Secret'ın bulunduğu ad alanı

    Birim yapılandırması

    Parametre Zorunlu Açıklama Varsayılan / Atlanırsa davranış
    fuseType Evet ossfs 2.0 istemcisini kullanmak için ossfs2 olarak ayarlanmalıdır —
    bucket Evet Bağlanacak OSS paketinin adı —
    path Hayır Paket köküne göre paket içindeki bağlama yolu Boş bırakılırsa paket kökünü bağlar
    url Evet OSS paketi uç noktası. Aynı bölge veya VPC bağlantılı erişim için dahili uç nokta (http://oss-<region>-internal.aliyuncs.com) veya bölge dışı erişim için genel uç nokta (http://oss-<region>.aliyuncs.com) kullanın.
    Not

    vpc100-oss-<region>.aliyuncs.com dahili uç nokta biçimi kullanımdan kaldırılmıştır.

    —
    otherOpts Hayır -o <flag> -o <flag> biçiminde ek bağlama seçenekleri. Tüm mevcut seçenekler için bkz. ossfs 2.0 bağlama seçenekleri Ek seçenek yok
    apiVersion: storage.k8s.io/v1
    kind: StorageClass
    metadata:
      name: ossfs2-sc
    parameters:
      csi.storage.k8s.io/node-publish-secret-name: oss-secret       # The Secret created above.
      csi.storage.k8s.io/node-publish-secret-namespace: default      # The namespace where the Secret lives.
      fuseType: ossfs2              # Must be ossfs2 to use the ossfs 2.0 client.
      bucket: cnfs-oss-test         # The name of your OSS bucket.
      path: /subpath                # The subdirectory to mount. Leave blank to mount the bucket root.
      url: oss-cn-hangzhou-internal.aliyuncs.com  # Internal endpoint (same region or VPC); use public endpoint for cross-region.
      otherOpts: "-o close_to_open=false"  # false (default): cache metadata for lower latency. true: fetch fresh metadata on every file open (increases latency and API costs).
    provisioner: ossplugin.csi.alibabacloud.com  # Fixed value.
    reclaimPolicy: Retain           # Only Retain is supported. Deleting the PVC does not delete the PV or OSS data.
    volumeBindingMode: Immediate    # OSS volumes have no zone-based node affinity requirements.
  2. StorageClass'ı oluşturun:

    kubectl create -f ossfs2-sc.yaml

Adım 3: PVC oluşturma

  1. ossfs2-pvc-dynamic.yaml dosyasını oluşturun:

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

    kubectl create -f ossfs2-pvc-dynamic.yaml
  3. PVC'nin bağlandığını doğrulayın:

    kubectl get pvc pvc-ossfs2

    Beklenen çıktı:

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

Adım 4: Birimi uygulamanıza bağlama

  1. ossfs2-test.yaml dosyasını oluşturun:

    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. Uygulamayı dağıtın:

    kubectl create -f ossfs2-test.yaml
  3. Pod'un çalıştığını doğrulayın:

    kubectl get pod -l app=ossfs2-test

    Beklenen çıktı:

    NAME            READY   STATUS    RESTARTS   AGE
    ossfs2-test-0   1/1     Running   0          2m
  4. Okuma ve yazma erişimini doğrulayın:

    # Write a test file
    kubectl exec -it ossfs2-test-0 -- touch /data/test.txt
    # List files at the mount point
    kubectl exec -it ossfs2-test-0 -- ls /data

    Çıktı test.txt içermeli olup birimin bağlandığını ve yazılabilir olduğunu onaylar.

Üretimde uygulama

Kategori En iyi uygulamalar
Güvenlik RRSA kullanın — geçici, otomatik döndürülen kimlik bilgileri ve pod düzeyinde izin yalıtımı sağlayarak statik anahtar ifşa riskini ortadan kaldırır. Yalnızca gereken minimum izinleri verin (yalnızca okuma veya okuma-yazma, belirli bir paketle sınırlı).
Performans Küme ve paket aynı bölgedeyse genel veri aktarım maliyetlerinden kaçınmak ve gecikme süresini azaltmak için dahili uç nokta kullanın. Çok sayıda küçük dosya okuyan iş yükleri için meta veri API çağrılarını azaltmak amacıyla close_to_open=false (varsayılan) ayarını koruyun. Başka bir sistem paketteki nesneleri sık sık güncelliyorsa ve pod'unuzun anında görünürlük ihtiyacı varsa yalnızca close_to_open=true ayarlayın. Ek ayarlama için bkz. ossfs 2.0 bağlama seçenekleri.
İş yükü uyumu ossfs 2.0, yoğun okuma ve yalnızca ekleme yapılan iş yükleri için optimize edilmiştir: yapay zeka eğitimi, çıkarım, büyük veri işleme ve otonom sürüş. Veritabanları veya ortak düzenleme gibi rastgele yazma iş yükleri için uygun değildir.
Maliyet Kesintiye uğrayan büyük dosya yüklemelerinden kaynaklanan biriken depolama maliyetlerini önlemek için OSS paketinizde eksik parçalı yüklemeleri otomatik olarak silen bir yaşam döngüsü kuralı yapılandırın.
Operasyonlar Bağlantı noktası kullanılabilirliğini kontrol etmek için pod'larınızda liveness probe yapılandırın — bağlantı başarısız olursa Kubernetes pod'u otomatik olarak yeniden başlatır. Sorunlar iş yükünüzü etkilemeden önce uyarı almak ve birim performansını izlemek için konteyner depolama izlemeyi ayarlayın.

SSS