共计 2756 个字符，预计需要花费 7 分钟才能阅读完成。
Kubernetes 部署的无效输入包括指定不存在的容器镜像，或者指定没有访问权限的容器镜像。因为默认注册表是 Dockerhub，所以如果使用了其它注册表（如 Amazon ECR 或 Quay.io），则需要指定注册表 URL。私有注册表在访问镜像时需要相关证书。当要拉取的标签名称无效时，镜像拉取也可能遇到错误。比如在 latest 标签不存在但镜像存在时，镜像拉取就会失败（如果没有特别指定，“latest”就是默认标签）。此外网络问题也可能会导致错误。这类情况下的错误消息彼此间十分相似，因此需要更深入的检查以确定确切的原因。
Kubernetes 中的部署失败常常导致特定的 Pod 无法启动。可以使用“kubectl describe pod <pod-name>”命令输出描述失败原因的事件日志。kubectl 命令采用“pod”，“replicaset”，和“deployment”参数。这些命令与“kubectl logs <podname>”组合是调试部署失败的关键。
如果把 Kubernetes 中的默认策略设置为不总是从注册表中拉取，则即使提交了更新后的改动并推送镜像，这些改动也可能不可见。在产品中推荐的解决方法是为每个镜像分配唯一标签，并在拉取请求中使用这些标签。此外在部署配置中指定不存在的持久卷（persistent volumes）也可能导致部署失败。
另外两种无效输入是缺少程序运行时 ConfigMap 或 Secrets，以及无效的 Spec 对象。ConfigMap 是一组键值对的映射，该组键值对属于应用程序所需的配置数据。ConfigMap 可以被指定为 CLI 参数，环境变量，或已安装卷中的文件。如果缺少了这些信息，那么 Pod 创建会停止，并且状态被设置为“RunContainerError”。Secrets 是一种用于存储敏感数据（如证书）的机制。Secrets 缺失将导致类似的问题。ConfigMap 和 Secrets 都可以安装为卷，如果安装失败，则容器创建停止，事件日志的状态停留在“ContainerCreating”。
另一种部署失败的原因是无效的 Kubernetes Spec 对象，这些无效对象是由 YAML 中的缩进错误或拼写错误所导致。通过基于 CLI 的 YAML 验证和使用 –dry-run 参数，我们可以很容易地避免此类错误，如下所示：
kubectl create -f test-application.deploy.yaml --dry-run --validate=true
但该方法需要运行 Kubernetes 集群。移除对集群依赖的工作正在进行当中，同时也会提供对客户端验证的支持。YAML 验证可以被添加到源控制系统中，成为预提交钩子（pre-commit hook）的一部分。
另一类失败的 Kubernetes 部署是因为超出资源限制。Pod 和容器都有指定的 CPU 和内存限制。超出这些限制将导致无法创建 Pod。调试该问题需要花一点精力。命令“kubectl describe deployment <deployment name>”可以帮助我们获取 ReplicaSet 的名称，此 ReplicaSet 正是 Kubernetes 所尝试去创建的。键入“kubectrl describe replicaset <replicaset name>”，并把上一步中获取的副本集（replica set）名称传递给它，就可以像在其它情况下一样，打印出事件日志，并显示错误消息。
部署失败也可能是因为超出资源配额。当团队间共享节点数固定的集群时，这种资源配额机制可以用来限制每个命名空间的资源消耗。资源包括 Pod，服务和部署，以及计算资源的总量。同样，在这种情况下，“kubectl describe”命令能够帮助我们挖掘出实际的错误消息。
当节点未充分使用资源时或者由于资源不足而无法运行 Pod 时，集群自动调整程序（cluster autoscaler）会自动调整 Kubernetes 集群大小。如果该自动调整程序未被启用，那么超出资源配额的部署将会失败，并且 Pod 停留在“Pending”状态。事件日志将显示出实际短缺的资源（由于该资源短缺而导致部署失败）。
应用程序行为的意外更改可能以不同的方式引起部署失败。应用程序崩溃常常会导致启动错误，该错误的错误消息是“CrashLoopBackOff”。应用程序日志可以帮助解决此问题。此外，如果配置错误或者响应超时，Liveness/Readiness 探测可能会停止工作，该探测被 Kubernetes 用来检测服务的健康情况。例如，URL 健康检查可能在应用程序中已发生变更，或者由于数据库变动，URL 健康检查可能无法正常工作。某些 URL 可能需要一段时间才能响应 Readiness 检查，这可能会超时并导致部署失败。
文章的作者已开源一个脚本，当创建失败时，该脚本可以在日志里打印出有用的相关信息。
Docker 中部署 Kubernetes http://www.linuxidc.com/Linux/2016-07/133020.htm
Kubernetes 集群部署 http://www.linuxidc.com/Linux/2015-12/125770.htm
Ubuntu 16.04 下安装搭建 Kubernetes 集群环境 http://www.linuxidc.com/Linux/2017-02/140555.htm
CentOS7.3 下 yum 安装 Kubernetes1.4 入门教程 http://www.linuxidc.com/Linux/2017-02/140723.htm
Kubernetes 集群搭建过程中遇到的问题及解决 http://www.linuxidc.com/Linux/2015-12/125735.htm
使用 Kubeadm 安装部署 Kubernetes1.5.2 http://www.linuxidc.com/Linux/2017-02/140722.htm
Ubuntu 16.04 下安装搭建 Kubernetes 集群环境 http://www.linuxidc.com/Linux/2017-02/140555.htm
Kubernetes 的详细介绍 ：请点这里
Kubernetes 的下载地址 ：请点这里
查看英文原文：Common Reasons for Failed Kubernetes Deployments
本文永久更新链接地址 ：http://www.linuxidc.com/Linux/2017-03/141470.htm
