應(yīng)用程序故障排查(kubectl)

常見問(wèn)題

故障診斷

--- 排查Pods的故障

• Pod始終處于Pending狀態(tài)

• Pod始終處于Waiting狀態(tài)

• Pod一直崩潰或運(yùn)行不正常

--- 排查Replication Controllers的故障

--- 排查Services的故障

• 服務(wù)沒(méi)有端點(diǎn)信息

故障診斷

故障排查的第一步是對(duì)故障進(jìn)行分類拙吉。一般來(lái)說(shuō)，應(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的問(wèn)題首先應(yīng)該了解Pod所處的狀況禀晓。下面這個(gè)命令能夠獲得Pod當(dāng)前的狀態(tài)和近期的事件列表：
$ kubectl describe pods ${POD_NAME}

確認(rèn)清楚在Pod以及其中每一個(gè)容器的狀態(tài)滚躯，是否都處于Runing轮蜕？通過(guò)觀察容器的已運(yùn)行時(shí)間判斷它是否剛剛才重新啟動(dòng)過(guò)？

根據(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)葛作，這意味著它無(wú)法被正常的調(diào)度到一個(gè)節(jié)點(diǎn)上寿羞。通常來(lái)說(shuō)，這是由于某種系統(tǒng)資源無(wú)法滿足Pod運(yùn)行的需求赂蠢。觀察剛才kubectl describe命令的輸出內(nèi)容绪穆，其中應(yīng)該包括了能夠判斷錯(cuò)誤原因的消息。常見的原因有以下這些：

系統(tǒng)沒(méi)有足夠的資源：你也許已經(jīng)用盡了集群中所有的CPU或內(nèi)存資源虱岂。對(duì)于這種情況玖院，你需要清理一些不在需要的Pod，調(diào)整它們所需的資源量第岖，或者向集群中增加新的節(jié)點(diǎn)难菌。在計(jì)算資源文檔有更詳細(xì)的說(shuō)明。

用戶指定了hostPort：通過(guò)hostPort用戶能夠?qū)⒎?wù)暴露到指定的主機(jī)端口上蔑滓，但這樣會(huì)限制Pod能夠被調(diào)度運(yùn)行的節(jié)點(diǎn)郊酒。在大多數(shù)情況下，hostPort配置都是沒(méi)有必要的键袱，用戶應(yīng)該采用Service的方式暴露其對(duì)外的服務(wù)燎窘。如果用戶確實(shí)必須使用hostPort的功能，那么此Pod最多只能部署到和集群節(jié)點(diǎn)相同的數(shù)目

• Pod始終處于Waiting狀態(tài)

Pod處在Waiting的狀態(tài)杠纵，說(shuō)明它已經(jīng)被調(diào)度分配到了一個(gè)工作節(jié)點(diǎn)荠耽，然而它無(wú)法在那個(gè)節(jié)點(diǎn)上運(yùn)行。同樣的比藻，在剛才kubectl describe命令的輸出內(nèi)容中铝量，應(yīng)該包含有更詳細(xì)的錯(cuò)誤信息。最經(jīng)常導(dǎo)致Pod始終Waiting的原因是無(wú)法下載所需的鏡像（譯者注：由于國(guó)內(nèi)特殊的網(wǎng)絡(luò)環(huán)境银亲，這類問(wèn)題出現(xiàn)得特別普遍）慢叨。用戶可以從下面三個(gè)方面進(jìn)行排查：

請(qǐng)確保正確書寫了鏡像的名稱

請(qǐng)檢查所需鏡像是否已經(jīng)推送到了倉(cāng)庫(kù)中

手工的在節(jié)點(diǎn)上運(yùn)行一次docker pull <鏡像名稱>檢測(cè)鏡像能否被正確的拉取下來(lái)

• Pod一直崩潰或運(yùn)行不正常

首先，查看正在運(yùn)行容器的日志务蝠。

$ kubectl logs <Pod名稱> <Pod中的容器名稱>

如果容器之前已經(jīng)崩潰過(guò)拍谐，通過(guò)以下命令可以獲得容器前一次運(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ò)誤便是它無(wú)法創(chuàng)建正確的Pod亡蓉，對(duì)于這種情況晕翠，應(yīng)該參考上面的『排查Pods的故障』部分進(jìn)行檢查。
也可以使用kubectl describe rc <控制器名稱>來(lái)顯示與指定Replication Controllers相關(guān)的事件信息砍濒。

排查Services的故障

Service為一系列后端Pod提供負(fù)載均衡的功能淋肾。有些十分常見的故障都可能導(dǎo)致Service無(wú)法正常工作，以下將提供對(duì)調(diào)試Service相關(guān)問(wè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ù)沒(méi)有端點(diǎn)信息

如果剛剛的命令顯示Service沒(méi)有端點(diǎn)信息陪白，請(qǐng)嘗試通過(guò)Service的選擇器找到具有相應(yīng)標(biāo)簽的所有Pod颈走。假設(shè)你的Service描述選擇器內(nèi)容如下：

Kubectl –n testnm describe svc [svcName]

公共應(yīng)用技術(shù)部-內(nèi)部 > kubectl 常見問(wèn)題排查方法 > image2019-1-23_9-48-5.png

可以使用以下命令找出相應(yīng)的Pod：

$ kubectl get pods --selector=name=nginx,type=frontend

找到了符合標(biāo)簽的Pod后，首先確認(rèn)這些被選中的Pod是正確咱士，有無(wú)錯(cuò)選立由、漏選的情況。

如果被選中的Pod沒(méi)有問(wèn)題序厉，則問(wèn)題很可能出在這些Pod暴露的端口沒(méi)有被正確的配置好锐膜。要是一個(gè)Service指定了containerPort，但被選中的Pod并沒(méi)有在配置中列出相應(yīng)的端口弛房，它們就不會(huì)出現(xiàn)在端點(diǎn)列表中道盏。

請(qǐng)確保所用Pod的containerPort與Service的containerPort配置信息是一致的。