解決Kubernetes Pod故障的5個簡單技巧分別是什么

本篇文章為大家展示了解決Kubernetes Pod故障的5個簡單技巧分別是什么，內(nèi)容簡明扼要并且容易理解，絕對能使你眼前一亮，通過這篇文章的詳細介紹希望你能有所收獲。

在很多情況下，你可能會發(fā)現(xiàn)Kubernetes中的應(yīng)用程序沒有正確地部署，或者沒有正常地工作。今天就提供如何去快速解決這類故障以及一些技巧。另外，我還將與大家分享一些關(guān)于自己操作Kubernetes的一些非常有用的技巧。

那么，我們開始吧！

首先，Pod失敗的原因一般有兩個：

1.  Kubernetes資源配置中的錯誤，例如在部署（Deployment）和服務(wù)（Service）里。

2.  代碼中的問題。

在第一種情況下，容器一般不會啟動。在后一個實例中，應(yīng)用程序代碼在容器啟動后失敗。我們將系統(tǒng)地處理每種情況。

在本練習(xí)中，我們會使用kubectl來實現(xiàn)與Kubernetes的交互。

技巧1：檢查Pod

確認(rèn)Pod處于運行（Running）狀態(tài)或準(zhǔn)備就緒（Ready）的狀態(tài)。

kubectl get pods

如圖，一個Pod在等待（Pending）狀態(tài)9個小時，肯定不是個好事！容器沒有啟動，我們將會使用技巧2中的describe命令對此進行深入地研究。但，在這里我們強調(diào)一下在容器啟動失敗時發(fā)生的其他錯誤代碼。如下：

•  Imagepullbackoff：

        Docker鏡像倉庫不可訪問，部署中指定的鏡像名稱或版本不正確。

        請確保鏡像名稱是正確的，并且鏡像倉庫是可訪問的以及經(jīng)過身份驗證的（docker login…）。

•  RunContainerError：

         也是一種可能。

         原因：

         缺少ConfigMap或Secrets。

•  ContainerCreating：

  容器創(chuàng)建時一些組件無法立刻啟用，比如持久卷？

在研究其他錯誤之前，讓我們先嘗試使用錯誤的鏡像名稱啟動Pod。

# start Pod from image "ngin".  # 'web' can be any name, is the name of resulting K8S deployment  kubectl run web --image=ngin --replicas=1

最后一行展示了鏡像錯誤

果然，完全不存在的鏡像“ngin”導(dǎo)致了ImagePullBackOff錯誤。使用正確的鏡像名稱“nginx”就能解決這個問題。

kubectl run temp --image=nginx --replicas=1  kubectl get pods

如圖，Pod已經(jīng)起來了。

接下來，這里有一些在容器啟動后可能發(fā)生的錯誤。

•  Crashloopbackoff：

        Pod存活檢查失敗或Docker鏡像出錯。

        例如，Docker CMD即刻退出。

        可以用下面的技巧3來檢查日志。

        注意：

        此截圖中的“重啟（RESTARTS）”列顯示了重啟的次數(shù)。

        在這種情況下，你應(yīng)該會看到一些重啟，因為當(dāng)錯誤發(fā)生時，Kubernetes會反復(fù)嘗試啟動Pod。

•  如果Pod處于運行（Running）狀態(tài)，而你的應(yīng)用程序仍然不能正常工作，請繼續(xù)技巧3和4。

技巧2：檢查和Pod相關(guān)的事件

如果你在Pod狀態(tài)上看到一個錯誤代碼，你可以使用describe命令獲得更多信息。這在容器本身沒有啟動的情況下是很有幫助的。

kubectl describe frontend-65c58c957d-f4cqn

截圖的最后一行表明，由于缺少CPU資源，Pod還沒有啟動，請參見底部的消息。你可以增加Pod的CPU再重新部署應(yīng)用程序。

技巧3：檢查日志（Log）

現(xiàn)在容器已經(jīng)啟動，可以通過檢查日志來查看應(yīng)用程序是否正常運行。例如，Pod frontend-65c58c957d-bzbg2：

kubectl logs --tail=10 frontend-65c58c957d-bzbg2

實時滾動查看一個正在運行的日志：

kubectl logs -f frontend-65c58c957d-bzbg2

如果kubectl logs后沒有任何輸出，試試使用get pod，然后會發(fā)現(xiàn)這很有可能是一個新啟動的Pod，因此可以嘗試檢查一些上一次掛掉的Pod的日志。

kubectl logs frontend-65c58c957d-bzbg2 --previous

技巧4：直接在Pod中運行“sh”、“bash”或“ash”

可以進入到Pod內(nèi)部并運行命令來對應(yīng)用程序進行故障排除（輸入exit即可退出）。

kubectl exec -it frontend-65c58c957d-bzbg2 /bin/sh

技巧5：顯示集群級別的事件

Kubernetes在它管理的資源狀態(tài)發(fā)生變化（正常、警告等）時觸發(fā)對應(yīng)的事件。這能幫助我們了解背后到底發(fā)生了什么。get events命令能提供事件的聚合透視圖。

# all events sorted by time.  kubectl get events --sort-by=.metadata.creationTimestamp# warnings only  kubectl get events --field-selector type=Warning# events related to Nodes  kubectl get events --field-selector involvedObject.kind=Node

額外的技巧

這是我最喜歡的技巧！熟練掌握各種命令會使你更有信心在游走在Kubernetes集群中。

首先，輸入kubectl可以列出所有kubectl的命令。

接下來，嘗試用下面的命令來執(zhí)行g(shù)rep調(diào)試命令。

kubectl | grep -i -A 10 debugging

列出可以在Kubernetes上運行的一些基本命令。

kubectl | grep -i -A 5 Basic

接下來，列出可操作的Kubernetes資源。

kubectl api-resources

現(xiàn)在可以自己搞一些命令了！你可以選擇一個命令（get、describe、explain）并選取一個資源然后運行它！例如，get nodes。所以，再試試別的吧！

雖然有些組合可能并沒什么意義，但除了這一點，整個command系統(tǒng)是相當(dāng)直觀和一致的；你可以輕松地編寫命令并進行各種探索。

只是千萬要小心，不要刪除或修改你不希望碰到的對象。

列出Kubernetes命名空間（namespace）：

kubectl get ns

這樣，你可以使用特定的命令來更深入地研究相應(yīng)的選項或示例。

kubectl get --help  # see K8S system pods in 'kube-system' namespace!  kubectl -n kube-system get pods

正如你所看到的，Kubernetes的命令系統(tǒng)非常容易理解，簡單地測試這些命令能讓我們學(xué)到很多東西。

有了這些，我希望你能在Kubernetes集群中找到并修復(fù)Kubernetes資源和代碼中的錯誤。同時我打算接下來再介紹一下Kubernetes服務(wù)（Service）和網(wǎng)絡(luò)的調(diào)試。

上述內(nèi)容就是解決Kubernetes Pod故障的5個簡單技巧分別是什么，你們學(xué)到知識或技能了嗎？如果還想學(xué)到更多技能或者豐富自己的知識儲備，歡迎關(guān)注億速云行業(yè)資訊頻道。