Troubleshoot ossfs 1.0 Client Issues - Container Service for Kubernetes

CSI eklenti sürümüne göre ossfs çalışma şekli

CSI eklenti sürümü, ossfs'in nerede çalıştığını ve günlüklerinin nasıl alınacağını belirler.

CSI eklenti sürümü	ossfs çalışma zamanı	Sorun giderme yöntemi
v1.28'den önce	Uygulama pod'unun düğümünde arka plan işlemi. Hata ayıklamak için ossfs'i ön planda yeniden bağlayın.	Hata ayıklama günlüklerini analiz edin
v1.28 ile v1.30.4 arasında	`kube-system` ad alanındaki bir pod içindeki konteyner	Pod günlüklerini sorgulayın
v1.30.4 ve sonrası	`ack-csi-fuse` ad alanındaki bir pod içindeki konteyner	Pod günlüklerini sorgulayın

Önemli

Günlük hacmini sınırlamak için konteynerleştirilmiş ossfs varsayılan olarak critical veya error günlük düzeyine ayarlanır. Kullanışlı hata ayıklama çıktısını yakalamak için hata ayıklama parametreleri ekleyin ve birimi yeniden bağlayın.

ossfs günlüklerini alma

Belirli bir sorunu teşhis etmeden önce etkilenen birim için ossfs günlüklerini alın. CSI eklenti sürümünüze bağlı olarak aşağıdaki komutları kullanın.

VOLUME_ID'yi bulma

<VOLUME_ID> genellikle kalıcı birim (PV) adıdır. Doğru değeri şu durumlardan birinde alın:

PV adı volumeHandle alanından farklıysa volumeHandle değerini kullanın:
```
kubectl get pv <PV_NAME> -o jsonpath='{.spec.csi.volumeHandle}'
```
PV adı çok uzunsa <VOLUME_ID> değeri PV adının SHA-1 karmasının başına h1. eklenerek oluşturulur:
```
echo -n "<PV_NAME>" | sha1sum | sed 's/^/h1./'
```
sha1sum mevcut değilse:
```
echo -n "<PV_NAME>" | openssl sha1 -binary | xxd -p -c 40 | sed 's/^/h1./'
```

ossfs pod durumunu kontrol etme

<VOLUME_ID> ve <NODE_NAME> değerlerini gerçek değerlerle değiştirin.

CSI v1.30.4 ve sonrası (ad alanı: ack-csi-fuse):

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

v1.30.4, ossfs konteynerine bir daemon işlemi eklediğinden ossfs'in doğru çalışıp çalışmadığına bakılmaksızın beklenen çıktı aynıdır:

NAME                   READY   STATUS    RESTARTS   AGE
csi-fuse-ossfs-xxxx    1/1     Running   0          5s

Pod Running durumunda değilse devam etmeden önce bu sorunu çözün.

v1.30.4'ten önceki CSI sürümleri (ad alanı: kube-system):

kubectl -n kube-system get pod -l csi.alibabacloud.com/volume-id=<VOLUME_ID> -o wide | grep <NODE_NAME>

ossfs beklenmedik şekilde sonlandıysa çıktı CrashLoopBackOff durumunu gösterir:

NAME                   READY   STATUS             RESTARTS     AGE
csi-fuse-ossfs-xxxx    0/1     CrashLoopBackOff   1 (4s ago)   5s

Pod günlüklerini alma

CSI v1.30.4 ve sonrası:

kubectl -n ack-csi-fuse logs csi-fuse-ossfs-xxxx

v1.30.4'ten önceki CSI sürümleri:

kubectl -n kube-system logs csi-fuse-ossfs-xxxx

Pod CrashLoopBackOff durumundaysa önceki çıkıştan günlükleri alın:

kubectl -n kube-system logs -p csi-fuse-ossfs-xxxx

Hata ayıklama günlüğünü etkinleştirme (isteğe bağlı)

Günlükler boşsa veya ayrıntı içermiyorsa günlük düzeyini debug olarak ayarlayın. İki yöntem kullanılabilir:

Yöntem 1: PV'ye hata ayıklama parametreleri ekleme (önerilir)

Orijinal PV yapılandırmasını kopyalayarak ve otherOpts alanına -o dbglevel=debug -o curldbg ekleyerek bir hata ayıklama OSS PV'si oluşturun. Yeni OSS PV'sini bağladıktan sonra ossfs pod'undan hata ayıklama çıktısını almak için kubectl logs komutunu çalıştırın.

Önemli

