在很多情況下,你可能會發(fā)現(xiàn)Kubernetes中的應(yīng)用程序沒有正確地部署,或者沒有正常地工作。今天這篇文章就提供了如何去快速解決這類故障以及一些技巧。
在閱讀了這篇文章之后,你還將深入了解Kubernetes的內(nèi)部機制,另外,我還將與大家分享一些關(guān)于自己操作Kubernetes的一些非常有用的技巧。
那么,我們開始吧!
首先,Pod失敗的原因一般有兩個:
Kubernetes資源配置中的錯誤,例如在部署(Deployment)和服務(wù)(Service)里。
代碼中的問題。
在第一種情況下,容器一般不會啟動。在后一個實例中,應(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命令對此進(jìn)行深入地研究。但,在這里我們強調(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”
可以進(jìn)入到Pod內(nèi)部并運行命令來對應(yīng)用程序進(jìn)行故障排除(輸入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)直觀和一致的;你可以輕松地編寫命令并進(jìn)行各種探索。
只是千萬要小心,不要刪除或修改你不希望碰到的對象。
列出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é)到很多東西。
結(jié)論
有了這些,我希望你能在Kubernetes集群中找到并修復(fù)Kubernetes資源和代碼中的錯誤。同時我打算接下來再介紹一下Kubernetes服務(wù)(Service)和網(wǎng)絡(luò)的調(diào)試。
如果你已經(jīng)走了這么遠(yuǎn),我想感謝你對學(xué)習(xí)Kubernetes的堅持和奉獻(xiàn)。請在下面留下你的評論,如果你有什么想法,或者有什么想談?wù)摰脑掝},也請告訴我。
最后,如果你想在Kubernetes中部署一個真實的應(yīng)用程序,請閱讀我的上一篇文章。然后可以使用命令和故障排除工具對其進(jìn)行修補。
翻譯:伊海峰
來源:http://dockone.io/article/10055
免責(zé)聲明:本文內(nèi)容由21ic獲得授權(quán)后發(fā)布,版權(quán)歸原作者所有,本平臺僅提供信息存儲服務(wù)。文章僅代表作者個人觀點,不代表本平臺立場,如有問題,請聯(lián)系我們,謝謝!