【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 状态

执行命令：

1. kubectl get pods

复制代码

效果分析

如果 Pod 状态为 Pending，则继承进行后续检查。大概的输出示例：

1. NAME         STATUS    READY   STATUS   RESTARTS   AGE
2. example-pod  Pending   0/1     0        0          5m

复制代码

状态为 Pending 意味着 Pod 尚未调理到节点上。
步调 2: 描述 Pod

执行命令：

1. kubectl describe pod example-pod

复制代码

效果分析

在输出中，检查 Events 部分，大概会看到如下信息：

1. Events:
2.   Type     Reason                  Age               From               Message
3.   ----     ------                  ----              ----               -------
4.   Warning  FailedScheduling        5m                default-scheduler  0/3 nodes are available: 3 Insufficient cpu.

复制代码

这表明由于 CPU 资源不足，调理失败。
步调 3: 检查资源环境

执行命令：

1. kubectl top nodes

复制代码

效果分析

输出大概如下：

1. NAME       CPU(cores)   CPU%   MEMORY(bytes)   MEMORY%
2. node1      3000m        90%    2000Mi          80%
3. node2      2000m        70%    1500Mi          60%

复制代码

如果某个节点的 CPU 或内存使用率接近 100%，则阐明资源不足。
步调 4: 检查调理计谋

检查 Pod 的设置文件，确认是否有任何亲和性或污点设置：

1. affinity:
2.   nodeAffinity:
3.     requiredDuringSchedulingIgnoredDuringExecution:
4.       nodeSelectorTerms:
5.       - matchExpressions:
6.         - key: disktype
7.           operator: In
8.           values:
9.           - SSD

复制代码

效果分析

如果存在亲和性规则，确认节点是否满意这些条件，大概导致 Pod 无法调理。
3. 解决方案

解决方案 1: 开释资源

• 淘汰其他 Pod 的数量：使用以下命令删除不必要的 Pod。
  

1. kubectl delete pod <unnecessary-pod>

复制代码

• 调整资源哀求：修改 Pod 的资源哀求（requests）和限定（limits），确保其合理。
  

解决方案 2: 扩展集群

• 增加节点：在云服务提供商上添加新的节点，增加集群的盘算本领。
  

解决方案 3: 调整调理计谋

• 修改亲和性规则：确保 Pod 可以调理到合适的节点。
  

解决方案 4: 检查网络插件

• 确保网络插件正常运行，可以通过以下命令查看 Pod 状态：
  

1. kubectl get pods
3. --namespace kube-system

复制代码

三、CrashLoopBackOff 状态分析与解决方案

1. 缘故起因分析

1.1 应用故障

• 代码错误：应用程序代码中的错误导致容器崩溃。
  
• 依赖题目：缺少必要的依赖或设置文件。
  

1.2 资源题目

• 资源不足：容器在启动时哀求的资源超出了实际可用资源。
  

2. 排查步调

步调 1: 查看 Pod 状态

执行命令：

1. kubectl get pods

复制代码

效果分析

如果 Pod 状态为 CrashLoopBackOff，大概的输出示例：

1. NAME         STATUS           READY   STATUS   RESTARTS   AGE
2. example-pod  CrashLoopBackOff 0/1     0        5          2m

复制代码

这表明 Pod 启动失败并多次实验重启。
步调 2: 查看 Pod 日记

查看崩溃前的日记：

1. kubectl logs example-pod --previous

复制代码

效果分析

日记输出示例：

1. Error: Cannot find module 'app'

复制代码

这表明应用程序由于缺少依赖（模块）而崩溃。
步调 3: 描述 Pod

执行命令：

1. kubectl describe pod example-pod

复制代码

效果分析

确认是否有资源不足或其他非常信息，特别是在 Events 部分。
3. 解决方案

解决方案 1: 修复应用代码

• 调试代码：检查应用程序的代码，确认是否有错误。
  
• 本地测试：在本地环境中运行容器，检查是否能成功启动。
  

解决方案 2: 调整资源设置

• 增加资源哀求：适当进步 Pod 的资源哀求和限定。
  

1. resources:
2.   requests:
3.     memory: "128Mi"
4.     cpu: "500m"
5.   limits:
6.     memory: "256Mi"
7.     cpu: "1"

复制代码

解决方案 3: 检查环境变量和启动命令

• 检查设置：确认所有必要的环境变量均已设置。
  
• 修改启动命令：确保容器的启动命令正确无误。
  

解决方案 4: 使用重启计谋

• 调整重启计谋：通过修改 Pod 的重启计谋，避免频繁重启：
  

1. restartPolicy: Always

复制代码

四、总结

Pod 无法启动的题目是 Kubernetes 运维中常见的挑战。通过深入分析 Pending 和 CrashLoopBackOff 状态的缘故起因，并进行系统化的排查和解决，用户可以有用地定位题目并采取相应措施。了解 Pod 的生命周期、调理机制及应用程序的特性，将有助于提升 Kubernetes 集群的稳固性和可用性。掌握这些知识和技能，将使运维人员在 Kubernetes 的管理中更加得心应手。

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。