成人免费xxxxx在线视频软件_久久精品久久久_亚洲国产精品久久久_天天色天天色_亚洲人成一区_欧美一级欧美三级在线观看

Longhorn 云原生容器分布式存儲(chǔ) - 故障排除指南

作者： 為少
云計(jì)算 存儲(chǔ)軟件 云原生 分布式
當(dāng) Longhorn 卷的文件系統(tǒng)損壞時(shí)，Longhorn 無法重新掛載該卷。因此，workload 無法重新啟動(dòng)。

[[429654]]

目錄

  1. 當(dāng) Longhorn 卷文件系統(tǒng)損壞時(shí)，Pod 卡在 creating 狀態(tài)
  2. 非標(biāo)準(zhǔn) Kubelet 目錄
  3. Longhorn 默認(rèn)設(shè)置不保留
  4. 分離和附加卷后，Recurring job 不會(huì)創(chuàng)建新 job
  5. 使用 Traefik 2.x 作為 ingress controller
  6. 使用 cURL 創(chuàng)建 Support Bundle
  7. Longhorn RWX 共享掛載所有權(quán)在 consumer Pod 中顯示為 nobody
  8. 由于節(jié)點(diǎn)上的多路徑，MountVolume.SetUp for volume 失敗
  9. Longhorn-UI:WebSocket 握手期間出錯(cuò):意外響應(yīng)代碼:200 #2265
  10. Longhorn 卷需要很長時(shí)間才能完成安裝
  11. volume readonly or I/O error
  12. volume pvc-xxx not scheduled

1. 當(dāng) Longhorn 卷文件系統(tǒng)損壞時(shí)，Pod 卡在 creating 狀態(tài)

適用版本

所有 Longhorn 版本。

癥狀

Pod 停留在容器 Creating 中，日志中有錯(cuò)誤。

  1. 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 
  2. 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. 
  3. /dev/longhorn/pvc-bb8582d5-eaa4-479a-b4bf-328d1ef1785d contains a file system with errors, check forced. 
  4. /dev/longhorn/pvc-bb8582d5-eaa4-479a-b4bf-328d1ef1785d: Inodes that were part of a corrupted orphan linked list found.   
  5.  
  6. /dev/longhorn/pvc-bb8582d5-eaa4-479a-b4bf-328d1ef1785d: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY. 
  7.   (i.e., without -a or -p options) 

原因

當(dāng) Longhorn 卷的文件系統(tǒng)損壞時(shí)，Longhorn 無法重新掛載該卷。因此，workload 無法重新啟動(dòng)。

Longhorn 無法自動(dòng)修復(fù)此問題。發(fā)生這種情況時(shí)，您需要手動(dòng)解決此問題。

解決方案

尋找跡象：

  • 如果卷未處于 error 狀態(tài)，則 Longhorn 卷內(nèi)的文件系統(tǒng)可能因外部原因而損壞。
    • 從 Longhorn UI 檢查卷是否處于 error 狀態(tài)。
    • 檢查 Longhorn 管理器 pod 日志以了解系統(tǒng)損壞錯(cuò)誤消息。
  • 縮減 workload。
  • 從 UI 將卷附加到任何一個(gè) node。
  • SSH 進(jìn)入 node。
  • 在 /dev/longhorn/ 下找到 Longhorn 卷對應(yīng)的塊設(shè)備。
  • 運(yùn)行 fsck 來修復(fù)文件系統(tǒng)。
  • 從 UI 分離卷。
  • 擴(kuò)大 workload。

2. 非標(biāo)準(zhǔn) Kubelet 目錄

適用版本

所有 Longhorn 版本。

癥狀

當(dāng) Kubernetes 集群使用非標(biāo)準(zhǔn)的 Kubelet 目錄時(shí)，longhorn-csi-plugin 無法啟動(dòng)。

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

原因

由于 Longhorn 無法檢測到 Kubelet 的根目錄設(shè)置在哪里。

