如果把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）名稱傳遞給它，就可以像在其它情況下一樣，打印出事件日志，并顯示錯誤消息。