Kubernetes應(yīng)用部署問題怎么處理

這篇文章主要講解了“Kubernetes應(yīng)用部署問題怎么處理”，文中的講解內(nèi)容簡單清晰，易于學(xué)習(xí)與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學(xué)習(xí)“Kubernetes應(yīng)用部署問題怎么處理”吧！

1、應(yīng)用部署問題處理的整體思路

在將容器化的應(yīng)用部署到Kubernetes集群中，可能會出現(xiàn)各種問題。根據(jù)Kubernetes的架構(gòu)設(shè)計(jì)原理，容器化應(yīng)用對外提供服務(wù)出現(xiàn)的主要問題在三個(gè)點(diǎn)上：

1）應(yīng)用本身的問題：此問題為應(yīng)用本身的問題，不在此文中進(jìn)行詳細(xì)的闡述；

2）作為容器化應(yīng)用邏輯主機(jī)的Pod的問題：此部分的問題主要涉及到容器化應(yīng)用是否在容器云中正常部署和運(yùn)行，這里會涉及到CPU、內(nèi)存、存儲資源等問題；

3）代理容器化應(yīng)用服務(wù)的問題：第三方服務(wù)或用戶會通過代理服務(wù)訪問容器化應(yīng)用，如果代理服務(wù)存在問題，則容器云應(yīng)用將無法對外提供服務(wù)能力，這里會涉及到服務(wù)是否存在、DNS解析是否正確等問題。

在本文中，以部署的高可用MySQL為例展示如何進(jìn)行問題定位和處理。另外為了能夠在Kubernetes集群外訪問MySQL數(shù)據(jù)庫，對外暴露了MySQL master的NodePort類型服務(wù)，服務(wù)名稱為mysql-0-svc。

2、調(diào)試Pods

在調(diào)試Pod之前，通過kubectl get pods命令查看一下Pod的運(yùn)行狀態(tài)。

$ kubectl get pods --namespace=kube-public

對于特定的Pod，可以通過kubectl describe pods命令查看詳細(xì)的信息。

$ kubectl describe pods/mysql-0 --namespace=kube-public

在Pod的生命周期中，有如下的幾個(gè)狀態(tài)：

• Pending: Pod已經(jīng)被Kubernetes系統(tǒng)接受，但是還有一個(gè)或者多個(gè)容器鏡像未被創(chuàng)建。這包括Pod正在被調(diào)度和從網(wǎng)絡(luò)上下載鏡像的時(shí)間。

• Running: Pod已經(jīng)被綁定到了一個(gè)Node，所有的容器也已經(jīng)被創(chuàng)建。至少有一個(gè)容器已經(jīng)在運(yùn)行，或者在啟動(dòng)或者重新啟動(dòng)的過程中。

• Succeeded: 在Pod中的所有的容器都已經(jīng)被成功的終止，并且不會再重啟。

• Failed: 在Pod中所有容器都已經(jīng)被終止，并且至少有一個(gè)容器是非正常終止的。即，容器以非零狀態(tài)退出或者被系統(tǒng)強(qiáng)行終止的。

• Unknown: 由于某些原因，Pod不能被獲取，典型的情況是在與Pod的主機(jī)進(jìn)行通信中發(fā)生了失敗。

• Waiting：由于某些原因，Pod已被調(diào)度到了Node節(jié)點(diǎn)上，但無法正常運(yùn)行。

• Crashing：由于某些原因，Pod處于崩潰狀態(tài)。

根據(jù)Pod所處的狀態(tài)，相應(yīng)的處理方式不同。

2.1 Pod處于待命（Pending）狀態(tài)

如果Pod被卡在待命（Pending）狀態(tài)，則意味著它無法被安排到Node節(jié)點(diǎn)上。造成這種情況通常因?yàn)槟撤N類型的資源不足，從而導(dǎo)致Pod無法被調(diào)度。通過查看kubectl describe …命令的輸出內(nèi)容，應(yīng)該有為什么Pod無法被調(diào)度的原因。這些原因包括：

• 沒有足夠的資源：集群中的CPU或內(nèi)存可能已經(jīng)耗盡了，在這種情況下，需要?jiǎng)h除Pod，調(diào)整資源請求或向集群中添加新的Node節(jié)點(diǎn)。

• 正在使用hostPort：將Pod綁定到了數(shù)量有限的hostPort。在大多數(shù)情況下，沒有必要使用hostPort，可以嘗試使用服務(wù)來暴露Pod。如果確實(shí)需要hostPort，那么只能調(diào)度與Kubernetes集群中的節(jié)點(diǎn)一樣多的Pod。

2.2 Pod處于等待（Waiting）狀態(tài)

如果Pod處于等待（Waiting）狀態(tài)，則它已被調(diào)度到一個(gè)工作Node上，但它無法在該Node上運(yùn)行。同樣，通過kubectl describe …應(yīng)該是能夠獲取有用的信息。處于等待（Waiting）狀態(tài)的最常見的原因是無法拉取鏡像。有三件事需要檢查：

• 確保鏡像名稱正確無誤。

• 確認(rèn)鏡像倉庫中是否存在此鏡像？

• 在機(jī)器上，運(yùn)行docker pull <image>命令，查看是否可以拉取鏡像。

2.3 Pod崩潰（Crashing）或其他不健康

首先，通過執(zhí)行kubectl logs ${POD_NAME} ${CONTAINER_NAME}查看當(dāng)前容器的日志：

$ kubectl logs mysql-0 mysql --namespace=kube-public