解決方案

Longhorn 通過 longhorn.yaml 安裝：

取消注釋并編輯：

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

Longhorn 通過 Rancher - App 安裝：

  • 點(diǎn)擊 Customize Default Settings 設(shè)置 Kubelet 根目錄
  • 相關(guān)信息
  • Longhorn issue：

https://github.com/longhorn/longhorn/issues/2537

更多信息可以在 OS/Distro 特定配置 下的故障排除部分找到。

3. Longhorn 默認(rèn)設(shè)置不保留

適用版本

所有 Longhorn 版本。

癥狀

  • 通過 helm 或 Rancher App 升級 Longhorn 系統(tǒng)時(shí)，修改后的 Longhorn 默認(rèn)設(shè)置不會(huì)保留。
  • 通過 kubectl -n longhorn-system edit configmap longhorn-default-setting 修改默認(rèn)設(shè)置時(shí)，修改不會(huì)應(yīng)用于 Longhorn 系統(tǒng)。

背景

此默認(rèn)設(shè)置僅適用于尚未部署的 Longhorn 系統(tǒng)。它對現(xiàn)有的 Longhorn 系統(tǒng)沒有影響。

解決方案

我們建議使用 Longhorn UI 更改現(xiàn)有集群上的 Longhorn 設(shè)置。

您也可以使用 kubectl，但請注意這將繞過 Longhorn 后端驗(yàn)證。

kubectl edit settings -n longhorn-system

4. 分離和附加卷后，Recurring job 不會(huì)創(chuàng)建新 job

適用版本

所有 Longhorn 版本。

癥狀

當(dāng)卷被分離很長時(shí)間后被附加時(shí)，循環(huán)作業(yè)不會(huì)創(chuàng)建新 job。

根據(jù) Kubernetes CronJob 限制：

  • https://kubernetes.io/docs/concepts/workloads/controllers/cron-jobs/#cron-job-limitations
  1. 對于每個(gè) CronJob，CronJob 控制器會(huì)檢查它在從上次調(diào)度時(shí)間到現(xiàn)在的持續(xù)時(shí)間內(nèi)錯(cuò)過了多少個(gè) schedule。如果有超過 100 個(gè)錯(cuò)過的 schedule，則它不會(huì)啟動(dòng) job 并記錄 error 
  2.  
  3. Cannot determine if job needs to be started. Too many missed start time (> 100). Set or decrease .spec.startingDeadlineSeconds or check clock skew. 

例如，如果 recurring backup job 設(shè)置為每分鐘運(yùn)行一次，則容限為 100 分鐘。

解決方案

直接刪除卡住的 cronjob，讓 Longhorn 重新創(chuàng)建。

  1. ip-172-30-0-211:/home/ec2-user # kubectl -n longhorn-system get cronjobs 
  2. NAME                                                  SCHEDULE    SUSPEND   ACTIVE   LAST SCHEDULE   AGE 
  3. pvc-394e6006-9c34-47da-bf27-2286ae669be1-c-ptl8l1-c   * * * * *   False     1        47s             2m23s 
  4.  
  5. ip-172-30-0-211:/home/ec2-user # kubectl -n longhorn-system delete cronjobs/pvc-394e6006-9c34-47da-bf27-2286ae669be1-c-ptl8l1-c 
  6. cronjob.batch "pvc-394e6006-9c34-47da-bf27-2286ae669be1-c-ptl8l1-c" deleted 
  7.  
  8. ip-172-30-0-211:/home/ec2-user # kubectl -n longhorn-system get cronjobs 
  9. No resources found in longhorn-system namespace. 
  10.  
  11. ip-172-30-0-211:/home/ec2-user # sleep 60 
  12.  
  13. ip-172-30-0-211:/home/ec2-user # kubectl -n longhorn-system get cronjobs 
  14. NAME                                                  SCHEDULE    SUSPEND   ACTIVE   LAST SCHEDULE   AGE 
  15. pvc-394e6006-9c34-47da-bf27-2286ae669be1-c-ptl8l1-c   * * * * *   False     1        2s             3m21s 

