ossfs故障處理 - Container Service for Kubernetes

OSS資料卷是通過ossfs檔案進行掛載的FUSE檔案系統。您可以通過分析Debug日誌或查詢Pod日誌的方式進行ossfs異常問題的排查。本文劃分了常見的ossfs異常問題，並通過樣本介紹了兩種運行方式的ossfs通用的排查方法。

排查說明

CSI儲存外掛程式為v1.26.6之前的版本中，ossfs以後台形式運行在業務Pod所在的節點上，運行異常時需要重新以前台方式掛載，您可以通過分析Debug日誌進行排查。
CSI儲存外掛程式為v1.26.6及之後的版本中，ossfs以容器形式運行在kube-system命名空間下的Pod中，您可以直接查詢Pod的日誌進行排查。
CSI儲存外掛程式為v1.30.4及之後的版本中，ossfs以容器形式運行在ack-csi-fuse命名空間下的Pod中，您可以直接查詢Pod的日誌進行排查。
重要
為避免ossfs運行時產生大量日誌，以容器方式運行時預設的日誌等級為critical或error。在進行Debug排查時，可能需要增加Debug參數並重新掛載。

適用情境1：掛載失敗

OSS靜態卷掛載失敗，Pod無法啟動，Event提示FailedMount時，請優先參見OSS靜態卷掛載失敗進行快速排查。

CSI Plugin組件為1.26.6之前的版本

問題現象

業務Pod啟動時，長期處於ContainerCreating狀態。

問題原因

執行以下命令，查詢Pod無法正常啟動的原因。
需替換的變數如下：
- <POD_NAMESPACE>：業務Pod所在的命名空間。
- <POD_NAME>：業務Pod名稱。
```
kubectl -n <POD_NAMESPACE> describe pod <POD_NAME>
```
查詢結果的Events中是否存在原因為FailedMount的事件。
需替換的變數如下：
- <PV_NAME>：OSS儲存卷名稱。
- <BUCKET>：掛載的OSS Bucket名稱。
- <PATH>：掛載的OSS Bucket的路徑。
- <POD_UID>：業務Pod的UID。
```
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
```
  出現此類事件的原因：CSI組件在拉起ossfs時，ossfs異常退出，此時節點上無對應的ossfs進程在運行。OSS連通性檢查出錯（Bucket不存在，許可權配置錯誤等）、掛載路徑不存在、無讀寫權限等初始化檢查的錯誤都可能導致此錯誤現象。

解決方案

步驟1：擷取原ossfs啟動指令

通過查詢FailedMount事件，查看掛載異常的輸出。具體操作，請參見適用情境1：掛載失敗中的情境1。

通過掛載異常的輸出擷取原ossfs啟動指令。

掛載異常輸出樣本如下：

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

其中，在mntCmd中，system-run --scope -- 後端內容為原ossfs的啟動指令。擷取到原ossfs啟動指令如下：

/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

步驟2：前台掛載ossfs並擷取Debug日誌

ossfs掛載的目錄存取權限預設為掛載點的所有者，即執行掛載命令的使用者，其他使用者無法訪問。因此若原指令中沒有-o allow_other配置項，可能導致掛載根路徑的許可權問題。

確認是否為掛載點路徑許可權問題。
如果許可權存在問題，請直接在建立PV時，增加配置項-o allow_other。關於ossfs的掛載點目錄存取權限配置，請參見配置存取權限，關於如何增加配置項，請參見使用OSS靜態儲存卷。

執行以下命令，在業務Pod所在節點以前台方式運行ossfs，並設定日誌為Debug模式。

其中，/test為測試用的掛載點路徑，前台啟動並執行ossfs將把OSS Bucket掛載到/test中。

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

