【K8S系列】Kubernetes pod节点Pending或CrashLoopBackOff 题目及解决方案
https://i-blog.csdnimg.cn/direct/4d57dce6fa9f496eb179556b6e4fa5b6.png#pic_center在 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-podPending 0/1 0 0 5m
状态为 Pending 意味着 Pod 尚未调理到节点上。
步调 2: 描述 Pod
执行命令：
kubectl describe pod example-pod
效果分析
在输出中，检查 Events 部分，大概会看到如下信息：
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
WarningFailedScheduling 5m default-scheduler0/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-podCrashLoopBackOff 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 的管理中更加得心应手。
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。
页:
[1]