相關(guān)信息

  • 相關(guān) Longhorn issue：
    • https://github.com/longhorn/longhorn/issues/2513

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

適用版本

所有 Longhorn 版本。

癥狀

Longhorn GUI 前端 API 請求有時(shí)無法到達(dá) longhorn-manager 后端。

原因

API 請求會(huì)改變 HTTPS/WSS 之間的協(xié)議，而這種改變會(huì)導(dǎo)致 CORS 問題。

解決方案

Traefik 2.x ingress controller 沒有設(shè)置 WebSocket header。

1.將以下中間件添加到 Longhorn 前端 service 的路由中。

  1. apiVersion: traefik.containo.us/v1alpha1 
  2. kind: Middleware 
  3. metadata: 
  4.   name: svc-longhorn-headers 
  5.   namespace: longhorn-system 
  6. spec: 
  7.   headers: 
  8.     customRequestHeaders: 
  9.       X-Forwarded-Proto: "https" 

2.更新 ingress 以使用中間件規(guī)則。

  1. apiVersion: networking.k8s.io/v1beta1 
  2. kind: Ingress 
  3. metadata: 
  4.   name: longhorn-ingress 
  5.   namespace: longhorn-system 
  6.   annotations: 
  7.     traefik.ingress.kubernetes.io/router.entrypoints: websecure 
  8.     traefik.ingress.kubernetes.io/router.tls: "true"        
  9.     traefik.ingress.kubernetes.io/router.middlewares: longhorn-system-svc-longhorn-headers@kubernetescrd 
  10. spec: 
  11.   rules: 
  12.   - http: 
  13.       paths: 
  14.       - path: / 
  15.         backend: 
  16.           serviceName: longhorn-frontend 
  17.           servicePort: 80 

相關(guān)信息

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

6. 使用 cURL 創(chuàng)建 Support Bundle

適用版本

所有 Longhorn 版本。

癥狀

無法使用 Web 瀏覽器創(chuàng)建 support bundle。

解決方案

暴露 Longhorn 后端服務(wù)。下面是一個(gè)使用 NodePort 的示例，如果設(shè)置了負(fù)載均衡器，您也可以通過負(fù)載均衡器暴露。

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

