BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

Kubernetes部署失败的常见原因

| 作者 Hrishikesh Barua 关注 12 他的粉丝 ,译者 谢旭 关注 0 他的粉丝 发布于 2017年3月7日. 估计阅读时间: 6 分钟 | 如何结合区块链技术,帮助企业降本增效?让我们深度了解几个成功的案例。

最近一系列文章重点介绍了Kubernetes部署失败的10种常见原因。这些原因涵盖了从缺少输入和错误输入,到超出资源限制。在大多数情况下,kubectl describe命令可以帮助确定背后的原因。

Kubernetes部署的无效输入包括指定不存在的容器镜像,或者指定没有访问权限的容器镜像。因为默认的registry是Dockerhub,所以如果使用了其它registry(如Amazon ECR或Quay.io),则需要指定registry URL。私有registry在访问镜像时需要相关证书。 当要拉取的标签名称无效时,镜像拉取也可能遇到错误。比如在latest标签不存在但镜像存在时,镜像拉取就会失败(如果没有特别指定,“latest”就是默认标签)。此外网络问题也可能会导致错误。这类情况下的错误消息彼此间十分相似,因此需要更深入的检查以确定确切的原因。

Kubernetes中的部署失败常常导致特定的Pod无法启动。可以使用“kubectl describe pod <pod-name>”命令输出描述失败原因的事件日志。kubectl命令采用“pod”,“replicaset”,和“deployment”参数。这些命令与“kubectl logs <podname>”组合是调试部署失败的关键。

如果把Kubernetes中的默认策略设置为不总是从registry中拉取,则即使提交了更新后的改动并推送镜像,这些改动也可能不可见。在产品中推荐的解决方法是为每个镜像分配唯一标签,并在拉取请求中使用这些标签。此外在部署配置中指定不存在的持久卷(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检查,这可能会超时并导致部署失败。

文章的作者已开源一个脚本,当创建失败时,该脚本可以在日志里打印出有用的相关信息。

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


感谢薛命灯对本文的审校。

给InfoQ中文站投稿或者参与内容翻译工作,请邮件至editors@cn.infoq.com。也欢迎大家通过新浪微博(@InfoQ@丁晓昀),微信(微信号:InfoQChina)关注我们。

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我
社区评论

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT