Container Service for Kubernetes:ossfs 2.0 persistent volume FAQ

# Check pod events for mount errors
kubectl describe pod <pod-name> -n <namespace>

# Check whether the ossfs 2.0 pod exists and is running
kubectl -n ack-csi-fuse get pod -l csi.alibabacloud.com/volume-id=<pv-name> -owide

AccessKey izinleri nedeniyle FailedMount hatasıyla pod başlatılamıyor

AccessKey gerekli izinlere sahip olmadığından pod FailedMount hatası bildirir.

Bu sorunu çözmek için:

1. RAM kullanıcısının erişim ilkesinin OSS bağlama gereksinimlerini karşıladığını doğrulayın. Bkz. Statik olarak sağlanan ossfs 2.0 birimi kullanma.

2. AccessKey'in devre dışı bırakılmadığını veya yenilenmediğini onaylayın.

Sanal düğümdeki pod "secrets is forbidden" hatasıyla başarısız oluyor

Pod olayı aşağıdaki içeriği içerir:

failed to get secret secrets "xxx" is forbidden: User "serverless-xxx" cannot get resource "secrets" in API group "" in the namespace "xxx"

Sanal düğümlerde (Container Compute Service pod'ları), nodePublishSecretRef tarafından başvurulan Secret, PersistentVolumeClaim (PVC) ile aynı ad alanında bulunmalıdır.

Secret'i PVC ad alanında oluşturun. PV'de bu Secret'a başvuracak şekilde nodePublishSecretRef değerini ayarlayın. Bkz. RAM kullanıcısının AccessKey'ini kullanarak kimlik doğrulama.

Pod "mounter.sock: connect: no such file or directory" hatasıyla başarısız oluyor

Pod olayı aşağıdaki içeriği içerir:

FailedMount /run/fuse.ossfs/xxxxxx/mounter.sock: connect: no such file or directory

ossfs 2.0 pod'u doğru şekilde başlatılmamış veya beklenmedik bir şekilde silinmiştir.

1. Uygulama pod'unun zamanlandığı düğümde ossfs 2.0 pod'unun var olup olmadığını kontrol edin:

   • Pod varsa ancak Running durumunda değilse sorunu giderin. Pod Running durumuna geldikten sonra uygulamayı yeniden bağlamak için uygulama pod'unu yeniden başlatın.

   • Pod yoksa bir sonraki adıma geçin.

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

2. (İsteğe bağlı) Beklenmedik pod silme işlemleri için denetim günlüklerini kontrol edin. Yaygın nedenler arasında temizleme betikleri, düğüm boşaltmaları ve otomatik iyileştirme yer alır. Tekrarlanmasını önlemek için yapılandırmaları ayarlayın.

3. Kalan VolumeAttachment kaynaklarını kontrol edin:

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

4. Yeni bir ossfs 2.0 pod'unun oluşturulduğunu doğrulamak ve yeniden bağlamayı tetiklemek için uygulama pod'unu yeniden başlatın.

Paket yansıtma tabanlı kökene geri dönüş kullandığı için bağlama başarısız oluyor

OSS paketi yansıtma tabanlı kökene geri dönüş kullanıyorsa ve bağlama dizini kaynaktan senkronize edilmemişse bağlama işlemi başarısız olur.

Bağlamadan önce verileri kaynaktan senkronize edin. Bkz. Kökene geri dönüş genel bakış.

Pakette statik web sitesi barındırma etkin olduğu için bağlama başarısız oluyor

Statik web sitesi barındırma etkinleştirildiğinde, ossfs 2.0 dizin kontrolleri index.html gibi dosyalara yönlendirilir ve bu durum bağlamanın başarısız olmasına neden olur.

Bağlamadan önce statik web sitesi barındırmayı devre dışı bırakın veya ayarlayın. Bkz. Statik web sitesi barındırma.

OSS paketinden tek bir dosya bağlama

ossfs 2.0, bir OSS paket yolunu dosya sistemi olarak bağlar; tek bir dosyayı doğrudan bağlayamaz. Belirli bir dosyaya erişmek için üst dizini bağlayın ve volumeMounts içinde subPath kullanın.

Örneğin, bucket:/subpath konumundaki a.txt ve b.txt dosyalarını farklı pod'larda /path/to/file/ konumuna bağlamak için:

PV yapılandırması -- üst dizini bağlayın:

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              # Parent path containing a.txt and b.txt
      url: "oss-cn-hangzhou.aliyuncs.com"
      fuseType: ossfs2

Pod volumeMounts -- dosyayı seçmek için subPath kullanın:

  volumeMounts:
    - mountPath: /path/to/file   # Maps to bucket:/subpath
      name: oss-pvc              # Must match the volume name
      subPath: a.txt             # Relative path within bucket:/subpath

Bağlama işleminden sonra, pod içindeki /path/to/file/a.txt yolu bucket:/subpath/a.txt konumuna eşlenir.

Bkz. Statik olarak sağlanan ossfs 2.0 birimi kullanma.

Farklı bir hesaptaki OSS paketini bağlama

Hesaplar arasında paket bağlamak için RRSA (Service Accounts için RAM Rolleri) kullanın.

Kümenizin ve CSI bileşeni sürümlerinizin RRSA gereksinimlerini karşıladığını doğrulayın.

Aşağıdaki yordam, B Hesabı'ndaki bir paketi A Hesabı'ndaki bir kümeye bağlar.

B Hesabı'nda (paketin bulunduğu hesap):

1. A Hesabı'na güvenen roleB adlı bir RAM rolü oluşturun. Bkz. Güvenilen Alibaba Cloud hesabı için RAM rolü oluşturma.

2. roleB rolüne hedef OSS paketlerine erişim izni verin.

3. RAM konsolu içinde roleB ayrıntılar sayfasını açın ve ARN'sini kopyalayın. Örnek: acs:ram::130xxxxxxxx:role/roleB.

A Hesabı'nda (kümenin bulunduğu hesap):

1. RRSA için roleA adlı bir RAM rolü oluşturun. Güvenilen varlık türünü OIDC IdP olarak ayarlayın.

2. roleA rolüne roleB rolünü üstlenme izni verin. roleA rolünün OSS erişim ilkesine ihtiyacı yoktur; sts:AssumeRole eylemini içeren bir ilke ekleyin (örneğin AliyunSTSAssumeRoleAccess). Bkz. Kümede RRSA'yı etkinleştirme (statik birimler) veya Dinamik olarak sağlanan ossfs 1.0 birimi kullanma (dinamik birimler).

Birimi yapılandırma -- assumeRoleArn değerini roleB rolünün ARN'sine ayarlayın:

• Statik olarak sağlanan birim (PV): volumeAttributes bölümüne ekleyin:

    assumeRoleArn: <ARN of roleB>

• Dinamik olarak sağlanan birim (StorageClass): parameters bölümüne ekleyin:

    assumeRoleArn: <ARN of roleB>

OSS erişim uç noktalarını çözmek için CoreDNS kullanma

OSS uç noktalarını dahili küme alan adı üzerinden çözmek için, bağlama sırasında CoreDNS'e öncelik verecek şekilde ossfs pod'u için bir DNS ilkesi yapılandırın.

CSI bileşeni v1.34.2 veya sonraki bir sürüm gerektirir. Yükseltme yapmak için bkz. CSI bileşenlerini yönetme.

• Statik birim (PV): spec.csi.volumeAttributes bölümüne dnsPolicy ekleyin.

  dnsPolicy: ClusterFirstWithHostNet

• Dinamik birimler (StorageClass): parameters bölümüne dnsPolicy ekleyin.

  dnsPolicy: ClusterFirstWithHostNet

RRSA için özel ARN veya ServiceAccount kullanma

Varsayılan olarak, PV'de roleName ayarlandığında CSI, Role ARN ve OIDC Provider ARN değerlerini otomatik olarak alır. Üçüncü taraf OIDC IdP kullanma veya varsayılan olmayan ServiceAccount kullanma gibi daha fazla kontrol sağlamak için roleArn ve oidcProviderArn değerlerini doğrudan belirtin.

roleArn ve oidcProviderArn birlikte yapılandırılmalıdır. Ayarlandıklarında roleName değerini geçersiz kılarlar.

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               # Must match the PV name
    volumeAttributes:
      bucket: "oss"
      url: "oss-cn-hangzhou.aliyuncs.com"
      authType: "rrsa"
      fuseType: "ossfs2"
      oidcProviderArn: "<oidc-provider-arn>"
      roleArn: "<role-arn>"
      # roleName: "<role-name>"        # Ignored when roleArn and oidcProviderArn are set
      serviceAccountName: "csi-fuse-<service-account-name>"

Yapılandırılan birim kapasitesinin aşılması

OSS, paketlerde veya alt dizinlerde kapasite sınırlarını zorlamaz. .spec.capacity (PV) ve .spec.resources.requests.storage (PVC) değerleri dikkate alınmaz; bağlı PV ve PVC arasında bu değerlerin eşleştiğinden emin olun.

Gerçek kullanım yapılandırılan kapasiteyi aşarsa birim normal şekilde çalışmaya devam eder. Ölçeklendirme gerekmez.

ossfs 2.0 işlemini yeniden başlatma

Kimlik bilgilerini veya ossfs 2.0 sürümünü değiştirdikten sonra çalışan işlem değişiklikleri otomatik olarak almaz. Değişikliklerin uygulanması için hem ossfs 2.0 pod'unun (ack-csi-fuse içindeki csi-fuse-ossfs2-*) hem de birimi kullanan tüm uygulama pod'larının yeniden başlatılması gerekir; bu durum hizmet kesintisine neden olur.

Yordam:

1. Hedef ossfs 2.0 pod'unu belirleyin. <pv-name> ve <node-name> değerlerini değiştirin:

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

2. Bu birimi kullanan tüm uygulama pod'larını belirleyin. <ns> ve <pvc-name> değerlerini değiştirin. Used By alanı pod'ları listeler:

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

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

3. ossfs 2.0 pod'u ile aynı düğümdeki uygulama pod'larını bulun:

      kubectl -n <ns> get pod -owide | grep <node-name>

4. Tüm uygulama pod'larını aynı anda silin. kubectl scale veya eşdeğer bir komut kullanın. Hiçbir pod bağlamaya referans vermediğinde CSI, csi-fuse-ossfs2-* pod'unu geri alır. Kopyalar yeniden oluşturulduğunda birim güncellenmiş yapılandırmayla yeniden bağlanır.

Alternatif yaklaşım -- aynı anda silme mümkün değilse (örneğin, bir Deployment, StatefulSet veya DaemonSet silinen pod'ları hemen yeniden oluşturuyorsa) veya uygulama geçici OSS okuma/yazma hatalarına tolerans gösteriyorsa:

1. Birim için VolumeAttachment öğesini bulun. Beklenen çıktı:

      kubectl get volumeattachment | grep <pv-name> | grep <node-name>

      csi-bd463c719189f858c2394608da7feb5af8f181704b77a46bbc219b**********   ossplugin.csi.alibabacloud.com   <pv-name>   <node-name>   true   12m

2. VolumeAttachment öğesini silin. Uygulama pod'ları OSS işlemlerinde disconnected error hatası döndürür.

3. Uygulama pod'larını tek tek yeniden başlatın. Her biri, güncellenmiş yapılandırmayla yeni bir csi-fuse-ossfs2-* pod'una bağlanır.