Longhorn 雲原生容器分散式儲存 - 故障排除指南

內容來源於官方 Longhorn 1.1.2 英文技術手冊。

系列

• Longhorn 是什麼?
• Longhorn 雲原生容器分散式儲存 - 設計架構和概念
• Longhorn 雲原生容器分散式儲存 - 部署篇
• Longhorn 雲原生容器分散式儲存 - 券和節點
• Longhorn 雲原生容器分散式儲存 - K8S 資源配置示例
• Longhorn 雲原生容器分散式儲存 - 監控(Prometheus)
• Longhorn 雲原生容器分散式儲存 - 備份與恢復
• Longhorn 雲原生容器分散式儲存 - 高可用
• Longhorn 雲原生容器分散式儲存 - 支援 ReadWriteMany (RWX) 工作負載
• Longhorn 雲原生容器分散式儲存 - 定製部署預設設定
• Longhorn雲原生容器分散式儲存 - Air Gap 安裝
• Longhorn 雲原生容器分散式儲存 - Python Client

目錄

1. 當 Longhorn 卷檔案系統損壞時，Pod 卡在 creating 狀態
2. 非標準 Kubelet 目錄
3. Longhorn 預設設定不保留
4. 分離和附加捲後，Recurring job 不會建立新 job
5. 使用 Traefik 2.x 作為 ingress controller
6. 使用 cURL 建立 Support Bundle
7. Longhorn RWX 共享掛載所有權在 consumer Pod 中顯示為 nobody
8. 由於節點上的多路徑，MountVolume.SetUp for volume 失敗
9. Longhorn-UI:WebSocket 握手期間出錯:意外響應程式碼:200 #2265
10. Longhorn 卷需要很長時間才能完成安裝
11. volume readonly or I/O error
12. volume pvc-xxx not scheduled

1. 當 Longhorn 卷檔案系統損壞時，Pod 卡在 creating 狀態

適用版本

所有 Longhorn 版本。

症狀

Pod 停留在容器 Creating 中，日誌中有錯誤。

Warning  FailedMount             30s (x7 over 63s)  kubelet                  MountVolume.SetUp failed for volume "pvc-bb8582d5-eaa4-479a-b4bf-328d1ef1785d" : rpc error: code = Internal desc = 'fsck' found errors on device /dev/longhorn/pvc-bb8582d5-eaa4-479a-b4bf-328d1ef1785d but could not correct them: fsck from util-linux 2.31.1
ext2fs_check_if_mount: Can't check if filesystem is mounted due to missing mtab file while determining whether /dev/longhorn/pvc-bb8582d5-eaa4-479a-b4bf-328d1ef1785d is mounted.
/dev/longhorn/pvc-bb8582d5-eaa4-479a-b4bf-328d1ef1785d contains a file system with errors, check forced.
/dev/longhorn/pvc-bb8582d5-eaa4-479a-b4bf-328d1ef1785d: Inodes that were part of a corrupted orphan linked list found.  

/dev/longhorn/pvc-bb8582d5-eaa4-479a-b4bf-328d1ef1785d: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
  (i.e., without -a or -p options)

原因

當 Longhorn 卷的檔案系統損壞時，Longhorn 無法重新掛載該卷。 因此，workload 無法重新啟動。

Longhorn 無法自動修復此問題。發生這種情況時，您需要手動解決此問題。

解決方案

1. 尋找跡象：
   • 從 Longhorn UI 檢查卷是否處於 error 狀態。
   • 檢查 Longhorn 管理器 pod 日誌以瞭解系統損壞錯誤訊息。

   如果卷未處於 error 狀態，則 Longhorn 卷內的檔案系統可能因外部原因而損壞。

2. 縮減 workload。
3. 從 UI 將卷附加到任何一個 node。
4. SSH 進入 node。
5. 在 /dev/longhorn/ 下找到 Longhorn 卷對應的塊裝置。
6. 執行 fsck 來修復檔案系統。
7. 從 UI 分離卷。
8. 擴大 workload。

2. 非標準 Kubelet 目錄

適用版本

所有 Longhorn 版本。

症狀

當 Kubernetes 叢集使用非標準的 Kubelet 目錄時，longhorn-csi-plugin 無法啟動。

ip-172-30-0-73:/home/ec2-user # kubectl -n longhorn-system get pod
NAME                                        READY   STATUS              RESTARTS   AGE
longhorn-ui-5b864949c4-4sgws                1/1     Running             0          7m35s
longhorn-manager-tx469                      1/1     Running             0          7m35s
longhorn-driver-deployer-5444f75b8f-kgq5v   1/1     Running             0          7m35s
longhorn-csi-plugin-s4fg7                   0/2     ContainerCreating   0          6m59s
instance-manager-r-d185a1e9                 1/1     Running             0          7m10s
instance-manager-e-b5e69e2d                 1/1     Running             0          7m10s
csi-attacher-7d975797bc-qpfrv               1/1     Running             0          7m
csi-snapshotter-7dbfc7ddc6-nqqtg            1/1     Running             0          6m59s
csi-attacher-7d975797bc-td6tw               1/1     Running             0          7m
csi-resizer-868d779475-v6jvv                1/1     Running             0          7m
csi-resizer-868d779475-2bbs2                1/1     Running             0          7m
csi-provisioner-5c6845945f-46qnb            1/1     Running             0          7m
csi-resizer-868d779475-n5vjn                1/1     Running             0          7m
csi-provisioner-5c6845945f-fjnrq            1/1     Running             0          7m
csi-snapshotter-7dbfc7ddc6-mhfpl            1/1     Running             0          6m59s
csi-provisioner-5c6845945f-4lx5c            1/1     Running             0          7m
csi-attacher-7d975797bc-flldq               1/1     Running             0          7m
csi-snapshotter-7dbfc7ddc6-cms2v            1/1     Running             0          6m59s
engine-image-ei-611d1496-dlqcs              1/1     Running             0          7m10s

