Tüm Ürünler
Search
Belge Merkezi

Container Service for Kubernetes:Mount OSS buckets using ossfs 1.0 dynamic volumes

Son Güncelleme:Oct 06, 2026

ossfs 1,0, dynamic provisioning özelliğini destekler. Bu özellik, bir StorageClass ve PersistentVolumeClaim (PVC) temel alarak otomatik olarak kalıcı bir birim (PV) oluşturur ve bir OSS Bucket bağlar. Manuel PV yapılandırmasına gerek kalmadan depolama yönetimini büyük ölçüde basitleştirir ve çok kiracılı ortamlar veya sık, talebe bağlı depolama sağlanması gerektiren senaryolar için idealdir.

Gereksinimler

Kümenizin ve CSI bileşenlerinizin (csi-plugin ve csi-provisioner) aşağıdaki gereksinimleri karşılaması gerekir:

  • RAM Roles for Service Accounts (RRSA) kimlik doğrulaması kullanımı için: Kümeniz 1,26 veya sonraki bir sürümde olmalı ve CSI sürümü v1,30,4 veya üzeri olmalıdır.

    v1,30,4 öncesi bir sürümde RRSA özelliğini kullandıysanız gerekli RAM Rolü yetkilendirme yapılandırmasını eklemek için [[Ürün Değişikliği] CSI ossfs sürüm yükseltmesi ve bağlama işlemi optimizasyonu](t2763435.xdita#) konusuna bakın.
  • AccessKey kimlik doğrulaması kullanımı için: Bağlama kararlılığını sağlamak adına CSI sürümü v1,18,8,45 veya üzerini öneririz.

Kümenizi yükseltmek için Küme manuel yükseltme konusuna bakın. CSI bileşenlerini yükseltmek için CSI bileşenlerini yükseltme konusuna bakın.

CSI v1,30,4-* sürümünden başlayarak, OSS statik birimlerinin bağlanması csi-provisioner bileşenine bağlıdır .

1. Adım: Bir kimlik doğrulama yöntemi seçin

Kümenizin OSS Bucket kaynaklarına güvenli ve uyumlu bir şekilde erişebilmesi için önce bir kimlik doğrulama yöntemi yapılandırmanız gerekir.

  • RRSA kimlik doğrulaması: Uygulama düzeyinde ayrıntılı izin yalıtımı sağlamak amacıyla Pod'lara geçici ve otomatik olarak döndürülen RAM rolleri dinamik olarak atanır. Bu yöntem daha güvenlidir.

  • AccessKey kimlik doğrulaması: Statik, uzun ömürlü anahtarlar bir Secret içinde saklanır. Yapılandırması daha kolay olsa da güvenlik düzeyi daha düşüktür.

Önemli
  • 1,26 veya sonraki sürümleri çalıştıran kümeler için AccessKey döndürme işlemlerinden kaynaklanan iş yükü yeniden başlatmalarını ve ossfs yeniden bağlamalarını önlemek amacıyla RRSA kimlik doğrulamasını öneririz.

  • Bu örnekte kümenin ve OSS Bucket aynı Alibaba Cloud hesabında olduğu varsayılır. Başka bir hesaba ait bir OSS Bucket'ı bağlamak için RRSA kimlik doğrulamasını kullanmanızı öneririz.

RRSA

1. Kümeniz için RRSA'yı etkinleştirin

  1. ACK Kümeleri sayfasında kümenizin adını tıklayın. Sol gezinme bölmesinde Cluster Information öğesini tıklayın.

  2. Basic Information sekmesinde, Security and Auditing bölümünde RRSA OIDC öğesinin sağındaki Enabled seçeneğini tıklayın. RRSA'yı yoğun olmayan saatlerde etkinleştirmek için ekrandaki talimatları izleyin.

    Küme durumu Updating durumundan Running durumuna geçtiğinde RRSA etkinleştirilmiş olur.

    Önemli

    RRSA'yı etkinleştirdikten sonra kümede yeni oluşturulan ServiceAccount belirteçlerinin maksimum geçerlilik süresi 12 saat ile sınırlanır.

2. Bir RAM rolü oluşturun ve yetkilendirin

Pod'larınızın RRSA kimlik doğrulamalı OSS depolama birimine erişmek için üstlenebileceği bir RAM rolü oluşturun.

Adımları görüntüle

  1. Bir RAM rolü oluşturun.

    1. RAM Konsolu'ndaki Rol Oluştur sayfasına gidin. Principal Type için IdP öğesini seçin. Ardından Visual Editor alanını açmak üzere Switch to Policy Editor seçeneğini tıklayın.

    2. Principal için IdP öğesini seçin. Parametreleri aşağıdaki tabloda açıklandığı gibi yapılandırmak için Edit seçeneğini tıklayın.

      Ana parametreleri yapılandırın ve diğer parametreler için varsayılan değerleri koruyun. Daha fazla bilgi için OIDC kimlik sağlayıcısı için RAM rolü oluşturma konusuna bakın.

      Parametre

      Açıklama

      IdP Type

      OIDC.

      IdP

      ack-rrsa-<cluster_id> seçeneğini belirleyin; burada <cluster_id>, kümenizin ID'sidir.

      Condition

      oidc:sub öğesini manuel olarak ekleyin.

      Role Name

      Örneğin, demo-role-for-rrsa girin.

  2. Bir erişim ilkesi oluşturun.

    Bu örnek en az ayrıcalık ilkesini takip eder. Hedef OSS Bucket'a erişim izni vermek için Özel ilke oluşturma işlemini uygulayın. Salt okunur veya okuma/yazma izinleri verebilirsiniz.

    1. RAM Konsolu'ndaki İlke Oluştur sayfasına gidin, JSON Editor alanına geçiş yapın ve ilke betiğini yapılandırın.

      Zaten OSS izinlerine sahip bir RAM rolünüz varsa güven ilkesini değiştirerek bu rolü yeniden kullanabilirsiniz. Daha fazla bilgi için Mevcut bir RAM rolü kullanma ve izin verme konusuna bakın.

      Salt okunur ilke

      ifadesini gerçek paket adıyla değiştirin.
      {
          "Statement": [
              {
                  "Action": [
                      "oss:Get*",
                      "oss:List*"
                  ],
                  "Effect": "Allow",
                  "Resource": [
                      "acs:oss:*:*:<myBucketName>",
                      "acs:oss:*:*:<myBucketName>/*"
                  ]
              }
          ],
          "Version": "1"
      }

      OSS okuma/yazma ilkesi

      Gerçek paket adıyla değiştirmek için <myBucketName> ifadesini kullanın.
      {
          "Statement": [
              {
                  "Action": "oss:*",
                  "Effect": "Allow",
                  "Resource": [
                      "acs:oss:*:*:<myBucketName>",
                      "acs:oss:*:*:<myBucketName>/*"
                  ]
              }
          ],
          "Version": "1"
      }
    2. (İsteğe bağlı) OSS nesnelerini şifrelemek için KMS tarafından yönetilen belirli bir CMK ID kullanıyorsanız role KMS izinleri de vermeniz gerekir. Daha fazla bilgi için Verileri şifrelemek için KMS tarafından yönetilen belirli bir CMK ID kullanma konusuna bakın.

  3. Erişim ilkesini RAM rolüne ekleyin.

    1. RAM Konsolu'ndaki Roller sayfasına gidin, oluşturduğunuz rolü bulun ve Actions sütununda Attach Policy seçeneğini tıklayın.

    2. Policies bölümünde oluşturduğunuz erişim ilkesini arayın ve seçin.

AccessKey

Hedef OSS Bucket'a erişim iznine sahip bir RAM kullanıcı oluşturun ve ardından bu kullanıcı için bir AccessKey edinin.

  1. Bir RAM kullanıcı oluşturun. Zaten bir RAM kullanıcınız varsa bu adımı atlayabilirsiniz.

    RAM Konsolu'ndaki Kullanıcı Oluştur sayfasına gidin ve ekrandaki talimatları izleyerek bir RAM kullanıcı oluşturun. Oturum açma adı ve parola gibi parametreleri belirtmeniz gerekir.

  2. Bir erişim ilkesi oluşturun.

    Bu örnek en az ayrıcalık ilkesini takip eder. Hedef OSS Bucket'a erişim izni vermek için Özel ilke oluşturma işlemini uygulayın. Salt okunur veya okuma/yazma izinleri verebilirsiniz.

    1. RAM Konsolu'ndaki İlke Oluştur sayfasına gidin, JSON Editor alanına geçiş yapın ve ilke betiğini yapılandırın.

      Salt okunur ilke

      Gerçek paket adıyla değiştirmek için <myBucketName> ifadesini kullanın.
      {
          "Statement": [
              {
                  "Action": [
                      "oss:Get*",
                      "oss:List*"
                  ],
                  "Effect": "Allow",
                  "Resource": [
                      "acs:oss:*:*:<myBucketName>",
                      "acs:oss:*:*:<myBucketName>/*"
                  ]
              }
          ],
          "Version": "1"
      }

      OSS okuma/yazma ilkesi

      Gerçek paket adıyla değiştirmek için <myBucketName> ifadesini kullanın.
      {
          "Statement": [
              {
                  "Action": "oss:*",
                  "Effect": "Allow",
                  "Resource": [
                      "acs:oss:*:*:<myBucketName>",
                      "acs:oss:*:*:<myBucketName>/*"
                  ]
              }
          ],
          "Version": "1"
      }

      Konsolda bir PV oluşturmak istiyorsanız oss:ListBuckets iznine de ihtiyacınız vardır.

      {
        "Effect": "Allow",
        "Action": "oss:ListBuckets",
        "Resource": "*"
      }
    2. (İsteğe bağlı) OSS nesnelerini şifrelemek için KMS tarafından yönetilen belirli bir CMK ID kullanıyorsanız RAM kullanıcıya KMS izinleri de vermeniz gerekir. Daha fazla bilgi için Verileri şifrelemek için KMS tarafından yönetilen belirli bir CMK ID kullanma konusuna bakın.

  3. Erişim ilkesini RAM kullanıcıya ekleyin.

    1. RAM Konsolu'ndaki Kullanıcılar sayfasına gidin, oluşturduğunuz kullanıcıyı bulun ve Actions sütununda Add Permissions seçeneğini tıklayın.

    2. Policies bölümünde oluşturduğunuz erişim ilkesini arayın ve seçin.

  4. Oluşturduğunuz AccessKey, PV için bir Secret olarak saklanacaktır.

    1. RAM Konsolu'ndaki Kullanıcılar sayfasına gidin, RAM kullanıcınızın adını tıklayın ve ardından AccessKey bölümünde Create AccessKey seçeneğini tıklayın.

    2. Bir AccessKey oluşturmak için ekrandaki talimatları izleyin. AccessKey ID ve AccessKey Secret değerlerini kopyalayın ve güvenli bir şekilde saklayın.

2. Adım: Bir StorageClass oluşturun

Kalıcı birimleri sağlamaya yönelik bir şablon tanımlamak için bir StorageClass oluşturun.

RRSA yöntemi

  1. sc-oss.yaml adlı bir dosya oluşturun.

    apiVersion: storage.k8s.io/v1
    kind: StorageClass
    metadata:
      name: sc-oss
    parameters:
      # Replace with the name of your OSS bucket.
      bucket: bucket  
      # Replace with the region of your OSS bucket.
      region: cn-hangzhou
      # The mount path relative to the bucket's root directory. You can specify a subdirectory.
      path: /
      # The endpoint of the region where the bucket is located.
      url: "https://oss-cn-hangzhou-internal.aliyuncs.com"  
      # Use the RRSA method for authentication.
      authType: rrsa
      # The RAM role that you created or modified.
      roleName: demo-role-for-rrsa
      # Custom parameters.
      otherOpts: "-o umask=022 -o max_stat_cache_size=100000 -o allow_other"
      # The volume access mode.
      volumeAs: sharepath
      # The signature version for requests sent to the OSS server.
      sigVersion: "v4" 
    # Fixed value for the Alibaba Cloud OSS CSI plug-in.
    provisioner: ossplugin.csi.alibabacloud.com
    # The reclaim policy for the dynamically provisioned persistent volume.

    Parametre

    Açıklama

    bucket

    Bağlanacak OSS paketi.

    region

    OSS imza v4 kullanılırken bu parametreyi paketin bulunduğu OSS bölgesine ayarlayın. OSS bölgesini sorgulamak için bkz. Paket bölgesini sorgulama.

    Bu parametre ayarlandığında OSS imza sürümü olarak otomatik olarak v4 kullanılır.

    path

    CSI bileşeni sürümü v1.14.8.32-c77e277b-aliyun veya üzeri olmalıdır.

    Paketin kök dizinine göre bağlama yolu. Varsayılan değer, tüm paketi bağlayan / değeridir.

    ossfs sürümü 1,91'den önceyse belirtilen path OSS paketinde mevcut olmalıdır. Daha fazla bilgi için bkz. ossfs 1,91 ve sonraki sürümlerdeki yeni özellikler.

    url

    Bağlanacak OSS Paketinin uç noktası.

    • Bağlama düğümü ve paket aynı bölgedeyse veya bir VPC bağlantısı kurulmuşsa dahili uç nokta kullanın.

    • Bağlama düğümü ve paket farklı bölgelerdeyse genel uç nokta kullanın.

    Farklı erişim bağlantı noktaları için yaygın biçimler aşağıda verilmiştir:

    • Dahili ağ biçimi: https://oss-{{regionName}}-internal.aliyuncs.com.

      vpc100-oss-{{regionName}}.aliyuncs.com dahili uç nokta biçimi kullanım dışıdır. Derhal yeni biçime geçin.
    • Genel ağ biçimi: https://oss-{{regionName}}.aliyuncs.com.

    Güvenlik amacıyla OSS'ye HTTPS üzerinden erişmenizi öneririz. Bunun yerine HTTP kullanmak için önceki biçimdeki https:// ön ekini http:// ile değiştirin.

    authType

    Kimlik doğrulama için RRSA kullanmak üzere bu parametreyi rrsa olarak ayarlayın.

    roleName

    Oluşturduğunuz veya değiştirdiğiniz RAM rolü.

    Farklı StorageClass'lar için farklı izinler yapılandırmak üzere birden fazla RAM rolü oluşturabilir ve her StorageClass'ta farklı roleName değerleri belirtebilirsiniz.

    otherOpts

    OSS kalıcı birimi için özel parametreler, -o -o biçimindedir. Örneğin: -o umask=022 -o max_stat_cache_size=100000 -o allow_other.

    Ayrıntılar için genişletin

    • umask: Dosyalar ve dizinler için izin maskesini ayarlar.

      Örneğin, umask=022 dosya izinlerini 755 olarak değiştirir. Bu, SDK'lar veya OSS konsolu gibi diğer yöntemlerle yüklenen ve varsayılan izni 640 olan dosyaların izin sorununu çözer. Okuma/yazma ayrımı veya çok kullanıcılı erişim için bu parametreyi yapılandırmanızı öneririz.

    • max_stat_cache_size: Meta veri önbelleği girişlerinin üst sınırını ayarlar, örneğin 100000. Meta veriler bellekte önbelleğe alınarak ls ve stat gibi işlemlerin performansı artırılır.

      Ancak bu önbellek, OSS konsolu, SDK'lar veya ossutil aracılığıyla yapılan dosya değişikliklerini anında algılayamaz. Bu durum uygulamaların tutarsız verileri okumasına neden olabilir. Katı veri tutarlılığı gereksinimleriniz varsa önbelleği devre dışı bırakmak için bu parametreyi 0 olarak ayarlayın veya stat_cache_expire parametresini kullanarak önbellek sona erme süresini kısaltın. Ancak bu, okuma performansını azaltabilir.

    • allow_other: Birimi bağlayan kullanıcı dışındaki kullanıcıların bağlama yolundaki dosyalara ve dizinlere erişmesine olanak tanır. Bu, birimi bağlamayan kullanıcıların da verilere erişmesi gereken çok kullanıcılı paylaşımlı ortamlar için uygundur.

    İsteğe bağlı parametreler hakkında daha fazla bilgi için bkz. Bağlama seçenekleri ve ossfs 1,0 yapılandırmasına ilişkin en iyi uygulamalar.

    provisioner

    Sürücü türü. Alibaba Cloud OSS CSI eklentisi kullanılırken bu değer ossplugin.csi.alibabacloud.com olarak sabittir.

    reclaimPolicy

    Dinamik olarak sağlanan kalıcı birimler için geri kazanma ilkesi. OSS kalıcı birimleri yalnızca Retain değerini destekler; bu, bir PVC'yi sildiğinizde karşılık gelen kalıcı birimin ve OSS paketindeki verilerin silinmediği anlamına gelir.

    volumeBindingMode

    Birim bağlama modu.

    OSS kalıcı birimleri kullanılabilirlik alanı tabanlı düğüm yakınlığı gerektirmez. Varsayılan Immediate değerini kullanabilirsiniz.

    volumeAs

    Birim erişim modu. Varsayılan değer sharepath değeridir. Geçerli değerler:

    • sharepath: Tüm kalıcı birimler aynı bağlama yolunu paylaşır. Veriler <bucket>:<path>/ konumunda depolanır.

    • subpath: Verileri yalıtmak için her kalıcı birim için özel bir alt dizin oluşturur. Veriler <bucket>:<path>/<pv-name>/ konumunda depolanır.

      Bu parametre yalnızca CSI bileşeni sürümü 1,31,3 veya üzeri olduğunda etkili olur.

    sigVersion

    OSS sunucusuna gönderilen isteklerin imza sürümü.

  2. StorageClass'ı oluşturun.

    kubectl apply -f sc-oss.yaml

AccessKey yöntemi

kubectl

1. Bir StorageClass oluşturun

  1. Uygulamanızla aynı ad alanında bir Secret oluşturun.

    akId ve akSecret değerlerini AccessKey ID'niz ve AccessKey Secret değerlerinizle değiştirin.

    kubectl create secret generic oss-secret --from-literal='akId=<yourAccessKey ID>' --from-literal='akSecret=<yourAccessKey Secret>'
  2. StorageClass'ı oluşturun.

    1. sc-oss.yaml adlı bir dosya oluşturun.

      apiVersion: storage.k8s.io/v1
      kind: StorageClass
      metadata:
        name: sc-oss
      parameters:
        # Replace with the name of your OSS bucket.
        bucket: bucket
        # Replace with the region of your OSS bucket.
        region: cn-hangzhou
        # The mount path relative to the bucket's root directory. You can specify a subdirectory.
        path: /
        # The endpoint of the region where the bucket is located.
        url: "https://oss-cn-hangzhou-internal.aliyuncs.com" 
        # The name of the Secret that stores the AccessKey information.
        csi.storage.k8s.io/node-publish-secret-name: oss-secret
        # The namespace where the Secret that stores the AccessKey information is located.
        csi.storage.k8s.io/node-publish-secret-namespace: default
        # Custom parameters.
        otherOpts: "-o umask=022 -o max_stat_cache_size=100000 -o allow_other"
        # The signature version for requests sent to the OSS server.
        sigVersion: "v4"
      # Fixed value for the Alibaba Cloud OSS CSI plug-in.
      provisioner: ossplugin.csi.alibabacloud.com
      # The reclaim policy for the dynamically provisioned persistent volume.
      reclaimPolicy: Retain
      # The volume binding mode.
      volumeBindingMode: Immediate
      

      Parametre

      Açıklama

      name

      StorageClass adı.

      bucket

      Bağlanacak OSS paketi.

      region

      OSS imza v4 kullanılırken bu parametreyi paketin bulunduğu OSS bölgesine ayarlayın. OSS bölgesini sorgulamak için bkz. Paket bölgesini sorgulama.

      Bu parametre ayarlandığında OSS imza sürümü olarak otomatik olarak v4 kullanılır.

      path

      CSI bileşeni sürümü v1.14.8.32-c77e277b-aliyun veya üzeri olmalıdır.

      Paketin kök dizinine göre bağlama yolu. Varsayılan değer, tüm paketi bağlayan / değeridir.

      ossfs sürümü 1,91'den önceyse belirtilen path OSS paketinde mevcut olmalıdır. Daha fazla bilgi için bkz. ossfs 1,91 ve sonraki sürümlerdeki yeni özellikler.

      url

      Bağlanacak OSS Paketinin uç noktası.

      • Bağlama düğümü ve paket aynı bölgedeyse veya bir VPC bağlantısı kurulmuşsa dahili uç nokta kullanın.

      • Bağlama düğümü ve paket farklı bölgelerdeyse genel uç nokta kullanın.

      Farklı erişim bağlantı noktaları için yaygın biçimler aşağıda verilmiştir:

      • Dahili ağ biçimi: https://oss-{{regionName}}-internal.aliyuncs.com.

        vpc100-oss-{{regionName}}.aliyuncs.com dahili uç nokta biçimi kullanım dışıdır. Derhal yeni biçime geçin.
      • Genel ağ biçimi: https://oss-{{regionName}}.aliyuncs.com.

      Güvenlik amacıyla OSS'ye HTTPS üzerinden erişmenizi öneririz. Bunun yerine HTTP kullanmak için önceki biçimdeki https:// ön ekini http:// ile değiştirin.

      csi.storage.k8s.io/node-publish-secret-name

      AccessKey bilgilerini saklayan Secret adı.

      csi.storage.k8s.io/node-publish-secret-namespace

      AccessKey bilgilerini saklayan Secret'ın bulunduğu ad alanı.

      otherOpts

      OSS kalıcı birimi için özel parametreler, -o -o biçimindedir. Örneğin: -o umask=022 -o max_stat_cache_size=100000 -o allow_other.

      Ayrıntılar için genişletin

      • umask: Dosyalar ve dizinler için izin maskesini ayarlar.

        Örneğin, umask=022 dosya izinlerini 755 olarak değiştirir. Bu, SDK'lar veya OSS konsolu gibi diğer yöntemlerle yüklenen ve varsayılan izni 640 olan dosyaların izin sorununu çözer. Okuma/yazma ayrımı veya çok kullanıcılı erişim için bu parametreyi yapılandırmanızı öneririz.

      • max_stat_cache_size: Meta veri önbelleği girişlerinin üst sınırını ayarlar, örneğin 100000. Meta veriler bellekte önbelleğe alınarak ls ve stat gibi işlemlerin performansı artırılır.

        Ancak bu önbellek, OSS konsolu, SDK'lar veya ossutil aracılığıyla yapılan dosya değişikliklerini anında algılayamaz. Bu durum uygulamaların tutarsız verileri okumasına neden olabilir. Katı veri tutarlılığı gereksinimleriniz varsa önbelleği devre dışı bırakmak için bu parametreyi 0 olarak ayarlayın veya stat_cache_expire parametresini kullanarak önbellek sona erme süresini kısaltın. Ancak bu, okuma performansını azaltabilir.

      • allow_other: Birimi bağlayan kullanıcı dışındaki kullanıcıların bağlama yolundaki dosyalara ve dizinlere erişmesine olanak tanır. Bu, birimi bağlamayan kullanıcıların da verilere erişmesi gereken çok kullanıcılı paylaşımlı ortamlar için uygundur.

      İsteğe bağlı parametreler hakkında daha fazla bilgi için bkz. Bağlama seçenekleri ve ossfs 1,0 yapılandırmasına ilişkin en iyi uygulamalar.

      provisioner

      Sürücü türü. Alibaba Cloud OSS CSI eklentisi kullanılırken bu değer ossplugin.csi.alibabacloud.com olarak sabittir.

      reclaimPolicy

      Dinamik olarak sağlanan kalıcı birimler için geri kazanma ilkesi. OSS kalıcı birimleri yalnızca Retain değerini destekler; bu, bir PVC'yi sildiğinizde karşılık gelen kalıcı birimin ve OSS paketindeki verilerin silinmediği anlamına gelir.

      volumeBindingMode

      Birim bağlama modu.

      OSS kalıcı birimleri kullanılabilirlik alanı tabanlı düğüm yakınlığı gerektirmez. Varsayılan Immediate değerini kullanabilirsiniz.

      volumeAs

      Birim erişim modu. Varsayılan değer sharepath değeridir. Geçerli değerler:

      • sharepath: Tüm kalıcı birimler aynı bağlama yolunu paylaşır. Veriler <bucket>:<path>/ konumunda depolanır.

      • subpath: Verileri yalıtmak için her kalıcı birim için özel bir alt dizin oluşturur. Veriler <bucket>:<path>/<pv-name>/ konumunda depolanır.

        Bu parametre yalnızca CSI bileşeni sürümü 1,31,3 veya üzeri olduğunda etkili olur.

      sigVersion

      OSS sunucusuna gönderilen isteklerin imza sürümü.

    2. StorageClass'ı oluşturun.

      kubectl apply -f sc-oss.yaml

Konsol

  1. 1. Adım bölümündeki AccessKey'i kalıcı birim için bir Secret olarak saklayın.

    1. ACK Kümeleri sayfasında kümenizin adını tıklayın. Sol gezinme bölmesinde Configurations > Secrets seçeneğini tıklayın.

    2. Create from YAML seçeneğini tıklayın ve Secret'ı oluşturmak için ekrandaki talimatları izleyin.

      apiVersion: v1
      kind: Secret
      metadata:
        name: oss-secret
        # Must match the namespace of the application.
        namespace: default
      stringData:
        # Replace with your AccessKey ID.
        akId: <your AccessKey ID>
        # Replace with your AccessKey secret.
        akSecret: <your AccessKey Secret>
  2. Clusters sayfasında kümenizin adını tıklayın. Sol gezinme bölmesinde Volumes > StorageClasses seçeneğini tıklayın.

  3. StorageClasses sayfasında Create seçeneğini tıklayın, PV Type değerini OSS olarak ayarlayın ve StorageClass'ı yapılandırmak için ekrandaki talimatları izleyin.

    Parametre

    Açıklama

    Erişim sertifikası

    AccessKey ID ve AccessKey Secret değerlerini içeren OSS'ye erişim için kullanılan Secret.

    Bucket ID:

    Kullanılacak OSS paketi.

    Konsol, yapılandırılan AccessKey'in erişebileceği paketleri yalnızca gösterir.

    OSS yolu

    CSI bileşeni sürümü v1.14.8.32-c77e277b-aliyun veya üzeri olmalıdır.

    Paketin kök dizinine göre bağlama yolu. Varsayılan değer, tüm paketi bağlayan / değeridir.

    ossfs sürümü 1,91'den önceyse belirtilen path OSS paketinde mevcut olmalıdır. Daha fazla bilgi için bkz. ossfs 1,91 ve sonraki sürümlerdeki yeni özellikler.

    Volume Mode

    Birim erişim modu. Varsayılan Shared Directory değeridir. Geçerli değerler:

    Subdirectory modu yalnızca CSI bileşeni sürümü 1,31,3 veya üzeri olduğunda etkili olur. Aksi takdirde Shared Directory modu kullanılır.
    • Shared Directory (sharepath): Tüm kalıcı birimler aynı bağlama yolunu paylaşır. Veriler <bucket>:<path>/ konumunda depolanır.

    • Subdirectory (subpath): Verileri yalıtmak için her kalıcı birim için özel bir alt dizin oluşturur. Veriler <bucket>:<path>/<pv-name>/ konumunda depolanır.

    Uç nokta

    OSS paketi için erişim uç noktası.

    • Küme düğümleriniz ve paket aynı bölgedeyse veya bir Sanal Özel Cloud (VPC) bağlantısı kurulmuşsa dahili uç nokta kullanın.

    • Bağlama düğümü ve paket farklı bölgelerdeyse genel uç nokta kullanın.

    Farklı erişim uç noktaları için yaygın biçimler aşağıda verilmiştir:

    • Dahili: http://oss-{{regionName}}-internal.aliyuncs.com veya https://oss-{{regionName}}-internal.aliyuncs.com.

      Not

      vpc100-oss-{{regionName}}.aliyuncs.com dahili erişim uç noktası biçimi kullanım dışıdır. En kısa sürede yeni biçime geçin.

    • Genel: http://oss-{{regionName}}.aliyuncs.com veya https://oss-{{regionName}}.aliyuncs.com.

    Konsol varsayılan olarak dahili ağ üzerinden OSS'ye erişmek için HTTP kullanır. HTTPS kullanmak için PV'yi kubectl kullanarak oluşturmanız gerekir.

    Geri kazanma ilkesi

    Dinamik olarak sağlanan kalıcı birimler için geri kazanma ilkesi. OSS kalıcı birimleri yalnızca Retain değerini destekler; bu, bir PVC'yi sildiğinizde karşılık gelen kalıcı birimin ve OSS paketindeki verilerin silinmediği anlamına gelir.

    Optional Parameters:

    OSS kalıcı birimi için özel parametreler, -o -o biçimindedir. Örneğin: -o umask=022 -o max_stat_cache_size=100000 -o allow_other.

    Ayrıntılar için genişletin

    • umask: Dosyalar ve dizinler için izin maskesini ayarlar.

      Örneğin, umask=022 dosya izinlerini 755 olarak değiştirir. Bu, SDK'lar veya OSS konsolu gibi diğer yöntemlerle yüklenen ve varsayılan izni 640 olan dosyaların izin sorununu çözer. Okuma/yazma ayrımı veya çok kullanıcılı erişim için bu parametreyi yapılandırmanızı öneririz.

    • max_stat_cache_size: Meta veri önbelleği girişlerinin üst sınırını ayarlar, örneğin 100000. Meta veriler bellekte önbelleğe alınarak ls ve stat gibi işlemlerin performansı artırılır.

      Ancak bu önbellek, OSS konsolu, SDK'lar veya ossutil aracılığıyla yapılan dosya değişikliklerini anında algılayamaz. Bu durum uygulamaların tutarsız verileri okumasına neden olabilir. Katı veri tutarlılığı gereksinimleriniz varsa önbelleği devre dışı bırakmak için bu parametreyi 0 olarak ayarlayın veya stat_cache_expire parametresini kullanarak önbellek sona erme süresini kısaltın. Ancak bu, okuma performansını azaltabilir.

    • allow_other: Birimi bağlayan kullanıcı dışındaki kullanıcıların bağlama yolundaki dosyalara ve dizinlere erişmesine olanak tanır. Bu, birimi bağlamayan kullanıcıların da verilere erişmesi gereken çok kullanıcılı paylaşımlı ortamlar için uygundur.

    İsteğe bağlı parametreler hakkında daha fazla bilgi için bkz. Bağlama seçenekleri ve ossfs 1,0 yapılandırmasına ilişkin en iyi uygulamalar.

3. Adım: Bir PVC oluşturun

Depolama kaynaklarını dinamik olarak talep etmek için bir PVC oluşturun. CSI eklentisi StorageClass'a dayanarak otomatik olarak bir PV oluşturur.

kubectl

  1. pvc-oss.yaml adlı bir dosya oluşturun:

    apiVersion: v1
    kind: PersistentVolumeClaim
    metadata:
      # PVC name
      name: pvc-oss
    spec:
      # Configure the access mode. ReadOnlyMany means that ossfs mounts the OSS bucket in read-only mode.
      accessModes:
      - ReadOnlyMany
      volumeMode: Filesystem
      resources:
        requests:
          # Declare the requested storage capacity. This value does not limit the actual capacity of the OSS volume.
          storage: 20Gi
      # Specify the StorageClass to use.
      storageClassName: sc-oss

    Parametre

    Açıklama

    accessModes

    Erişim modunu belirtir. Desteklenen değerler ReadOnlyMany ve ReadWriteMany değerleridir.

    ReadOnlyMany olarak ayarlanırsa ossfs OSS paketini salt okunur modda bağlar.

    storage

    Birim için talep edilen kapasite. Bu değer OSS biriminin gerçek kapasitesini sınırlamaz.

    storageClassName

    StorageClass adı.

  2. PVC'yi oluşturun:

    kubectl apply -f pvc-oss.yaml
  3. PVC'nin oluşturulduğunu ve Bound durumunda olduğunu doğrulayın:

    kubectl get pvc pvc-oss

    Beklenen çıktı:

    NAME           STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS         VOLUMEATTRIBUTESCLASS   AGE
    pvc-oss        Bound    oss-251d111d-3b0b-4879-81a0-eb5a19xxxxxx   20Gi       ROX            sc-oss             <unset>                 4d20h

Konsol

  1. Clusters sayfasında kümenizin adını tıklayın. Sol gezinme bölmesinde Volumes > Persistent Volume Claims seçeneğini tıklayın.

  2. Persistent Volume Claims sayfasında Create seçeneğini tıklayın. PVC Type değerini OSS olarak ayarlayın ve parametreleri yapılandırın.

    Parametre

    Açıklama

    Allocation Mode

    Use StorageClass seçeneğini belirleyin.

    Existing Storage Class

    Select Storage Class seçeneğini tıklayın ve daha önce oluşturulan StorageClass'ı seçin.

    Kapasite

    Birim için talep edilen kapasite. Bu değer OSS biriminin gerçek kapasitesini sınırlamaz.

    Access Mode

    Erişim modunu belirtir. Desteklenen değerler ReadOnlyMany ve ReadWriteMany değerleridir.

    ReadOnlyMany olarak ayarlanırsa ossfs OSS paketini salt okunur modda bağlar.

4. Adım: Bir uygulama oluşturun ve bir birim bağlayın

Birimi bağlamak için uygulamanızda PVC'ye başvurun.

kubectl

  1. Bir oss-workload.yaml dosyası oluşturun.

    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: oss-workload
      labels:
        app: nginx
    spec:
      replicas: 2
      selector:
        matchLabels:
          app: nginx
      template:
        metadata:
          labels:
            app: nginx
        spec:
          containers:
          - name: nginx
            image: anolis-registry.cn-zhangjiakou.cr.aliyuncs.com/openanolis/nginx:1.14.1-8.6
            ports:
            - containerPort: 80
            volumeMounts:
              # The mount path in the container.
              - name: pvc-oss
                mountPath: "/data"
            # Configure a health check.
            livenessProbe:
              exec:
                command:
                - ls
                - /data
              initialDelaySeconds: 30
              periodSeconds: 30
          volumes:
            - name: pvc-oss
              persistentVolumeClaim:
                # Reference the PVC that you created.
                claimName: pvc-oss
  2. Uygulamayı oluşturun.

    kubectl create -f oss-workload.yaml
  3. Bağlamayı doğrulayın.

    • Pod'ların çalıştığını onaylayın.

      kubectl get pod -l app=nginx
    • Bir Pod'a erişin ve bağlama noktasını kontrol edin.

      kubectl exec -it <pod-name> -- ls /data

      Çıktıda OSS bağlama yolundaki dosyalar listelenmelidir.

Konsol

  1. ACK Kümeleri sayfasında kümenizin adını tıklayın. Sol gezinme bölmesinde Workloads > Deployments seçeneğini tıklayın.

  2. Deployments sayfasının sağ üst köşesinde Create from Image seçeneğini tıklayın.

  3. Create from Image seçeneğini tıklayın ve uygulama parametrelerini yapılandırmak için ekrandaki talimatları izleyin.

    Ana parametreler aşağıdaki tabloda açıklanmıştır. Diğer parametreler için varsayılan değerleri kullanabilirsiniz. Daha fazla bilgi için Deployment oluşturma konusuna bakın.

    Yapılandırma sayfası

    Parametre

    Açıklama

    Basic Information

    Replicas:

    Deployment için Pod çoğaltma sayısı.

    Container

    Görüntü adı

    Uygulama kapsayıcı görüntüsünün adresi, örneğin anolis-registry.cn-zhangjiakou.cr.aliyuncs.com/openanolis/nginx:1.14.1-8.6.

    Required Resources

    Her kapsayıcıya ayrılacak vCPU ve bellek miktarı.

    Volumes

    Add PVC seçeneğini tıklayın ve ardından parametreleri yapılandırın.

    • Mount Source: Daha önce oluşturduğunuz PVC'yi seçin.

    • Container Path: Birimin bağlanacağı kapsayıcı içindeki yol, örneğin /data.

    Labels and Annotations

    Pod etiketi

    Örneğin, anahtarı 'app' ve değeri 'nginx' olarak ayarlayın.

  4. Uygulama dağıtım durumunu kontrol edin.

    Deployments sayfasında uygulamanızın adını tıklayın. Pods sekmesinde Pod'ların Running durumunda olduğunu doğrulayın.

5. Adım: Paylaşımlı ve kalıcı depolamayı doğrulayın

Paylaşımlı depolamayı doğrulayın

Paylaşımlı depolamayı doğrulamak için bir Pod'da bir dosya oluşturun ve ardından başka bir Pod'da görüntüleyin.

  1. Uygulama Pod'larının adlarını alın.

    kubectl get pod -l app=nginx
  2. Bu örnekte oss-workload-66fbb85b67-d**** Pod'u kullanılmaktadır:

    • ReadWriteMany: /data yolunda tmpfile dosyasını oluşturun.

      kubectl exec oss-workload-66fbb85b67-d**** -- touch /data/tmpfile
    • ReadOnlyMany: OSS konsolu aracılığıyla veya cp ile dosya yükleme yoluyla tmpfile dosyasını OSS paketindeki ilgili yola yükleyin.

  3. Başka bir Pod'un bağlama yolunda dosyayı kontrol edin.

    Örnek olarak bağlama yolu data olan oss-workload-66fbb85b67-l**** adlı bir Pod ele alınmaktadır.

    kubectl exec oss-workload-66fbb85b67-l**** -- ls /data | grep tmpfile

    Çıktıda dosyanın var olması Pod'ların veri paylaşabildiğini doğrular.

    tmpfile
    Beklenen çıktıyı görmüyorsanız CSI bileşeni sürümünüzün v1,20,7 veya üzeri olduğundan emin olun.

Kalıcı depolamayı doğrulayın

Kalıcı depolamayı doğrulamak için bir Pod'u silin ve ardından Pod otomatik olarak yeniden oluşturulduktan sonra dosyanın kaldığını kontrol edin.

  1. Bir uygulama Pod'unu silin. Deployment denetleyicisi Pod'u otomatik olarak yeniden oluşturur.

    kubectl delete pod oss-workload-66fbb85b67-d****
  2. Pod'ların durumunu kontrol edin. Yeni Pod'un başlamasını ve Running durumuna gelmesini bekleyin.

    kubectl get pod -l app=nginx
  3. /data yolundaki dosyaları görüntüleyin.

    Bu örnekte bağlama yolu data olan oss-workload-66fbb85b67-z**** adlı bir Pod kullanılmaktadır.

    kubectl exec oss-workload-66fbb85b67-z**** -- ls /data | grep tmpfile

    Çıktıda tmpfile dosyasının hâlâ var olduğu görülür; bu da Pod yeniden oluşturulduktan sonra bile verilerin kalıcı olduğunu doğrular.

    tmpfile

Bilinen etkiler

  • Veri bütünlüğü riskleri

    • Eşzamanlı yazma tutarlılığı riski: Yazma kararlılığını artırmak için CSI bileşenini v1,28 veya üzeri bir sürüme yükseltmenizi öneririz. Ancak tek dosyalı eşzamanlı yazma senaryolarında OSS'nin "üzerine yazarak yükleme" özelliği yine de verilerin üzerine yazabilir. Veri tutarlılığını uygulama katmanında sağlamalısınız.

    • Veri senkronizasyonu ve yanlışlıkla silme riski: Bir birim bağlandığında bir uygulama Pod'unda veya ana bilgisayar düğümünde bağlama yolundaki dosyaların silinmesi veya değiştirilmesi bu değişiklikleri doğrudan OSS Bucket'taki kaynak dosyalarla senkronize eder. Yanlışlıkla veri silinmesini önlemek için OSS Bucket'ınızda sürüm oluşturmayı etkinleştirmenizi öneririz.

  • Uygulama kararlılığı riskleri

    • OOM riski: Çok sayıda dosyada (örneğin, düğüm belleğine bağlı olarak 100.000'den fazla) ilk kez readdir işlemi (örneğin, bir kabuk betiğindeki ls komutu) gerçekleştirdiğinizde ossfs tüm meta verileri bir kerede yükler ve büyük miktarda bellek tüketir. Bu durum işlemin OOM Killed hatası almasına ve bağlama noktasının kullanılamaz hale gelmesine neden olabilir.

      Bu riski azaltmak için OSS Paketinin bir alt dizinini bağlamanızı veya dizin yapınızı optimize etmenizi öneririz.

    • Uzatılmış bağlama süresi: Bir uygulamada securityContext.fsgroup yapılandırılması kubelet'in bir birim bağlarken dosya izinlerini yinelemeli olarak değiştirmesine (chmod/chown) neden olur. Birimde çok sayıda dosya varsa bağlama süresi önemli ölçüde uzar ve bu durum ciddi Pod başlatma gecikmelerine yol açabilir.

      Bu parametreyi yapılandırmanız gerekiyorsa ancak bağlama süresini azaltmak istiyorsanız OSS birimleri için artan bağlama süresi konusuna bakın.

    • Anahtar geçersiz kılma riski (AccessKey kimlik doğrulaması): Bir PV tarafından başvurulan bir AccessKey geçersiz hale gelirse veya izinleri değişirse ilişkili uygulama hemen erişimi kaybeder.

      Erişimi geri yüklemek için Secret'taki kimlik bilgilerini güncellemeniz ve yeniden bağlamayı zorlamak için uygulama Pod'unu yeniden başlatmanız gerekir. Bu durum hizmet kesintisine neden olur; bu nedenle işlemi bir bakım penceresi sırasında gerçekleştirin. Daha fazla bilgi için Çözümler konusuna bakın.

  • Maliyet riskleri

    • Parça maliyetleri: 10 MB'tan büyük dosyalar yüklenirken ossfs çok parçalı yükleme gerçekleştirerek dosyayı parçalara böler. Uygulama yeniden başlatma gibi nedenlerle bir yükleme beklenmedik şekilde kesintiye uğrarsa eksik parçalardan kaynaklanan depolama maliyetlerinden kaçınmak için parçaları manuel olarak silmeniz veya yaşam döngüsü kuralları kullanarak silmeniz gerekir.

Kaynak serbest bırakma

  1. İş yüklerini silin

    • Eylem: PVC'yi kullanan Deployment'lar ve StatefulSet'ler gibi tüm iş yüklerini silin. Bu işlem Pod'ları durdurur ve birimin bağlantısını kaldırır.

    • Örnek komut: kubectl delete deployment <your-deployment-name>

  2. PVC'yi silin

    • Eylem: PVC'yi silin. Dinamik olarak sağlanan OSS birimleri için geri kazanma ilkesi (reclaimPolicy) yalnızca Retain değerini destekler. PVC'yi sildiğinizde buna bağlı olan PV Released durumuna geçer ve arka plandaki OSS paketi ilgili alt dizini ve verileri tamamen korur.

    • Örnek komut: kubectl delete pvc <your-pvc-name>

  3. PV'yi silin

    • Eylem: Released durumundaki PV'yi silin. Bu işlem yalnızca PV kaynak nesnesini Kubernetes'ten kaldırır ve arka plandaki OSS paketindeki hiçbir veriyi silmez.

    • Örnek komut: kubectl delete pv <your-pv-name>

  4. StorageClass ve Secret'ı silin (isteğe bağlı)

    • Eylem: Artık ihtiyaç duyulmuyorsa StorageClass'ı ve ilişkili Secret'ı silin. Bu işlem yalnızca kaynak nesnelerini Kubernetes'ten kaldırır ve arka plandaki OSS paketini etkilemez.

    • Örnek komutlar: kubectl delete sc <your-storageclass-name>, kubectl delete secret <your-secret-name>

İlgili belgeler

  • CNFS kullanarak OSS birimlerini yönetin ve performanslarını ile QoS'lerini iyileştirin. Daha fazla bilgi için OSS birimlerinin yaşam döngüsünü yönetme konusuna bakın.

  • OSS'de beklemedeki hassas verileri korumak için sunucu tarafı şifrelemeyi etkinleştirin. Daha fazla bilgi için ossfs 1,0 birimlerini şifreleme konusuna bakın.

  • ossfs ve OSS ile ilgili sık sorulan sorular için ossfs 1,0 (varsayılan) ve ossfs 1,0 birimi SSS konularına bakın.

  • Kapsayıcı depolama izleme özelliğini etkinleştirin ve uyarıları yapılandırarak birim anomalilerini veya performans darboğazlarını hızla tespit edin.

  • ossfs 1,0, rastgele ve eşzamanlı yazmalar için ossfs 2,0 sürümüne kıyasla daha güçlü veri tutarlılığı sağlar. Ancak ossfs 2,0 sıralı okuma ve yazma işlemleri için daha iyi performans sunar.