Kubernetes故障排除要领

要在最短的停机时间内运行应用程序，需要完善故障排除技能，将应用程序扩展到运行它们的Kubernetes集群。定期对整个Kubernetes集群进行调试和故障排除，以提供一致的支持和服务，这一点至关重要。故障排除包括识别、诊断和解决Kubernetes集群、节点、pod、容器和其他资源中的问题。

由于Kubernetes是一个复杂的系统，故障排除很有挑战性。问题可能发生在单个容器、一个或多个pod、控制器、控制平面组件或这些组件的组合中。这使得即使在小型的本地Kubernetes集群中也很难诊断和修复错误。如果在大规模生产环境中能见度有限，活动部件众多，问题就会恶化。

幸运的是，有一些成功的方法可以解决这些问题。本文探讨了最常见的Kubernetes问题和解决方案，包括ImagePullBackOff、CrashLoopBackOff、内存不足（OOM）错误、BackOffLimitsExceeded消息以及活跃度和就绪度探测问题。

Kubernetes故障排除速成

以下部分列出了一些最常见的Kubernetes错误消息和问题，当它们发生时识别它们的命令以及解决它们的技巧。

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编码的凭据，可以使用base64命令，该命令在大多数类似Unix的操作系统中可用，包括Linux和macOS。例如：

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>

将<USERNAME>和<PASSWORD>替换为从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集群中的特定节点上运行，就会出现这种情况。

内存不足

当容器因OOM错误而终止时，通常会出现资源短缺或内存泄漏。

执行kubectl describe pod＜pod name＞命令，以确定pod中的容器是否已达到资源限制。如果是，终止的原因将显示为OOMKilled。此错误表示pod的容器试图使用的内存超过配置的限制。

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

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

BackoffLimitExceeded

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

Kubernetes中的作业可以控制pod的运行时，监控其状态，并在pod失败时重新启动。backoffLimit是一个作业配置选项，用于控制pod失败的次数，并在作业最终被视为失败之前重试。此配置设置的默认值为6。这意味着作业将重试六次，之后重试将停止。可以执行kubectl describepod＜pod name＞命令来确定作业是否由于BackoffLimitExceeded错误而失败。

Kubernetes作业的成功或失败状态基于其管理的容器的最终退出代码。因此，如果作业的退出代码不是0，那么它就被视为失败。作业失败的原因有很多，包括指定的路径不存在，或者作业找不到要处理的输入文件。

可以通过对作业定义执行失败分析来克服此作业失败。执行kubectl logs＜pod name＞命令来检查pod的日志，通常会发现失败的原因。

探测器故障

为了监控和响应pod的状态，Kubernetes提供了探针（健康检查），以确保只有健康的pod才能为请求提供服务。每个探针（启动、活力和就绪）都有助于Kubernetes pod在不健康时自我修复。当探针处于挂起状态的时间过长，或者没有准备好或无法安排时，它可能会失败。

pod有四个阶段的生命周期：挂起、运行、成功和失败。其当前阶段取决于其主要容器的终止状态。如果pod处于挂起状态，则无法将其调度到节点上。在大多数情况下，由于缺乏资源而无法进行调度。

查看kubectl describe命令的输出将使你更加清楚。如果pod保持挂起状态，那么这可能是一个问题，根本原因可能是节点中的资源不足。或者，如果正在为容器指定一个不可用的主机端口，或者该端口已经在Kubernetes集群的所有节点中使用，那么pod可能还没有准备好。

不管失败的原因是什么，都可以使用kubectl describe pod命令来找出pod失败的原因。下一步将根据失败的原因而有所不同。例如，如果在容器中运行的应用程序的响应时间比配置的探针超时时间长，那么Kubernetes中的探针失败就会发生。通过增加探针超时、监视日志和手动测试探针进行故障排除。一旦确定了根本原因，就可以优化应用程序、扩大资源规模或调整探针配置。

结论

Kubernetes中的故障排除是一项艰巨的任务。然而，通过正确诊断问题并了解其背后的原因，你会发现故障排除过程更易于管理，也不那么令人沮丧。

Kubernetes故障排除允许你采取适当的步骤来解决组件中的问题并有效地解决这些问题。总是自下而上地处理问题，将帮助你更快地解决问题，方法是专注于pod等本地化资源，而不是跨多个组件的服务等资源。