運(yùn)行以下腳本以創(chuàng)建和下載 support bundle。您需要替換 BACKEND_URL、ISSUE_URL、ISSUE_DESCRIPTION。

  1. # Replace this block ====> 
  2. BACKEND_URL="18.141.237.97:32595" 
  3.  
  4. ISSUE_URL="https://github.com/longhorn/longhorn/issues/dummy" 
  5. ISSUE_DESCRIPTION="dummy description" 
  6. # <==== Replace this block 
  7.  
  8. # Request to create the support bundle 
  9. REQUEST_SUPPORT_BUNDLE=$( curl -sSX POST -H 'Content-Type: application/json' -d '{ "issueURL": "'"${ISSUE_URL}"'", "description": "'"${ISSUE_DESCRIPTION}"'" }' http://${BACKEND_URL}/v1/supportbundles ) 
  10.  
  11. ID=$( jq -r '.id' <<< ${REQUEST_SUPPORT_BUNDLE} ) 
  12. SUPPORT_BUNDLE_NAME=$( jq -r '.name' <<< ${REQUEST_SUPPORT_BUNDLE} ) 
  13. echo "Creating support bundle ${SUPPORT_BUNDLE_NAME} on Node ${ID}" 
  14.  
  15. while [ $(curl -sSX GET http://${BACKEND_URL}/v1/supportbundles/${ID}/${SUPPORT_BUNDLE_NAME} | jq -r '.state' ) != "ReadyForDownload" ]; do 
  16.   echo "Progress: $(curl -sSX GET http://${BACKEND_URL}/v1/supportbundles/${ID}/${SUPPORT_BUNDLE_NAME} | jq -r '.progressPercentage' )%" 
  17.   sleep 1s 
  18. done 
  19.  
  20. curl -i -X GET http://${BACKEND_URL}/v1/supportbundles/${ID}/${SUPPORT_BUNDLE_NAME}/download --output /tmp/${SUPPORT_BUNDLE_NAME}.zip 
  21. echo "Downloaded support bundle to /tmp/${SUPPORT_BUNDLE_NAME}.zip" 

相關(guān)信息

  • 相關(guān)的 Longhorn comment:
    • https://github.com/longhorn/longhorn/issues/2118#issuecomment-748099002

7. Longhorn RWX 共享掛載所有權(quán)在 consumer Pod 中顯示為 nobody

適用版本

Longhorn 版本 = v1.1.0

癥狀

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

  1. root@ip-172-30-0-139:/home/ubuntu# kubectl exec -it rwx-test-2pml2 -- ls -l /data 
  2. total 16 
  3. drwx------ 2 nobody 42949672 16384 Mar 31 04:16 lost+found 
  4.  
  5. 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 
  6. total 16 
  7. drwx------ 2 root root 16384 Mar 31 04:42 lost+found 

背景

share-manager 中的 nfs-ganesha 使用 idmapd 進(jìn)行 NFSv4 ID 映射，并設(shè)置為使用 localdomain 作為其導(dǎo)出域。

原因

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

讓我們看一個(gè)例子：

我們假設(shè)您沒有修改集群主機(jī)上的 /etc/idmapd.conf。對于某些操作系統(tǒng)，Domain = localdomain 被注釋掉，默認(rèn)情況下它使用 FQDN 減去 hostname。

當(dāng)主機(jī)名為 ip-172-30-0-139 且 FQDN 為 ip-172-30-0-139.lan 時(shí)，主機(jī) idmapd 將使用 lan 作為 Domain。

  1. root@ip-172-30-0-139:/home/ubuntu# hostname 
  2. ip-172-30-0-139 
  3.  
  4. root@ip-172-30-0-139:/home/ubuntu# hostname -f 
  5. ip-172-30-0-139.lan 

這導(dǎo)致 share-manager(localdomain) 和集群主機(jī)(lan)之間的域不匹配。因此觸發(fā)文件權(quán)限更改為使用 nobody。

  1. [Mapping] section variables 
  2.  
  3. Nobody-User 
  4. Local user name to be used when a mapping cannot be completed. 
  5. Nobody-Group 
  6. Local group name to be used when a mapping cannot be completed. 

解決方案

1.在所有群集主機(jī)上的 /etc/idmapd.conf 中取消注釋或添加 Domain = localdomain。

  1. root@ip-172-30-0-139:~# cat /etc/idmapd.conf  
  2. [General] 
  3.  
  4. Verbosity = 0 
  5. Pipefs-Directory = /run/rpc_pipefs 
  6. # set your own domain here, if it differs from FQDN minus hostname 
  7. Domain = localdomain 
  8.  
  9. [Mapping] 
  10.  
  11. Nobody-User = nobody 
  12. Nobody-Group = nogroup 

2.刪除并重新創(chuàng)建 RWX 資源堆棧(pvc + pod)。

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

相關(guān)信息

  • 相關(guān)的 Longhorn issue:
    • https://github.com/longhorn/longhorn/issues/2357
  • 相關(guān)的 idmapd.conf 文檔：
    • https://linux.die.net/man/5/idmapd.conf

8. 由于節(jié)點(diǎn)上的多路徑，MountVolume.SetUp for volume 失敗

適用版本

所有 Longhorn 版本。

癥狀

帶有卷的 pod 未啟動(dòng)并在 longhorn-csi-plugin 中遇到錯(cuò)誤消息：

  1. 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\"}" 
  2. 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\" > " 
  3. E0416 08:49:27.567704 1 mount_linux.go:143] Mount failed: exit status 32 
  4. Mounting command: mount 
  5. 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 
  6. 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. 
  7. 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) 
  8. time="2020-04-16T08:49:27Z" level=error msg="GRPC error: rpc error: code = Internal desc = exit status 1" 

詳情

這是由于多路徑為任何符合條件的設(shè)備路徑創(chuàng)建了多路徑設(shè)備，包括未明確列入黑名單的每個(gè) Longhorn 卷設(shè)備。

故障排除

1.查找 Longhorn 設(shè)備的 major:minor 編號。在節(jié)點(diǎn)上，嘗試 ls -l /dev/longhorn/。major:minor 編號將顯示在設(shè)備名稱前，例如 8、32。

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

2.查找 Linux 為相同的 major:minor 編號生成的設(shè)備是什么。使用 ls -l /dev 并找到相同 major:minor 編號的設(shè)備，例如 /dev/sde。

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

找到進(jìn)程。使用 lsof 獲取正在使用的文件處理程序列表，然后使用 grep 獲取設(shè)備名稱(例如 sde 或 /dev/longhorn/xxx。您應(yīng)該在那里找到一個(gè)。

  1. lsof | grep sdc 
  2. multipath 514292                              root    8r      BLK               8,32        0t0        534 /dev/sdc 
  3. multipath 514292 514297 multipath             root    8r      BLK               8,32        0t0        534 /dev/sdc 
  4. multipath 514292 514299 multipath             root    8r      BLK               8,32        0t0        534 /dev/sdc 
  5. multipath 514292 514300 multipath             root    8r      BLK               8,32        0t0        534 /dev/sdc 
  6. multipath 514292 514301 multipath             root    8r      BLK               8,32        0t0        534 /dev/sdc 
  7. multipath 514292 514302 multipath             root    8r      BLK               8,32        0t0        534 /dev/sdc 
  8. multipath 514292 514304 multipath             root    8r      BLK       

解決方案

按照以下步驟防止多路徑守護(hù)進(jìn)程(multipath daemon)添加由 Longhorn 創(chuàng)建的額外塊設(shè)備。

首先使用 lsblk 檢查 Longhorn 創(chuàng)建的設(shè)備：

  1. root@localhost:~# lsblk 
  2. NAME MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT 
  3. sda    8:0    0 79.5G  0 disk / 
  4. sdb    8:16   0  512M  0 disk [SWAP] 
  5. 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 
  6. 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 
  7. 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 
  8. 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 
  9. 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 
  10. 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 
  11. 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 設(shè)備名稱以 /dev/sd[x] 開頭

  • 如果不存在，則創(chuàng)建默認(rèn)配置文件 /etc/multipath.conf
  • 將以下行添加到黑名單部分 devnode "^sd[a-z0-9]+"
  1. blacklist { 
  2.     devnode "^sd[a-z0-9]+" 
  3. } 
  • 重啟多路徑服務(wù)
  1. systemctl restart multipathd.service 
  • 驗(yàn)證是否應(yīng)用了配置
  1. multipath -t 

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

相關(guān)信息

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

9. Longhorn-UI:WebSocket 握手期間出錯(cuò):意外響應(yīng)代碼:200 #2265

適用版本

現(xiàn)有 Longhorn 版本 < v1.1.0 升級到 Longhorn >= v1.1.0。

癥狀

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

入口消息：

  1. {"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 消息：

  1. 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" 
  2. 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" 
  3. 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" 
  4. 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" 
  5. 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" 
  6. 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 重新構(gòu)建了 UI 以使用 hash history，原因有兩個(gè)：

  • 支持 Longhorn UI 路由到不同路徑。例如，/longhorn/#/dashboard
  • 通過分離前端和后端來支持單頁應(yīng)用程序。

結(jié)果，/ 更改為 /#/。

之后，輸出消息應(yīng)類似于以下內(nèi)容：

Ingress 消息應(yīng)該沒有 websocket 錯(cuò)誤：

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

Longhorn UI 消息：

使用 Ingress：

  1. 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" 
  2. 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" 
  3. 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" 
  4. 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" 
  5. 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" 
  6. 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：

  1. 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" 
  2. 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" 
  3. 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" 
  4. 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" 
  5. 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" 
  6. 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" 
  7. 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" 
  8. 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。

相關(guān)信息

  • 相關(guān) Longhorn issue:
    • https://github.com/longhorn/longhorn/issues/2265
    • https://github.com/longhorn/longhorn/issues/1660

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

適用版本

所有 Longhorn 版本。

癥狀

啟動(dòng)使用 Longhorn 卷的工作負(fù)載 pod 時(shí)，Longhorn UI 顯示 Longhorn 卷連接很快，但卷完成掛載和工作負(fù)載能夠啟動(dòng)需要很長時(shí)間。

僅當(dāng) Longhorn 卷具有許多文件/目錄并且在工作負(fù)載 pod 中設(shè)置 securityContext.fsGroup 時(shí)才會(huì)發(fā)生此問題，如下所示：

  1. spec: 
  2.   securityContext: 
  3.     runAsUser: 1000 
  4.     runAsGroup: 3000 
  5.     fsGroup: 2000 

原因

默認(rèn)情況下，當(dāng)看到 fsGroup 字段時(shí)，每次掛載卷時(shí)，Kubernetes 都會(huì)對卷內(nèi)的所有文件和目錄遞歸調(diào)用 chown() 和 chmod()。即使卷的組所有權(quán)已經(jīng)與請求的 fsGroup 匹配，也會(huì)發(fā)生這種情況，并且對于包含大量小文件的較大卷來說可能非常昂貴，這會(huì)導(dǎo)致 pod 啟動(dòng)需要很長時(shí)間。

解決方案

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

自從版本 1.20.x 以來，Kubernetes 引入了一個(gè)新的 beta 特性：字段 fsGroupChangePolicy。即，

  1. spec: 
  2.   securityContext: 
  3.     runAsUser: 1000 
  4.     runAsGroup: 3000 
  5.     fsGroup: 2000 
  6.     fsGroupChangePolicy: "OnRootMismatch" 

當(dāng) fsGroupChangePolicy 設(shè)置為 OnRootMismatch 時(shí)，如果卷的根已具有正確的權(quán)限，則將跳過遞歸權(quán)限和所有權(quán)更改。這意味著，如果用戶在 pod 啟動(dòng)之間不更改 pod.spec.securityContext.fsGroup，K8s 只需檢查根目錄的權(quán)限和所有權(quán)，與總是遞歸地更改卷的所有權(quán)和權(quán)限相比，裝載過程將快得多。

相關(guān)信息

  • 相關(guān) Longhorn issue:
    • https://github.com/longhorn/longhorn/issues/2131
  • 相關(guān) 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 版本。

癥狀

當(dāng)應(yīng)用程序?qū)?shù)據(jù)寫入現(xiàn)有文件或在 Longhorn 卷的掛載點(diǎn)創(chuàng)建文件時(shí)，將顯示以下消息：

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

在相關(guān) pod 或節(jié)點(diǎn)主機(jī)中運(yùn)行 dmesg 時(shí)，會(huì)顯示以下消息：

  1. [1586907.286218] EXT4-fs (sdc): mounted filesystem with ordered data mode. Opts: (null) 
  2. [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) 
  3. [1587403.789877] EXT4-fs error (device sdc): ext4_find_entry:1455: inode #2: comm sh: reading directory lblock 0 
  4. [1587404.353594] EXT4-fs warning (device sdc): htree_dirblock_to_tree:994: inode #2: lblock 0: comm ls: error -5 reading directory block 
  5. [1587404.353598] EXT4-fs error (device sdc): ext4_journal_check_start:61: Detected aborted journal 
  6. [1587404.355087] EXT4-fs (sdc): Remounting filesystem read-only 
  7. ...... 

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

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

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

通過運(yùn)行 kubectl -n longhorn-system logs | grep ，在工作負(fù)載運(yùn)行的節(jié)點(diǎn)上檢查 Longhorn manager pod 的日志時(shí)，顯示以下消息：

  1. 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" 
  2. 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" 
  3. ...... 
  4. 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 
  5. ...... 
  6. 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 卷的掛載點(diǎn)將失效。那么就無法通過掛載點(diǎn)讀取或?qū)懭?Longhorn 卷中的數(shù)據(jù)。