原因

由於 Longhorn 無法檢測到 Kubelet 的根目錄設定在哪裡。

解決方案

Longhorn 通過 longhorn.yaml 安裝：

取消註釋並編輯：

#- name: KUBELET_ROOT_DIR
#  value: /var/lib/rancher/k3s/agent/kubelet

Longhorn 通過 Rancher - App 安裝：

點選 Customize Default Settings 設定 Kubelet 根目錄

相關資訊

• Longhorn issue：
  • https://github.com/longhorn/longhorn/issues/2537
• 更多資訊可以在 OS/Distro 特定配置 下的故障排除部分找到。

3. Longhorn 預設設定不保留

適用版本

所有 Longhorn 版本。

症狀

• 通過 helm 或 Rancher App 升級 Longhorn 系統時，修改後的 Longhorn 預設設定不會保留。
• 通過 kubectl -n longhorn-system edit configmap longhorn-default-setting 修改預設設定時，修改不會應用於 Longhorn 系統。

背景

此預設設定僅適用於尚未部署的 Longhorn 系統。 它對現有的 Longhorn 系統沒有影響。

解決方案

我們建議使用 Longhorn UI 更改現有叢集上的 Longhorn 設定。

您也可以使用 kubectl，但請注意這將繞過 Longhorn 後端驗證。

kubectl edit settings <SETTING-NAME> -n longhorn-system

4. 分離和附加捲後，Recurring job 不會建立新 job

適用版本

所有 Longhorn 版本。

症狀

當卷被分離很長時間後被附加時，迴圈作業不會建立新 job。

根據 Kubernetes CronJob 限制：

• https://kubernetes.io/docs/concepts/workloads/controllers/cron-jobs/#cron-job-limitations

對於每個 CronJob，CronJob 控制器會檢查它在從上次排程時間到現在的持續時間內錯過了多少個 schedule。
如果有超過 100 個錯過的 schedule，則它不會啟動 job 並記錄 error

Cannot determine if job needs to be started. Too many missed start time (> 100). Set or decrease .spec.startingDeadlineSeconds or check clock skew.

這意味著 recurring job 可以容忍的附加/分離操作的持續時間取決於排程的間隔(scheduled interval)。

例如，如果 recurring backup job 設定為每分鐘執行一次，則容限為 100 分鐘。

解決方案

直接刪除卡住的 cronjob，讓 Longhorn 重新建立。

ip-172-30-0-211:/home/ec2-user # kubectl -n longhorn-system get cronjobs
NAME                                                  SCHEDULE    SUSPEND   ACTIVE   LAST SCHEDULE   AGE
pvc-394e6006-9c34-47da-bf27-2286ae669be1-c-ptl8l1-c   * * * * *   False     1        47s             2m23s

ip-172-30-0-211:/home/ec2-user # kubectl -n longhorn-system delete cronjobs/pvc-394e6006-9c34-47da-bf27-2286ae669be1-c-ptl8l1-c
cronjob.batch "pvc-394e6006-9c34-47da-bf27-2286ae669be1-c-ptl8l1-c" deleted

ip-172-30-0-211:/home/ec2-user # kubectl -n longhorn-system get cronjobs
No resources found in longhorn-system namespace.

ip-172-30-0-211:/home/ec2-user # sleep 60

ip-172-30-0-211:/home/ec2-user # kubectl -n longhorn-system get cronjobs
NAME                                                  SCHEDULE    SUSPEND   ACTIVE   LAST SCHEDULE   AGE
pvc-394e6006-9c34-47da-bf27-2286ae669be1-c-ptl8l1-c   * * * * *   False     1        2s             3m21s

相關資訊

• 相關 Longhorn issue：
  • https://github.com/longhorn/longhorn/issues/2513

5. 使用 Traefik 2.x 作為 ingress controller

適用版本

所有 Longhorn 版本。

症狀

Longhorn GUI 前端 API 請求有時無法到達 longhorn-manager 後端。

原因

API 請求會改變 HTTPS/WSS 之間的協議，而這種改變會導致 CORS 問題。

解決方案

Traefik 2.x ingress controller 沒有設定 WebSocket header。

1. 將以下中介軟體新增到 Longhorn 前端 service 的路由中。

apiVersion: traefik.containo.us/v1alpha1
kind: Middleware
metadata:
  name: svc-longhorn-headers
  namespace: longhorn-system
spec:
  headers:
    customRequestHeaders:
      X-Forwarded-Proto: "https"

2. 更新 ingress 以使用中介軟體規則。

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: longhorn-ingress
  namespace: longhorn-system
  annotations:
    traefik.ingress.kubernetes.io/router.entrypoints: websecure
    traefik.ingress.kubernetes.io/router.tls: "true"       
    traefik.ingress.kubernetes.io/router.middlewares: longhorn-system-svc-longhorn-headers@kubernetescrd
