當(dāng)K8s出現(xiàn)問題時(shí)，我們可以從哪些方面排查出

K8s問題的排查

1. POD啟動(dòng)異常、部分節(jié)點(diǎn)無(wú)法啟動(dòng)pod2. 審視集群狀態(tài)3. 追蹤事件日志4. 聚焦Pod狀態(tài)5. 檢查網(wǎng)絡(luò)連通性6. 審視存儲(chǔ)配置7. 研究容器日志8. K8S集群網(wǎng)絡(luò)通信9. 問題：Service 是否通過 DNS 工作？10. 總結(jié)

1、POD啟動(dòng)異常、部分節(jié)點(diǎn)無(wú)法啟動(dòng)pod

容器里管理應(yīng)用

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

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

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

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

審視集群狀態(tài)

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

3. 追蹤事件日志

追蹤事件日志

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

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

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

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

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

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

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

6. 審視存儲(chǔ)配置

審視存儲(chǔ)配置

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

7. 研究容器日志

研究容器日志

??深入容器的日志能夠提供關(guān)于應(yīng)用程序故障的重要線索。使用kubectl logs命令查看特定Pod中容器的日志輸出。如果Pod內(nèi)含多個(gè)容器，你可以使用kubectl logs-c來(lái)查看特定容器的日志。

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

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

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

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

• Canel是Calico和Flannel網(wǎng)絡(luò)插件的結(jié)合體。

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

1. 同一個(gè)Pod內(nèi)多個(gè)容器之間的網(wǎng)絡(luò)通信。

2. Pod與Pod之間的網(wǎng)絡(luò)通信。

3. Pod與Service的通信。

4. Service資源與集群外部的通信

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

??從相同 Namespace 下的 Pod 中運(yùn)行：

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

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

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

??如果成功，那么需要調(diào)整您的應(yīng)用，使用跨命名空間的名稱去訪問服務(wù)，或者，在相同的 Namespace 中運(yùn)行應(yīng)用和 Service。如果仍然失敗，請(qǐng)嘗試一個(gè)完全限定的名稱：

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

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

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

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

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

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

u@pod$ cat /etc/resolv.confnameserver 10.0.0.10search default.svc.cluster.local svc.cluster.local cluster.local example.comoptions ndots:5

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

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

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

10. 總結(jié)

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

鏈接：https://blog.csdn.net/2201_75366661/article/details/133522298?spm=1001.2100.3001.7377&utm_medium=distribute.pc_feed_blog_category.none-task-blog-classify_tag-2-133522298-null-null.nonecase&depth_1-utm_source=distribute.pc_feed_blog_category.none-task-blog-classify_tag-2-133522298-null-null.nonecase

（版權(quán)歸原作者所有，侵刪）