Hata ayıklama günlükleri büyük olabilir. Bu ayarı yalnızca hata ayıklama sırasında kullanın.

Yöntem 2: ConfigMap kullanma (genel)

kube-system ad alanında csi-plugin adlı bir ConfigMap oluşturun:

apiVersion: v1
kind: ConfigMap
metadata:
  name: csi-plugin
  namespace: kube-system
data:
  fuse-ossfs: |
    dbglevel=debug     # Log level

CSI eklenti v1.28.2 ve önceki sürümler için maksimum günlük düzeyi info değeridir.

Etkilenen düğümdeki csi-plugin pod'unu ve tüm csi-provisioner pod'larını yeniden başlatın ardından yeniden bağlamayı tetiklemek için uygulama pod'unu yeniden başlatın. Yeniden bağlamadan sonra csi-fuse-ossfs-xxxx pod'unun yeniden dağıtıldığını onaylayın.

Önemli

ConfigMap genel olarak uygulanır. Hata ayıklamadan sonra ConfigMap'i silin csi-plugin pod'unu ve tüm csi-provisioner pod'larını yeniden başlatın ardından hata ayıklama günlüğünü devre dışı bırakmak için uygulama pod'unu yeniden başlatın.

ossfs hata kategorilerini anlama

ossfs hataları iki kategoriye ayrılır:

ossfs kaynaklı hatalar — örneğin bağlama noktası dizini boş değildir. Çözümler için ossfs SSS bölümüne bakın. Nedeni belirleyemezseniz destek talebi gönderin.
OSS'den gelen 200 dışı HTTP yanıtları — örneğin 404 NoSuchBucket hatası. Hata kodunu ve mesajını OSS HTTP hata kodları referansında arayın.

Senaryo 1: Pod ContainerCreating durumunda takılı kalıyor (bağlama hatası)

CSI eklenti v1.26.6 ve sonrası

Belirtiler

Uygulama pod'u başlatılırken ContainerCreating durumunda kalır.

Neden

CSI bileşeni ossfs konteynerini başlattığında ossfs bağlamayı tamamlamadan önce sonlanır. Yaygın nedenler arasında başarısız OSS bağlantı kontrolü (paket mevcut değil yanlış izinler) var olmayan bir bağlama yolu veya yetersiz okuma/yazma izinleri bulunur.

Çözüm

ossfs günlüklerini alma bölümündeki komutları kullanarak ossfs konteyner günlüklerini alın.
Günlükler boşsa veya yetersizse Hata ayıklama günlüğünü etkinleştirme bölümünde açıklandığı gibi hata ayıklama günlüğünü etkinleştirin.

Günlükleri analiz edin. Örnek: ossfs hatası — bağlama noktası boş değil

ossfs: MOUNTPOINT directory /test is not empty. if you are sure this is safe, can use the 'nonempty' mount option.

Bağlama noktası dizini boş değildir. PV bağlama seçeneklerine -o nonempty ekleyin. Örnek: OSS sunucu hatası — paket mevcut değil

[ERROR]  2023-10-16 12:38:38:/tmp/ossfs/src/curl.cpp:CheckBucket(3420): Check bucket failed, oss response: <?xml version="1.0" encoding="UTF-8"?>
<Error>
  <Code>NoSuchBucket</Code>
  <Message>The specified bucket does not exist.</Message>
  <RequestId>652D2ECEE1159C3732F6E0EF</RequestId>
  <HostId><bucket-name>.oss-<region-id>-internal.aliyuncs.com</HostId>
  <BucketName><bucket-name></BucketName>
  <EC>0015-00000101</EC>
  <RecommendDoc>https://api.alibabacloud.com/troubleshoot?q=0015-00000101</RecommendDoc>
</Error>

Belirtilen OSS paketi mevcut değildir. OSS konsolunda oturum açın paketi oluşturun ve ardından birimi yeniden bağlayın.

v1.26.6'dan önceki CSI eklenti sürümleri

Belirtiler

Uygulama pod'u başlatılırken ContainerCreating durumunda kalır.

Neden

CSI bileşeni ossfs'i başlatmaya çalıştığında ossfs sonlanır bu nedenle düğümde çalışan bir ossfs işlemi yoktur. Pod olayı bir FailedMount uyarısı gösterir. Yaygın nedenler v1.26.6 ve sonraki sürümlerdekiyle aynıdır: paket mevcut değil yanlış izinler var olmayan bağlama yolu veya yetersiz okuma/yazma izinleri.

Hızlı bir kontrol için OSS birimi bağlanamıyor ve uygulama pod olayı FailedMount gösteriyor konusuna bakın.

