摘要：對(duì)于節(jié)點(diǎn)已經(jīng)登陸不了的情況，如果希望快速恢復(fù)可以在控制臺(tái)找到對(duì)應(yīng)主機(jī)斷電重啟。與綁定完成，插件完成后續(xù)的掛載和等工作。

UK8S 人工支持

對(duì)于使用 UK8S 遇到的本文檔未涉及的問題，如果需要人工支持，請(qǐng)?zhí)砑酉旅婀€信任，并提供主機(jī)的 uhost-id

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDGIFVUtrp+jAnIu1fBvyLx/4L4GNsX+6v8RodxM+t3G7gCgaG+kHqs1xkLBWQNNMVQz2c/vA1gMNYASnvK/aQJmI9NxuOoaoqbL/yrZ58caJG82TrDKGgByvAYcT5yJkJqGRuLlF3XL1p2C0P8nxf2dzfjQgy5LGvZ1awEsIeoSdEuicaxFoxkxzTH/OM2WSLuJ+VbFg8Xl0j3F5kP9sT/no1Gau15zSHxQmjmpGJSjiTpjSBCm4sMaJQ0upruK8RuuLAzGwNw8qRXJ4qY7Tvg36lu39KHwZ22w/VZT1cNZq1mQXvsR54Piaix163YoXfS7jke6j8L6Nm2xtY4inqd uk8s-tech-support

為什么我的容器一起來就退出了？

1. 查看容器log，排查異常重啟的原因
2. pod是否正確設(shè)置了啟動(dòng)命令，啟動(dòng)命令可以在制作鏡像時(shí)指定，也可以在pod配置中指定
3. 啟動(dòng)命令必須保持在前臺(tái)運(yùn)行，否則k8s會(huì)認(rèn)為pod已經(jīng)結(jié)束，并重啟pod。

Docker 如何調(diào)整日志等級(jí)

1. 修改/etc/docker/daemon.json 文件，增加一行配置"debug": true
2. systemctl reload docker 加載配置，查看日志
3. 如果不再需要查看詳細(xì)日志，刪除debug配置，重新reload docker即可

為什么節(jié)點(diǎn)已經(jīng)異常了，但是 Pod 還處在 Running 狀態(tài)

1. 這是由于k8s的狀態(tài)保護(hù)造成的，在節(jié)點(diǎn)較少或異常節(jié)點(diǎn)很多的情況下很容易出現(xiàn)
2. 具體可以查看文檔 https://kubernetes.io/zh/docs/concepts/architecture/nodes/#reliability

節(jié)點(diǎn)宕機(jī)了 Pod 一直卡在 Termnating 怎么辦

1. 節(jié)點(diǎn)宕機(jī)超過一定時(shí)間后（一般為 5 分鐘），k8s 會(huì)嘗試驅(qū)逐 pod，導(dǎo)致 pod 變?yōu)?Termnating 狀態(tài)
2. 由于此時(shí) kubelet 無法執(zhí)行刪除pod的一系列操作，pod 會(huì)一直卡在 Termnating
3. 類型為 daemonset 的 pod，默認(rèn)在每個(gè)節(jié)點(diǎn)都有調(diào)度，因此 pod 宕機(jī)不需要考慮此種類型 pod，k8s 也默認(rèn)不會(huì)驅(qū)逐該類型的 pod
4. 類型為 depolyment 和 replicaset 的 pod，當(dāng) pod 卡在 termanting 時(shí)，控制器會(huì)自動(dòng)拉起對(duì)等數(shù)量的 pod
5. 類型為 statefulset 的 pod，當(dāng) pod 卡在 termanting 時(shí)，由于 statefulset 下屬的 pod 名稱固定，必須等上一個(gè) pod 徹底刪除，對(duì)應(yīng)的新 pod 才會(huì)被拉起，在節(jié)點(diǎn)宕機(jī)情況下無法自動(dòng)拉起恢復(fù)
6. 對(duì)于使用 udisk-pvc 的 pod，由于 pvc 無法卸載，會(huì)導(dǎo)致新起的 pod 無法運(yùn)行，請(qǐng)按照本文 pvc 相關(guān)內(nèi)容(#如何查看pvc對(duì)應(yīng)的udisk實(shí)際掛載情況)，確認(rèn)相關(guān)關(guān)系

Pod 異常退出了怎么辦？

1. kubectl describe pods pod-name -n ns 查看 pod 的相關(guān) event 及每個(gè) container 的 status，是 pod 自己退出，還是由于 oom 被殺，或者是被驅(qū)逐
2. 如果是 pod 自己退出，kubectl logs pod-name -p -n ns 查看容器退出的日志，排查原因
3. 如果是由于 oom 被殺，建議根據(jù)業(yè)務(wù)重新調(diào)整 pod 的 request 和 limit 設(shè)置（兩者不宜相差過大），或檢查是否有內(nèi)存泄漏
4. 如果 pod 被驅(qū)逐，說明節(jié)點(diǎn)壓力過大，需要檢查時(shí)哪個(gè) pod 占用資源過多，并調(diào)整 request 和 limit 設(shè)置
5. 非 pod 自身原因?qū)е碌耐顺?，需要?zhí)行dmesg查看系統(tǒng)日志以及journalctl -u kubelet查看 kubelet 相關(guān)日志。