參數	說明
-d	開啟日誌資訊。
-f	以前台方式而非守護進程方式運行ossfs，在前台模式下，日誌會輸出到終端螢幕。該參數一般用於調試問題時使用。
-o allow_other	賦予電腦上其他使用者訪問掛載目錄的許可權，避免前台掛載ossfs時，出現新的掛載點路徑許可權問題。
-o curldbg	開啟libcurl的日誌資訊，用於排查OSS服務端返回的錯誤。

步驟3：分析Debug日誌

以前台方式運行ossfs後，日誌將輸出到終端。通常ossfs拋錯的原因可以分為兩類，分別為ossfs自身拋錯，以及ossfs向OSS服務端發送請求後收到非200錯誤碼。下文分別以兩種拋錯類型的例子介紹通用的排查方法。

下文以掛載失敗情境中，ossfs運行後很快退出為例介紹如何進行問題排查。

ossfs自身拋錯

查詢日誌，發現ossfs退出前列印的錯誤記錄檔如下。

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

根據日誌資訊定位，報錯的原因是掛載點路徑本為非空，可通過增加配置項-o nonempty解決。

說明

根據錯誤記錄檔，可在OSS文檔ossfs常見問題查詢相關解決方案。若未找到相關原因，請提交工單解決。

OSS服務端返回非200錯誤碼

查詢日誌，發現ossfs退出前列印的OSS服務端的返回碼為404，錯誤原因為NoSuchBucket，錯誤資訊為The specified bucket does not exist。