Çözüm

Adım 1: Orijinal ossfs başlatma komutunu alın

FailedMount olayını görüntülemek için pod'u tanımlayın:
```
kubectl -n <POD_NAMESPACE> describe pod <POD_NAME>
```

Events bölümünde FailedMount girdisini bulun:

Warning  FailedMount  3s  kubelet  MountVolume.SetUp failed for volume "<PV_NAME>" : rpc error: code = Unknown desc = Mount is failed in host, mntCmd:systemd-run --scope -- /usr/local/bin/ossfs <BUCKET>:/<PATH> /var/lib/kubelet/pods/<POD_UID>/volumes/kubernetes.io~csi/<PV_NAME>/mount -ourl=oss-cn-beijing-internal.aliyuncs.com -o allow_other , err: ..... with error: exit status 1

Orijinal ossfs başlatma komutunu mntCmd alanından — systemd-run --scope -- kısmından sonraki içerikten — çıkarın:

/usr/local/bin/ossfs <BUCKET>:/<PATH> /var/lib/kubelet/pods/<POD_UID>/volumes/kubernetes.io~csi/<PV_NAME>/mount -ourl=oss-cn-beijing-internal.aliyuncs.com -o allow_other

Adım 2: ossfs'i ön planda bağlayın ve hata ayıklama günlüklerini alın

Varsayılan olarak yalnızca bağlama komutunu çalıştıran kullanıcı ossfs ile bağlanan dizine erişebilir. Orijinal komut -o allow_other seçeneğini içermiyorsa bağlama noktasında izin sorunları oluşabilir.

Orijinal komutun -o allow_other seçeneğini içerip içermediğini kontrol edin. İçermiyorsa PV oluştururken bu seçeneği ekleyin. Ayrıntılar için Paket bağlama ve Statik olarak sağlanan ossfs 1.0 birimi kullanma konularına bakın.

Uygulama pod'unun düğümünde hata ayıklama günlüğü ile ossfs'i ön planda çalıştırın:

Parametre	Açıklama
`-f`	ossfs'i daemon olarak değil ön planda çalıştırır. Günlükler terminale yazılır.
`-o allow_other`	Bağlanan dizine diğer kullanıcıların erişimine izin vererek bağlama noktası izin sorunlarını önler.
`-o dbglevel=debug`	Günlük düzeyini debug olarak ayarlar.
`-o curldbg`	OSS'den gelen HTTP hatalarını ortaya çıkarmak için libcurl günlüğünü etkinleştirir.

mkdir /test && /usr/local/bin/ossfs <BUCKET>:/<PATH> /test -ourl=oss-cn-beijing-internal.aliyuncs.com -f -o allow_other -o dbglevel=debug -o curldbg

Adım 3: Hata ayıklama günlüklerini analiz edin

ossfs ön planda çalışırken günlükler terminale yazılır.

Örnek: ossfs hatası — bağlama noktası boş değil

ossfs: MOUNTPOINT directory /test is not empty. if you are sure this is safe, can use the 'nonempty' mount option.

PV bağlama seçeneklerine -o nonempty ekleyin.

Örnek: OSS sunucu hatası — paket mevcut değil

[INFO]       Jul 10 2023:13:03:47:/tmp/ossfs/src/curl.cpp:RequestPerform(2382): HTTP response code 404 was returned, returning ENOENT, Body Text: <?xml version="1.0" encoding="UTF-8"?>
<Error>
  <Code>NoSuchBucket</Code>
  <Message>The specified bucket does not exist.</Message>
  <RequestId>xxxx</RequestId>
  <HostId><BUCKET>.oss-cn-beijing-internal.aliyuncs.com</HostId>
  <BucketName><BUCKET></BucketName>
  <EC>0015-00000101</EC>
</Error>

OSS konsolunda oturum açın paketi oluşturun ve ardından birimi yeniden bağlayın.

Senaryo 2: POSIX komut hatası (pod çalışıyor)

CSI eklenti v1.26.6 ve sonrası

Belirtiler

Uygulama pod'u Running durumundadır ancak bir POSIX komutu (örneğin read, write veya chmod) yürütüldüğünde ossfs bir hata döndürür.

Neden

ossfs OSS paketini doğru şekilde bağlar ancak belirli POSIX işlemlerini yürütürken başarısız olur. Başarısız olan komutu ve hata türünü belirlemek için uygulama günlüklerini kontrol edin — örneğin chmod -R 777 /mnt/path komutunda bir I/O error oluşması.

