Kubernetes部署失敗的常見原因

責(zé)任編輯:editor004

作者:Hrishikesh Barua

2017-03-07 11:32:43

摘自:INFOQ

另一種部署失敗的原因是無效的Kubernetes Spec對象,這些無效對象是由YAML中的縮進(jìn)錯誤或拼寫錯誤所導(dǎo)致。文章的作者已開源一個腳本,當(dāng)創(chuàng)建失敗時,該腳本可以在日志里打印出有用的相關(guān)信息。

最近一系列的文章重點(diǎn)介紹了Kubernetes部署失敗的10種常見原因。這些原因涵蓋了從缺少輸入和錯誤輸入,到超出資源限制。在大多數(shù)情況下,kubectl describe命令可以幫助確定背后的原因。

Kubernetes部署的無效輸入包括指定不存在的容器鏡像,或者指定沒有訪問權(quán)限的容器鏡像。因為默認(rèn)注冊表是Dockerhub,所以如果使用了其它注冊表(如Amazon ECR或Quay.io),則需要指定注冊表URL。私有注冊表在訪問鏡像時需要相關(guān)證書。 當(dāng)要拉取的標(biāo)簽名稱無效時,鏡像拉取也可能遇到錯誤。比如在latest標(biāo)簽不存在但鏡像存在時,鏡像拉取就會失敗(如果沒有特別指定,“latest”就是默認(rèn)標(biāo)簽)。此外網(wǎng)絡(luò)問題也可能會導(dǎo)致錯誤。這類情況下的錯誤消息彼此間十分相似,因此需要更深入的檢查以確定確切的原因。

Kubernetes中的部署失敗常常導(dǎo)致特定的Pod無法啟動??梢允褂?ldquo;kubectl describe pod ”命令輸出描述失敗原因的事件日志。kubectl命令采用“pod”,“replicaset”,和“deployment”參數(shù)。這些命令與“kubectl logs ”組合是調(diào)試部署失敗的關(guān)鍵。

如果把Kubernetes中的默認(rèn)策略設(shè)置為不總是從注冊表中拉取,則即使提交了更新后的改動并推送鏡像,這些改動也可能不可見。在產(chǎn)品中推薦的解決方法是為每個鏡像分配唯一標(biāo)簽,并在拉取請求中使用這些標(biāo)簽。此外在部署配置中指定不存在的持久卷(persistent volumes)也可能導(dǎo)致部署失敗。

另外兩種無效輸入是缺少程序運(yùn)行時ConfigMap或Secrets,以及無效的Spec對象。 ConfigMap是一組鍵值對的映射,該組鍵值對屬于應(yīng)用程序所需的配置數(shù)據(jù)。ConfigMap可以被指定為CLI參數(shù),環(huán)境變量,或已安裝卷中的文件。如果缺少了這些信息,那么Pod創(chuàng)建會停止,并且狀態(tài)被設(shè)置為“RunContainerError”。Secrets是一種用于存儲敏感數(shù)據(jù)(如證書)的機(jī)制。Secrets缺失將導(dǎo)致類似的問題。ConfigMap和Secrets都可以安裝為卷,如果安裝失敗,則容器創(chuàng)建停止,事件日志的狀態(tài)停留在“ContainerCreating”。

另一種部署失敗的原因是無效的Kubernetes Spec對象,這些無效對象是由YAML中的縮進(jìn)錯誤或拼寫錯誤所導(dǎo)致。通過基于CLI的YAML驗證和使用--dry-run參數(shù),我們可以很容易地避免此類錯誤,如下所示:

kubectl create -f test-application.deploy.yaml --dry-run --validate=true

但該方法需要運(yùn)行Kubernetes集群。移除對集群依賴的工作正在進(jìn)行當(dāng)中,同時也會提供對客戶端驗證的支持。YAML驗證可以被添加到源控制系統(tǒng)中,成為預(yù)提交鉤子(pre-commit hook)的一部分。

另一類失敗的Kubernetes部署是因為超出資源限制。Pod和容器都有指定的CPU和內(nèi)存限制。超出這些限制將導(dǎo)致無法創(chuàng)建Pod。調(diào)試該問題需要花一點(diǎn)精力。命令“kubectl describe deployment ”可以幫助我們獲取ReplicaSet的名稱,此ReplicaSet正是Kubernetes所嘗試去創(chuàng)建的。鍵入“kubectrl describe replicaset ”,并把上一步中獲取的副本集(replica set)名稱傳遞給它,就可以像在其它情況下一樣,打印出事件日志,并顯示錯誤消息。

部署失敗也可能是因為超出資源配額。當(dāng)團(tuán)隊間共享節(jié)點(diǎn)數(shù)固定的集群時,這種資源配額機(jī)制可以用來限制每個命名空間的資源消耗。資源包括Pod,服務(wù)和部署,以及計算資源的總量。 同樣,在這種情況下,“kubectl describe”命令能夠幫助我們挖掘出實際的錯誤消息。

當(dāng)節(jié)點(diǎn)未充分使用資源時或者由于資源不足而無法運(yùn)行Pod時,集群自動調(diào)整程序(cluster autoscaler)會自動調(diào)整Kubernetes集群大小。如果該自動調(diào)整程序未被啟用,那么超出資源配額的部署將會失敗,并且Pod停留在“Pending”狀態(tài)。 事件日志將顯示出實際短缺的資源(由于該資源短缺而導(dǎo)致部署失?。?。

應(yīng)用程序行為的意外更改可能以不同的方式引起部署失敗。應(yīng)用程序崩潰常常會導(dǎo)致啟動錯誤,該錯誤的錯誤消息是“CrashLoopBackOff”。應(yīng)用程序日志可以幫助解決此問題。此外,如果配置錯誤或者響應(yīng)超時,Liveness/Readiness探測可能會停止工作,該探測被Kubernetes用來檢測服務(wù)的健康情況。例如,URL健康檢查可能在應(yīng)用程序中已發(fā)生變更,或者由于數(shù)據(jù)庫變動,URL健康檢查可能無法正常工作。某些URL可能需要一段時間才能響應(yīng)Readiness檢查,這可能會超時并導(dǎo)致部署失敗。

文章的作者已開源一個腳本,當(dāng)創(chuàng)建失敗時,該腳本可以在日志里打印出有用的相關(guān)信息。

查看英文原文:Common Reasons for Failed Kubernetes Deployments

鏈接已復(fù)制,快去分享吧

企業(yè)網(wǎng)版權(quán)所有?2010-2024 京ICP備09108050號-6京公網(wǎng)安備 11010502049343號