根本原因

引擎崩潰通常是由于失去與每個(gè)副本的連接而導(dǎo)致的。以下是發(fā)生這種情況的可能原因：

1.節(jié)點(diǎn)上的 CPU 利用率過高。如果 Longhorn 引擎沒有足夠的 CPU 資源來處理請求，則請求可能會(huì)超時(shí)，導(dǎo)致與副本的連接丟失。您可以參考下面文檔，了解如何為 Longhorn 實(shí)例管理器 Pod 預(yù)留適當(dāng)數(shù)量的 CPU 資源。

https://longhorn.io/docs/1.1.0/best-practices/#guaranteed-engine-cpu

2.網(wǎng)絡(luò)帶寬不夠。通常，如果所有這些卷都運(yùn)行高密集型工作負(fù)載，則 1Gbps 網(wǎng)絡(luò)將只能為 3 個(gè)卷提供服務(wù)。

3.網(wǎng)絡(luò)延遲相對較高。如果一個(gè)節(jié)點(diǎn)上同時(shí)有多個(gè)卷 r/w，最好保證延遲小于 20ms。

4.網(wǎng)絡(luò)中斷。它可能導(dǎo)致所有副本斷開連接，然后引擎崩潰。

5.磁盤性能太低，無法及時(shí)完成請求。我們不建議在 Longhorn 系統(tǒng)中使用低 IOPS 磁盤(例如旋轉(zhuǎn)磁盤)。

