Kubernetes 應用故障的一些定位方法

1. 常備工作
   
2. 準備一個工具鏡像
   
3. 其中包含 nslookup, ping, curl, 甚至是 ab、siege 等常用工具以及一個順手的 Shell。一言不合就可以用靜態 Pod 的方式將其運行到 Kubernetes 之中進行內部診斷。
   
4. sysctl -a | grep forwarding
   
5. 你猜這是幹啥的？
   
6. 服務狀態查詢
   
7. 各個 Kubernetes 組件的狀態檢查。可以使用 Ansible 之類的工具進行快速查詢。
   
8. Service 不通
   
9. 這裏我們首先假設 Pod 工作正常
   
10. 目前我們的應用均採用的是 NodePort 模式對外提供服務：
    

1. 邏輯：Service 將 符合其選擇器的 Pod 暴露的端口 從 各個 Node 的同一端 口暴露出來對外進行監聽。
2. 技術：Kube-proxy 通過網絡插件，一般利用 Iptables vxLan 等烏七八糟的蜜汁技術，完成對外服務負載均衡，並分發給各個 Pod 的內部 IP 的相應端口。
3. 前面我們假設 Pod 是正常工作的，因此，這裏只考慮 Service 的情況。
   
4. 通過上面的陳述我們能看到大致的一些要素，下面從內向外進行列表：
   
5. Pod 能夠正常工作
   
6. 見後文
   
7. Service 的選擇器能夠正確的找到 Pod
   
8. 這裏我們可以使用kubectl describe svc panic-service命令，查看輸出內容的endpoint一節內容，如果其中有 Pod 地址，也就說明選擇器和 Pod 的標籤是匹配的。如果爲空，則需要對服務或者 Pod Controller 的定義進行排查。
   
9. Proxy 的工作狀態
   
10. 首先可以使用systemctl -l Kube-proxy來查看服務狀況。
11. 還可以使用其他 Node 的同一端口測試訪問，看是否單一節點的故障。
12. DNS 工作狀態
    
13. Kubectl 查看 DNS 各個 Pod 的存活狀態。
    
14. 利用上面提到的工具 Pod 嘗試解析服務。失敗了其實也沒啥辦法，刪 DNS Pod 重啓吧。
    
15. 端口是否定義正確
    
16. 看 Pod 的端口是否能夠正確偵聽，是否符合服務定義。例如 Service 定義了到 Pod 8080 端口的訪問，而 Pod 開放的卻是 80，這樣的情況跟標籤無法匹配一樣，是很常見的問題。
    
17. 說完了服務，我們來說說 Pod
    
18. 兩個順手的命令：
    
19. kubectl get po -o wide | grep -v Running kubectl describe po unhealthy
    
20. 一般來說，一個行爲端正的 Pod，應該是以 Running 狀態持續運行的。在進入 Running 之前，大致有調度、創建、初始化等幾個環節，如果正常運行之後出了故障，會發生重啓。如果在啓動容器內進程時出現問題，則會進入 CrashLoopBackOff 的狀態。
    
21. 除了 Running/Complet 以及 CrashLoopBackOff：
    
22. 這幾種情況其實不同，不過隨性寫到這，就不深究了，首先是 describe 一下。
    
23. Pod 啓動有幾個條件：
    
24. 有符合要求的節點供其運行
    1. Taint 隔離的節點，要求 Pod 有顯式聲明對該種 Taint 的容錯能力，纔可以在其上運行。
    2. 節點和 Pod 的親和性定義
    3. Node Selector 的定義
25. 符合其需求的資源
    1. CPU 和 內存的 request limit 定義
    2. 可能存在的第三方資源需求定義
    3. 加載卷（nfs gluster ceph 等）/Secret/Configmap 的定義
26. 鏡像必須存在，可 Pull
27. 調度部分一般來說查看 Pod 定義，和節點的 Describe 進行匹配即可，Describe 內容中也會明確說出無合適 Pod。
    
28. 資源部分 CPU 和內存的 Describe 結果也會很明顯。
    
29. 存儲部分，往往就需要更復雜的排查：
    
30. 首先看看是不是每個 Node 都如此。
31. 是否安裝了對應的客戶端驅動。
32. 對分佈式存儲的訪問網絡是否可用。
33. 存儲服務容量是否足夠分配。
34. 是否能夠成功的手工 Mount。
35. 至於對 ConfigMap 和 Secret 的依賴，很簡單，Kubectl 查詢即可。
    
36. CrashLoopBackOff 以及 Restart 大於 1
    
37. 這種情況一般來說屬於業務內部的問題，可以通過 kubectl logs -f 命令進行查看，目前經驗比較多的非業務情況是：
    
38. 對於 Kubernetes API 進行訪問的應用，經常會是因爲RBAC 權限不足導致無法啓動
39. 依賴的 Service 無法訪問。

本文轉自中文社區-Kubernetes Informer 詳解