Çözüm

ossfs pod'unun çalıştığını onaylamak için ossfs günlüklerini alma bölümündeki komutları kullanın.
ossfs konteyner günlüklerini alın.
Günlükler yetersizse Hata ayıklama günlüğünü etkinleştirme bölümünde açıklandığı gibi hata ayıklama günlüğünü etkinleştirin.

Günlükleri analiz edin. Örnek: ossfs hatası — bağlama noktasında chmod Hatayı tetikleyen komut:

chmod -R 777 /test

chmod işlemi /test içindeki dosyalar için başarılı olur ancak bağlama noktasının kendisinde başarısız olur:

[ERROR]  2023-10-18 06:03:24:/tmp/ossfs/src/ossfs.cpp:ossfs_chmod(1745): Could not change mode for mount point.

Bağlama noktasının kendisinin izinlerinin değiştirilmesi desteklenmez. Geçici çözümler için ossfs 1.0 birimi SSS konusuna bakın. Örnek: OSS sunucu hatası — nesne bulunamadı

[INFO]        2023-10-18 06:05:46:/tmp/ossfs/src/curl.cpp:HeadRequest(3014): [tpath=/xxxx]
[INFO]        2023-10-18 06:05:46:/tmp/ossfs/src/curl.cpp:PreHeadRequest(2971): [tpath=/xxxx][bpath=][save=][sseckeypos=-1]
[INFO]        2023-10-18 06:05:46:/tmp/ossfs/src/curl.cpp:prepare_url(4660): URL is http://oss-cn-beijing-internal.aliyuncs.com/<bucket>/<path>/xxxxx
[INFO]        2023-10-18 06:05:46:/tmp/ossfs/src/curl.cpp:prepare_url(4693): URL changed is http://<bucket>.oss-cn-beijing-internal.aliyuncs.com/<path>/xxxxx
[INFO]        2023-10-18 06:05:46:/tmp/ossfs/src/curl.cpp:RequestPerform(2383): HTTP response code 404 was returned, returning ENOENT, Body Text:

Nesne OSS sunucusunda mevcut değildir. Nedenler ve çözümler için 404 hatası konusuna bakın.

v1.26.6'dan önceki CSI eklenti sürümleri

Belirtiler

Uygulama pod'u Running durumundadır ancak bir POSIX komutu yürütüldüğünde ossfs bir hata döndürür. Örneğin:

kubectl -n <POD_NAMESPACE> exec -it <POD_NAME> -- /bin/bash

bash-4.4# chmod -R 777 /mnt/path
chmod: /mnt/path: I/O error

Neden

ossfs doğru çalışır ve OSS paketini bağlar ancak chmod, read veya open gibi bir POSIX komutu yürütürken bir hata döndürür.

Çözüm

Adım 1: Orijinal ossfs başlatma komutunu alın

ossfs zaten çalıştığından başlatma komutunu doğrudan düğümden alın:

ps -aux | grep ossfs | grep <PV_NAME>

Beklenen çıktı:

root     2097450  0.0  0.2 124268 33900 ?        Ssl  20:47   0:00 /usr/local/bin/ossfs <BUCKET> /<PATH> /var/lib/kubelet/pods/<POD_UID>/volumes/kubernetes.io~csi/<PV_NAME>/mount -ourl=oss-cn-beijing-internal.aliyuncs.com -o allow_other

<BUCKET> değerinden sonraki boşluğu iki nokta üst üste ile değiştirin. Orijinal başlatma komutu şöyledir:

/usr/local/bin/ossfs <BUCKET>:/<PATH> /var/lib/kubelet/pods/<POD_UID>/volumes/kubernetes.io~csi/<PV_NAME>/mount -ourl=oss-cn-beijing-internal.aliyuncs.com -o allow_other

Adım 2: ossfs'i ön planda bağlayın ve hata ayıklama günlüklerini alın

Orijinal komutun -o allow_other seçeneğini içerip içermediğini kontrol edin. İçermiyorsa PV oluştururken bu seçeneği ekleyin. Ayrıntılar için Paket bağlama ve Statik olarak sağlanan ossfs 1.0 birimi kullanma konularına bakın.

Hata ayıklama günlüğü ile ossfs'i ön planda çalıştırın:

Parametre	Açıklama
`-f`	ossfs'i daemon olarak değil ön planda çalıştırır. Günlükler terminale yazılır.
`-o allow_other`	Bağlanan dizine diğer kullanıcıların erişimine izin vererek bağlama noktası izin sorunlarını önler.
`-o dbglevel=debug`	Günlük düzeyini debug olarak ayarlar.
`-o curldbg`	OSS'den gelen HTTP hatalarını ortaya çıkarmak için libcurl günlüğünü etkinleştirir.