自動(dòng)恢復(fù)

對于 v1.1.0 之前的 Longhorn 版本，Longhorn 會(huì)嘗試自動(dòng)重新掛載卷，但它可以處理的場景有限。

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

手動(dòng)恢復(fù)

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

如果工作負(fù)載 Pod 屬于 Deployment/StatefulSet，您可以通過縮減然后擴(kuò)展工作負(fù)載副本來重新啟動(dòng) Pod。

對于 Longhorn v1.1.0 或更高版本，您可以啟用設(shè)置“卷意外分離時(shí)自動(dòng)刪除工作負(fù)載 Pod(Automatically Delete Workload Pod when The Volume Is Detached Unexpectedly)”。

其他原因

當(dāng)相關(guān)工作負(fù)載仍在使用卷時(shí)，用戶意外或手動(dòng)分離了 Longhorn 卷。

相關(guān)信息

  • 最小資源需求調(diào)查和結(jié)果：
    • https://github.com/longhorn/longhorn/issues/1691
  • 設(shè)置 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 創(chuàng)建 Pod 時(shí)，Pod 無法啟動(dòng)。

使用 kubectl describe 檢查錯(cuò)誤消息時(shí)，會(huì)顯示以下消息： 

  1. 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] 

在上面的錯(cuò)誤中注意到 Longhorn 返回的消息：

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

