應(yīng)用程序故障排查(kubectl)
常見問題
故障診斷
--- 排查Pods的故障
Pod始終處于Pending狀態(tài)
Pod始終處于Waiting狀態(tài)
Pod一直崩潰或運(yùn)行不正常
--- 排查Replication Controllers的故障
--- 排查Services的故障
- 服務(wù)沒有端點(diǎn)信息
故障診斷
故障排查的第一步是對(duì)故障進(jìn)行分類。一般來說，應(yīng)用程序的故障可以分為下面幾個(gè)方面：
- Pods的故障
- ReplicationControllers的故障
- Services的故障
插入一些比較常用的命令：
Kubectl get nodes:獲取所有kubenetes的節(jié)點(diǎn)
Kubectl get namespace:獲取所有
kubectl –n testnm get svc:獲取namesapce為testnm下所有的service
Kubectl –n testnm get pods –o wide: 獲取namesapce為testnm下的所有的pod,并可現(xiàn)實(shí)pod實(shí)例化在哪個(gè)kubectl的節(jié)點(diǎn)上
Kubectl –n testnm get pods:獲取namesapce為testnm下的所有的pod
Kubectl –n testnm logs [podName]:查看pod的日志
Kubectl –n testnm logs –f [podName]:實(shí)時(shí)查看pod的日志
Kubectl –n testnm describe pod [podName]:查看pod的狀態(tài)
kubectl -n testnm exec -it [podName] /bin/bash:進(jìn)入到指定的容器內(nèi)
排查Pods的故障
檢查Pod的問題首先應(yīng)該了解Pod所處的狀況。下面這個(gè)命令能夠獲得Pod當(dāng)前的狀態(tài)和近期的事件列表：
$ kubectl describe pods ${POD_NAME}
確認(rèn)清楚在Pod以及其中每一個(gè)容器的狀態(tài)，是否都處于Runing？通過觀察容器的已運(yùn)行時(shí)間判斷它是否剛剛才重新啟動(dòng)過？
根據(jù)不同的運(yùn)行狀態(tài)，用戶應(yīng)該采取不同的調(diào)查措施。
注解：
Name:容器的名稱
Ready：1/1 前1為可用的有多少個(gè)，后1為總共多少個(gè)
Status:運(yùn)行狀態(tài)（pending，waiting，running…）
Restarts：重啟的次數(shù)
Age：?jiǎn)?dòng)的總時(shí)間
Ip:容器的ip地址
Node：容器在kubenetes的哪個(gè)節(jié)點(diǎn)上啟動(dòng)
- Pod始終處于Pending狀態(tài)
如果Pod保持在Pending的狀態(tài)，這意味著它無法被正常的調(diào)度到一個(gè)節(jié)點(diǎn)上。通常來說，這是由于某種系統(tǒng)資源無法滿足Pod運(yùn)行的需求。觀察剛才kubectl describe命令的輸出內(nèi)容，其中應(yīng)該包括了能夠判斷錯(cuò)誤原因的消息。常見的原因有以下這些：
系統(tǒng)沒有足夠的資源：你也許已經(jīng)用盡了集群中所有的CPU或內(nèi)存資源。對(duì)于這種情況，你需要清理一些不在需要的Pod，調(diào)整它們所需的資源量，或者向集群中增加新的節(jié)點(diǎn)。在計(jì)算資源文檔有更詳細(xì)的說明。
用戶指定了hostPort：通過hostPort用戶能夠?qū)⒎?wù)暴露到指定的主機(jī)端口上，但這樣會(huì)限制Pod能夠被調(diào)度運(yùn)行的節(jié)點(diǎn)。在大多數(shù)情況下，hostPort配置都是沒有必要的，用戶應(yīng)該采用Service的方式暴露其對(duì)外的服務(wù)。如果用戶確實(shí)必須使用hostPort的功能，那么此Pod最多只能部署到和集群節(jié)點(diǎn)相同的數(shù)目
- Pod始終處于Waiting狀態(tài)
Pod處在Waiting的狀態(tài)，說明它已經(jīng)被調(diào)度分配到了一個(gè)工作節(jié)點(diǎn)，然而它無法在那個(gè)節(jié)點(diǎn)上運(yùn)行。同樣的，在剛才kubectl describe命令的輸出內(nèi)容中，應(yīng)該包含有更詳細(xì)的錯(cuò)誤信息。最經(jīng)常導(dǎo)致Pod始終Waiting的原因是無法下載所需的鏡像（譯者注：由于國內(nèi)特殊的網(wǎng)絡(luò)環(huán)境，這類問題出現(xiàn)得特別普遍）。用戶可以從下面三個(gè)方面進(jìn)行排查：
請(qǐng)確保正確書寫了鏡像的名稱
請(qǐng)檢查所需鏡像是否已經(jīng)推送到了倉庫中
手工的在節(jié)點(diǎn)上運(yùn)行一次docker pull <鏡像名稱>檢測(cè)鏡像能否被正確的拉取下來
- Pod一直崩潰或運(yùn)行不正常
首先，查看正在運(yùn)行容器的日志。
$ kubectl logs <Pod名稱> <Pod中的容器名稱>
如果容器之前已經(jīng)崩潰過，通過以下命令可以獲得容器前一次運(yùn)行的日志內(nèi)容。
$ kubectl logs --previous <Pod名稱> <Pod中的容器名稱>
此外，還可以使用exec命令在指定的容器中運(yùn)行任意的調(diào)試命令。
$ kubectl exec <Pod名稱> -c <Pod中的容器名稱> -- <任意命令> <命令參數(shù)列表...>
Kubectl –n testnm exec -it [podName] /bin/bash 這條命令可以進(jìn)入到pod容器中
排查Replication Controllers的故障
Replication Controllers的邏輯十分直白，它的作用只是創(chuàng)建新的Pod副本，僅僅可能出現(xiàn)的錯(cuò)誤便是它無法創(chuàng)建正確的Pod，對(duì)于這種情況，應(yīng)該參考上面的『排查Pods的故障』部分進(jìn)行檢查。
也可以使用kubectl describe rc <控制器名稱>來顯示與指定Replication Controllers相關(guān)的事件信息。
排查Services的故障
Service為一系列后端Pod提供負(fù)載均衡的功能。有些十分常見的故障都可能導(dǎo)致Service無法正常工作，以下將提供對(duì)調(diào)試Service相關(guān)問題的參考。
首先，檢查Service連接的服務(wù)提供端點(diǎn)（endpoint），對(duì)于任意一個(gè)Service對(duì)象，apiserver都會(huì)為其創(chuàng)建一個(gè)端點(diǎn)資源（譯者注：即提供服務(wù)的IP地址和端口號(hào)）。
這個(gè)命令可以查看到Service的端口資源：
$ kubectl get endpoints <Service名稱>
$ Kubectl –n testnm get pods –o wide
$ Kubectl –n testnm get endpoints [podName]
請(qǐng)檢查這個(gè)命令輸出端點(diǎn)信息中的端口號(hào)與實(shí)際容器提供服務(wù)的端口號(hào)是否一致。例如，如果你的Service使用了三個(gè)Nginx容器的副本（replicas），這個(gè)命令應(yīng)該輸出三個(gè)不同的IP地址的端點(diǎn)信息。
- 服務(wù)沒有端點(diǎn)信息
如果剛剛的命令顯示Service沒有端點(diǎn)信息，請(qǐng)嘗試通過Service的選擇器找到具有相應(yīng)標(biāo)簽的所有Pod。假設(shè)你的Service描述選擇器內(nèi)容如下：
Kubectl –n testnm describe svc [svcName]
公共應(yīng)用技術(shù)部-內(nèi)部 > kubectl 常見問題排查方法 > image2019-1-23_9-48-5.png
可以使用以下命令找出相應(yīng)的Pod：
$ kubectl get pods --selector=name=nginx,type=frontend
找到了符合標(biāo)簽的Pod后，首先確認(rèn)這些被選中的Pod是正確，有無錯(cuò)選、漏選的情況。
如果被選中的Pod沒有問題，則問題很可能出在這些Pod暴露的端口沒有被正確的配置好。要是一個(gè)Service指定了containerPort，但被選中的Pod并沒有在配置中列出相應(yīng)的端口，它們就不會(huì)出現(xiàn)在端點(diǎn)列表中。
請(qǐng)確保所用Pod的containerPort與Service的containerPort配置信息是一致的。