mkdir /test && /usr/local/bin/ossfs <BUCKET>:/<PATH> /test -ourl=oss-cn-beijing-internal.aliyuncs.com -f -o allow_other -o dbglevel=debug -o curldbg

Adım 3: Hata ayıklama günlüklerini analiz edin

İkinci bir terminal açın ve yeni günlük çıktısını yakalamak için başarısız olan komutu yeniden çalıştırın.

Örnek: ossfs hatası — bağlama noktasında chmod

chmod -R 777 /test

[ERROR] Jul 10 2023:13:03:18:/tmp/ossfs/src/ossfs.cpp:ossfs_chmod(1742): Could not change mode for mount point.

Bağlama noktasının izinlerinin değiştirilmesi desteklenmez. Geçici çözümler için ossfs 1.0 birimi SSS konusuna bakın.

Örnek: OSS sunucu hatası — nesne bulunamadı

[INFO]       Aug 23 2022:11:54:11:/tmp/ossfs/src/curl.cpp:RequestPerform(2377): HTTP response code 404 was returned, returning ENOENT, Body Text: <?xml version="1.0" encoding="UTF-8"?>
<Error>
  <Code>NoSuchKey</Code>
  <Message>The specified key does not exist.</Message>
  <RequestId>xxxx</RequestId>
  <HostId><BUCKET>.oss-cn-beijing-internal.aliyuncs.com</HostId>
  <Key><object-name></Key>
  <EC>0026-00000001</EC>
</Error>

Nesne OSS'de mevcut değildir. Nedenler ve çözümler için NoSuchKey konusuna bakın.

Gelişmiş hata ayıklama

ossfs'i ön planda bağlama (konteynerleştirilmiş ossfs)

PV bağlama parametrelerini değiştiremiyorsanız veya genel ConfigMap'i kullanamıyorsanız PV'yi yeniden oluşturmadan tam hata ayıklama günlüklerini yakalamak için ossfs'i düğümde ön planda bağlayın.

Önemli

ossfs konteynerlerde çalıştığından artık düğümlere varsayılan olarak yüklenmez. Manuel olarak yüklediğiniz sürüm pod'da çalışan sürümden farklı olabilir. Önce PV parametresi veya ConfigMap yaklaşımlarını deneyin.

ossfs'in en son sürümünü yükleyin.

Düğümde PV adının SHA-256 karmasını alın:

echo -n "<PV_NAME>" | sha256sum

sha256sum mevcut değilse:

echo -n "<PV_NAME>" | openssl sha256 -binary | xxd -p -c 256

pv-oss için beklenen çıktı şöyledir:

8f3e75e1af90a7dcc66882ec1544cb5c7c32c82c2b56b25a821ac77cea60a928

ossfs bağlama parametrelerini alın:
```
ps -aux | grep <sha256-value>
```

Kimlik doğrulama dosyasını oluşturun. Hata ayıklamadan hemen sonra silin.

mkdir -p /etc/ossfs && echo "<bucket-name>:<akId>:<akSecret>" > /etc/ossfs/passwd-ossfs && chmod 600 /etc/ossfs/passwd-ossfs

Segmentasyon hatalarını giderme

Hata günlüğü "ossfs exited with error" err="signal: segmentation fault (core dumped)" içeriyorsa ossfs işlemi segmentasyon hatası nedeniyle çökmüştür.

Teknik desteğin sorunu teşhis etmesine yardımcı olmak için core dump dosyasını toplayın ve destek talebi gönderin.

Düğüme giriş yapın ve çökme kayıtlarını listeleyin:

coredumpctl list

Beklenen çıktı:

TIME                          PID       UID   GID  SIG   COREFILE   EXE
Mon 2025-11-17 11:21:44 CST   2108767   0     0    1     present    /usr/bin/xxx
Tue 2025-11-18 19:35:58 CST   493791    0     0    1     present    /usr/local/bin/ossfs

TIME ve EXE alanlarını kontrol ederek ossfs çökme kaydını belirleyin ardından PID değerini not edin. Yukarıdaki örnekte PID değeri 493791 değeridir.

Core dump dosyasını dışa aktarın:

# Replace <PID> with the actual PID
coredumpctl dump <PID> --output ossfs.dump

Destek talebi gönderin ve ossfs.dump dosyasını ekleyin.