詳情

這是由于 Longhorn 在不同節(jié)點(diǎn)上找不到足夠的空間來存儲(chǔ)卷的數(shù)據(jù)，導(dǎo)致卷調(diào)度失敗。

最常見的原因

對于 Longhorn v1.0.x，默認(rèn) Longhorn 安裝有以下設(shè)置：

  1. Node Level Soft Anti-affinity: false
  2. 默認(rèn) StorageClass longhorn 的副本計(jì)數(shù)設(shè)置為 3。

這意味著 Longhorn 將始終嘗試在三個(gè)不同節(jié)點(diǎn)上為三個(gè)副本分配足夠的空間。

如果無法滿足此要求，例如 由于集群中的節(jié)點(diǎn)少于 3 個(gè)，卷調(diào)度將失敗。

解決方案

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

  1. 要么將節(jié)點(diǎn)級軟反親和性(Node Level Soft Anti-affinity)設(shè)置為 true。
  2. 或者，創(chuàng)建一個(gè)副本數(shù)設(shè)置為 1 或 2 的新 StorageClass。
  3. 或者，向集群添加更多節(jié)點(diǎn)。

其他原因

有關(guān)調(diào)度策略的詳細(xì)說明，請參閱 Longhorn 文檔中的調(diào)度部分。

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

