【K8S系列】Kubernetes pod节点Pending或CrashLoopBackOff 问题及解决方案详解【已解决】
在 Kubernetes 中，Pod 是最小的可调度单元，负责运行容器。当 Pod 的状态显示为
Pending或CrashLoopBackOff
时，意味着它无法成功启动或持续崩溃。本文将详细分析这两种状态的原因、排查步骤、执行后的结果及相应的解决方案。
一、Pod 状态概述
1. Pending 状态
Pod 的状态为 Pending 表示它尚未被调度到任何节点上。这可能是由于资源不足、调度限制或网络问题等多种原因。
2. CrashLoopBackOff 状态
CrashLoopBackOff 状态表示 Pod 启动后崩溃，Kubernetes 会不断尝试重启它，但由于不断崩溃而进入 BackOff 状态，导致重新启动的间隔时间逐渐增加。
二、Pending 状态分析与解决方案
1. 原因分析
1.1 资源不足
- CPU/内存不足：节点的资源不足以满足 Pod 的请求。
- 存储不足：持久卷（PV）未能满足请求。
1.2 调度限制
- 节点亲和性（Affinity）：Pod 的调度限制可能导致它无法找到合适的节点。
- 资源限制：使用了过高的资源请求。
2. 排查步骤
步骤 1: 查看 Pod 状态
执行命令：
kubectl get pods
结果分析
如果 Pod 状态为 Pending，则继续进行后续检查。可能的输出示例：
NAME STATUS READY STATUS RESTARTS AGE
example-pod Pending 0/1 0 0 5m
状态为 Pending 意味着 Pod 尚未调度到节点上。
步骤 2: 描述 Pod
执行命令：
kubectl describe pod example-pod
结果分析
在输出中，检查 Events 部分，可能会看到如下信息：
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning FailedScheduling 5m default-scheduler 0/3 nodes are available: 3 Insufficient cpu.
这表明由于 CPU 资源不足，调度失败。
步骤 3: 检查资源情况
执行命令：
kubectl top nodes
结果分析
输出可能如下：
NAME CPU(cores) CPU% MEMORY(bytes) MEMORY%
node1 3000m 90% 2000Mi 80%
node2 2000m 70% 1500Mi 60%
如果某个节点的 CPU 或内存使用率接近 100%，则说明资源不足。
步骤 4: 检查调度策略
检查 Pod 的配置文件，确认是否有任何亲和性或污点设置：
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: disktype
operator: In
values:
- SSD
结果分析
如果存在亲和性规则，确认节点是否满足这些条件，可能导致 Pod 无法调度。
3. 解决方案
解决方案 1: 释放资源
- 减少其他 Pod 的数量：使用以下命令删除不必要的 Pod。
kubectl delete pod <unnecessary-pod>
- 调整资源请求：修改 Pod 的资源请求（requests）和限制（limits），确保其合理。
解决方案 2: 扩展集群
- 增加节点：在云服务提供商上添加新的节点，增加集群的计算能力。
解决方案 3: 调整调度策略
- 修改亲和性规则：确保 Pod 可以调度到合适的节点。
解决方案 4: 检查网络插件
- 确保网络插件正常运行，可以通过以下命令查看 Pod 状态：
kubectl get pods --namespace kube-system
三、CrashLoopBackOff 状态分析与解决方案
1. 原因分析
1.1 应用故障
- 代码错误：应用程序代码中的错误导致容器崩溃。
- 依赖问题：缺少必要的依赖或配置文件。
1.2 资源问题
- 资源不足：容器在启动时请求的资源超出了实际可用资源。
2. 排查步骤
步骤 1: 查看 Pod 状态
执行命令：
kubectl get pods
结果分析
如果 Pod 状态为 CrashLoopBackOff，可能的输出示例：
NAME STATUS READY STATUS RESTARTS AGE
example-pod CrashLoopBackOff 0/1 0 5 2m
这表明 Pod 启动失败并多次尝试重启。
步骤 2: 查看 Pod 日志
查看崩溃前的日志：
kubectl logs example-pod --previous
结果分析
日志输出示例：
Error: Cannot find module 'app'
这表明应用程序由于缺少依赖（模块）而崩溃。
步骤 3: 描述 Pod
执行命令：
kubectl describe pod example-pod
结果分析
确认是否有资源不足或其他异常信息，特别是在 Events 部分。
3. 解决方案
解决方案 1: 修复应用代码
- 调试代码：检查应用程序的代码，确认是否有错误。
- 本地测试：在本地环境中运行容器，检查是否能成功启动。
解决方案 2: 调整资源配置
- 增加资源请求：适当提高 Pod 的资源请求和限制。
resources:
requests:
memory: "128Mi"
cpu: "500m"
limits:
memory: "256Mi"
cpu: "1"
解决方案 3: 检查环境变量和启动命令
- 检查配置：确认所有必要的环境变量均已设置。
- 修改启动命令：确保容器的启动命令正确无误。
解决方案 4: 使用重启策略
- 调整重启策略：通过修改 Pod 的重启策略，避免频繁重启：
restartPolicy: Always
四、总结
Pod 无法启动的问题是 Kubernetes 运维中常见的挑战。通过深入分析 Pending 和 CrashLoopBackOff 状态的原因，并进行系统化的排查和解决，用户可以有效地定位问题并采取相应措施。了解 Pod 的生命周期、调度机制及应用程序的特性，将有助于提升 Kubernetes 集群的稳定性和可用性。掌握这些知识和技能，将使运维人员在 Kubernetes 的管理中更加得心应手。
原文地址：https://blog.csdn.net/weixin_36755535/article/details/143018394
免责声明：本站文章内容转载自网络资源，如本站内容侵犯了原著者的合法权益，可联系本站删除。更多内容请关注自学内容网（zxcms.com）！