Container Service for Kubernetes:FAQ for ossfs 1.0 volumes

Yavaş OSS birimi bağlama işlemleri

Belirti

Bir OSS biriminin bağlanması beklenenden daha uzun sürer.

Neden

Aşağıdaki iki koşul da geçerliyse kubelet, birim bağlama sırasında chmod veya chown işlemi gerçekleştirir ve bu durum bağlama süresini artırır.

• PV ve PVC'de AccessModes değeri ReadWriteOnce olarak ayarlanır.

• Uygulama şablonunda securityContext.fsgroup yapılandırması vardır.

Çözüm

• ossfs bağlama aracı, kendi bağlama noktasındaki dosyaların UID, GID ve mod değerlerini değiştirmek için parametreler sağlar.

  Parametre	Açıklama
  uid	Bağlama dizinindeki alt dizinlerin ve dosyaların sahibi olan kullanıcının UID değerini belirtir.
  gid	Bağlama dizinindeki alt dizinlerin ve dosyaların sahibi olan kullanıcı grubunun GID değerini belirtir.
  umask	Bağlama hedefindeki dosya ve klasörler için izin maskesini ayarlar. umask seçeneği veya chmod aracılığıyla). Bu seçenek değer almaz ve yalnızca -oallow_other olarak belirtilir. Varsayılan olarak yalnızca root kullanıcısı bunu kullanabilir." data-node="2183793" id="70d5a8f3f6yf4" is-conref="true">Sistemdeki tüm kullanıcıların bağlama noktası dizinine erişmesine olanak tanır. Bu ayarın yalnızca bağlama noktasının kendisini etkilediğini, içindeki dosyaları etkilemediğini unutmayın. Dosya izinlerinin ayrı olarak yönetilmesi gerekir (örneğin umask seçeneği veya chmod aracılığıyla). Bu seçenek değer almaz ve yalnızca -oallow_other olarak belirtilir. Varsayılan olarak yalnızca root kullanıcısı bunu kullanabilir. Not Sürüm 1.91.*: Dosyalar için varsayılan izin 0640, klasörler için varsayılan izin 0750'dir. Sürüm 1.80.*: Hem dosyalar hem de klasörler için varsayılan izin 0777'dir.

  Bu parametreleri yapılandırdıktan sonra securityContext içindeki fsgroup parametresini kaldırın.

• Kubernetes kümelerinin 1.20 ve sonraki sürümlerinde fsGroupChangePolicy değerini OnRootMismatch olarak da ayarlayabilirsiniz. Bu sayede chmod ve chown işlemleri yalnızca ilk başlatmada gerçekleştirilir. Sonraki bağlama süreleri normal olacaktır. fsGroupChangePolicy hakkında daha fazla bilgi için bkz. Configure a Security Context for a Pod or Container.

OSS birimi bağlama izin sorunları

Aşağıdaki senaryolarda Permission Denied veya Operation not permitted hatasıyla karşılaşabilirsiniz.

OSS birim bağlama hatası ve uygulama Pod olayı: FailedMount

Belirti

Bir OSS birimi bağlanamaz, pod başlatılamaz ve olay günlüğünde FailedMount hatası görünür.

Neden