CNI 插件升級(jí)為什么失敗了？

1. 檢查節(jié)點(diǎn)是否設(shè)置了污點(diǎn)及禁止調(diào)度（master 節(jié)點(diǎn)的默認(rèn)污點(diǎn)不計(jì)算在內(nèi)），帶有污點(diǎn)的節(jié)點(diǎn)需要選擇強(qiáng)制升級(jí)（不會(huì)對(duì)節(jié)點(diǎn)有特殊影響）。
2. 如果強(qiáng)制升級(jí)失敗的，請(qǐng)重新點(diǎn)擊 cni 強(qiáng)制升級(jí)。
3. 執(zhí)行kubectl get pods -n kube-system |grep plugin-operation找到對(duì)應(yīng)插件升級(jí)的 pod，并 describe pod 查看 pod 失敗原因。

UK8S 頁面概覽頁一直刷新不出來？

1. api-server 對(duì)應(yīng)的 ulb4 是否被刪除（uk8s-xxxxxx-master-ulb4）
2. UK8S 集群的三臺(tái) master 主機(jī)是否被刪了或者關(guān)機(jī)等

3. 登陸到 UK8S 三臺(tái) master 節(jié)點(diǎn)，檢查 etcd 和 kube-apiserver 服務(wù)是否正常，如果異常，嘗試重啟服務(wù)

   • 3.1 systemctl status etcd / systemctl restart etcd 如果單個(gè) etcd 重啟失敗，請(qǐng)嘗試三臺(tái)節(jié)點(diǎn)的 etcd 同時(shí)重啟
   • 3.2 systemctl status kube-apiserver / systemctl restart kube-apiserver

UK8S 節(jié)點(diǎn) NotReady 了怎么辦

1. kubectl describe node node-name 查看節(jié)點(diǎn) notReady 的原因，也可以直接在 console 頁面上查看節(jié)點(diǎn)詳情。
2. 如果可以登陸節(jié)點(diǎn)，journalctl -u kubelet 查看 kubelet 的日志， system status kubelet查看 kubelet 工作是否正常。
3. 對(duì)于節(jié)點(diǎn)已經(jīng)登陸不了的情況，如果希望快速恢復(fù)可以在控制臺(tái)找到對(duì)應(yīng)主機(jī)斷電重啟。
4. 查看主機(jī)監(jiān)控，或登陸主機(jī)執(zhí)行sar命令，如果發(fā)現(xiàn)磁盤 cpu 和磁盤使用率突然上漲 且內(nèi)存使用率也高，一般情況下是內(nèi)存 oom 導(dǎo)致的。關(guān)于內(nèi)存占用過高導(dǎo)致節(jié)點(diǎn)宕機(jī)，由于內(nèi)存占用過高，磁盤緩存量很少，會(huì)導(dǎo)致磁盤讀寫頻繁，進(jìn)一步增加系統(tǒng)負(fù)載，打高cpu的惡性循環(huán)
5. 內(nèi)存 oom 的情況需要客戶自查是進(jìn)程的內(nèi)存情況，k8s 建議 request 和 limit 設(shè)置的值不宜相差過大，如果相差較大，比較容易導(dǎo)致節(jié)點(diǎn)宕機(jī)。
6. 如果對(duì)節(jié)點(diǎn) notready 原因有疑問，請(qǐng)按照UK8S人工支持聯(lián)系人工支持

為什么我的集群連不上外網(wǎng)?

集群若需要訪問公網(wǎng)，進(jìn)行拉取鏡像等操作，需要為集群所在 VPC 綁定 NAT 網(wǎng)關(guān)，并配置相應(yīng)規(guī)則，詳見：https://docs.ucloud.cn/vpc/introduction/natgw

為什么我的 UHub 登陸失敗了?

