博彩游戏推荐网站博彩平台网页加载速度评价[[429654]] 目次 当 Longhorn 卷文献系统损坏时，Pod 卡在 creating 景况 非轨范 Kubelet 目次 Longhorn 默许设立不保留 辨认和附加卷后，Recurring job 不会创建新 job 使用 Traefik 2.x 算作 ingress controller 使用 cURL 创建 Support Bundle Longhorn RWX 分享挂载通盘权在 consumer Pod 中自满为 nobody 由于节点上的多旅途，MountVolume.SetUp for volume 失败 Longhorn-UI:WebSocket 执手技艺出错:不测反映代码:200 #2265 Longhorn 卷需要很永劫期智商完成装配 volume readonly or I/O error 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 无法自动栽培此问题。发生这种情况时，您需要手动处分此问题。

处分决策

寻找迹象：

如若卷未处于 error 景况，则 Longhorn 卷内的文献系统可能因外部原因而损坏。 从 Longhorn UI 查验卷是否处于 error 景况。 查验 Longhorn 管制器 pod 日记以了解系统损坏作假音问。 缩减 workload。 从 UI 将卷附加到任何一个 node。 SSH 参加 node。 在 /dev/longhorn/ 下找到 Longhorn 卷对应的块开垦。 运行 fsck 来栽培文献系统。 从 UI 辨认卷。 扩大 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 -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 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。

欧博入口 处分决策

泄漏 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 

运行以下剧本以创建和下载 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 

找到程度。使用 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       

处分决策

按照以下门径防患多旅途督察程度(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 通过辨认前端和后端来救助单页应用花样。

成果，/ 鼎新为 /#/。

之后，输出音问应一样于以下本色：

博彩游戏推荐网站

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" 

处分决策 铲除浏览器缓存。 从 /# 打听/再行储藏 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 时才会发生此问题，如下所示：

www.imperialsportspro.com

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

原因

默许情况下，当看到 fsGroup 字段时，每次挂载卷时，Kubernetes 王人会对卷内的通盘文献和目次递归调用 chown() 和 chmod()。即使卷的组通盘权也曾与申请的 fsGroup 匹配，也会发生这种情况，况兼关于包含大批小文献的较大卷来说可能迥殊竭力，这会导致 pod 启动需要很永劫期。

处分决策

在 Kubernetes v1.19.x 及之前版块中莫得处分此问题的花样。

皇冠hg86a

自从版块 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 查验事件时，自满如下事件：

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 | grep ，在职责负载运行的节点上查验 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 卷中的数据。

皇冠客服飞机：@seo3687

压根原因

引擎崩溃时时是由于失去与每个副本的相接而导致的。以下是发生这种情况的可能原因：

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 卷。

琢磨信息

最小资源需求侦探和成果： https://github.com/longhorn/longhorn/issues/1691 设立 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 查验作假音问时，会自满以下音问：

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 装配有以下设立：

承女士说，自己是学医的，见状后立马到卫生间用肥皂冲洗涂抹，并为自己涂上药。随后去医院就诊。

Node Level Soft Anti-affinity: false 默许 StorageClass longhorn 的副本计数设立为 3。

这意味着 Longhorn 将永恒尝试在三个不同节点上为三个副分内派满盈的空间。

如若无法知足此要求，举例 由于集群中的节点少于 3 个，卷出动将失败。

处分决策

如若是这种情况，您不错：

要么将节点级软反亲和性(Node Level Soft Anti-affinity)设立为 true。 或者，创建一个副本数设立为 1 或 2 的新 StorageClass。 或者，向集群添加更多节点。 其他原因

琢磨出动战略的翔实证据，请参阅 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