• Neden 1: ossfs'in eski sürümleri, paket içinde mevcut olmayan bir dizini bağlamayı desteklemez.

  Önemli

  OSS konsolunda görünen bir alt dizin yolu, sunucuda fiilen mevcut olmayabilir. Gerçek durum kaynağı ossutil aracı veya OSS API çağrılarından dönen yanıttır. Örneğin, doğrudan /a/b/c/ dizinini oluşturursanız /a/b/c/ bağımsız bir dizin nesnesidir ancak /a/ veya /a/b/ dizin nesneleri fiilen mevcut değildir. Benzer şekilde, /a/*, /a/b ve /a/c gibi dosyalar yüklerseniz bunlar ayrı dosya nesneleridir ancak /a/ dizin nesnesi mevcut değildir.

• Neden 2: AccessKey veya RRSA rol bilgileri yanlış ya da ilişkili izinler yetersiz.

• Neden 3: Uygulamanın çalışma zamanı ortamı, OSS paket ilkesi tarafından engelleniyor.

• Neden 4: Olay aşağıdaki mesajı 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 (ACS podları) oluşturulan uygulamalar için PVC, kimlik doğrulama bilgilerini nodePublishSecretRef alanını kullanarak belirtiyorsa Secret, PVC ile aynı ad alanında olmalıdır.

• Neden 5: CSI sürüm 1.30.4 ve sonrasında OSSFS'in çalıştığı pod ack-csi-fuse ad alanında çalışır. Bağlama sırasında CSI sürücüsü önce OSSFS'in bulunduğu pod'u başlatır ardından bu pod'daki OSSFS işlemini başlatmak için bir RPC isteği gönderir. Olay FailedMount /run/fuse.ossfs/xxxxxx/mounter.sock: connect: no such file or directory mesajını içeriyorsa OSSFS'in bulunduğu pod başlatılamamış veya beklenmedik şekilde silinmiştir.

• Neden 6: Olay Failed to find executable /usr/local/bin/ossfs: No such file or directory mesajını içerir. Bu durum, OSSFS'in düğüme yüklenemediğini gösterir.

• Neden 7: Olay error while loading shared libraries: xxxxx: cannot open shared object file: No such file or directory mesajını içerir. Geçerli CSI sürümünde ossfs doğrudan düğüm üzerinde çalıştığından ve düğümün işletim sistemi ossfs için gereken dinamik kütüphaneleri içermediğinden bağlama başarısız olur. Bu hata aşağıdaki durumlarda oluşabilir:

  • Düğüme işletim sistemiyle uyumlu olmayan bir ossfs sürümü yüklediniz.

  • Düğümdeki işletim sistemi yükseltmesi varsayılan OpenSSL sürümünü değiştirdi. Örneğin, Alibaba Cloud Linux 2'den Alibaba Cloud Linux 3'e geçiş.

  • ossfs bir düğümde çalışırken yalnızca CentOS, Alibaba Cloud Linux, ContainerOS ve Anolis OS desteklenir.

  • Uyumlu bir işletim sistemine sahip bir düğümde FUSE, cURL veya xml2 gibi ossfs için gerekli olan varsayılan dinamik kütüphaneleri sildiniz ya da varsayılan OpenSSL sürümünü değiştirdiniz.

• Neden 8: Bir OSS alt dizini bağlarken AccessKey veya RRSA rolünün yalnızca o alt dizin için izinleri varsa bağlama başarısız olur. ossfs pod günlüklerinde hem 403 AccessDenied hem de 404 NoSuchKey hataları bulunur.

  ossfs başladığında OSS paketinin izinlerini ve bağlantısını otomatik olarak denetler. Hedef bir OSS alt dizini olduğunda 1.91.5 öncesi ossfs sürümleri önce paketin kök dizinine erişmeyi dener. Erişim başarısız olursa alt dizine erişmeyi yeniden dener. Pakette tam salt okunur izinlere sahipseniz ossfs'in yeni sürümleri OSS paketinde mevcut olmayan bir alt dizini bağlayabilir.

  Bu nedenle AccessKey veya RRSA tarafından kullanılan rol yalnızca alt dizin üzerinde izinlere sahipse ilk doğrulama sırasında 403 AccessDenied hatası bildirilir. Alt dizin ayrıca mevcut değilse ardından 404 NoSuchKey hatası bildirilir ve işlem sonlandırılarak bağlama başarısız olur.

• Neden 9: Paket, yansıtma tabanlı kaynak siteye geri dönüş için yapılandırılmıştır ancak bağlama dizini kaynak siteden eşitlenmemiştir.

• Neden 10: Paket statik web sitesi barındırma için yapılandırılmıştır. ossfs OSS tarafındaki bağlama dizinini denetlerken istek index.html gibi dosyalara yönlendirilir.

Çözüm

• Neden 1 için çözüm:

  Alt yolun OSS sunucusunda var olup olmadığını denetleyin.

  PV'nin bağlama yolunun sub/path/ olduğunu varsayalım. objectname değeri sub/path/ olan bir nesneyi sorgulamak için stat (Paket ve nesne bilgilerini görüntüleme) kullanabilir veya key değeri sub/path/ olan bir nesneyi sorgulamak için HeadObject OpenAPI kullanabilirsiniz. 404 hatası dönerse alt dizin sunucu tarafında mevcut değildir.

  • Eksik paketi veya alt dizini manuel olarak oluşturmak ve ardından yeniden bağlamak için ossutil, SDK veya OSS konsolu gibi araçları kullanabilirsiniz.

  • ossfs 1.91 ve sonraki sürümler bağlama dizininin mevcut olmasını gerektirmez. ossfs sürümünü yükseltmek de bu sorunu çözer. Daha fazla bilgi için bkz. ossfs 1.0'ın yeni özellikleri ve performans testleri. Yükseltmeden sonra bağlama hala başarısız olursa bu konunun Neden 8 bölümüne bakın.

• Neden 2 için çözüm:

  • Bağlama için kullanılan RAM kullanıcısının veya RAM rolünün ilkesinin 2. RAM rolü oluşturma ve yetkilendirme bölümünde listelenen izinleri içerdiğini doğrulayın.

  • Kök bağlama yolunun ve alt yolun dosya sistemi izinlerini doğrulayın. Daha fazla bilgi için OSS birim bağlama izin sorunlarındaki Senaryo 2 ve 7'ye bakın.

  • RAM kullanıcısı AccessKey kimlik doğrulaması kullanılarak bağlanan birimler için bağlamada kullanılan AccessKey'in devre dışı bırakılıp bırakılmadığını veya döndürülüp döndürülmediğini doğrulayın. Daha fazla bilgi için OSS birim bağlama izin sorunlarındaki Senaryo 5'e bakın.

  • RRSA kimlik doğrulaması kullanılarak bağlanan birimler için RAM rolünde doğru güven ilkesinin yapılandırıldığını doğrulayın. Güven ilkesinin nasıl yapılandırılacağı hakkında bilgi için bkz. 1. Küme için RRSA'yı etkinleştirme. Varsayılan olarak güvenilir ServiceAccount, uygulamanın kullandığı ServiceAccount değil ack-csi-fuse ad alanındaki csi-fuse-ossfs değeridir.

    Önemli

    RRSA kimlik doğrulaması yalnızca 1.30.4 veya sonraki sürüm CSI bileşenlerini kullanan 1.26 veya sonraki sürüm kümeler için desteklenir. 1.30.4 öncesi sürümlerde 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.

• Neden 3 için çözüm:

  OSS paket ilkesini denetleyin ve düzeltin. Daha fazla bilgi için OSS birim bağlama izin sorunlarındaki Senaryo 1'e bakın.

• Neden 4 için çözüm:

  Secret'ı PVC ile aynı ad alanında oluşturun. Ardından yeni bir PV oluştururken nodePublishSecretRef alanını bu Secret'a yönlendirin. Daha fazla bilgi için bkz. OSS salt okunur izin ilkesi.

• Neden 5 için çözüm:

  1. ossfs pod'unun var olduğunu onaylamak için aşağıdaki komutu çalıştırın. Komutta PV_NAME bağlanan OSS PV'sinin adıdır ve NODE_NAME birimi gerektiren uygulama pod'unun bulunduğu düğümün adıdır.

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

     Pod mevcutsa ancak anormal durumdaysa anormalliğin nedenini araştırın. Pod'un Running durumunda olduğundan emin olun ve ardından yeniden bağlamayı tetiklemek için uygulama pod'unu yeniden başlatın. Pod mevcut değilse sonraki adımlara geçin.

  2. (İsteğe bağlı) Denetim günlüklerini veya diğer kaynakları denetleyerek pod'un beklenmedik şekilde silinip silinmediğini onaylayın. Beklenmedik silmenin yaygın nedenleri arasında temizleme betikleri, düğüm boşaltma ve düğüm kendi kendini iyileştirme yer alır. Bu sorunun tekrar etmesini önlemek için ayarlamalar yapmanızı öneririz.

  3. Hem CSI provisioner hem de CSI eklentisinin 1.30.4 veya sonraki bir sürüme yükseltildiğini onayladıktan sonra aşağıdaki adımları gerçekleştirin:

     1. Kalıcı VolumeAttachment kaynakları olup olmadığını denetlemek için aşağıdaki komutu çalıştırın.

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

        Varsa VolumeAttachment kaynağını silin.

     2. Yeniden bağlamayı tetiklemek için uygulama pod'unu yeniden başlatın ve OSSFS pod'unun beklendiği gibi oluşturulduğunu onaylayın.

• Neden 6 için çözüm:

  1. csi-plugin'i v1.26.2 veya sonraki bir sürüme yükseltmenizi öneririz. Bu sürüm, yeni ölçeklendirilmiş bir düğümün başlatılması sırasında ossfs yükleme hatasını giderir.

  2. İlgili düğümdeki csi-plugin'i yeniden başlatmak için aşağıdaki komutu çalıştırın ve ardından pod'un normal şekilde başlayıp başlamadığını denetleyin.

     Aşağıdaki kodda csi-plugin-**** düğümdeki csi-plugin'in pod adıdır.

     kubectl -n kube-system delete pod csi-plugin-****

  3. Bileşeni yükselttikten veya yeniden başlattıktan sonra sorun devam ederse düğüme oturum açın ve aşağıdaki komutu çalıştırın:

     ls /etc/csi-tool

     Kısmi beklenen çıktı:

     ... ossfs_<ossfsVer>_<ossfsArch>_x86_64.rpm ...

     • Çıktıda OSSFS RPM paketi varsa aşağıdaki komutu çalıştırın ve pod'un normal şekilde başlayıp başlamadığını denetleyin:

       rpm -i /etc/csi-tool/ossfs_<ossfsVer>_<ossfsArch>_x86_64.rpm

     • Çıktıda OSSFS RPM paketi yoksa en son sürümü indirmek için ossfs 1.0 yükleme konusuna bakın.

• Neden 7 için çözüm:

  • ossfs aracını manuel olarak yüklediyseniz işletim sistemi uyumluluğunun düğümün işletim sistemiyle eşleştiğini denetleyin.

  • Düğümün işletim sistemini yükselttiyseniz csi-plugin'i yeniden başlatmak, ossfs sürümünü güncellemek ve ardından yeniden bağlamayı denemek için aşağıdaki komutu çalıştırabilirsiniz:

    kubectl -n kube-system delete pod -l app=csi-plugin

  • CSI sürücüsünü sürüm 1.28 veya sonraki bir sürüme yükseltmenizi öneririz. Bir OSS birimi bağlarken ossfs kümede bir konteyner olarak çalışır ve düğümün işletim sistemi için herhangi bir gereksinimi yoktur.

  • CSI sürücü sürümünü yükseltemiyorsanız uyumlu bir işletim sistemine geçebilir veya eksik dinamik kütüphaneleri manuel olarak yükleyebilirsiniz. Aşağıdaki örnek bir Ubuntu düğümünü kullanır:

    • ossfs'in geçerli kurulum konumunu bulmak için which komutunu kullanın (varsayılan yol /usr/local/bin/ossfs).

      which ossfs

    • ossfs için eksik dinamik kütüphane dosyalarını belirlemek üzere ldd komutunu kullanın.

      ldd /usr/local/bin/ossfs

    • Eksik bir dinamik kütüphane dosyasının (örneğin libcrypto.so.10) ait olduğu paketi bulmak için apt-file komutunu kullanın.

      apt-get install apt-file
      apt-file update
      apt-file search libcrypto.so.10

    • İlgili paketi (örneğin libssl1.0.0) yüklemek için apt-get komutunu kullanın.

      apt-get install libssl1.0.0

• Neden 8 için çözüm:

  • Önerilen çözüm: CSI sürümünü v1.32.1-35c87ee-aliyun veya sonraki bir sürüme yükseltin.

  • Alternatif çözüm 1: Alt dizinin mevcut olup olmadığını onaylamak için Neden 1 çözümüne bakın.

  • Alternatif çözüm 2: Uygulamanız bir alt dizinin uzun süreli bağlanmasını gerektiriyorsa izin kapsamını tüm pakete genişletmenizi öneririz.

• Neden 9 için çözüm:

  Birimi bağlamadan önce verileri kaynak siteden eşitlemeniz gerekir. Daha fazla bilgi için bkz. Kaynak siteye geri dönüş yapılandırmasına genel bakış.

• Neden 10 için çözüm:

  Birimi bağlamadan önce statik web sitesi barındırma yapılandırmasını devre dışı bırakmanız veya ayarlamanız gerekir. Daha fazla bilgi için bkz. Statik web sitesi barındırma.

OSS birim bağlama hatası: uygulama Pod şu olayı bildirir:FailedAttachVolume

Belirti

Bir OSS birimi bağlanamaz, pod başlatılamaz ve olay günlüğünde FailedAttachVolume hatası görünür.

Neden

Olay AttachVolume.Attach failed for volume "xxxxx" : attaching volumes from the kubelet is not supported mesajını içerir. Bu hata, düğümün kubeleti için enable-controller-attach-detach yapılandırmasının etkinleştirilmediğini gösterir.

Bu durum genellikle FlexVolume'dan CSI'ye geçiş yaptığınızda ortaya çıkar. CSI sürüm 1.30.4 ve sonrası AttachVolume işlemini gerçekleştirmek için bu parametreye dayanır ancak geçiş sırasında düğümün kubelet yapılandırması doğru şekilde güncellenmemiştir.

Çözüm

1. Düğümün kubelet yapılandırmasını denetleyin

   Düğüme oturum açma ve kubeletin enable-controller-attach-detach parametresini denetleyin.

   Komutta /etc/systemd/system/kubelet.service.d/10-kubeadm.conf kubelet için varsayılan yapılandırma dosyası yoludur. Kümenizdeki gerçek yolla değiştirin.

   cat /etc/systemd/system/kubelet.service.d/10-kubeadm.conf | grep enable-controller-attach-detach

   Beklenen çıktı true değeridir.

   …… --enable-controller-attach-detach=true ……

2. Düğüm yapılandırmasını güncelleyin

   Kubelet için enable-controller-attach-detach yapılandırması etkinleştirilmemişse önce kümedeki tüm FlexVolume birimlerinin taşındığından emin olun. Ardından Kalıcı depolama olmayan bir küme için FlexVolume'ları CSI'ye taşıma konusuna bakın ve düğüm havuzu ile mevcut düğümler için yapılandırmaları güncellemek amacıyla Adım 3: Kümedeki tüm düğüm havuzlarının yapılandırmalarını değiştirme ve Adım 4: Mevcut düğümlerin yapılandırmalarını değiştirme bölümlerindeki talimatları izleyin.

Bir OSS biriminden tek bir dosya bağlama

Bir OSS birimi, bir pod'da bir OSS yolunu dosya sistemi olarak bağlamak için ossfs kullanır. ossfs tek bir dosyanın bağlanmasını desteklemez. Bir pod'un OSS'ten yalnızca belirli bir dosyayı görmesini istiyorsanız subPath özelliğini kullanın.

OSS'teki bucket:/subpath konumundaki a.txt ve b.txt dosyalarını hedef yol her pod'da /path/to/file/ olacak şekilde iki farklı poda bağlamak istediğinizi varsayalım. İlgili PV'yi aşağıdaki YAML şablonunu kullanarak oluşturabilirsiniz:

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 # The parent path of a.txt and b.txt.
      url: "oss-cn-hangzhou.aliyuncs.com"

İlgili PVC'yi oluşturduktan sonra pod'daki PVC için volumeMounts öğesini aşağıdaki gibi yapılandırın:

  volumeMounts:
    - mountPath: /path/to/file/a.txt # The mount path in the pod that corresponds to bucket:/subpath.
      name: oss-pvc # Must match the name in Volumes.
      subPath: a.txt # Or b.txt. The relative path of the file in bucket:/subpath.

Bağlamadan sonra pod'da a.txt dosyasına erişmek için tam yol /path/to/file/a.txt olur ve bu aslında bucket:/subpath/a.txt konumuna erişir.

OSS birimlerini kullanmaya ilişkin temel talimatlar için bkz. Statik olarak sağlanan ossfs 1.0 birimi kullanma.

RRSA için belirli bir ARN veya ServiceAccount kullanma

OSS birimleri için varsayılan RRSA kimlik doğrulaması üçüncü taraf OIDC kimlik sağlayıcısı kullanma veya varsayılan olmayan ServiceAccount kullanma gibi belirli gereksinimleri karşılamayabilir.

Bu gibi durumlarda PV'de roleName yapılandırma öğesini kullanarak RAM rol adını belirtebilirsiniz. Bu sayede CSI eklentisi varsayılan Rol ARN'sini ve OIDC Sağlayıcı ARN'sini alabilir. Özelleştirilmiş RRSA kimlik doğrulaması uygulamak istiyorsanız PV yapılandırmasını aşağıdaki gibi değiştirmeniz gerekir:

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 be the same as the PV name.
    volumeAttributes:
      bucket: "oss"
      url: "oss-cn-hangzhou.aliyuncs.com"
      otherOpts: "-o umask=022 -o max_stat_cache_size=0 -o allow_other"
      authType: "rrsa"
      oidcProviderArn: "<oidc-provider-arn>"
      roleArn: "<role-arn>"
      #roleName: "<role-name>" # After roleArn and oidcProviderArn are configured, roleName becomes invalid.
      serviceAccountName: "csi-fuse-<service-account-name>" 

Başka bir hesaptan bir OSS paketi bağlama

Başka bir hesaptan bir OSS paketi bağlamak için RRSA kimlik doğrulaması kullanmanızı öneririz.

Küme ve CSI bileşeni sürümlerinin RRSA kimlik doğrulaması gereksinimlerini karşıladığından emin olun.

RRSA kimlik doğrulamasıyla bağlanan bir birim oluşturmadan önce gerekli RAM yetkilendirmesini tamamlamanız gerekir. Aşağıdaki örnekte (kümenin bulunduğu) A Hesabında (OSS paketinin bulunduğu) B Hesabından bir paketin nasıl bağlanacağı gösterilmektedir.

1. B Hesabında aşağıdaki işlemleri gerçekleştirin:

   1. B Hesabında A Hesabına güvenen roleB adlı bir RAM rolü oluşturun. Daha fazla bilgi için bkz. Güvenilen bir Alibaba Cloud hesabı için RAM rolü oluşturma.

   2. roleB rolüne bağlamak istediğiniz OSS paketi için gerekli izinleri verin.

   3. RAM konsolunda roleB ayrıntıları sayfasına gidin ve acs:ram::130xxxxxxxx:role/roleB gibi ARN değerini kopyalayın.

2. A Hesabında aşağıdaki işlemleri gerçekleştirin:

   1. Uygulama için RRSA kimlik doğrulaması amacıyla roleA adlı bir RAM rolü oluşturun ve güvenilir varlık türünü OIDC kimlik sağlayıcısı olarak ayarlayın.

   2. roleA rolüne roleB rolünü üstlenme izni verin. Daha fazla bilgi için bkz. 1. Küme için RRSA'yı etkinleştirme (statik birimler için) veya Dinamik olarak sağlanan ossfs 1.0 birimi kullanma (dinamik birimler için).

      roleA için OSS ile ilgili izin ilkeleri gerekmez. Ancak sts:AssumeRole API'sini içeren bir izin ilkesi gerekir; örneğin sistem ilkesi AliyunSTSAssumeRoleAccess.

3. Kümede birimi yapılandırın:

   Bir birim oluştururken assumeRoleArn parametresini roleB ARN'sine ayarlayın:

   • Statik birim (PV): spec.csi.volumeAttributes alanına assumeRoleArn ekleyin.

     assumeRoleArn: <ARN of roleB>

   • Dinamik birimler (StorageClass): parameters alanına assumeRoleArn ekleyin.

     assumeRoleArn: <ARN of roleB>

CoreDNS kullanarak OSS erişim uç noktalarını çözümleme

Bir OSS uç noktasını dahili bir küme etki alanına işaret etmek için ossfs'in çalıştığı pod için belirli bir DNS ilkesi yapılandırabilirsiniz. Bu yapılandırma bağlama sırasında kümenin CoreDNS'ini öncelikli olarak kullanmaya zorlar.

Bu özellik yalnızca CSI bileşeni sürüm v1.34.2 ve sonrasında desteklenir. Yükseltme yapmak için bkz. CSI bileşenlerini yükseltme.

• Statik birim (PV): spec.csi.volumeAttributes alanına dnsPolicy ekleyin.

  dnsPolicy: ClusterFirstWithHostNet

• Dinamik birimler (StorageClass): StorageClass'ın parameters alanına dnsPolicy ekleyin.

  dnsPolicy: ClusterFirstWithHostNet

Konteynerleştirilmiş ossfs için özel bağlama modunu etkinleştirme

Belirti

Aynı düğümdeki birden çok pod aynı OSS birimini paylaşılan tek bir bağlama noktası üzerinden bağlar.

Neden

Konteynerleştirmeden önce ossfs varsayılan olarak özel bağlama modunu kullanırdı. Bu modda bir OSS birimi bağlayan her pod için düğümde bir ossfs işlemi başlatılır. Farklı ossfs işlemlerinin bağlama noktaları tamamen bağımsızdır; bu nedenle aynı OSS birimi üzerindeki farklı pod'ların okuma ve yazma işlemleri birbirini etkilemez.

Konteynerleştirmeden sonra ossfs işlemi bir pod'da bir konteyner olarak çalışır; özellikle kube-system veya ack-csi-fuse ad alanında csi-fuse-ossfs-* adlı bir pod'da çalışır. Çoklu bağlama senaryolarında özel bağlama modu kümede çok sayıda pod başlatır ve bu durum yetersiz esnek ağ arabirimleri gibi sorunlara yol açabilir. Bu nedenle konteynerleştirmeden sonra varsayılan olarak paylaşılan bağlama modu kullanılır. Bu modda aynı düğümdeki aynı OSS birimini bağlayan birden çok pod tek bir bağlama noktasını paylaşır. Hepsi aynı csi-fuse-ossfs-* pod'una karşılık gelir ve aynı ossfs işlemi tarafından bağlanır.

Çözüm

1.30.4 öncesi CSI sürümleri için OSS birimini oluştururken useSharedPath yapılandırma öğesini ekleyip "false" olarak ayarlayarak konteynerleştirmeden önceki özel bağlama davranışına geri dönebilirsiniz. Aşağıdaki kod bir örnek sağlar:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: oss-pv
spec:
  accessModes:
  - ReadOnlyMany
  capacity:
    storage: 5Gi
  csi:
    driver: ossplugin.csi.alibabacloud.com
    nodePublishSecretRef:
      name: oss-secret
      namespace: default
    volumeAttributes:
      bucket: bucket-name
      otherOpts: -o max_stat_cache_size=0 -o allow_other
      url: oss-cn-zhangjiakou.aliyuncs.com
      useSharedPath: "false" 
    volumeHandle: oss-pv
  persistentVolumeReclaimPolicy: Delete
  volumeMode: Filesystem

**subpath veya subpathExpr** bağlamalarında hatalar

Belirti

Bir OSS birimini subpath veya subpathExpr yöntemiyle bağlarken aşağıdaki hatalar oluşabilir:

• Bağlama hatası: OSS birimini bağlayan pod oluşturulduktan sonra CreateContainerConfigError durumunda kalır ve aşağıdakine benzer bir olay görünür.

  Warning  Failed          10s (x8 over 97s)  kubelet            Error: failed to create subPath directory for volumeMount "pvc-oss" of container "nginx"

• Okuma/yazma hatası: Bağlanan OSS biriminde okuma veya yazma işlemleri gerçekleştirirken Operation not permitted veya Permission denied gibi bir izin hatası bildirilir.

• Bağlantıyı kaldırma hatası: Bağlanan OSS birimine sahip pod silindiğinde pod Terminating durumunda kalır.

Neden

Nedenleri ve çözümleri açıklamak için PV'nin aşağıdaki gibi yapılandırıldığını varsayalım:

...
    volumeAttributes:
      bucket: bucket-name
      path: /path
      ...

Ve pod aşağıdaki gibi yapılandırılmıştır:

...
       volumeMounts:
      - mountPath: /path/in/container
        name: oss-pvc
        subPath: subpath/in/oss
      ...

Bu durumda OSS sunucusundaki alt yol bağlama dizini paketteki /path/subpath/in/oss/ değeridir.

• Bağlama hatasının nedenleri:

  • Neden 1: Bağlama dizini /path/subpath/in/oss/ OSS'te mevcut değildir ve birimin kullanıcısına veya rolüne PutObject izni verilmemiştir. Örneğin salt okunur bir senaryoda yalnızca OSS ReadOnly izni yapılandırılmıştır.

    Kubelet yetersiz izinler nedeniyle OSS sunucusunda /path/subpath/in/oss/ dizinini oluşturamaz.

  • Neden 2: OSS sunucusundaki bağlama dizini /path/subpath/in/oss/ içindeki bazı seviyelerdeki bir dizin nesnesi (/ ile biten bir anahtar; örneğin path/ veya path/subpath/) dosya sisteminde dosya olarak ayrıştırılır ve bu durum Kubelet'in alt yol durumunu doğru şekilde belirlemesini engeller.

• Okuma/yazma hatalarının nedeni: Kök olmayan uygulama konteynerleri varsayılan olarak 640 olan /path/subpath/in/oss/ dizinindeki dosyalar için izinlere sahip değildir. Bir OSS birimini subpath yöntemiyle bağlarken ossfs aslında PV'de tanımlanan path dizinini (bu örnekte /path) bağlar; /path/subpath/in/oss/ dizinini değil. allow_other bağlama seçeneği yalnızca /path dizininde etkili olur. Alt dizin /path/subpath/in/oss/ hala varsayılan 640 iznine sahiptir.

• Bağlantıyı kaldırma hatasının nedeni: OSS sunucusundaki /path/subpath/in/oss/ bağlama dizini silinmiştir; bu durum kubelet'in alt yolu geri kazanmasını engeller ve bağlantının kaldırılamamasına neden olur.

Çözüm

• Bağlama hatası için çözüm:

  • Neden 1 için:

    1. Kubelet için bir bağlama yolu sağlamak üzere OSS sunucusunda /path/subpath/in/oss/ dizinini önceden oluşturun.

    2. Çok sayıda dizin oluşturmanız gerekiyorsa (örneğin bir OSS birimini subpathExpr yöntemiyle bağlarken) ve hepsini önceden oluşturamıyorsanız OSS birimi tarafından kullanılan kullanıcıya veya role PutObject izni verin.

  • Neden 2 için:

    1. OSS sunucusundaki her dizin nesnesinin var olup olmadığını denetlemek (anahtarlar path/ ve path/subpath/ gibidir; sorgularken anahtarı / ile başlatmayın) ve content-type ile content-length alanlarını incelemek için Bir dizin bağlandıktan sonra dosya nesnesi olarak görüntülenir bölümündeki Neden 1 çözümüne bakın. Aşağıdaki koşullar karşılanıyorsa dizin nesnesi yanlışlıkla dosya olarak tanımlanmış olabilir:

       Dizin nesnesi mevcuttur (content-type ve content-length alanlarının anlamlı olması için API'nin 2XX kodu döndürmesi gerekir), content-type değeri plain, octet-stream veya x-directory (örneğin json veya tar) değildir ve content-length değeri 0 değildir.

    2. Bu koşullar karşılanıyorsa anormal dizin nesnelerini kaldırmak için Bir dizin bağlandıktan sonra dosya nesnesi olarak görüntülenir bölümündeki Neden 1 çözümüne bakın.

• Okuma/yazma hataları için çözüm: Alt dizinlerin varsayılan izinlerini değiştirmek için umask seçeneğini kullanın. Örneğin -o umask=000 varsayılan izni 777 olarak değiştirir.

• Bağlantıyı kaldırma hatası için çözüm: Statik olarak sağlanan bir OSS biriminin bağlantısı kaldırılamıyor ve pod Terminating durumunda kalıyor bölümündeki Neden 2 çözümüne bakın.

OSS paketlerinde yavaş paket erişimi

Belirti

Bir OSS paketi kullanılarak bir pakete erişim yavaştır.

Neden

• Neden 1: OSS'de sürüm oluşturma etkinleştirildikten sonra, pakette çok sayıda silme işaretçisi bulunduğunda listObjectsV1 işleminin performansı düşer.

• Neden 2: Paketin depolama sınıfı OSS sunucusunda Standart dışı bir depolama sınıfı olarak ayarlanmıştır. Diğer depolama sınıfları veri erişim performansını düşürebilir.

Çözüm

• Neden 1 için çözüm:

  1. CSI eklentisini v1.26.6 veya sonraki bir sürüme yükseltin. Bu sürüm, ossfs'nin listObjectsV2 kullanarak paketlere erişmesine olanak tanır.

  2. Statik OSS PV'sinin otherOpts alanına, sorunu çözmek için -o listobjectsv2 seçeneğini ekleyin.

• Neden 2 için çözüm: Depolama sınıfını değiştirin veya nesneleri geri yükleyin.

Dosyalar OSS konsolunda 0 boyutunda görüntüleniyor

Belirti

Bir konteynere bir OSS veri birimi bağladıktan ve bir dosyaya veri yazdıktan sonra, OSS konsolu dosya boyutunu 0 olarak gösterir.

Neden

Bir konteyner ossfs kullanarak bir OSS paketi bağladığında, bağlama FUSE tabanlı bir işlem olarak gerçekleşir. Bu nedenle, dosya içeriği yalnızca dosya kapatıldığında veya arabellekten diske yazıldığında OSS sunucusuna yüklenir.

Çözüm

Dosyanın başka bir süreç tarafından kullanılıp kullanılmadığını kontrol etmek için lsof <file_name> komutunu kullanın. Kullanılıyorsa, dosya tanımlayıcısını (fd) serbest bırakmak için süreci kapatın. Daha fazla bilgi için bkz. lsof.

"Transport endpoint is not connected" hatası

Belirti

Bir konteynere bir OSS veri birimi bağlandıktan sonra, bağlama noktasına erişim aniden "Transport endpoint is not connected" hatasıyla başarısız olur.

Neden

Bir konteyner, bir OSS paketini bağlamak için ossfs kullanır. Bir uygulama OSS paketindeki verilere erişirken ossfs süreci beklenmedik şekilde sonlanırsa, bağlama noktasının bağlantısı kesilir.

ossfs sürecinin beklenmedik şekilde sonlanmasının temel nedenleri şunlardır:

• Yetersiz kaynaklar; örneğin, sürecin Bellek Yetersizliği (OOM) hatası nedeniyle sonlandırılması.

• ossfs sürecinin veri erişimi sırasında bir segmentasyon hatası nedeniyle sonlanması.

Çözüm

1. ossfs sürecinin neden beklenmedik şekilde sonlandığını belirleyin.

   Önemli

   Üretim uygulamanız bağlantısı kesilen bağlama noktasından etkileniyorsa ve bu aralıklı bir sorunsa, hızlı bir düzeltme olarak OSS birimini yeniden bağlamak için uygulama konteynerini yeniden dağıtabilirsiniz.

   OSS biriminin yeniden bağlanmasının, aşağıdaki sorun giderme adımları için gereken bazı bilgilerin kaybolmasına neden olacağını unutmayın. Bu durum, geçerli olduğu yerlerde belirtilmiştir.

   1. Sürecin yetersiz kaynaklar nedeniyle sonlanıp sonlanmadığını kontrol edin.

      1. Pod düzeyinde kaynak yetersizliği: CSI v1.28 veya sonraki bir sürümü kullanıyorsanız, ossfs Pod'unun yeniden başlatılıp başlatılmadığını ve son çıkışın bir OOM hatası veya benzeri bir sorundan kaynaklanıp kaynaklanmadığını kontrol edin. ossfs Pod'unu nasıl elde edeceğiniz hakkında daha fazla bilgi için bkz. ossfs 1.0 özel durumlarını giderme.

      2. Düğüm düzeyinde kaynak yetersizliği: Sorunlu Pod yeniden bağlamadan sonra silindiyse veya 1.28'den önceki bir CSI sürümü kullanıyorsanız, birim bağlandığında düğümün yüksek kaynak kullanımına sahip olup olmadığını belirlemek için ACK veya ECS izleme panosunu kontrol edin.

   2. Sürecin bir segmentasyon hatası nedeniyle sonlanıp sonlanmadığını kontrol edin.

      1. 1.28'den önceki bir CSI sürümü kullanıyorsanız, ossfs düğümde bir süreç olarak çalışır. Segmentasyon hataları hakkında bilgi almak için düğüme oturum açmanız ve sistem günlüklerini sorgulamanız gerekir.

         journalctl -u ossfs | grep segfault

      2. CSI sürümü 1.28 veya sonraki bir sürüm ise, segmentasyon hatası çıkışlarıyla ilgili "signal: segmentation fault" gibi bilgileri ossfs Pod'unun günlüklerinde kontrol edin.

         Not

         Aşağıdaki durumlarda, ilgili günlükler alınamaz. ossfs sürecinin yetersiz kaynaklar nedeniyle sonlanmadığını doğruladıysanız, sorun gidermeye bir segmentasyon hatası varsayımıyla devam etmenizi öneririz.

         • Segmentasyon hatası uzun zaman önce meydana geldiyse, günlük döndürme nedeniyle düğüm veya Pod günlükleri kaybolmuş olabilir.

         • Uygulama konteyneri yeniden bağlandıysa, Pod silindiğinde günlükler kaybolur.

2. ossfs süreci yetersiz kaynaklar nedeniyle sonlandıysa, ossfs Pod'unun kaynak sınırlarını ayarlayın veya OSS birimini kullanan uygulama Pod'unu daha fazla kullanılabilir kaynağa sahip bir düğüme zamanlayın.

   ossfs'nin kendisinin çok fazla bellek tükettiğini onaylarsanız, neden bir uygulamanın veya üçüncü taraf tarama yazılımının bağlama noktasında readdir işlemleri gerçekleştirmesi olabilir. Bu durum, ossfs'nin OSS sunucusuna çok sayıda HeadObject isteği göndermesine neden olur. Bu durumda, readdir optimizasyonunu etkinleştirebilirsiniz. Daha fazla bilgi için bkz. Yeni özellik: readdir optimizasyonu.

3. ossfs'nin önceki sürümlerinde oluşan segmentasyon hatası sorunlarının çoğu, 1.91 ve sonraki sürümlerde düzeltilmiştir. ossfs süreci bir segmentasyon hatası nedeniyle sonlanıyorsa, ossfs'yi 1.91.8.ack.2 veya sonraki bir sürüme yükseltmenizi öneririz; bu da CSI sürümünün 1.34.4 veya sonraki bir sürüme yükseltilmesi anlamına gelir. ossfs sürümleri hakkında daha fazla bilgi için bkz. ossfs 1.0 sürümleri.

   CSI sürümünüz zaten güncelse, segmentasyon hatası coredump dosyasını toplamak ve bir destek talebi göndermek için şu adımları izleyin.

   • Bir düğüm Alibaba Cloud Linux 3 çalıştırıyorsa, coredump parametreleri varsayılan olarak yapılandırılır. Bir ossfs segmentasyon hatası oluştuğunda, düğüme oturum açabilir ve /var/lib/systemd/coredump/ yolunda paketlenmiş coredump dosyası core.ossfs.xxx.lz4 dosyasını bulabilirsiniz.

   • Alibaba Cloud Linux 3 çalıştırmayan düğümler için, düğümün süreçlerin coredump dosyaları oluşturmasına izin verdiğinden emin olun. Örneğin, Alibaba Cloud Linux 2 çalıştıran bir düğümde, düğüme oturum açın ve aşağıdaki komutu çalıştırın:

     echo "|/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h %e" > /proc/sys/kernel/core_pattern

     Yapılandırıldıktan sonra, Alibaba Cloud Linux 3 işletim sistemine benzer şekilde, bir ossfs segmentasyon hatası oluştuğunda düğüme oturum açabilir ve /var/lib/systemd/coredump/ yolunda paketlenmiş coredump dosyası core.ossfs.xxx.xz dosyasını bulabilirsiniz.

Bağlama noktasına erişilirken "Input/output error" hatası

Belirti

Bir uygulama, bağlama noktasına erişirken bir "Input/output error" hatası bildirir.

Neden

• Neden 1: OSS bağlama yolundaki bir nesnenin adı özel karakterler içeriyor ve bu durum sunucu yanıtının ayrıştırılmasını engelliyor.

• Neden 2: FUSE dosya sistemi, kök bağlama noktasında chmod ve chown gibi işlemleri desteklemiyor.

• Neden 3: Bir RAM ilkesi tek bir pakete veya bir paket içindeki bir dizine izin verdiğinde, yetkilendirme eksik kalır.

Çözüm

• Neden 1 için çözüm:

  ossfs 1.0 özel durumlarını giderme bölümünde açıklandığı gibi ossfs istemci günlüklerini alın. Günlükler aşağıdakine benzer bir hata mesajı içerir:

  parser error : xmlParseCharRef: invalid xmlChar value 16
      <Prefix>xxx&#16;xxxx/</Prefix>

  Bu durumda,  ayrıştırılamayan bir Unicode karakterini temsil eder ve xxxxxxx/ nesnenin tam adını (bu örnekte bir dizin nesnesi) temsil eder. API ve konsol gibi araçları kullanarak nesnenin OSS sunucusunda var olduğunu doğrulayabilirsiniz. OSS konsolunda bu karakter boşluk olarak görüntülenebilir.

  Nesneyi Bir nesneyi yeniden adlandırma bölümünde açıklandığı gibi OSS sunucusunda yeniden adlandırın. Nesne bir dizinse, tüm dizini Yaygın işlemler bölümünde açıklandığı gibi ossbrowser 2.0 kullanarak yeniden adlandırmanızı öneririz.

• Neden 2 için çözüm:

  Bağlama yolunda chmod işlevine benzer bir etki elde etmek için -o allow_other ve -o umask bağlama parametrelerini kullanın:

  Parametre	Açıklama
  allow_other	Bağlama dizininin izinlerini 777 olarak ayarlar.

  Bağlama yolunda chown işlevine benzer bir etki elde etmek için -o gid ve -o uid bağlama parametrelerini kullanın:

  Parametre	Açıklama
  uid	Bağlama dizinindeki alt dizinlerin ve dosyaların sahibi olan kullanıcının kullanıcı kimliğini (UID) belirtir.
  gid	Bağlama dizinindeki alt dizinlerin ve dosyaların sahibi olan kullanıcının grup kimliğini (GID) belirtir.

• Neden 3 için çözüm:

  Yalnızca belirli bir pakete veya bir paket içindeki bir yola izin vermeniz gerekiyorsa, paket için hem mybucket hem de mybucket/* öğelerine veya yol için hem mybucket/subpath hem de mybucket/subpath/* öğelerine izin vermeniz gerekir. Daha fazla bilgi için bkz. 2. Bir RAM rolü oluşturun ve izin verin.

Dizin dosya olarak görüntüleniyor

Belirti

Bir konteynere bir OSS veri birimi bağlandığında, bir dizin dosya olarak görüntülenir.

Neden

• Neden 1: OSS sunucusundaki bir dizin nesnesinin content-type değeri varsayılan application/octet-stream türü değilse (örneğin text/html veya image/jpeg) veya dizin nesnesinin boyutu 0 değilse, ossfs meta verilerine göre bunu bir dosya nesnesi olarak kabul eder.

• Neden 2: Neden, Neden 1'de açıklanan neden değildir. Dizin nesnesi x-oss-meta-mode meta verilerini eksiktir.

Çözüm

• Neden 1 için çözüm:

  Bir dizin nesnesinin meta verilerini HeadObject veya stat (Paket ve nesne bilgilerini görüntüleme) kullanarak alabilirsiniz. Dizin nesnesinin adı eğik çizgi ("/") ile bitmelidir, örneğin a/b/. Aşağıda bir API yanıtı örneği verilmiştir.

  {
    "server": "AliyunOSS",
    "date": "Wed, 06 Mar 2024 02:48:16 GMT",
    "content-type": "application/octet-stream",
    "content-length": "0",
    "connection": "keep-alive",
    "x-oss-request-id": "65E7D970946A0030334xxxxx",
    "accept-ranges": "bytes",
    "etag": "\"D41D8CD98F00B204E9800998ECFxxxxx\"",
    "last-modified": "Wed, 06 Mar 2024 02:39:19 GMT",
    "x-oss-object-type": "Normal",
    "x-oss-hash-crc6xxxxx": "0",
    "x-oss-storage-class": "Standard",
    "content-md5": "1B2M2Y8AsgTpgAmY7Phxxxxx",
    "x-oss-server-time": "17"
  }

  Yukarıdaki yanıt örneğinde:

  • content-type: Değer application/octet-stream şeklindedir. Bu tür dizin nesneleri için kullanılır.

  • content-length: Değer 0'dır. Bir dizin nesnesinin boyutu 0'dır.

  Bu koşullar karşılanmıyorsa, sorunu aşağıdaki yollardan biriyle çözebilirsiniz:

  1. Verilerin yararlı olup olmadığını onaylamak için nesneyi GetObject veya ossutil komut satırı aracı hızlı başlangıç kullanarak alın. Veriler yararlıysa veya emin değilseniz, yedeklemenizi öneririz. Örneğin, adını değiştirebilir (bir xx/ dizin nesnesi için yeni ad olarak xx kullanmayın) ve OSS'e yükleyebilirsiniz.

  2. Sorunlu dizin nesnesini silmek için DeleteObject veya rm (sil) kullanın ve ardından ossfs'nin dizini doğru şekilde görüntüleyip görüntülemediğini kontrol edin.

• Neden 2 için çözüm:

  Neden 1 için çözüm sorunu çözmezse, bir konteynere bir OSS veri birimi bağlarken OSS statik PV'sinin otherOpts alanına -o complement_stat ekleyerek sorunu çözebilirsiniz.

  Not

  Bu seçenek, CSI eklentisi v1.26.6 ve sonraki sürümlerde varsayılan olarak etkindir. Sorunu çözmek için depolama bileşenini v1.26.6 veya sonraki bir sürüme yükseltebilir ve ardından statik OSS birimini yeniden bağlamak için uygulama Pod'unu yeniden başlatabilirsiniz.

OSS sunucusunda anormal istek trafiği

Belirti

Bir konteynere bir OSS veri birimi bağlandığında, OSS sunucusunda izlenen istek sayısı beklenenden çok daha yüksektir.

Neden

ossfs OSS'i bağladığında, düğümde bir bağlama yolu oluşturulur. ECS örneğindeki diğer süreçler tarafından yapılan bağlama noktası taramaları da OSS'e isteklere dönüştürülür. Aşırı sayıda istek ücrete tabi olabilir.

Çözüm

Sorunu çözmek için istekte bulunan süreçleri denetleyin ve izleyin. Düğümde aşağıdaki işlemleri gerçekleştirebilirsiniz.

1. auditd'yi yükleyin ve başlatın.

   sudo yum install auditd
   sudo service auditd start

2. İzlenecek dizin olarak ossfs bağlama yolunu ayarlayın.

   • Tüm bağlama yollarını eklemek için aşağıdaki komutu çalıştırın:

     for i in $(mount | grep -i ossfs | awk '{print $3}');do auditctl -w ${i};done

   • Belirli bir PV'nin bağlama yolunu eklemek için aşağıdaki komutu çalıştırın:

     <pv-name> belirtilen PV'nin adıdır.

     for i in $(mount | grep -i ossfs | grep -i <pv-name> | awk '{print $3}');do auditctl -w ${i};done

3. Hangi süreçlerin OSS paketindeki yollara eriştiğini görmek için denetim günlüklerini kontrol edin.

   ausearch -i 

   Aşağıda bir denetim günlüğü analizi örneği verilmiştir. Aşağıdaki örnekte, --- ayırıcıları arasındaki denetim günlükleri tek bir grup oluşturur ve izlenen bağlama noktasındaki tek bir işlemi kaydeder. Bu örnek, updatedb sürecinin bağlama noktasındaki bir alt dizinde bir open işlemi gerçekleştirdiğini ve süreç kimliğinin (PID) 1636611 olduğunu gösterir.

   ---
   type=PROCTITLE msg=audit(2023.09.22 15:09:26.244:291) : proctitle=updatedb
   type=PATH msg=audit(2023.09.22 15:09:26.244:291) : item=0 name=. inode=14 dev=00:153 mode=dir,755 ouid=root ogid=root rdev=00:00 nametype=NORMAL cap_fp=none cap_fi=none cap_fe=0 cap_fver=0
   type=CWD msg=audit(2023.09.22 15:09:26.244:291) : cwd=/subdir1/subdir2
   type=SYSCALL msg=audit(2023.09.22 15:09:26.244:291) : arch=x86_64 syscall=open success=yes exit=9 a0=0x55f9f59da74e a1=O_RDONLY|O_DIRECTORY|O_NOATIME a2=0x7fff78c34f40 a3=0x0 items=1 ppid=1581119 pid=1636611 auid=root uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=pts1 ses=1355 comm=updatedb exe=/usr/bin/updatedb key=(null)
   ---

4. Uygulama dışı süreçlerden gelen çağrıları kontrol etmek için günlükleri kullanın ve herhangi bir sorunu çözün.

   Örneğin, denetim günlüğü updatedb işleminin bağlı dizinleri taradığını gösteriyorsa, bunları atlaması için /etc/updatedb.conf dosyasını değiştirebilirsiniz. Yordam aşağıdaki gibidir.

   1. RUNEFS = değerinden sonra fuse.ossfs ekleyin.

   2. PRUNEPATHS = değerinden sonra bağlı dizini ekleyin.

Dosya Content-Type değeri her zaman application/octet-stream

Belirti

Bir OSS birimi aracılığıyla yazılan tüm dosya nesnelerinin Content-Type meta verisi application/octet-stream şeklindedir. Bu durum, tarayıcıların veya diğer istemcilerin bu dosyaları doğru şekilde tanımlamasını ve işlemesini engeller.

Neden

• Content-Type belirtilmezse, ossfs dosya nesnelerini varsayılan olarak ikili akış dosyaları olarak değerlendirir.

• /etc/mime.types yapılandırma dosyasında bir Content-Type belirtilmiş ancak yapılandırma etkili olmamıştır.

Çözüm

1. CSI bileşen sürümünü kontrol edin. CSI bileşen sürümleri 1.26.6 ve 1.28.1'in Content-Type yapılandırmalarıyla uyumluluk sorunları vardır. Bu sürümlerden birini kullanıyorsanız, CSI'yi en son sürüme yükseltin. Daha fazla bilgi için bkz. [[Bileşen Duyurusu] csi-plugin ve csi-provisioner 1.26.6 ve 1.28.1 sürümleriyle uyumluluk sorunları](t2552026.xdita#).

2. Bir düğümde /etc/mime.types dosyasını oluşturmak için mailcap veya mime-support kullanarak Content-Type belirttiyseniz, CSI sürümünü yükselttikten sonra ilgili OSS birimini yeniden bağlayın.

3. Bir Content-Type belirtmediyseniz, bunu aşağıdaki yollardan biriyle yapabilirsiniz:

   • Düğüm düzeyi yapılandırması: Düğümde, düğüme yeni bağlanan tüm OSS birimlerine uygulanan bir /etc/mime.types yapılandırma dosyası oluşturulur. Daha fazla bilgi için bkz. SSS.

   • Küme düzeyi yapılandırması: Bu yapılandırma, kümedeki yeni bağlanan tüm OSS birimlerine uygulanır. /etc/mime.types içeriği, mailcap tarafından oluşturulan varsayılan içerikle eşleşir.

     1. csi-plugin yapılandırma dosyasının var olup olmadığını kontrol edin.

        kubectl -n kube-system get cm csi-plugin

        csi-plugin ConfigMap yoksa, aşağıdaki içeriği kullanarak oluşturun. ConfigMap'in data.fuse-ossfs bölümünde mime-support="true" ayarı yoksa, bunu ekleyin.

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: csi-plugin
          namespace: kube-system
        data:
          fuse-ossfs: |
            mime-support=true

     2. Yapılandırmayı uygulamak için csi-plugin'i yeniden başlatın.

        csi-plugin'i yeniden başlatmak, şu anda bağlı birimlerin kullanımını etkilemez.

        kubectl -n kube-system delete pod -l app=csi-plugin

4. İlgili OSS birimini yeniden bağlayın.

Sabit bağlantı oluşturma hatası

Belirti

Sabit bağlantı oluşturulurken Operation not supported veya Operation not permitted hatası döndürülür.

Neden

OSS birimleri sabit bağlantı işlemlerini desteklemez ve bir Operation not supported hatası döndürür. Daha eski CSI sürümlerinde, sabit bağlantı işlemleri için döndürülen hata Operation not permitted idi.

Çözüm

OSS birimleri kullanırken sabit bağlantı işlemlerinden kaçınmak için uygulamanızı değiştirin. Uygulamanızın sabit bağlantı işlemlerini kullanması gerekiyorsa, farklı bir depolama türü kullanmanızı öneririz.

OSS birimleri için erişim günlüklerini görüntüleme

OSS konsolunda OSS işlem kayıtlarını görüntüleyebilirsiniz. Gerçek zamanlı günlük sorgulamayı etkinleştirdiğinizden emin olun.

1. OSS konsolunda oturum açın.

2. Sol gezinme bölmesinde, Buckets seçeneğine tıklayın. Paketler sayfasında istediğiniz paketi bulun ve üzerine tıklayın.

3. Sol gezinme bölmesinde, Logging > Real-time Log Query seçeneğini belirleyin.

4. Real-time Log Query sekmesinde, sorgu sözdizimine ve analiz sözdizimine dayalı olarak sorgu ve analiz ifadelerini girerek OSS günlüklerini analiz edin. Günlüklerin ACK'den gelip gelmediğini belirlemek için user_agent ve client_ip alanlarını kullanabilirsiniz.

   1. ACK'den gönderilen OSS işlem isteklerini bulmak için user_agent alanını seçin. Genişletilmiş bilgiler, user_agent içeriğinin ossfs içerdiğini gösterir.

      Önemli

      • user-agent alanının değeri ossfs sürümüne bağlı olarak değişir, ancak her zaman aliyun-sdk-http/1.0()/ossfs ile başlar.

      • Bir ECS örneğinde birimleri bağlamak için ossfs kullanıyorsanız, ilgili günlükler de burada yer alır.

   2. Belirli bir ECS örneğini veya kümeyi bulmak için client_ip alanını ve ardından ilgili IP adresini seçin.

   Aşağıdaki örnekte, bu iki alan kullanılarak sorgulanan günlükler gösterilmektedir.

   * and __topic__: oss_access_log and bucket: cnfs-oss-csdr-test and client_ip : "192.168.xxx.xxx" and user_agent : "aliyun-sdk-go/v2.1.8 (Linux/5.10.134-15.al8.x86_64/x86_64;go1.17.13)"

   Günlük sorgu alanlarının açıklaması

   Alan	Açıklama
   operation	OSS üzerinde gerçekleştirilen işlemin türü. Örnekler: GetObject ve GetBucketStat. Daha fazla bilgi için bkz. İşlemler.
   object	Nesnenin adı; bu, OSS'de bir dizin veya dosya olabilir.
   request_id	İsteğin benzersiz tanımlayıcısı. Belirli bir isteği sorgulamak için istek kimliğini kullanabilirsiniz.
   http_status, error_code	Bir isteğin sonucunu sorgulamak için kullanılır. Daha fazla bilgi için bkz. Hata yanıtları.

Paylaşılan bağlamalar için ossfs sürecini yeniden başlatma

Belirti

Kimlik doğrulama bilgilerini veya ossfs sürümünü değiştirdikten sonra, çalışan ossfs süreci otomatik olarak değişmez.

Neden

• Kimlik doğrulama bilgileri gibi yapılandırmalar, ossfs çalışmaya başladıktan sonra değiştirilemez. Yapılandırmayı değiştirmek, ossfs sürecinin (konteynerize sürümlerde süreç kube-system veya ack-csi-fuse ad alanındaki csi-fuse-ossfs-* Pod'udur) ve ilgili uygulama Pod'larının yeniden başlatılmasını gerektirir; bu da hizmet kesintisine neden olur. Bu nedenle, CSI varsayılan olarak çalışan bir ossfs örneğine değişiklikleri uygulamaz.

• Normal koşullar altında, CSI ossfs'nin dağıtımını ve silinmesini yönetir. ossfs sürecini içeren Pod'u manuel olarak silmek, CSI'nin ossfs'yi yeniden dağıtmasını veya VolumeAttachment gibi ilgili kaynakları silmesini tetiklemez.

Çözüm

Konteynerize olmayan bir CSI sürümü kullanıyorsanız veya özel bağlamaları etkinleştirdiyseniz, ilgili uygulama Pod'unu doğrudan yeniden başlatabilirsiniz. Konteynerize sürümler varsayılan olarak paylaşılan bağlamalar kullanır; bu, aynı OSS birimini bağlayan bir düğümdeki tüm uygulama Pod'larının tek bir ossfs sürecini paylaşması anlamına gelir.

1. Geçerli FUSE Pod'unu hangi uygulama Pod'larının kullandığını belirleyin.

   1. Değiştirmeniz gereken csi-fuse-ossfs-* Pod'unu belirlemek için aşağıdaki komutu çalıştırın.

      Burada <pv-name> PV adıdır ve <node-name> düğüm adıdır.

      1.30.4'ten önceki CSI sürümleri için aşağıdaki komutu çalıştırın:

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

      1.30.4 ve sonraki CSI sürümleri için aşağıdaki komutu çalıştırın:

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

      Beklenen çıktı:

      csi-fuse-ossfs-xxxx   1/1     Running   0          10d     192.168.128.244   cn-beijing.192.168.XX.XX   <none>           <none>

   2. OSS birimini bağlayan tüm Pod'ları belirlemek için aşağıdaki komutu çalıştırın.

      Burada <ns> ad alanı adıdır ve <pvc-name> PVC adıdır.

   3. Beklenen çıktı ("Used By" bölümü içerir):

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

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

   4. csi-fuse-ossfs-xxxx tarafından bağlanan Pod'ları, yani csi-fuse-ossfs-xxxx ile aynı düğümde çalışan Pod'ları almak için aşağıdaki komutu çalıştırın.

      kubectl -n <ns> get pod -owide | grep cn-beijing.192.168.XX.XX 

      Beklenen çıktı:

      NAME                         READY   STATUS    RESTARTS   AGE     IP               NODE                         NOMINATED NODE   READINESS GATES
      oss-static-94849f647-4****   1/1     Running   0          10d     192.168.100.11   cn-beijing.192.168.100.3     <none>           <none>
      oss-static-94849f647-6****   1/1     Running   0          7m36s   192.168.100.18   cn-beijing.192.168.100.3     <none>           <none>

2. Uygulamayı ve ossfs sürecini yeniden başlatın.

   Uygulama Pod'larını (yukarıdaki örnekte oss-static-94849f647-4** ve oss-static-94849f647-6**) kubectl scale gibi bir komut kullanarak aynı anda silin. Bağlı uygulama Pod'u olmadığında, csi-fuse-ossfs-xxxx Pod'u otomatik olarak geri kazanılır. Replika sayısı geri yüklendiğinde, PV yeni yapılandırmayla yeniden bağlanır ve CSI yeni bir csi-fuse-ossfs-yyyy Pod'u oluşturur.

   Bu Pod'ların aynı anda silindiğinden emin olamıyorsanız (örneğin, bir Deployment, StatefulSet veya DaemonSet tarafından yönetilen Pod'ları silmek anında yeniden başlatmayı tetikler) veya Pod'lar OSS okuma/yazma hatalarını tolere edebiliyorsa:

   • CSI sürümü 1.30.4'ten önceyse, csi-fuse-ossfs-xxxx Pod'unu doğrudan silebilirsiniz; bu durum, uygulama Pod'u içinden OSS'ye yönelik okuma ve yazma işlemlerinin bir disconnected error döndürmesine neden olur.

   • 1.30.4 ve sonraki CSI sürümleri için aşağıdaki komutu çalıştırabilirsiniz:

     kubectl get volumeattachment | grep <pv-name> | grep cn-beijing.192.168.XX.XX 

     Beklenen çıktı:

     csi-bd463c719189f858c2394608da7feb5af8f181704b77a46bbc219b**********   ossplugin.csi.alibabacloud.com    <pv-name>                   cn-beijing.192.168.XX.XX    true       12m

     VolumeAttachment'ı doğrudan silerseniz, uygulama Pod'u içindeki OSS'ye yönelik okuma/yazma işlemleri bir disconnected error döndürür.

   Ardından, uygulama Pod'larını tek tek yeniden başlatın. Yeniden başlatılan Pod'lar, CSI tarafından oluşturulan yeni csi-fuse-ossfs-yyyy Pod'u aracılığıyla OSS'ye okuma ve yazma erişimini geri yükler.

ossfs sürümünü kontrol etme

ossfs sürümü, CSI sürümüyle birlikte güncellenir. ACK'de kullanılan ossfs sürümleri, genel ossfs sürümlerine dayanır ve sürüm numaraları 1.91.1.ack.1 gibi bir biçimdedir. Daha fazla bilgi için bkz. Sürüm geçmişi. Genel sürümler hakkında daha fazla bilgi için bkz. ossfs 1.0 yükleme ve ossfs 2.0 yükleme.

• Bir OSS birimini bağlamak için kullanılan varsayılan ossfs sürümü, CSI bileşen sürümüne bağlı olarak değişir. Daha fazla bilgi için bkz. csi-provisioner.

  Not

  1.28'den önceki CSI sürümleri için (v1.26.6 hariç), ossfs 1.0 düğümde çalışır ve kullanılan sürüm düğümde gerçekten yüklü olan sürümdür. ossfs sürümünü aşağıdaki yöntemleri kullanarak sorgulamanız gerekir.

• Zaten bağlanmış bir OSS birimi için bkz. ossfs sürümünü görüntüleme.

CSI bileşeninin sürümü, ossfs'nin varsayılan sürümünü belirler. ACK tarafından kullanılan ossfs sürümü, topluluk sürüm numarasına .ack.x son ekini ekler, örneğin 1.91.1.ack.1. Daha fazla bilgi için bkz. Sürüm notları.

Genel topluluk sürümleri hakkında bilgi için bkz. ossfs 1.0 yükleme ve ossfs 2.0 yükleme .

Sürüm bilgilerini aşağıdaki yollarla bulabilirsiniz:

• Sürüm eşlemesi: Belirli bir CSI sürümüne karşılık gelen ossfs sürümünü öğrenmek için bkz. csi-provisioner.

  Daha eski CSI sürümleri için (v1.28'den önce ve v1.26.6 değil), ossfs 1.0 doğrudan düğümde çalışır. Sürüm, CSI tarafından değil, düğümde yüklü olan sürüm tarafından belirlenir. Gerçekten yüklü olan sürümü doğrudan sorgulamanız gerekir.

• Gerçek sürümü doğrulayın: Şu anda bağlı bir birim için çalışan kesin ossfs sürümünü onaylamak için bkz. ossfs sürümünü görüntüleme.

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

OSS, paketlerin veya alt dizinlerin kapasitesini sınırlamaz ve bir kapasite kota özelliği sağlamaz. Bu nedenle, bir PV'nin .spec.capacity alanı ve bir PVC'nin .spec.resources.requests.storage alanı için yapılan ayarlar yoksayılır ve etkili olmaz. Yalnızca bağlı PV ve PVC'nin kapasite değerlerinin aynı olduğundan emin olmanız gerekir.

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

OSS statik biriminin ayrılması başarısız oluyor

Belirti

Statik olarak sağlanan bir OSS birimi ayrılamaz ve pod, Terminating durumunda takılı kalır.

Neden

Bir podun Terminating durumunda takılı kalmasının birkaç nedeni olabilir. Sorunu belirlemek için öncelikle kubelet günlüklerini kontrol edin. En yaygın nedenler şunlardır:

• Neden 1: Düğümdeki birimin bağlama noktası kullanımda olduğu için CSI eklentisi bunu ayıramaz.

• Neden 2: PV içinde belirtilen OSS paketi veya dizini silindiği için CSI eklentisi bağlama noktasının durumunu belirleyemez.

Çözüm

• Neden 1 için çözüm

  1. Pod'un UID değerini almak için aşağıdaki komutu çalıştırın.

     <ns-name> ve <pod-name> ifadelerini pod'un ad alanı ve adıyla değiştirin.

     kubectl -n <ns-name> get pod <pod-name> -ogo-template --template='{{.metadata.uid}}'

     Beklenen çıktı:

     5fe0408b-e34a-497f-a302-f77049****

  2. Terminating durumunda olan pod'un çalıştığı düğüme giriş yapın.

  3. Bağlama noktasını kullanan herhangi bir işlem olup olmadığını kontrol etmek için düğümde aşağıdaki komutu çalıştırın.

     lsof /var/lib/kubelet/pods/<pod-uid>/volumes/kubernetes.io~csi/<pv-name>/mount/

     Komut herhangi bir çıktı döndürürse bu işlemleri belirleyin ve sonlandırın.

• Neden 2 için çözüm

  1. OSS konsoluna giriş yapın.

  2. Paketin veya dizinin silinip silinmediğini kontrol edin. Birimi monte etmek için subPath kullandıysanız subPath tarafından belirtilen alt dizinin de silinip silinmediğini kontrol edin.

  3. Ayrılma hatasının silinen bir dizinden kaynaklandığını doğrularsanız aşağıdaki adımları uygulayın:

     1. Pod'un UID değerini almak için aşağıdaki komutu çalıştırın.

        <ns-name> ve <pod-name> ifadelerini pod'un ad alanı ve adıyla değiştirin.

        kubectl -n <ns-name> get pod <pod-name> -ogo-template --template='{{.metadata.uid}}'

        Beklenen çıktı:

        5fe0408b-e34a-497f-a302-f77049****

     2. Terminating durumunda olan pod'un çalıştığı düğüme giriş yapın. Ardından, pod tarafından kullanılan bağlama noktalarını bulmak için düğümde aşağıdaki komutu çalıştırın.

        mount | grep <pod-uid> | grep fuse.ossfs

        Beklenen çıktı:

        ossfs on /var/lib/kubelet/pods/<pod-uid>/volumes/kubernetes.io~csi/<pv-name>/mount type fuse.ossfs (ro,nosuid,nodev,relatime,user_id=0,group_id=0,allow_other)
        ossfs on /var/lib/kubelet/pods/<pod-uid>/volume-subpaths/<pv-name>/<container-name>/0 type fuse.ossfs (ro,relatime,user_id=0,group_id=0,allow_other)

        ossfs on ile type arasındaki yol, düğümdeki gerçek bağlama noktasıdır.

     3. Bağlama noktalarını manuel olarak ayırın.

        umount /var/lib/kubelet/pods/<pod-uid>/volumes/kubernetes.io~csi/<pv-name>/mount
        umount /var/lib/kubelet/pods/<pod-uid>/volume-subpaths/<pv-name>/<container-name>/0

     4. Kubelet'in sonraki yeniden denemesinde kaynakları geri almasını bekleyin veya pod'u --force bayrağını kullanarak zorla silin.