1. 請(qǐng)確認(rèn)是在公網(wǎng)還是 UCloud 內(nèi)網(wǎng)進(jìn)行登陸的（如果 ping uhub 的 ip 為 117.50.7.5 則表示是通過公網(wǎng)拉?。?/li>
2. 如果在公網(wǎng)登陸，請(qǐng)?jiān)?UHub 的 Console 頁面確認(rèn)外網(wǎng)訪問選項(xiàng)打開
3. 確認(rèn)是否使用獨(dú)立密碼登陸，UHub 獨(dú)立密碼是和用戶綁定的，而不是和鏡像庫綁定的

UHub 下載失?。?/h2>

1. ping uhub.service.ucloud.cn （如果ip為117.50.7.5 則表示是通過公網(wǎng)拉取，有限速）
2. curl https://uhub.service.ucloud.cn/v2/ 查看是否通，正常會(huì)返回 UNAUTHORIZED 或 301
3. systemctl show --property=Environment docker 查看是否配置了代理
4. 在拉鏡像節(jié)點(diǎn)執(zhí)行iftop -i any -f host 命令，同時(shí)嘗試?yán)?UHub 鏡像，查看命令輸出（uhub-ip替換為步驟1中得到的ip）
5. 對(duì)于公網(wǎng)拉鏡像的用戶，還需要在 Console 頁面查看外網(wǎng)訪問是否開啟

PV PVC StorageClass 以及 UDisk 的各種關(guān)系？

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: udisk-ssd-test
provisioner: udisk.csi.ucloud.cn #存儲(chǔ)供應(yīng)方，此處不可更改。
---
apiVersion: v1
kind: PersistentVolumeClaim
spec:
  storageClassName: ssd-csi-udisk

用戶只需要設(shè)置好 StorageClass，在使用 pvc 時(shí)，csi-udisk 插件會(huì)自動(dòng)完成 UDisk 的創(chuàng)建掛載 mount 等一系列的操作，主要流程如下

1. StorageClass 設(shè)置相關(guān)參數(shù)，與 CSI 插件綁定。
2. pvc 與 StorageClass 進(jìn)行綁定。
3. K8S 觀察到使用 StorageClass 的新建 pvc，會(huì)自動(dòng)創(chuàng)建 pv，并交給 CSI 插件完成新建 UDisk 的工作。
4. pv 與 pvc 綁定完成，CSI 插件完成后續(xù) UDisk 的掛載和 mount 等工作。
5. UCloud 的 CSI 插件查看可以通過kubectl get pods -o wide -n kube-system |grep udisk 查看（一個(gè)總的 controller 及每個(gè) node 對(duì)應(yīng)的 pod）

Statefulset 中使用 PVC

1. Statefulset 控制器中的 pvctemplate 字段，可以設(shè)置 K8S 集群在對(duì)應(yīng) pvc 不存在時(shí)自動(dòng)創(chuàng)建pvc，使得上述流程更加自動(dòng)化(pvc和pv均由UK8S來建)。
2. Statefulset 只負(fù)責(zé)創(chuàng)建不負(fù)責(zé)刪除 pvc，因此對(duì)應(yīng)多余的 pvc 需要手動(dòng)刪除

VolumeAttachment 的作用

VolumeAttachment 并不由用戶自己創(chuàng)建，因此很多用戶并不清楚它的作用，但是在 pvc 的使用過程中，VolumeAttachment 有著很重要的作用

1. VolumeAttachment所表示的，是 K8S 集群中記載的 pv 和某個(gè) Node 的掛載關(guān)系?？梢詧?zhí)行kubectl get volumeattachment |grep pv-name 進(jìn)行查看
2. 這個(gè)掛載關(guān)系和 UDisk 與云主機(jī)的掛載關(guān)系往往是一致的，但是有時(shí)可能會(huì)出現(xiàn)不一致的情況。
3. 不一致的情況多見于 UDisk 已經(jīng)從云主機(jī)卸載，但是 VolumeAttachment 記錄中仍然存在，UDisk 是否掛載在云主機(jī)上，可以通過如何查看 PVC 對(duì)應(yīng)的 UDisk 實(shí)際掛載情況來查看
4. 對(duì)于不一致的情況，可用選擇手動(dòng)刪除對(duì)應(yīng)的 VolumeAttachment 字段，并新建一個(gè)相同的 VolumeAttachment（新建后 ATTACHED 狀態(tài)為 false）
5. 如果不能刪除，可以通過kubectl logs csi-udisk-controller-0 -n kube-system csi-udisk 查看 csi-controller 日志定位原因
6. 一般 kubelet 手動(dòng)刪除不掉的情況，可能是對(duì)應(yīng)的節(jié)點(diǎn)已經(jīng)不存在了，此時(shí)直接 edit volumeattachment 刪除 finalizers 字段即可

