K8s 中Pod无法启动5个常见问题总结

2024-01-07 18:08:04

一、ImagePullBackOff
Kubernetes pod 无法启动的原因之一是运行时无法从注册表中检索容器镜像。换句话说,pod 不会启动,因为至少有一个在清单中指定的容器没有启动。

当 pod 遇到此问题时,kubectl get pods 命令会将 pod 的状态显示为ImagePullBackOff。当镜像名称或标签错误地输入到 pod 清单中时,可能会发生此错误。在这种情况下,从连接到 Docker 注册表的任何集群节点使用 docker pull 来确认正确的镜像名称。然后,在 pod 清单中更改它。

当容器注册表的权限和身份验证问题阻止 pod 检索镜像时,也会出现ImagePullBackOff。这通常发生在秘密持有凭证(ImagePullSecret)出现问题或 pod 缺少所需的基于角色的访问控制 (RBAC) 角色时。要解决此问题,请确保 pod 和节点具有适当的权限和机密,然后使用 docker pull 命令手动尝试操作。

可以通过为 docker pull 命令设置 --v 参数来更改日志详细程度。调高日志级别以获取有关错误发生原因的更多信息。

如果不知道用于登录和拉取镜像的凭据或 ImagePullSecret 的内容,可以按照以下步骤操作。

首先,使用kubectl get secret 命令,将 <SECRET_NAME> 替换为要检索的 ImagePullSecret 的名称。

kubectl get secret <SECRET_NAME> -o json

上述命令将输出机密的 JSON 表示形式,其中包括包含 base64 编码凭据的数据字段。

要解码 base64 编码的凭据,您可以使用大多数类 Unix 操作系统(包括 Linux 和 macOS)中提供的 base64 命令。例如:

kubectl get secret <SECRET_NAME> -o json | jq -r '.data.".dockerconfigjson"' | base64 --decode

此命令使用 jq 提取“.dockerconfigjson”字段的值,其中包含 base64 编码的凭据,然后将输出通过管道传输到 base64 命令以对其进行解码。

获得解码的凭据后,可以将它们与 docker login 命令一起使用,以通过 Docker 注册表进行身份验证。例如:

docker login -u <USERNAME> -p <PASSWORD> <REGISTRY_URL>

将 和 替换为从 ImagePullSecret 解码的凭据,并将 <REGISTRY_URL> 替换为要用于身份验证的 Docker 注册表的 URL。然后发出 docker pull 命令来测试拉取镜像。

二、CrashLoopBackOff
Pod 可能无法启动的另一个原因是无法在节点上调度指定的容器。当 pod 遇到此问题时,kubectl get pods 命令会将 pod 的状态显示为 CrashLoopBackOff。

如果 pod 无法安装请求的卷或者节点没有运行 pod 所需的资源,则可能会发生此错误。要获取有关该错误的更多信息,请运行以下命令:

kubectl describe pod <pod name>

输出的末尾将有助于确定根本原因。如果原因是 pod 无法安装请求的卷,通过确保清单适当地指定其详细信息并确保 pod 可以使用这些定义访问存储卷来手动验证卷。
或者,如果该节点没有足够的资源,则手动从该节点中删除 pod,以便将 pod 调度到另一个节点上。否则,您可以扩展节点资源容量。
如果使用 nodeSelector 安排 pod 在 Kubernetes 集群中的特定节点上运行,就会发生这种情况。

三、Out-of-Memory
当容器因 OOM 错误而终止时,通常会出现资源短缺或内存泄漏。

执行 kubectl describe pod <pod name> 命令来确定 pod 中的容器是否已达到资源限制。如果是这样,终止的原因将显示为 OOMKilled。此错误表明 Pod 的容器已尝试使用超过配置限制的内存。

要解决 OOMKilled,增加容器的内存限制作为 pod 规范的一部分。如果pod仍然失败,检查应用是否存在内存泄漏,并通过在应用前端修复内存泄漏问题及时解决。

为了最大限度地减少 OOM 错误的可能性并优化 Kubernetes 环境,可以在指定 pod 时定义容器需要多少资源,例如 CPU 和内存。kube-scheduler 根据对其容器的资源请求选择哪个节点来引导 pod。然后,kubelet 为该容器分配该节点资源的一部分。此外,kubelet 对已定义的容器实施资源限制(limits),防止正在运行的容器使用超出预期的资源。

四、BackoffLimitExceeded
BackoffLimitExceeded 表示 Kubernetes 作业在多次重启失败后已达到其重试限制。

Kubernetes 中的作业可以控制 pod 的运行时、监视其状态并在 pod 出现故障时重新启动。backoffLimit 是一个作业配置选项,它控制在作业最终被视为失败之前 pod 可以失败和重试的次数。此配置设置的默认值为 6。这意味着作业将重试六次,之后重试将停止。可以执行 kubectl describe pod <pod name> 命令来确定作业是否因 BackoffLimitExceeded错误而失败。

Kubernetes 作业的成功或失败状态取决于它管理的容器的最终退出代码。因此,如果作业的退出代码不是 0,则视为失败。作业可能因多种原因而失败,包括指定路径不存在或作业无法找到要处理的输入文件。

您可以通过对作业定义执行故障分析来克服此作业故障。执行 kubectl logs <pod name> 命令来检查 pod 的日志,这通常会发现失败的原因。

五、Probe Failures
为了监控和响应 Pod 的状态,Kubernetes 提供了探针(健康检查)以确保只有健康的 Pod 才能为请求提供服务。每个探针(Startup、Liveness 和 Readiness)都有助于 Kubernetes pod 在不健康时进行自我修复。当探针处于挂起状态的时间过长或者未就绪或无法安排时,它可能会失败。

Pod 有四个阶段的生命周期:Pending、Running、Succeeded 和 Failed。它的当前阶段取决于其主要容器的终止状态。如果 pod 卡在 Pending中,则无法将其调度到节点上。在大多数情况下,调度会因资源不足而受阻。

查看 kubectl describe命令的输出将使您更加清楚。如果 pod 保持挂起状态,则可能是一个问题,根本原因可能是节点中的资源不足。或者,如果为不可用的容器指定主机端口,或者该端口已在 Kubernetes 集群的所有节点中使用,则 pod 可能未就绪。

不管失败的原因是什么,都可以使用 kubectl describe pod 命令来找出 pod 失败的原因。例如,如果在容器中运行的应用程序响应时间比配置的探测超时时间长,则 Kubernetes 中可能会发生探测失败。通过增加探测超时、监视日志和手动测试探测来排除故障。确定根本原因后,优化应用程序、扩展资源或调整探针配置。

文章来源:https://blog.csdn.net/weixin_45432833/article/details/135373114
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。