[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 Bucket不存在，可通過登入OSS管理主控台建立Bucket後重新掛載解決。

說明

通過錯誤碼及錯誤原因，可在OSS文檔HTTP錯誤碼中查詢相關的解決辦法。

CSI Plugin組件為1.26.6及之後的版本

問題現象

業務Pod啟動時，長期處於ContainerCreating狀態。

問題原因

執行以下命令，確認ossfs容器是否正常運行。
替換以下<PV_NAME>為實際業務PV的名稱。
CSI版本小於1.30.4時，執行：
```
kubectl -n kube-system get pod -l csi.alibabacloud.com/volume-id=<PV_NAME>
```
- 若ossfs容器運行異常，則預期輸出為：
```
NAME                   READY   STATUS             RESTARTS     AGE
csi-fuse-ossfs-xxxx    0/1     CrashLoopBackOff   1 (4s ago)   5s
```
- 若ossfs容器運行正常，請排查是否由於節點異常等原因導致Pod處於ContainerCreating狀態。
CSI版本大於等於1.30.4時，執行：
```
kubectl -n ack-csi-fuse get pod -l csi.alibabacloud.com/volume-id=<PV_NAME>
```
- 由於該版本ossfs容器中新增守護進程，無論ossfs進程是否正常運行，預期輸出均為：
```
NAME                   READY   STATUS             RESTARTS     AGE
csi-fuse-ossfs-xxxx    1/1     Running            0            5s
```
  若ossfs容器處於非Running狀態，請先排查異常原因。

出現此類事件的原因：CSI組件在拉起ossfs容器時，ossfs異常退出。OSS連通性檢查出錯（例如Bucket不存在和許可權配置錯誤等）、OSS掛載路徑不存在、無讀寫權限等初始化檢查的錯誤均可能導致此問題。

解決方案

執行以下命令，查詢ossfs容器日誌。
CSI版本小於1.30.4時，執行：
```
kubectl -n kube-system logs -p csi-fuse-ossfs-xxxx 
```
CSI版本大於等於1.30.4時，執行：
```
kubectl -n ack-csi-fuse logs -p csi-fuse-ossfs-xxxx 
```
（可選）如果日誌為空白，或資訊過少無法定位問題，說明日誌等級過高，需要通過以下方式增加相關配置。
說明
該方式無需重新部署新的Debug儲存卷及對應的儲存聲明，但無法直擷取OSS側的rest請求響應。
1. 建立用於Debug的OSS儲存卷，在原儲存卷配置的基礎上，在otherOpts欄位中增加-o dbglevel=debug -o curldbg。使用建立的OSS儲存卷掛載後，通過kubectl logs指令從ossfs Pod擷取Debug日誌。Debug日誌量較大，僅建議在Debug情境使用。
2. 使用以下內容，在kube-system空間建立名為csi-plugin的ConfiMap。將日誌等級設為debug。
  說明
  CSI plugin 1.28.2及之前的版本，日誌等級只能設定到info。
```
apiVersion: v1
kind: ConfigMap
metadata:
  name: csi-plugin
  namespace: kube-system
data:
  fuse-ossfs: |
    dbglevel=debug # 日誌  level
```
  重啟應用所在節點的csi-plugin Pod及csi-provisioner的所有Pod，使Configmap的配置生效，重啟應用Pod觸發重掛載，並確認重掛載後的csi-fuse-ossfs-xxxx重新部署。
  重要
  ConfigMap為全域配置，Debug完成後，請刪除該ConfigMap，再次重啟節點的csi-plugin Pod及csi-provisioner的所有Pod以關閉Debug日誌。最後重啟應用Pod再次觸發重掛載，避免ossfs產生大量Debug日誌。
分析ossfs容器日誌。
通常ossfs拋錯的原因可以分為兩類，分別為ossfs自身拋錯和ossfs向OSS服務端發送請求後收到非200錯誤碼。以下通過兩種拋錯類型的樣本介紹通用的排查方法。
ossfs自身拋錯
查詢日誌，發現ossfs退出前列印的錯誤記錄檔如下。
```
ossfs: MOUNTPOINT directory /test is not empty. if you are sure this is safe, can use the 'nonempty' mount option.
```
根據日誌資訊定位，報錯的原因是掛載點路徑本應為非空，可通過增加配置項-o nonempty解決。
說明
根據錯誤記錄檔，可在OSS文檔ossfs常見問題查詢相關解決方案。若未找到相關原因，請提交工單解決。
OSS服務端返回非200錯誤碼
查詢日誌，發現ossfs退出前檢查掛載Bucket時，OSS服務端返回的錯誤碼為404，錯誤原因為NoSuchBucket，錯誤資訊為The specified bucket does not exist。
```
[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.aliyun.com/troubleshoot?q=0015-00000101</RecommendDoc>
</Error>
```
通過日誌資訊定位，報錯的原因為掛載的OSS Bucket不存在，可通過登入OSS管理主控台建立Bucket後重新掛載解決。
說明
通過錯誤碼及錯誤原因，可在OSS文檔HTTP錯誤碼中查詢相關的解決辦法。
其他說明
- 如果您的日誌等級過高，無法定位問題，並且包含以下需求：
  - 不希望重建OSS儲存卷。
  - 擔心全域ConfigMap配置影響其他問題，例如，Debug期間可能發生的其他OSS儲存卷的掛載或卸載。
  此時，您可以以前台方式掛載ossfs並擷取Debug日誌進行定位。具體操作，請參見CSI Plugin組件為1.26.6之前的版本問題的處理。
  重要
  ossfs容器化運行後，節點未預設安裝ossfs。手動安裝的ossfs版本與實際Pod中啟動並執行ossfs版本可能不一致，建議您優先參考上述解決方案，通過變更PV掛載參數或全域ConfigMap配置的方式進行排查。
- 執行以下操作掛載ossfs：
  1. 安裝最新版本的ossfs，安裝方法請參考安裝ossfs
  2. 在節點上執行以下操作，擷取PV名稱的sha256值：
```
echo -n "<pv-name>" | sha256sum
```
    如對"pv-oss"，預期輸出為：
```
8f3e75e1af90a7dcc66882ec1544cb5c7c32c82c2b56b25a821ac77cea60a928
```
  3. 在節點上執行以下操作，擷取ossfs的掛載參數：
```
ps -aux | grep <sha256-value>
```
    預期輸出中包含ossfs的進程記錄。
  4. 在節點上執行以下命令，產生ossfs掛載時需要的鑒權資訊。在Debug之後，請您及時清理該檔案。
```
mkdir -p /etc/ossfs && echo "<bucket-name>:<akId>:<akSecret>" > /etc/ossfs/passwd-ossfs && chmod 600 /etc/ossfs/passwd-ossfs
```

適用情境2：執行POSIX指令拋錯

CSI Plugin組件為1.26.6之前的版本

問題現象

業務Pod狀態為Running，但執行讀寫等POSIX指令時ossfs拋錯。

問題原因

藉助業務的日誌確認發生錯誤的指令及返回的錯誤類型。例如，執行chmod -R 777 /mnt/path指令時返回I/O error。

執行以下命令，進入業務Pod確認。

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

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

出現此類事件的原因：CSI組件在拉起ossfs後，ossfs進程正常運行，並在業務Pod所在節點指定的掛載點路徑掛載OSS Bucket。但在執行chmod、read、open等POSIX指令時，ossfs運行異常並返回錯誤。

解決方案

步驟1：擷取原ossfs啟動指令

由於ossfs已在節點上運行，您可以通過OSS儲存卷名稱在業務Pod所在的節點上執行以下指令，擷取原ossfs啟動指令。

ps -aux | grep ossfs | grep <PV_NAME>

預期輸出：

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>後面的空格替換為冒號（:），即由<BUCKET> /<PATH>改為<BUCKET>:/<PATH>，擷取到原ossfs啟動指令如下。

/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

步驟2：前台掛載ossfs並擷取Debug日誌

確認是否為掛載點路徑許可權問題。
如果許可權存在問題，請直接在建立PV時，增加配置項-o allow_other。關於ossfs的掛載點目錄存取權限配置，請參見配置存取權限，關於如何增加配置項，請參見使用OSS靜態儲存卷。

執行以下命令，在業務Pod所在節點以前台方式運行ossfs，並設定日誌為Debug模式。

其中，/test為測試用的掛載點路徑，前台啟動並執行ossfs將把OSS Bucket掛載到/test中。

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

參數	說明
-d	開啟日誌資訊。
-f	以前台方式而非守護進程方式運行ossfs，在前台模式下，日誌會輸出到終端螢幕。該參數一般用於調試問題時使用。
-o allow_other	賦予電腦上其他使用者訪問掛載目錄的許可權，避免前台掛載ossfs時，出現新的掛載點路徑許可權問題。
-o curldbg	開啟libcurl的日誌資訊，用於排查OSS服務端返回的錯誤。

步驟3：分析Debug日誌

執行POSIX失敗情境中，需要另起終端執行出錯的指令，並分析執行新列印的ossfs日誌。

ossfs自身拋錯

下文以執行chmod -R 777 <業務Pod中的掛載點路徑>指令出錯為例，介紹如何進行問題排查。

由於測試ossfs進程掛載至/test路徑下，則需執行的指令如下。

chmod -R 777 /test

查詢日誌，發現掛載點路徑/test下的檔案Chmod成功，而Chmod /test本身的錯誤記錄檔如下。

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

根據日誌資訊定位，掛載點路徑不支援通過Chmod變更許可權。關於如何修改掛載點的許可權，請參見OSS儲存卷FAQ。

說明

根據錯誤記錄檔，可在OSS文檔ossfs常見問題查詢相關解決方案。若未找到相關原因，請提交工單解決。

OSS服務端返回非200錯誤碼

下文以對Bucket中的某個對象進行操作時，都返回錯誤為例，介紹如何進行問題排查。

[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>

執行出錯的指令，發現退出前列印的OSS服務端的返回碼為404，錯誤原因為NoSuchKey，錯誤資訊為The specified key does not exist。

根據日誌資訊定位，該對象在OSS服務端中不存在。關於出現該現象的原因及對應的解決辦法，請參見NoSuchKey。

說明

通過錯誤碼及錯誤原因，可在OSS文檔HTTP錯誤碼中查詢相關的解決辦法。

CSI Plugin組件為1.26.6及之後的版本

問題現象

業務Pod狀態為Running，但執行讀寫等POSIX指令時ossfs拋錯。

問題原因

執行以下命令，確認ossfs容器是否正常運行。
替換以下<PV_NAME>為實際業務PV的名稱。
CSI版本小於1.30.4時，執行：
```
kubectl -n kube-system get pod -l csi.alibabacloud.com/volume-id=<PV_NAME>
```
CSI版本大於等於1.30.4時，執行：
```
kubectl -n ack-csi-fuse get pod -l csi.alibabacloud.com/volume-id=<PV_NAME>
```
預期輸出：
```
NAME                   READY   STATUS             RESTARTS     AGE
csi-fuse-ossfs-xxxx     1/1    Running              0          5s
```
若ossfs容器運行異常，請先排查容器異常的原因。具體操作，請參見Pod異常問題排查。
通過業務的日誌確認發生錯誤的指令及返回的錯誤類型。例如，執行chmod -R 777 /mnt/path指令時返回I/O error。

出現此類事件的原因：CSI組件在拉起ossfs容器後，ossfs Pod正常運行，並在業務Pod所在節點指定的掛載點路徑上掛載OSS Bucket，但在執行chmod、read、open等POSIX指令時，ossfs運行異常並返回錯誤，並在日誌中列印對應錯誤。

解決方案

執行以下命令，查詢ossfs容器日誌。
CSI版本小於1.30.4時，執行：
```
kubectl -n kube-system logs -p csi-fuse-ossfs-xxxx 
```
CSI版本大於等於1.30.4時，
```
kubectl -n ack-csi-fuse logs -p csi-fuse-ossfs-xxxx 
```
（可選）如果日誌為空白，或資訊過少無法定位問題，說明日誌等級過高，需要通過以下方式增加相關配置。
說明
該方式無需重新部署新的Debug儲存卷及對應的儲存聲明，但無法直擷取OSS側的rest請求響應。
1. 建立用於Debug的OSS儲存卷，在原儲存卷配置的基礎上，在otherOpts欄位中增加-o dbglevel=debug -o curldbg。使用建立的OSS儲存卷掛載後，通過kubectl logs指令從ossfs Pod擷取Debug日誌。Debug日誌量較大，僅建議在Debug情境使用。
2. 使用以下內容，在kube-system空間建立名為csi-plugin的ConfiMap。將日誌等級設為debug。
  說明
  CSI plugin 1.28.2及之前的版本，日誌等級只能設定到info。
```
apiVersion: v1
kind: ConfigMap
metadata:
  name: csi-plugin
  namespace: kube-system
data:
  fuse-ossfs: |
    dbglevel=debug # 日誌  level
```
  重啟應用所在節點的csi-plugin Pod及csi-provisioner的所有Pod，使Configmap的配置生效，重啟應用Pod觸發重掛載，並確認重掛載後的csi-fuse-ossfs-xxxx重新部署。
  重要
  ConfigMap為全域配置，Debug完成後，請刪除該ConfigMap，再次重啟節點的csi-plugin Pod及csi-provisioner的所有Pod以關閉Debug日誌。最後重啟應用Pod再次觸發重掛載，避免ossfs產生大量Debug日誌。
分析ossfs容器日誌。
通常ossfs拋錯的原因可以分為兩類，分別為ossfs自身拋錯和ossfs向OSS服務端發送請求後收到非200錯誤碼。以下通過兩種拋錯類型的樣本介紹通用的排查方法。
ossfs自身拋錯
此處以執行chmod -R 777 <業務Pod中的掛載點路徑>指令出錯為例，介紹如何進行問題排查。
1. 若測試ossfs的掛載路徑為/test，則執行以下命令。
```
chmod -R 777 /test
```
  查詢日誌後，發現掛載點路徑/test下的檔案Chmod成功，而Chmod /test自身的錯誤記錄檔如下。
```
[ERROR]  2023-10-18 06:03:24:/tmp/ossfs/src/ossfs.cpp:ossfs_chmod(1745): Could not change mode for mount point.
```
  根據日誌資訊定位，掛載點路徑不支援通過Chmod變更許可權。關於如何修改掛載點的許可權，請參見OSS儲存卷FAQ。
  說明
  根據錯誤記錄檔，可在OSS文檔ossfs常見問題查詢相關解決方案。若未找到相關原因，請提交工單解決。
OSS服務端返回非200錯誤碼
下文以對Bucket中的某個對象進行操作時，都返回錯誤為例，介紹如何進行問題排查。
```
[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:
```
執行出錯的指令，發現退出前列印的OSS服務端的HTTP返回碼為404。推斷原因為該對象在OSS服務端中不存在。關於出現該現象的原因及對應的解決辦法，請參見404錯誤。
說明
通過錯誤碼及錯誤原因，可在OSS文檔HTTP錯誤碼中查詢相關的解決辦法。
其他說明
- 如果您的日誌等級過高，無法定位問題，並且包含以下需求：
  - 不希望重建OSS儲存卷。
  - 擔心全域ConfigMap配置影響其他問題，例如，Debug期間可能發生的其他OSS儲存卷的掛載或卸載。
  此時，您可以以前台方式掛載ossfs並擷取Debug日誌進行定位。具體操作，請參見CSI Plugin組件為1.26.6之前的版本問題的處理。
  重要
  ossfs容器化運行後，節點未預設安裝ossfs。手動安裝的ossfs版本與實際Pod中啟動並執行ossfs版本可能不一致，建議您優先參考上述解決方案，通過變更PV掛載參數或全域ConfigMap配置的方式進行排查。
- 執行以下操作掛載ossfs：
  1. 安裝最新版本的ossfs，安裝方法請參考安裝ossfs
  2. 在節點上執行以下操作，擷取PV名稱的sha256值：
```
echo -n "<pv-name>" | sha256sum
```
    如對"pv-oss"，預期輸出為：
```
8f3e75e1af90a7dcc66882ec1544cb5c7c32c82c2b56b25a821ac77cea60a928
```
  3. 在節點上執行以下操作，擷取ossfs的掛載參數：
```
ps -aux | grep <sha256-value>
```
    預期輸出中包含ossfs的進程記錄。
  4. 在節點上執行以下命令，產生ossfs掛載時需要的鑒權資訊。在Debug之後，請您及時清理該檔案。
```
mkdir -p /etc/ossfs && echo "<bucket-name>:<akId>:<akSecret>" > /etc/ossfs/passwd-ossfs && chmod 600 /etc/ossfs/passwd-ossfs
```

排查說明

適用情境1：掛載失敗

CSI Plugin組件為1.26.6之前的版本

問題現象

問題原因

解決方案

步驟1：擷取原ossfs啟動指令

步驟2：前台掛載ossfs並擷取Debug日誌

步驟3：分析Debug日誌

ossfs自身拋錯

OSS服務端返回非200錯誤碼

CSI Plugin組件為1.26.6及之後的版本

問題現象

問題原因

解決方案

ossfs自身拋錯

OSS服務端返回非200錯誤碼

其他說明

適用情境2：執行POSIX指令拋錯

CSI Plugin組件為1.26.6之前的版本

問題現象

問題原因

解決方案

步驟1：擷取原ossfs啟動指令

步驟2：前台掛載ossfs並擷取Debug日誌

步驟3：分析Debug日誌

ossfs自身拋錯

OSS服務端返回非200錯誤碼

CSI Plugin組件為1.26.6及之後的版本

問題現象

問題原因

解決方案

ossfs自身拋錯

OSS服務端返回非200錯誤碼

其他說明