[root@10-9-112-196 ~]# kubectl get volumeattachment |grep pvc-e51b694f-ffac-4d23-af5e-304a948a155a
NAME                                                                   ATTACHER              PV                                         NODE           ATTACHED   AGE
csi-1d52d5a7b4c5c172de7cfc17df71c312059cf8a2d7800e05f46e04876a0eb50e   udisk.csi.ucloud.cn   pvc-e51b694f-ffac-4d23-af5e-304a948a155a   10.9.184.108   true       2d2h

apiVersion: storage.k8s.io/v1
kind: VolumeAttachment
metadata:
  annotations:
    csi.alpha.kubernetes.io/node-id: 10.9.184.108 # 綁定的節(jié)點(diǎn)ip，填寫報(bào)錯(cuò)pod所在節(jié)點(diǎn)
  finalizers:
  - external-attacher/udisk-csi-ucloud-cn
  name: csi-1d52d5a7b4c5c172de7cfc17df71c312059cf8a2d7800e05f46e04876a0eb50e # 名稱，按照pod報(bào)錯(cuò)名稱填寫
spec:
  attacher: udisk.csi.ucloud.cn
  nodeName: 10.9.184.108 #綁定的節(jié)點(diǎn)ip，填寫報(bào)錯(cuò)pod所在節(jié)點(diǎn)
  source:
    persistentVolumeName: pvc-e51b694f-ffac-4d23-af5e-304a948a155a # 綁定的pv，填寫pod使用的pv 

如何查看 PVC 對(duì)應(yīng)的 UDisk 實(shí)際掛載情況

對(duì)應(yīng)關(guān)系表

1. kubectl get pvc -n ns pvc-name 查看對(duì)應(yīng)的 VOLUME 字段，找到與 pvc 綁定的 pv，一般為（pvc-e51b694f-ffac-4d23-af5e-304a948a155a）
2. kubectl get pv pv-name -o yaml 在 spec.csi.volumeHandle 字段，可以查看到改 pv 綁定的 UDisk盤(flexv 插件為 pv 的最后幾位)
3. 在控制臺(tái)查看該udisk盤的狀態(tài)是否掛載到某個(gè)主機(jī)
4. kubectl get volumeattachment |grep pv-name 查看 K8S 集群內(nèi)記錄的磁盤掛載狀態(tài)，VolumeAttachment的作用
5. ssh 到對(duì)應(yīng)的主機(jī)上，lsblk可以看到對(duì)應(yīng)的盤
6. mount |grep pv-name 可用查看盤的實(shí)際掛載點(diǎn)，有一個(gè) globalmount 及一個(gè)或多個(gè) pod 的 mount 點(diǎn)

[root@10-9-184-108 ~]# mount |grep pvc-e51b694f-ffac-4d23-af5e-304a948a155a
/dev/vdc on /data/kubelet/plugins/kubernetes.io/csi/pv/pvc-e51b694f-ffac-4d23-af5e-304a948a155a/globalmount type ext4 (rwrelatime)
/dev/vdc on /data/kubelet/pods/587962f5-3009-4c53-a56e-a78f6636ce86/volumes/kubernetes.io~csi/pvc-e51b694f-ffac-4d23-af5e-304a948a155a/mount type ext4 (rwrelatime)

磁盤掛載的錯(cuò)誤處理

1. 由于磁盤內(nèi)容多流程長，建議在出現(xiàn)問題時(shí)，首先確定當(dāng)前狀態(tài)如何查看 PVC 對(duì)應(yīng)的 UDisk 實(shí)際掛載情況
2. 如果有UK8S中狀態(tài)和主機(jī)狀態(tài)不一致的情況，首先進(jìn)行清理，刪除掉不一致的資源，之后走正常流程進(jìn)行恢復(fù)

PV 和 PVC 一直卡在 terminating/磁盤卸載失敗怎么辦

1. 通過如何查看 PVC 對(duì)應(yīng)的 UDisk 實(shí)際掛載情況確定當(dāng)前 pv 和 pvc 的實(shí)際掛載狀態(tài)
2. 手動(dòng)按照自己的需求進(jìn)行處理，首先清理所有使用該 pv 和 pvc 的所有 pod（如果 pvc 已經(jīng)成功刪除，則不需要這一步）
3. 如果刪除 pvc 卡在 terminating，則手動(dòng) umount 掉對(duì)應(yīng)的掛載路徑
4. 如果刪除 VolumeAttachment 卡在 terminating，則手動(dòng)在控制臺(tái)卸載掉磁盤（如果卡在卸載中找主機(jī)處理）
5. 如果刪除 pv 卡在 terminating，則手動(dòng)在控制臺(tái)刪除掉磁盤（刪除 pv 前需要確保相關(guān)的 VolumeAttachment 已經(jīng)刪除完成）
6. 確保手動(dòng)釋放完成對(duì)應(yīng)的資源后，可以通過kubectl edit 對(duì)應(yīng)的資源刪除掉其中的 finalizers 字段，此時(shí)資源就會(huì)成功釋放掉
7. 刪除 VolumeAttachment 后，如果 pod 掛載報(bào)錯(cuò)，按照VolumeAttachment 的作用中提供的yaml文件，重新補(bǔ)一個(gè)同名的 VolumeAttachment 即可

