摘要：對于節點已經登陸不了的情況，如果希望快速恢復可以在控制臺找到對應主機斷電重啟。與綁定完成，插件完成后續的掛載和等工作。

UK8S 人工支持

對于使用 UK8S 遇到的本文檔未涉及的問題，如果需要人工支持，請添加下面公鑰信任，并提供主機的 uhost-id

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

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

1. 查看容器log，排查異常重啟的原因
2. pod是否正確設置了啟動命令，啟動命令可以在制作鏡像時指定，也可以在pod配置中指定
3. 啟動命令必須保持在前臺運行，否則k8s會認為pod已經結束，并重啟pod。

Docker 如何調整日志等級

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

為什么節點已經異常了，但是 Pod 還處在 Running 狀態

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

節點宕機了 Pod 一直卡在 Termnating 怎么辦

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

Pod 異常退出了怎么辦？

1. kubectl describe pods pod-name -n ns 查看 pod 的相關 event 及每個 container 的 status，是 pod 自己退出，還是由于 oom 被殺，或者是被驅逐
2. 如果是 pod 自己退出，kubectl logs pod-name -p -n ns 查看容器退出的日志，排查原因
3. 如果是由于 oom 被殺，建議根據業務重新調整 pod 的 request 和 limit 設置（兩者不宜相差過大），或檢查是否有內存泄漏
4. 如果 pod 被驅逐，說明節點壓力過大，需要檢查時哪個 pod 占用資源過多，并調整 request 和 limit 設置
5. 非 pod 自身原因導致的退出，需要執行dmesg查看系統日志以及journalctl -u kubelet查看 kubelet 相關日志。

CNI 插件升級為什么失敗了？

1. 檢查節點是否設置了污點及禁止調度（master 節點的默認污點不計算在內），帶有污點的節點需要選擇強制升級（不會對節點有特殊影響）。
2. 如果強制升級失敗的，請重新點擊 cni 強制升級。
3. 執行kubectl get pods -n kube-system |grep plugin-operation找到對應插件升級的 pod，并 describe pod 查看 pod 失敗原因。

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

1. api-server 對應的 ulb4 是否被刪除（uk8s-xxxxxx-master-ulb4）
2. UK8S 集群的三臺 master 主機是否被刪了或者關機等

3. 登陸到 UK8S 三臺 master 節點，檢查 etcd 和 kube-apiserver 服務是否正常，如果異常，嘗試重啟服務

   • 3.1 systemctl status etcd / systemctl restart etcd 如果單個 etcd 重啟失敗，請嘗試三臺節點的 etcd 同時重啟
   • 3.2 systemctl status kube-apiserver / systemctl restart kube-apiserver

UK8S 節點 NotReady 了怎么辦

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

為什么我的集群連不上外網?

集群若需要訪問公網，進行拉取鏡像等操作，需要為集群所在 VPC 綁定 NAT 網關，并配置相應規則，詳見：https://docs.ucloud.cn/vpc/introduction/natgw

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

1. 請確認是在公網還是 UCloud 內網進行登陸的（如果 ping uhub 的 ip 為 117.50.7.5 則表示是通過公網拉取）
2. 如果在公網登陸，請在 UHub 的 Console 頁面確認外網訪問選項打開
3. 確認是否使用獨立密碼登陸，UHub 獨立密碼是和用戶綁定的，而不是和鏡像庫綁定的

UHub 下載失敗（慢）

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

PV PVC StorageClass 以及 UDisk 的各種關系？

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

用戶只需要設置好 StorageClass，在使用 pvc 時，csi-udisk 插件會自動完成 UDisk 的創建掛載 mount 等一系列的操作，主要流程如下

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

Statefulset 中使用 PVC

1. Statefulset 控制器中的 pvctemplate 字段，可以設置 K8S 集群在對應 pvc 不存在時自動創建pvc，使得上述流程更加自動化(pvc和pv均由UK8S來建)。
2. Statefulset 只負責創建不負責刪除 pvc，因此對應多余的 pvc 需要手動刪除

VolumeAttachment 的作用

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