spec:
  rules:
  - http:
      paths:
      - path: /
        backend:
          serviceName: longhorn-frontend
          servicePort: 80

相關資訊

• Longhorn issue comment:
  • https://github.com/longhorn/longhorn/issues/1442#issuecomment-639761799

6. 使用 cURL 建立 Support Bundle

適用版本

所有 Longhorn 版本。

症狀

無法使用 Web 瀏覽器建立 support bundle。

解決方案

1. 暴露 Longhorn 後端服務。下面是一個使用 NodePort 的示例，如果設定了負載均衡器，您也可以通過負載均衡器暴露。

ip-172-30-0-21:~ # kubectl -n longhorn-system     patch svc longhorn-backend -p '{"spec":    {"type":"NodePort"}}'
service/longhorn-backend patched
ip-172-30-0-21:~ # kubectl -n longhorn-system get     svc/longhorn-backend
NAME               TYPE       CLUSTER-IP          EXTERNAL-IP   PORT(S)          AGE
longhorn-backend   NodePort   10.43.136.157       <none>        9500:32595/TCP   156m

2. 執行以下指令碼以建立和下載 support bundle。您需要替換 BACKEND_URL、ISSUE_URL、ISSUE_DESCRIPTION。

# Replace this block ====>
BACKEND_URL="18.141.237.97:32595"

ISSUE_URL="https://github.com/longhorn/longhorn/issues/dummy"
ISSUE_DESCRIPTION="dummy description"
# <==== Replace this block