Pod 的 PVC 一直掛載不上怎么辦？

1. kubectl get pvc -n ns pvc-name 查看對(duì)應(yīng)的 VOLUME 字段，找到與 pvc 綁定的 pv，一般為（pvc-e51b694f-ffac-4d23-af5e-304a948a155a）
2. kubectl get pv pv-name -o yaml 在 spec.csi.volumeHandle 字段，可以查看到改 pv 綁定的 UDisk 盤(flexv 插件為 pv 的最后幾位)
3. 找到 UDisk 磁盤后，如果控制臺(tái)頁面中磁盤處于可用狀態(tài)或者掛載的主機(jī)不是 pod 所在主機(jī)，可以找技術(shù)支持，查看該 UDisk的掛載和卸載請(qǐng)求的錯(cuò)誤日志，并聯(lián)系主機(jī)同時(shí)進(jìn)行處理
4. 如果沒有 UDisk相關(guān)的錯(cuò)誤日志，聯(lián)系UK8S值班人員，并提供kubectl logs csi-udisk-controller-0 -n kube-system csi-udisk的日志輸出及 pod 的event

UDisk-PVC 使用注意事項(xiàng)

1. 由于 UDisk 不可跨可用區(qū)，因此在建立 StorageClass 時(shí)必須指定 volumeBindingMode: WaitForFirstConsumer
2. 由于 UDisk 不可多點(diǎn)掛載，因此必須在 pvc 中指定 accessModes 為 ReadWriteOnce
3. 基于 UDisk 不可多點(diǎn)掛載，多個(gè) pod 不可共用同一個(gè) udisk-pvc，上一個(gè) pod 的 udisk-pvc 未處理干凈時(shí)，會(huì)導(dǎo)致后續(xù) pod 無法創(chuàng)建，此時(shí)可以查看 VolumeAttachment 的狀態(tài)進(jìn)行確認(rèn)

為什么在 K8S 節(jié)點(diǎn) Docker 直接起容器網(wǎng)絡(luò)不通

1. UK8S 使用 UCloud 自己的 CNI 插件，而直接用 Docker 起的容器并不能使用該插件，因此網(wǎng)絡(luò)不通。
2. 如果需要長期跑任務(wù)，不建議在 UK8S 節(jié)點(diǎn)用 Docker 直接起容器，應(yīng)該使用 pod
3. 如果只是臨時(shí)測(cè)試，可以添加--network host 參數(shù)，使用 hostnetwork 的模式起容器

使用 ULB4 時(shí) Vserver 為什么會(huì)有健康檢查失效

1. 如果 svc 的 externalTrafficPolicy 為 Local 時(shí)，這種情況是正常的，失敗的節(jié)點(diǎn)表示沒有運(yùn)行對(duì)應(yīng)的 pod
2. 需要在節(jié)點(diǎn)上抓包 tcpdump -i eth0 host 查看是否正常 ulb-ip 替換為 svc 對(duì)應(yīng)的實(shí)際 ip
3. 查看節(jié)點(diǎn)上 kube-proxy 服務(wù)是否正常 systemctl status kube-proxy
4. 執(zhí)行iptables -L -n -t nat |grep KUBE-SVC 及 ipvsadm -L -n查看轉(zhuǎn)發(fā)規(guī)則是否下發(fā)正常

ULB4 對(duì)應(yīng)的端口為什么不是 NodePort 的端口

1. K8S 節(jié)點(diǎn)上對(duì) ulb_ip+serviceport 的端口組合進(jìn)行了 iptables 轉(zhuǎn)發(fā)，所以不走 nodeport
2. 如果有興趣，可以通過在節(jié)點(diǎn)上執(zhí)行iptables -L -n -t nat 或者ipvsadm -L -n 查看對(duì)應(yīng)規(guī)則

實(shí)時(shí)文檔歡迎訪問https://docs.ucloud.cn/uk8s/troubleshooting/k8s_debug_summary