1. VolumeAttachment所表示的，是 K8S 集群中記載的 pv 和某個 Node 的掛載關系。可以執行kubectl get volumeattachment |grep pv-name 進行查看
2. 這個掛載關系和 UDisk 與云主機的掛載關系往往是一致的，但是有時可能會出現不一致的情況。
3. 不一致的情況多見于 UDisk 已經從云主機卸載，但是 VolumeAttachment 記錄中仍然存在，UDisk 是否掛載在云主機上，可以通過如何查看 PVC 對應的 UDisk 實際掛載情況來查看
4. 對于不一致的情況，可用選擇手動刪除對應的 VolumeAttachment 字段，并新建一個相同的 VolumeAttachment（新建后 ATTACHED 狀態為 false）
5. 如果不能刪除，可以通過kubectl logs csi-udisk-controller-0 -n kube-system csi-udisk 查看 csi-controller 日志定位原因
6. 一般 kubelet 手動刪除不掉的情況，可能是對應的節點已經不存在了，此時直接 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 # 綁定的節點ip，填寫報錯pod所在節點
  finalizers:
  - external-attacher/udisk-csi-ucloud-cn
  name: csi-1d52d5a7b4c5c172de7cfc17df71c312059cf8a2d7800e05f46e04876a0eb50e # 名稱，按照pod報錯名稱填寫
spec:
  attacher: udisk.csi.ucloud.cn
  nodeName: 10.9.184.108 #綁定的節點ip，填寫報錯pod所在節點
  source:
    persistentVolumeName: pvc-e51b694f-ffac-4d23-af5e-304a948a155a # 綁定的pv，填寫pod使用的pv 

如何查看 PVC 對應的 UDisk 實際掛載情況

對應關系表

1. kubectl get pvc -n ns pvc-name 查看對應的 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盤的狀態是否掛載到某個主機
4. kubectl get volumeattachment |grep pv-name 查看 K8S 集群內記錄的磁盤掛載狀態，VolumeAttachment的作用
5. ssh 到對應的主機上，lsblk可以看到對應的盤
6. mount |grep pv-name 可用查看盤的實際掛載點，有一個 globalmount 及一個或多個 pod 的 mount 點

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

磁盤掛載的錯誤處理

1. 由于磁盤內容多流程長，建議在出現問題時，首先確定當前狀態如何查看 PVC 對應的 UDisk 實際掛載情況
2. 如果有UK8S中狀態和主機狀態不一致的情況，首先進行清理，刪除掉不一致的資源，之后走正常流程進行恢復

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

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

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

1. kubectl get pvc -n ns pvc-name 查看對應的 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 磁盤后，如果控制臺頁面中磁盤處于可用狀態或者掛載的主機不是 pod 所在主機，可以找技術支持，查看該 UDisk的掛載和卸載請求的錯誤日志，并聯系主機同時進行處理
4. 如果沒有 UDisk相關的錯誤日志，聯系UK8S值班人員，并提供kubectl logs csi-udisk-controller-0 -n kube-system csi-udisk的日志輸出及 pod 的event

UDisk-PVC 使用注意事項

1. 由于 UDisk 不可跨可用區，因此在建立 StorageClass 時必須指定 volumeBindingMode: WaitForFirstConsumer
2. 由于 UDisk 不可多點掛載，因此必須在 pvc 中指定 accessModes 為 ReadWriteOnce
3. 基于 UDisk 不可多點掛載，多個 pod 不可共用同一個 udisk-pvc，上一個 pod 的 udisk-pvc 未處理干凈時，會導致后續 pod 無法創建，此時可以查看 VolumeAttachment 的狀態進行確認

為什么在 K8S 節點 Docker 直接起容器網絡不通

1. UK8S 使用 UCloud 自己的 CNI 插件，而直接用 Docker 起的容器并不能使用該插件，因此網絡不通。
2. 如果需要長期跑任務，不建議在 UK8S 節點用 Docker 直接起容器，應該使用 pod
3. 如果只是臨時測試，可以添加--network host 參數，使用 hostnetwork 的模式起容器

使用 ULB4 時 Vserver 為什么會有健康檢查失效

1. 如果 svc 的 externalTrafficPolicy 為 Local 時，這種情況是正常的，失敗的節點表示沒有運行對應的 pod
2. 需要在節點上抓包 tcpdump -i eth0 host 查看是否正常 ulb-ip 替換為 svc 對應的實際 ip
3. 查看節點上 kube-proxy 服務是否正常 systemctl status kube-proxy
4. 執行iptables -L -n -t nat |grep KUBE-SVC 及 ipvsadm -L -n查看轉發規則是否下發正常

ULB4 對應的端口為什么不是 NodePort 的端口

1. K8S 節點上對 ulb_ip+serviceport 的端口組合進行了 iptables 轉發，所以不走 nodeport
2. 如果有興趣，可以通過在節點上執行iptables -L -n -t nat 或者ipvsadm -L -n 查看對應規則

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