# Request to create the support bundle
REQUEST_SUPPORT_BUNDLE=$( curl -sSX POST -H 'Content-Type: application/json' -d '{ "issueURL": "'"${ISSUE_URL}"'", "description": "'"${ISSUE_DESCRIPTION}"'" }' http://${BACKEND_URL}/v1/supportbundles )

ID=$( jq -r '.id' <<< ${REQUEST_SUPPORT_BUNDLE} )
SUPPORT_BUNDLE_NAME=$( jq -r '.name' <<< ${REQUEST_SUPPORT_BUNDLE} )
echo "Creating support bundle ${SUPPORT_BUNDLE_NAME} on Node ${ID}"

while [ $(curl -sSX GET http://${BACKEND_URL}/v1/supportbundles/${ID}/${SUPPORT_BUNDLE_NAME} | jq -r '.state' ) != "ReadyForDownload" ]; do
  echo "Progress: $(curl -sSX GET http://${BACKEND_URL}/v1/supportbundles/${ID}/${SUPPORT_BUNDLE_NAME} | jq -r '.progressPercentage' )%"
  sleep 1s
done

curl -i -X GET http://${BACKEND_URL}/v1/supportbundles/${ID}/${SUPPORT_BUNDLE_NAME}/download --output /tmp/${SUPPORT_BUNDLE_NAME}.zip
echo "Downloaded support bundle to /tmp/${SUPPORT_BUNDLE_NAME}.zip"

相關資訊

• 相關的 Longhorn comment:
  • https://github.com/longhorn/longhorn/issues/2118#issuecomment-748099002

7. Longhorn RWX 共享掛載所有權在 consumer Pod 中顯示為 nobody

適用版本

Longhorn 版本 = v1.1.0

症狀

當 Pod 使用 RWX 卷掛載時，Pod 共享掛載目錄及其 recurring contents 的所有 ownership 顯示為 nobody，但在 share-manager 中顯示為 root。

root@ip-172-30-0-139:/home/ubuntu# kubectl exec -it rwx-test-2pml2 -- ls -l /data
total 16
drwx------ 2 nobody 42949672 16384 Mar 31 04:16 lost+found

root@ip-172-30-0-139:~# kubectl -n longhorn-system exec -it share-manager-pvc-f3775852-1e27-423f-96ab-95ccd04e4777 -- ls -l /export/pvc-f3775852-1e27-423f-96ab-95ccd04e4777
total 16
drwx------ 2 root root 16384 Mar 31 04:42 lost+found

背景

share-manager 中的 nfs-ganesha 使用 idmapd 進行 NFSv4 ID 對映，並設定為使用 localdomain 作為其匯出域。

原因

client(host) 和 server(share-manager) 之間 /etc/idmapd.conf 中的內容不匹配導致 ownership 更改。

讓我們看一個例子：

我們假設您沒有修改叢集主機上的 /etc/idmapd.conf。對於某些作業系統，Domain = localdomain 被註釋掉，預設情況下它使用 FQDN 減去 hostname。

當主機名為 ip-172-30-0-139 且 FQDN 為 ip-172-30-0-139.lan 時，主機 idmapd 將使用 lan 作為 Domain。

root@ip-172-30-0-139:/home/ubuntu# hostname
ip-172-30-0-139

root@ip-172-30-0-139:/home/ubuntu# hostname -f
ip-172-30-0-139.lan

這導致 share-manager(localdomain) 和叢集主機（lan）之間的域不匹配。 因此觸發檔案許可權更改為使用 nobody。

[Mapping] section variables

Nobody-User
Local user name to be used when a mapping cannot be completed.
Nobody-Group
Local group name to be used when a mapping cannot be completed.

解決方案

1. 在所有群集主機上的 /etc/idmapd.conf 中取消註釋或新增 Domain = localdomain。

root@ip-172-30-0-139:~# cat /etc/idmapd.conf 
[General]

Verbosity = 0
Pipefs-Directory = /run/rpc_pipefs
# set your own domain here, if it differs from FQDN minus hostname
Domain = localdomain

[Mapping]

Nobody-User = nobody
Nobody-Group = nogroup

2. 刪除並重新建立 RWX 資源堆疊（pvc + pod）。

root@ip-172-30-0-139:/home/ubuntu# kubectl exec -it volume-test -- ls -l /data
total 16
drwx------    2 root     root         16384 Mar 31 04:42 lost+found

相關資訊

• 相關的 Longhorn issue:
  • https://github.com/longhorn/longhorn/issues/2357
• 相關的 idmapd.conf 文件：
  • https://linux.die.net/man/5/idmapd.conf

8. 由於節點上的多路徑，MountVolume.SetUp for volume 失敗

適用版本

所有 Longhorn 版本。

症狀

帶有卷的 pod 未啟動並在 longhorn-csi-plugin 中遇到錯誤訊息：

time="2020-04-16T08:49:27Z" level=info msg="GRPC request: {\"target_path\":\"/var/lib/kubelet/pods/cf0a0b5b-106e-4793-a74a-28bfae21be1a/volumes/kubernetes.io~csi/pvc-d061512e-870a-4ece-bd45-2f04672d5256/mount\",\"volume_capability\":{\"AccessType\":{\"Mount\":{\"fs_type\":\"ext4\"}},\"access_mode\":{\"mode\":1}},\"volume_context\":{\"baseImage\":\"\",\"fromBackup\":\"\",\"numberOfReplicas\":\"3\",\"staleReplicaTimeout\":\"30\",\"storage.kubernetes.io/csiProvisionerIdentity\":\"1586958032802-8081-driver.longhorn.io\"},\"volume_id\":\"pvc-d061512e-870a-4ece-bd45-2f04672d5256\"}"
time="2020-04-16T08:49:27Z" level=info msg="NodeServer NodePublishVolume req: volume_id:\"pvc-d061512e-870a-4ece-bd45-2f04672d5256\" target_path:\"/var/lib/kubelet/pods/cf0a0b5b-106e-4793-a74a-28bfae21be1a/volumes/kubernetes.io~csi/pvc-d061512e-870a-4ece-bd45-2f04672d5256/mount\" volume_capability:<mount:<fs_type:\"ext4\" > access_mode:<mode:SINGLE_NODE_WRITER > > volume_context:<key:\"baseImage\" value:\"\" > volume_context:<key:\"fromBackup\" value:\"\" > volume_context:<key:\"numberOfReplicas\" value:\"3\" > volume_context:<key:\"staleReplicaTimeout\" value:\"30\" > volume_context:<key:\"storage.kubernetes.io/csiProvisionerIdentity\" value:\"1586958032802-8081-driver.longhorn.io\" > "
E0416 08:49:27.567704 1 mount_linux.go:143] Mount failed: exit status 32
Mounting command: mount
Mounting arguments: -t ext4 -o defaults /dev/longhorn/pvc-d061512e-870a-4ece-bd45-2f04672d5256 /var/lib/kubelet/pods/cf0a0b5b-106e-4793-a74a-28bfae21be1a/volumes/kubernetes.io~csi/pvc-d061512e-870a-4ece-bd45-2f04672d5256/mount
Output: mount: /var/lib/kubelet/pods/cf0a0b5b-106e-4793-a74a-28bfae21be1a/volumes/kubernetes.io~csi/pvc-d061512e-870a-4ece-bd45-2f04672d5256/mount: /dev/longhorn/pvc-d061512e-870a-4ece-bd45-2f04672d5256 already mounted or mount point busy.
E0416 08:49:27.576477 1 mount_linux.go:487] format of disk "/dev/longhorn/pvc-d061512e-870a-4ece-bd45-2f04672d5256" failed: type:("ext4") target:("/var/lib/kubelet/pods/cf0a0b5b-106e-4793-a74a-28bfae21be1a/volumes/kubernetes.io~csi/pvc-d061512e-870a-4ece-bd45-2f04672d5256/mount") options:(["defaults"])error:(exit status 1)
time="2020-04-16T08:49:27Z" level=error msg="GRPC error: rpc error: code = Internal desc = exit status 1"

詳情

這是由於多路徑為任何符合條件的裝置路徑建立了多路徑裝置，包括未明確列入黑名單的每個 Longhorn 卷裝置。

故障排除

1. 查詢 Longhorn 裝置的 major:minor 編號。在節點上，嘗試 ls -l /dev/longhorn/。major:minor 編號將顯示在裝置名稱前，例如 8、32。

ls -l /dev/longhorn
brw-rw---- 1 root root 8, 32 Aug 10 21:50 pvc-39c0db31-628d-41d0-b05a-4568ec02e487

2. 查詢 Linux 為相同的 major:minor 編號生成的裝置是什麼。 使用 ls -l /dev 並找到相同 major:minor 編號的裝置，例如 /dev/sde。

brw-rw---- 1 root disk      8,  32 Aug 10 21:50 sdc

3. 找到程式。使用 lsof 獲取正在使用的檔案處理程式列表，然後使用 grep 獲取裝置名稱（例如 sde 或 /dev/longhorn/xxx。您應該在那裡找到一個。

lsof | grep sdc
multipath 514292                              root    8r      BLK               8,32        0t0        534 /dev/sdc
multipath 514292 514297 multipath             root    8r      BLK               8,32        0t0        534 /dev/sdc
multipath 514292 514299 multipath             root    8r      BLK               8,32        0t0        534 /dev/sdc
multipath 514292 514300 multipath             root    8r      BLK               8,32        0t0        534 /dev/sdc
multipath 514292 514301 multipath             root    8r      BLK               8,32        0t0        534 /dev/sdc
multipath 514292 514302 multipath             root    8r      BLK               8,32        0t0        534 /dev/sdc
multipath 514292 514304 multipath             root    8r      BLK               8,32        0t0        534 /dev/sdc

解決方案

按照以下步驟防止多路徑守護程式(multipath daemon)新增由 Longhorn 建立的額外塊裝置。

首先使用 lsblk 檢查 Longhorn 建立的裝置：

root@localhost:~# lsblk
NAME MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda    8:0    0 79.5G  0 disk /
sdb    8:16   0  512M  0 disk [SWAP]
sdc    8:32   0    1G  0 disk /var/lib/kubelet/pods/c2c2b848-1f40-4727-8a52-03a74f9c76b9/volumes/kubernetes.io~csi/pvc-859bc3c9-faa8-4f54-85e4-b12935b5ae3c/mount
sdd    8:48   0    1G  0 disk /var/lib/kubelet/pods/063a181a-66ac-4644-8268-9215305f9b73/volumes/kubernetes.io~csi/pvc-837eb6ac-45fe-4de7-9c97-8d371eb02190/mount
sde    8:64   0    1G  0 disk /var/lib/kubelet/pods/4c80842d-7257-4b91-b668-bb5b111da003/volumes/kubernetes.io~csi/pvc-c01cee3e-f292-4979-b183-6546d6397fbd/mount
sdf    8:80   0    1G  0 disk /var/lib/kubelet/pods/052dadd9-042a-451c-9bb1-2d9418f0381f/volumes/kubernetes.io~csi/pvc-ba7a5c9a-d84d-4cb0-959d-3db39f34d81b/mount
sdg    8:96   0    1G  0 disk /var/lib/kubelet/pods/7399b073-c262-4963-8c7f-9e481272ea36/volumes/kubernetes.io~csi/pvc-2b122b42-141a-4181-b8fd-ce3cf91f6a64/mount
sdh    8:112  0    1G  0 disk /var/lib/kubelet/pods/a63d919d-201b-4eb1-9d84-6440926211a9/volumes/kubernetes.io~csi/pvc-b7731785-8364-42a8-9e7d-7516801ab7e0/mount
sdi    8:128  0    1G  0 disk /var/lib/kubelet/pods/3e056ee4-bab4-4230-9054-ab214bdf711f/volumes/kubernetes.io~csi/pvc-89d37a02-8480-4317-b0f1-f17b2a886d1d/mount

請注意，Longhorn 裝置名稱以 /dev/sd[x] 開頭

• 如果不存在，則建立預設配置檔案 /etc/multipath.conf
• 將以下行新增到黑名單部分 devnode "^sd[a-z0-9]+"

blacklist {
    devnode "^sd[a-z0-9]+"
}

• 重啟多路徑服務

systemctl restart multipathd.service

• 驗證是否應用了配置

multipath -t

多路徑黑名單部分的預設配置預設阻止以下裝置名稱
^(ram|raw|loop|fd|md|dm-|sr|scd|st|dcssblk)[0-9] ^(td|hd|vd)[a-z]

相關資訊

• 相關 Longhorn issue：
  • https://github.com/longhorn/longhorn/issues/1210
• 相關手冊
  • http://manpages.org/multipathconf/5

9. Longhorn-UI:WebSocket 握手期間出錯:意外響應程式碼:200 #2265

適用版本

現有 Longhorn 版本 < v1.1.0 升級到 Longhorn >= v1.1.0。

症狀

Longhorn 升級到版本 >= v1.1.0 後，遇到如下情況：

入口訊息：

{"level":"error","msg":"vulcand/oxy/forward/websocket: Error dialing \"10.17.1.246\": websocket: bad handshake with resp: 200 200 OK","time":"2021-03-09T08:29:03Z"}

Longhorn UI 訊息：

10.46.0.3 - - [19/Feb/2021:11:33:24 +0000] "GET /node/v1/ws/1s/engineimages HTTP/1.1" 200 578 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.150 Safari/537.36 Edg/88.0.705.68"
10.46.0.3 - - [19/Feb/2021:11:33:29 +0000] "GET /node/v1/ws/1s/volumes HTTP/1.1" 200 578 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.150 Safari/537.36 Edg/88.0.705.68"
10.46.0.3 - - [19/Feb/2021:11:33:32 +0000] "GET /node/v1/ws/1s/nodes HTTP/1.1" 200 578 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.150 Safari/537.36 Edg/88.0.705.68"
10.46.0.3 - - [19/Feb/2021:11:33:37 +0000] "GET /node/v1/ws/1s/events HTTP/1.1" 200 578 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.150 Safari/537.36 Edg/88.0.705.68"
10.46.0.3 - - [19/Feb/2021:11:33:38 +0000] "GET /node/v1/ws/1s/engineimages HTTP/1.1" 200 578 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.150 Safari/537.36 Edg/88.0.705.68"
10.46.0.3 - - [19/Feb/2021:11:33:41 +0000] "GET /node/v1/ws/1s/volumes HTTP/1.1" 200 578 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.150 Safari/537.36 Edg/88.0.705.68"

原因

為了支援不同的路由（Rancher-Proxy、NodePort、Ingress 和 Nginx），Longhorn v1.1.0 重新構建了 UI 以使用 hash history，原因有兩個：

• 支援 Longhorn UI 路由到不同路徑。例如，/longhorn/#/dashboard
• 通過分離前端和後端來支援單頁應用程式。

結果，<LONGHORN_URL>/<TAG> 更改為 <LONGHORN_URL>/#/<TAG>。

之後，輸出訊息應類似於以下內容：

Ingress 訊息應該沒有 websocket 錯誤：

time="2021-03-16T04:54:23Z" level=debug msg="websocket: open" id=6809628160892941023 type=events
time="2021-03-16T04:54:23Z" level=debug msg="websocket: open" id=3234910863291903636 type=engineimages
time="2021-03-16T04:54:23Z" level=debug msg="websocket: open" id=2117763315178050120 type=backingimages
time="2021-03-16T04:54:23Z" level=debug msg="websocket: open" id=621105775322000457 type=volumes

Longhorn UI 訊息：

使用 Ingress：

10.42.0.8 - - [16/Mar/2021:04:54:34 +0000] "GET /v1/nodes HTTP/1.1" 200 6729 "http://10.17.0.169/" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/89.0.4389.90 Safari/537.36"
10.42.0.8 - - [16/Mar/2021:04:54:34 +0000] "GET /v1/backingimages HTTP/1.1" 200 117 "http://10.17.0.169/" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/89.0.4389.90 Safari/537.36"
10.42.0.8 - - [16/Mar/2021:04:54:34 +0000] "GET /v1/volumes HTTP/1.1" 200 162 "http://10.17.0.169/" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/89.0.4389.90 Safari/537.36"
10.42.0.8 - - [16/Mar/2021:04:54:34 +0000] "GET /v1/engineimages HTTP/1.1" 200 1065 "http://10.17.0.169/" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/89.0.4389.90 Safari/537.36"
10.42.0.8 - - [16/Mar/2021:04:54:34 +0000] "GET /v1/settings HTTP/1.1" 200 30761 "http://10.17.0.169/" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/89.0.4389.90 Safari/537.36"
10.42.0.8 - - [16/Mar/2021:04:54:34 +0000] "GET /v1/events HTTP/1.1" 200 62750 "http://10.17.0.169/" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/89.0.4389.90 Safari/537.36"

使用 Proxy：

10.42.0.0 - - [16/Mar/2021:05:03:51 +0000] "GET /v1/engineimages HTTP/1.1" 200 1070 "http://localhost:8001/api/v1/namespaces/longhorn-system/services/http:longhorn-frontend:80/proxy/" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/89.0.4389.90 Safari/537.36"
10.42.0.0 - - [16/Mar/2021:05:03:51 +0000] "GET /v1/events HTTP/1.1" 200 62904 "http://localhost:8001/api/v1/namespaces/longhorn-system/services/http:longhorn-frontend:80/proxy/" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/89.0.4389.90 Safari/537.36"
10.42.0.0 - - [16/Mar/2021:05:03:52 +0000] "GET /v1/engineimages HTTP/1.1" 200 1071 "http://localhost:8001/api/v1/namespaces/longhorn-system/services/http:longhorn-frontend:80/proxy/" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/89.0.4389.90 Safari/537.36"
10.42.0.0 - - [16/Mar/2021:05:03:52 +0000] "GET /v1/nodes HTTP/1.1" 200 6756 "http://localhost:8001/api/v1/namespaces/longhorn-system/services/http:longhorn-frontend:80/proxy/" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/89.0.4389.90 Safari/537.36"
10.42.0.0 - - [16/Mar/2021:05:03:52 +0000] "GET /v1/settings HTTP/1.1" 200 30882 "http://localhost:8001/api/v1/namespaces/longhorn-system/services/http:longhorn-frontend:80/proxy/" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/89.0.4389.90 Safari/537.36"
10.42.0.0 - - [16/Mar/2021:05:03:52 +0000] "GET /v1/volumes HTTP/1.1" 200 168 "http://localhost:8001/api/v1/namespaces/longhorn-system/services/http:longhorn-frontend:80/proxy/" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/89.0.4389.90 Safari/537.36"
10.42.0.0 - - [16/Mar/2021:05:03:52 +0000] "GET /v1/backingimages HTTP/1.1" 200 120 "http://localhost:8001/api/v1/namespaces/longhorn-system/services/http:longhorn-frontend:80/proxy/" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/89.0.4389.90 Safari/537.36"
10.42.0.0 - - [16/Mar/2021:05:03:52 +0000] "GET /v1/events HTTP/1.1" 200 62900 "http://localhost:8001/api/v1/namespaces/longhorn-system/services/http:longhorn-frontend:80/proxy/" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/89.0.4389.90 Safari/537.36"

解決方案

1. 清除瀏覽器快取。
2. 從 <LONGHORN_URL>/# 訪問/重新收藏 Longhorn URL。

相關資訊

• 相關 Longhorn issue:
  • https://github.com/longhorn/longhorn/issues/2265
  • https://github.com/longhorn/longhorn/issues/1660

10. Longhorn 卷需要很長時間才能完成安裝

適用版本

所有 Longhorn 版本。

症狀

啟動使用 Longhorn 卷的工作負載 pod 時，Longhorn UI 顯示 Longhorn 卷連線很快，但卷完成掛載和工作負載能夠啟動需要很長時間。

僅當 Longhorn 卷具有許多檔案/目錄並且在工作負載 pod 中設定 securityContext.fsGroup 時才會發生此問題，如下所示：

spec:
  securityContext:
    runAsUser: 1000
    runAsGroup: 3000
    fsGroup: 2000

原因

預設情況下，當看到 fsGroup 欄位時，每次掛載卷時，Kubernetes 都會對卷內的所有檔案和目錄遞迴呼叫 chown() 和 chmod()。即使卷的組所有權已經與請求的 fsGroup 匹配，也會發生這種情況，並且對於包含大量小檔案的較大卷來說可能非常昂貴，這會導致 pod 啟動需要很長時間。

解決方案

在 Kubernetes v1.19.x 及之前版本中沒有解決此問題的方法。

自從版本 1.20.x 以來，Kubernetes 引入了一個新的 beta 特性：欄位 fsGroupChangePolicy。即，

spec:
  securityContext:
    runAsUser: 1000
    runAsGroup: 3000
    fsGroup: 2000
    fsGroupChangePolicy: "OnRootMismatch"

當 fsGroupChangePolicy 設定為 OnRootMismatch 時，如果卷的根已具有正確的許可權，則將跳過遞迴許可權和所有權更改。這意味著，如果使用者在 pod 啟動之間不更改 pod.spec.securityContext.fsGroup，K8s 只需檢查根目錄的許可權和所有權，與總是遞迴地更改卷的所有權和許可權相比，裝載過程將快得多。

相關資訊

• 相關 Longhorn issue:
  • https://github.com/longhorn/longhorn/issues/2131
• 相關 Kubernetes 文件：
  • https://kubernetes.io/blog/2020/12/14/kubernetes-release-1.20-fsgroupchangepolicy-fsgrouppolicy/#allow-users-to-skip-recursive-permission-changes-on-mount

11. volume readonly or I/O error

適用版本

所有 Longhorn 版本。

症狀

當應用程式將資料寫入現有檔案或在 Longhorn 卷的掛載點建立檔案時，將顯示以下訊息：

/ # cd data
/data # echo test > test
sh: can't create test: I/O error

在相關 pod 或節點主機中執行 dmesg 時，會顯示以下訊息：

[1586907.286218] EXT4-fs (sdc): mounted filesystem with ordered data mode. Opts: (null)
[1587396.152106] EXT4-fs warning (device sdc): ext4_end_bio:323: I/O error 10 writing to inode 12 (offset 0 size 4096 starting block 33026)
[1587403.789877] EXT4-fs error (device sdc): ext4_find_entry:1455: inode #2: comm sh: reading directory lblock 0
[1587404.353594] EXT4-fs warning (device sdc): htree_dirblock_to_tree:994: inode #2: lblock 0: comm ls: error -5 reading directory block
[1587404.353598] EXT4-fs error (device sdc): ext4_journal_check_start:61: Detected aborted journal
[1587404.355087] EXT4-fs (sdc): Remounting filesystem read-only
......

使用 `kubectl -n longhorn-system get event 檢查事件時 | grep ，顯示如下事件：

使用 kubectl -n longhorn-system get event | grep <volume name> 檢查事件時，顯示如下事件：

2m26s       Warning   DetachedUnexpectly       volume/pvc-342edde0-d3f4-47c6-abf6-bf8eeda3c32c               Engine of volume pvc-342edde0-d3f4-47c6-abf6-bf8eeda3c32c dead unexpectedly, reattach the volume

通過執行 kubectl -n longhorn-system logs <longhorn manager pod name> | grep <volume name>，在工作負載執行的節點上檢查 Longhorn manager pod 的日誌時，顯示以下訊息：

time="2021-01-05T11:20:46Z" level=debug msg="Instance handler updated instance pvc-342edde0-d3f4-47c6-abf6-bf8eeda3c32c-e-0fe2dac3 state, old state running, new state error"
time="2021-01-05T11:20:46Z" level=warning msg="Instance pvc-342edde0-d3f4-47c6-abf6-bf8eeda3c32c-e-0fe2dac3 crashed on Instance Manager instance-manager-e-a1fd54e4 at shuo-cluster-0-worker-3, try to get log"
......
time="2021-01-05T11:20:46Z" level=warning msg="Engine of volume dead unexpectedly, reattach the volume" accessMode=rwo controller=longhorn-volume frontend=blockdev node=shuo-cluster-0-worker-3 owner=shuo-cluster-0-worker-3 state=attached volume=pvc-342edde0-d3f4-47c6-abf6-bf8eeda3c32c
......
time="2021-01-05T11:20:46Z" level=info msg="Event(v1.ObjectReference{Kind:\"Volume\", Namespace:\"longhorn-system\", Name:\"pvc-342edde0-d3f4-47c6-abf6-bf8eeda3c32c\", UID:\"69bb0f94-da48-4d15-b861-add435f25d00\", APIVersion:\"longhorn.io/v1beta1\", ResourceVersion:\"7466467\", FieldPath:\"\"}): type: 'Warning' reason: 'DetachedUnexpectly' Engine of volume pvc-342edde0-d3f4-47c6-abf6-bf8eeda3c32c dead unexpectedly, reattach the volume"

失敗原因

一旦 Longhorn 卷意外崩潰，Longhorn 卷的掛載點將失效。那麼就無法通過掛載點讀取或寫入 Longhorn 卷中的資料。

根本原因

引擎崩潰通常是由於失去與每個副本的連線而導致的。 以下是發生這種情況的可能原因：

1. 節點上的 CPU 利用率過高。 如果 Longhorn 引擎沒有足夠的 CPU 資源來處理請求，則請求可能會超時，導致與副本的連線丟失。 您可以參考下面文件，瞭解如何為 Longhorn 例項管理器 Pod 預留適當數量的 CPU 資源。
   • https://longhorn.io/docs/1.1.0/best-practices/#guaranteed-engine-cpu
2. 網路頻寬不夠。通常，如果所有這些卷都執行高密集型工作負載，則 1Gbps 網路將只能為 3 個卷提供服務。
3. 網路延遲相對較高。如果一個節點上同時有多個卷 r/w，最好保證延遲小於 20ms。
4. 網路中斷。它可能導致所有副本斷開連線，然後引擎崩潰。
5. 磁碟效能太低，無法及時完成請求。我們不建議在 Longhorn 系統中使用低 IOPS 磁碟（例如旋轉磁碟）。

自動恢復

對於 v1.1.0 之前的 Longhorn 版本，Longhorn 會嘗試自動重新掛載卷，但它可以處理的場景有限。

從 Longhorn v1.1.0 版本開始，引入了一個新設定“卷意外分離時自動刪除工作負載 Pod(Automatically Delete Workload Pod when The Volume Is Detached Unexpectedly)”，以便 Longhorn 將自動刪除由控制器管理的工作負載 Pod（例如 deployment、statefulset、daemonset 等）。

手動恢復

如果工作負載是一個簡單的 pod，您可以刪除並重新部署 pod。 如果回收策略不是 Retain，請確保相關 PVC 或 PV 未被刪除。否則，一旦相關的 PVC/PV 消失，Longhorn 卷將被刪除。

如果工作負載 Pod 屬於 Deployment/StatefulSet，您可以通過縮減然後擴充套件工作負載副本來重新啟動 Pod。

對於 Longhorn v1.1.0 或更高版本，您可以啟用設定“卷意外分離時自動刪除工作負載 Pod(Automatically Delete Workload Pod when The Volume Is Detached Unexpectedly)”。

其他原因

當相關工作負載仍在使用卷時，使用者意外或手動分離了 Longhorn 卷。

相關資訊

1. 最小資源需求調查和結果：
   • https://github.com/longhorn/longhorn/issues/1691
2. 設定 Automatically Delete Workload Pod when The Volume Is Detached Unexpectedly 的討論
   • https://github.com/longhorn/longhorn/issues/1719

12. volume pvc-xxx not scheduled

適用版本

所有 Longhorn 版本。

症狀

使用 Longhorn Volume 作為 PVC 建立 Pod 時，Pod 無法啟動。

使用 kubectl describe <pod> 檢查錯誤訊息時，會顯示以下訊息：

Warning  FailedAttachVolume  4m29s (x3 over 5m33s)  attachdetach-controller     AttachVolume.Attach failed for volume "pvc-xxx" : rpc error: code = Internal desc = Bad response statusCode [500]. Status [500 Internal Server Error]. Body: [message=unable to attach volume pvc-xxx to node-xxx: volume pvc-xxx not scheduled, code=Server Error, detail=] from [http://longhorn-backend:9500/v1/volumes/pvc-xxx?action=attach]

在上面的錯誤中注意到 Longhorn 返回的訊息：

unable to attach volume pvc-xxx to node-xxx: volume pvc-xxx not scheduled

詳情

這是由於 Longhorn 在不同節點上找不到足夠的空間來儲存卷的資料，導致卷排程失敗。

最常見的原因

對於 Longhorn v1.0.x，預設 Longhorn 安裝有以下設定：

1. Node Level Soft Anti-affinity: false
2. 預設 StorageClass longhorn 的副本計數設定為 3。

這意味著 Longhorn 將始終嘗試在三個不同節點上為三個副本分配足夠的空間。

如果無法滿足此要求，例如 由於叢集中的節點少於 3 個，卷排程將失敗。

解決方案

如果是這種情況，您可以：

1. 要麼將節點級軟反親和性(Node Level Soft Anti-affinity)設定為 true。
2. 或者，建立一個副本數設定為 1 或 2 的新 StorageClass。
3. 或者，向叢集新增更多節點。

其他原因

有關排程策略的詳細說明，請參閱 Longhorn 文件中的排程部分。

• https://longhorn.io/docs/1.0.2/volumes-and-nodes/scheduling/

相關資訊

從 Longhorn v1.1.0 開始，我們將引入一個新設定 Allow Volume Creation With Degraded Availability（預設為 true），以幫助處理較小叢集上的用例。

• https://github.com/longhorn/longhorn/issues/1701