相關(guān)信息

從 Longhorn v1.1.0 開始，我們將引入一個(gè)新設(shè)置 Allow Volume Creation With Degraded Availability(默認(rèn)為 true)，以幫助處理較小集群上的用例。

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

 

責(zé)任編輯：武曉燕 來源： 黑客下午茶
云原生分布式存儲(chǔ)
相關(guān)推薦

2021-09-03 05:00:28

分布式存儲(chǔ)云原生

2021-08-29 23:53:32

存儲(chǔ)Air Gap安裝

2021-08-17 00:24:38

塊存儲(chǔ)云原生分布式

2021-08-26 00:23:14

分布式存儲(chǔ)高可用

2021-08-24 05:02:34

云原生容器分布式

2022-02-21 10:17:33

Rancher開源云原生

2021-08-25 05:05:26

存儲(chǔ) 備份恢復(fù)

2021-08-26 23:54:46

分布式存儲(chǔ)負(fù)載

2021-08-28 05:04:19

存儲(chǔ)云原生分布式

2021-08-17 12:36:21

Longhorn云原生存儲(chǔ)

2020-08-24 07:08:37

分布式云云遷移云計(jì)算

2021-08-18 14:33:53

存儲(chǔ)云原生容器

2019-04-30 09:17:31

Ceph存儲(chǔ)OSD

2023-09-14 15:38:55

云原生分布式架構(gòu)

2022-10-10 17:21:50

固態(tài)硬盤分布式云存儲(chǔ)

2017-10-27 08:40:44

分布式存儲(chǔ)剪枝系統(tǒng)

2021-10-13 10:24:29

云計(jì)算首席信息官分布式云

2020-03-03 10:47:47

LinuxSystemdDocker

2022-09-15 21:04:20

JuiceFS云原生
點(diǎn)贊
收藏

51CTO技術(shù)棧公眾號

主站蜘蛛池模板： 亚洲人成网亚洲欧洲无码 | 成人午夜毛片 | 日韩午夜网站 | 日韩综合网 | 拍拍无遮挡人做人爱视频免费观看 | 亚洲国产成人精品女人久久久 | 91精品久久久久久久久 | 天堂一区二区三区四区 | 色婷婷av777 av免费网站在线 | 男人阁久久 | 亚洲国产精品人人爽夜夜爽 | 久久久国产一区 | 亚洲一区二区电影在线观看 | 久久精品小视频 | 亚洲色欲色欲www | 日韩精品二区 | 91麻豆久久久 | 狠狠操天天干 | 亚洲综合色自拍一区 | 日韩成人 | 国产 欧美 日韩 一区 | 香蕉婷婷| 91精品在线看 | 女同久久 | 日韩国产高清在线观看 | 久久精品成人 | 激情网站 | 天堂在线中文字幕 | 在线色网站 | 欧美精品在线视频 | 欧美mv日韩mv国产网站91进入 | 成人午夜毛片 | 国产精品亚洲一区 | 日韩欧美国产一区二区 | 欧美激情亚洲激情 | 亚洲精品不卡 | 成人深夜福利 | 可以免费观看的av片 | 成人自拍视频网站 | 国产激情偷乱视频一区二区三区 | 国产午夜精品一区二区三区嫩草 |