如果容器之前已崩潰，可以使用以下命令訪問上一個(gè)容器的崩潰日志：

$ kubectl logs --previous mysql-0 mysql --namespace=kube-public

或者，也可以使用kubectl exec在該容器內(nèi)運(yùn)行命令：

$ kubectl exec ${POD_NAME} -c ${CONTAINER_NAME} -- ${CMD} ${ARG1} ${ARG2} ... ${ARGN}

請注意，這-c ${CONTAINER_NAME}是可選的，對于僅包含單個(gè)容器的Pod，可以省略。

如果這些方法都不起作用，可以找到運(yùn)行該pod的主機(jī)，并通過SSH連接到該主機(jī)。

2.4 Pod正在運(yùn)行，但沒有按照要求執(zhí)行

如果Pod沒有按預(yù)期運(yùn)行，可能是Pod描述中存在錯(cuò)誤，并且在創(chuàng)建Pod時(shí)忽略了該錯(cuò)誤。通?？赡苁牵琍od描述的一部分嵌套不正確，或鍵名不正確，因此鍵被忽略。例如，如果拼寫錯(cuò)誤command，commnd則將創(chuàng)建Pod，但不會按照希望使用命令行。

首先，要做的第一件事是刪除此Pod，并嘗試使用–validate選項(xiàng)再次創(chuàng)建它。例如，運(yùn)行kubectl create –validate -f mypod.yaml。如果拼寫錯(cuò)誤command，commnd那么會出現(xiàn)如下錯(cuò)誤：

I0805 10:43:25.129850   46757 schema.go:126] unknown field: commnd
I0805 10:43:25.129973   46757 schema.go:129] this may be a false alarm, see https://github.com/kubernetes/kubernetes/issues/6842pods/mypod

接下來，要檢查的是apiserver上的Pod是否與要?jiǎng)?chuàng)建的Pod相匹配。例如，運(yùn)行kubectl get pods/mypod -o yaml > mypod-on-apiserver.yaml，然后將原始的Pod描述mypod.yaml與從apiserver返回的描述文件mypod-on-apiserver.yaml進(jìn)行比較?！癮piserver”版本通常會有一些不在原始版本上的內(nèi)容，這不影響。但是，如果原始版本上有不在apiserver版本上的行，則可能意味著原始版本Pod描述規(guī)范存在問題。

3、調(diào)試代理服務(wù)

根據(jù)Kubernetes的架構(gòu)設(shè)計(jì)，用戶或其它應(yīng)用通過代理服務(wù)訪問容器化應(yīng)用。因此需要通過調(diào)試確認(rèn)代理服務(wù)是否正常，需要做的工作包括：

1）檢查代理服務(wù)本身是否存在；

2）檢查代理服務(wù)是否能夠正常通過DNS進(jìn)行解析；

3）檢查代理服務(wù)本身是否正確。

3.1 檢查服務(wù)是否存在

在調(diào)試服務(wù)時(shí)，第一步要做的就是檢查服務(wù)是否存在。在本文的前面說明了，在Kubernetes中通過NodePort類型對外暴露了MySQL master。通過執(zhí)行kubectl get svc命令，可以獲取是否存在相應(yīng)服務(wù)：

$ kubectl get svc/mysql-0-svc --namespace=kube-public

通過返回的結(jié)果可以看出，在Kubernetes集群中存在此服務(wù)。

3.2 能否通過DNS解析正常解析代理服務(wù)

對于處于同一個(gè)命名空間的容器化應(yīng)用，可以直接通過代理服務(wù)的名稱(mysql-0-svc)訪問MySQL master。

$ kubectl exec -it redis-ha-redis-ha-sentinel-5947b9569-r2b56 --namespace=kube-public -- nslookup mysql-0-svc

對Kubernetes集群中不同命名空間的容器化應(yīng)用，則需要通過添加命名空間名稱后(mysql-0-svc.kube-public)訪問MySQL master：

$ kubectl exec -it gf1-6497d5df45-98g8v -- nslookup mysql-0-svc.kube-public

根據(jù)返回的可以看出，通過DNS能夠正確的解析代理服務(wù)。

3.2.1 DNS是否正常工作

如果通過上述的操作都無法正常解析服務(wù)，通過kubectl exec -it  ${POD_NAME}  — nslookup命令檢查一下Kubernetes master是否正常工作：

$ kubectl exec -it gf1-6497d5df45-98g8v -- nslookup kubernetes.default

如果此操作也失敗，則需要檢查Kubernetes集群中的DNS服務(wù)是否正常運(yùn)行。

3.3 代理服務(wù)本身是否正確

如果代理服務(wù)也存在，DNS解析也沒有問題。則需要檢查一下代理服務(wù)本身是否有問題：

$ kubectl get service mysql-0-svc -o yaml --namespace=kube-public

例如訪問的端口是否正確？targetPort是否指向了正確的Pods端口？這里的端口協(xié)議是否與Pod暴露出來的端口協(xié)議一致等。

感謝各位的閱讀，以上就是“Kubernetes應(yīng)用部署問題怎么處理”的內(nèi)容了，經(jīng)過本文的學(xué)習(xí)后，相信大家對Kubernetes應(yīng)用部署問題怎么處理這一問題有了更深刻的體會，具體使用情況還需要大家實(shí)踐驗(yàn)證。這里是億速云，小編將為大家推送更多相關(guān)知識點(diǎn)的文章，歡迎關(guān)注！