本文部分內容源自網絡，侵刪。
概述
為了跟蹤和發現在Kubernetes集群中運行的容器應用出現的問題，我們常用如下排查方法：
- 查看Kubernetes對象的當前運行時信息，特別是與對象關聯的
Event事件。這些事件記錄了相關主題、發生時間、最近發生時間、發生次數及事件原因等，對排查故障非常有價值。此外，通過查看對象的運行時數據，我們還可以發現參數錯誤、關聯錯誤、狀態異常等明顯問題。由於在Kubernetes中多種對象相互關聯，因此這一步可能會涉及多個相關對象的排查問題。 - 對於服務、容器方面的問題，可能需要深入容器內部進行故障診斷，此時可以通過查看容器的運行日志來定位具體問題。
- 對於某些復雜問題，例如
Pod調度這種全局性的問題，可能需要結合集群中每個節點上的Kubernetes服務日志來排查。比如搜集Master上的kube-apiserver、kube-schedule、kube-controler-manager服務日志，以及各個Node上的kubelet、kube-proxy服務日志，通過綜合判斷各種信息，就能找到問題的成因並解決問題。
查看系統Event
Kubernetes提供了以下命令來查看一個Pod的詳細信息：
kubectl describe pod -n <namespace>
通過以上命令可以顯示Pod創建時的配置定義、狀態等信息，還可以顯示與該Pod相關的最近的Event事件，事件信息對於查錯非常有用。
從Event事件中獲知Pod失敗的原因可能有以下幾種：
- 沒有可用的
Node以供調度。 - 開啟了資源配額管理，但在當前調度的目標節點上資源不足。
- 鏡像下載失敗，鏡像下載失敗通常為網絡問題。
同理，通過kubectl describe命令，還可以查看其他Kubernetes對象，包括Node、RC、Service、Namespace、Secrets等，對每種對象都會顯示相關的其他信息。
查看容器日志
在需要排查容器內部應用程序生成的日志時，我們可以使用以下命令：
kubectl logs <pod_name> -n <namespace>
如果在某個Pod中包含多個容器，就需要通過-c參數指定容器的名稱來查看
kubectl logs <pod_name> -c <container_name> -n <namespace>
容器中應用程序生成的日志與容器的生命周期是一致的，所以在容器被銷毀之后，容器內部的文件也會被丟棄，包括日志等。如果需要保留容器內應用程序生成的日志，則可以使用掛載的Volume將容器內應用程序生成的日志保存到宿主機，還可以通過一些工具如Fluentd、Elasticsearch等對日志進行采集。
查看Kubernetes服務日志
如果在Linux系統上安裝Kubernetes，並且使用systemd系統管理Kubernetes服務，那么systemd的journal系統會接管服務程序的輸出日志。在這種環境中，可以通過使用systemd status或journalctl工具來查看系統服務的日志。
例如查看kube-controller-manager服務的日志：
systemctl status kube-controller-manager
使用journalctl命令查看：
journalctl -u kube-controller-manager
如果不使用systemd系統接管Kubernetes服務的標准輸出，則也可以通過日志相關的啟動參數來指定日志的存放目錄。
--logtostderr=false：不輸出到stderr。--log-dir=/var/log/kubernetes：日志的存放目錄。--alsologtostderr=false：將其設置為true時，表示將日志同時輸出到文件和stderr。--v=0：glog的日志級別。--vmodule=gfs*=2,test*=4：glog基於模塊的詳細日志級別。
在大多數情況下，我們從WARNING和ERROR級別的日志中就能找到問題的成因，但有時還需要排查INFO級別的日志甚至DEBUG級別的詳細日志。此外，etcd服務也屬於Kubernetes集群的重要組成部分，所以不能忽略它的日志。
如果某個Kubernetes對象存在問題，則可以用這個對象的名字作為關鍵字搜索Kubernetes的日志來發現和解決問題。在大多數情況下，我們遇到的主要是與Pod對象相關的問題，比如無法創建Pod、Pod啟動后就停止或者Pod副本無法增加，等等。此時，可以先確定Pod在哪個節點上，然后登錄這個節點，從kubelet的日志中查詢該Pod的完整日志，然后進行問題排查。對於與Pod擴容相關或者與RC相關的問題，則很可能在kube-controller-manager及kube-scheduler的日志中找出問題的關鍵點。
另外，kube-proxy經常被我們忽視，因為即使它意外停止，Pod的狀態也是正常的，但會導致某些服務訪問異常。這些錯誤通常與每個節點上的kube-proxy服務有着密切的關系。遇到這些問題時，首先要排查kube-proxy服務的日志，同時排查防火牆服務，要特別留意在防火牆中是否有人為添加的可疑規則。
常見問題
由於無法下載pause鏡像導致Pod一直處於Pending狀態
現象：無法下載pause鏡像導致Pod一直處於Pending狀態。
解決方法如下：
- 如果服務器可以訪問Internet，並且不希望使用HTTPS的安全機制來訪問
gcr.io，則可以在Docker Daemon的啟動參數中加上--insecure-registry gcr.io，來表示可以匿名下載。 - 如果Kubernetes集群在內網環境中無法訪問
gcr.io網站，則可以先通過一台能夠訪問gcr.io的機器下載pause鏡像，將pause鏡像導出后，再導入內網的Docker私有鏡像庫，並在kubelet的啟動參數中加上--pod_infra_container_image。
除了pause鏡像，其他Docker鏡像也可能存在無法下載的情況，與上述情況類似，很可能也是網絡配置使得鏡像無法下載，解決方法同上。
Pod創建成功，但RESTARTS數量持續增加
現象：創建一個RC之后，Pod一會兒是Running狀態，一會兒是ExitCode:0狀態，在READY列中始終無法變成1/1，而且RESTARTS（重啟的數量）的數量不斷增加。
原因：在Kubernetes中根據RC定義創建Pod，之后啟動容器。在容器的啟動命令執行完成時，認為該容器的運行已經結束，並且是成功結束（ExitCode=0）的。根據Pod的默認重啟策略定義（RestartPolicy=Always），RC將啟動這個容器。
解決：新的容器在執行啟動命令后仍然會成功結束，之后RC會再次重啟該容器，如此往復。其解決方法為將Docker鏡像的啟動命令設置為一個前台運行的命令。
通過服務名無法訪問服務
在Kubernetes集群中應盡量使用服務名訪問正在運行的微服務，但有時會訪問失敗。由於服務涉及服務名的DNS域名解析、kube-proxy組件的負載分發、后端Pod列表的狀態等，所以可通過以下幾方面排查問題。
1.查看Service的后端Endpoint是否正常
可以通過kubectl get endpoints <service_name>命令查看某個服務的后端Endpoint列表，如果列表為空，則可能因為：
- Service的Label Selector與Pod的Label不匹配；
- 后端Pod一直沒有達到Ready狀態（通過kubectl get pods進一步查看Pod的狀態）；
- Service的targetPort端口號與Pod的containerPort不一致等。
2．查看Service的名稱能否被正確解析為ClusterIP地址
可以通過在客戶端容器中ping <service_name>.<namespace>.svc進行檢查，如果能夠得到Service的ClusterIP地址，則說明DNS服務能夠正確解析Service的名稱；如果不能得到Service的ClusterIP地址，則可能是因為Kubernetes集群的DNS服務工作異常。
3．查看kube-proxy的轉發規則是否正確
我們可以將kube-proxy服務設置為IPVS或iptables負載分發模式。
對於IPVS負載分發模式，可以通過ipvsadm工具查看Node上的IPVS規則，查看是否正確設置Service ClusterIP的相關規則。
對於iptables負載分發模式，可以通過查看Node上的iptables規則，查看是否正確設置ServiceClusterIP的相關規則。