K8s常見的10個問題排查

1、POD啟動異常、部分節(jié)點無法啟動pod

容器里管理應用

pod是k8S中最小調度單元,POD里面的容器共享pod的空間、資源、網(wǎng)絡、存儲等。
pod管理一個容器。
pod管理多個容器。

pod出現(xiàn)異常的原因：

1、資源過剩：大量POD在同一個物理節(jié)點，出現(xiàn)資源占用太多導致物理節(jié)點宕機。
2、內存和CPU超標：pod中的應用出現(xiàn)內存泄露，導致pod內存迅速增多，pod kill 了影響節(jié)點正常提供服務。（解決辦法：壓測占用多少內存和CPU，做資源限制；）
3、網(wǎng)絡問題：導致POD無法通信（解決辦法：檢查calico網(wǎng)絡插件情況）
4、存儲問題：pod掛載的共享存儲連接不上導致pod啟動異常(解決辦法：查看共享存儲是否正常,存儲卷是否正常)
5、代碼問題：應用程序代碼在容器啟動后失敗（解決辦法：排查應用程序代碼）
6、配置問題：在部署deployment和statefulset時，資源清單編寫有問題，導致pod無法正常創(chuàng)建(解決辦法：查看資源配置的清單)
7、借助監(jiān)控系統(tǒng)排查以上問題。

2. 審視集群狀態(tài)

審視集群狀態(tài)

K8S的集群狀態(tài)是排查故障的關鍵起點。使用kubectl get nodes命令來檢查節(jié)點狀態(tài)。如果有節(jié)點未能就緒或出現(xiàn)異常狀態(tài)，可能會對應用程序造成故障。確?；窘M件，如etcd、kubelet和kube-proxy等，正常運行。

3. 追蹤事件日志

追蹤事件日志

深入了解集群中發(fā)生的事件是解決K8S故障的重要環(huán)節(jié)。通過kubectl get events命令查看事件日志。事件日志記錄了與集群中重要事件和錯誤相關的信息。透過事件日志的檢查，能夠了解K8S組件或應用程序中存在的潛在故障，并準確定位問題。

4. 聚焦Pod狀態(tài)

第三方面：聚焦Pod狀態(tài)

通過運行kubectl get pods --all-namespaces命令，獲取集群中所有Pod的狀態(tài)。若有Pod未處于運行狀態(tài)（例如掛起、錯誤或未就緒等），很可能與容器或應用程序相關的問題有關。借助kubectl describe pod命令，獲取特定Pod的詳細信息，以便深入排查。

5. 檢查網(wǎng)絡連通性

檢查網(wǎng)絡連通性

確保網(wǎng)絡連接正常。審查服務、Pod和節(jié)點之間的網(wǎng)絡通信是否存在問題。運行kubectl get services命令查看服務狀態(tài)，使用kubectl describe service獲取相關服務的詳細信息。同時，驗證網(wǎng)絡策略和防火墻規(guī)則的正確配置。

6. 審視存儲配置

審視存儲配置

如果你的應用程序使用持久性存儲（例如Persistent Volumes和Storage Classes），務必確保存儲配置正確。檢查存儲卷聲明、存儲類和持久卷的狀態(tài)。通過kubectl get pv、kubectl get pvc和kubectl get storageclass命令，獲取與存儲相關的信息。

7. 研究容器日志

研究容器日志

深入容器的日志能夠提供關于應用程序故障的重要線索。使用kubectl logs命令查看特定Pod中容器的日志輸出。如果Pod內含多個容器，你可以使用kubectl logs-c來查看特定容器的日志。

8. K8S集群網(wǎng)絡通信

K8S集群有自己獨立的內部網(wǎng)絡，整個集群的通信都需要依賴網(wǎng)絡插件，常見的網(wǎng)絡插件有Calico、Flannel、Canel等等。

Calico網(wǎng)絡插件支持IP地址的分配以及網(wǎng)絡策略的調整，性能和Flannel不相上下。

Flannel網(wǎng)絡插件只支持IP地址分配。

Canel是Calico和Flannel網(wǎng)絡插件的結合體。

K8S集群中的網(wǎng)絡通信主要有以下幾種：

同一個Pod內多個容器之間的網(wǎng)絡通信。

Pod與Pod之間的網(wǎng)絡通信。

Pod與Service的通信。

Service資源與集群外部的通信

9. 問題：Service 是否通過 DNS 工作？

從相同 Namespace 下的 Pod 中運行：

u@pod$ nslookup hostnames
Address?1:?10.0.0.10?kube-dns.kube-system.svc.cluster.local


Name:      hostnames
Address 1: 10.0.1.175 hostnames.default.svc.cluster.local

如果失敗，那么您的 Pod 和 Service 可能位于不同的 Namespace 中，請嘗試使用限定命名空間的名稱：

u@pod$ nslookup hostnames.default
Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local
Name:      hostnames.default
Address 1: 10.0.1.175 hostnames.default.svc.cluster.local

如果成功，那么需要調整您的應用，使用跨命名空間的名稱去訪問服務，或者，在相同的 Namespace 中運行應用和 Service。如果仍然失敗，請嘗試一個完全限定的名稱：

u@pod$ nslookup hostnames.default.svc.cluster.local
Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local


Name:      hostnames.default.svc.cluster.local
Address 1: 10.0.1.175 hostnames.default.svc.cluster.local

注意這里的后綴：”default.svc.cluster.local”?！眃efault” 是我們正在操作的 Namespace?！眘vc” 表示這是一個 Service?！眂luster.local” 是您的集群域，在您自己的集群中可能會有所不同。

您也可以在集群中的 Node 上嘗試此操作：

注意：10.0.0.10 是我的 DNS Service，您的可能不同）

u@node$ nslookup hostnames.default.svc.cluster.local 10.0.0.10
Server:         10.0.0.10
Address:        10.0.0.10#53
Name:   hostnames.default.svc.cluster.local
Address: 10.0.1.175

如果您能夠使用完全限定的名稱查找，但不能使用相對名稱，則需要檢查 /etc/resolv.conf 文件是否正確。

u@pod$ cat /etc/resolv.conf
nameserver 10.0.0.10
search default.svc.cluster.local svc.cluster.local cluster.local example.com
options ndots:5

nameserver 行必須指示您的集群的 DNS Service，它通過 --cluster-dns 標志傳遞到 kubelet。

search 行必須包含一個適當?shù)暮缶Y，以便查找 Service 名稱。在本例中，它在本地 Namespace（default.svc.cluster.local）、所有 Namespace 中的 Service（svc.cluster.local）以及集群（cluster.local）中查找服務。根據(jù)您自己的安裝情況，可能會有額外的記錄（最多 6 條）。集群后綴通過 --cluster-domain 標志傳遞給 kubelet。本文檔中，我們假定它是 “cluster.local”，但是您的可能不同，這種情況下，您應該在上面的所有命令中更改它。

options 行必須設置足夠高的 ndots，以便 DNS 客戶端庫考慮搜索路徑。在默認情況下，Kubernetes 將這個值設置為 5，這個值足夠高，足以覆蓋它生成的所有 DNS 名稱。

10. 總結

當然，具體的排查方法還取決于你的集群配置、應用程序部署方式以及故障的具體現(xiàn)象。根據(jù)實際情況，可能需要進一步調查或采取其他排查措施。立足于這些方向，你將更有把握解決K8S故障，并確保應用程序持續(xù)穩(wěn)定運行。

編輯：黃飛