文章目录
- 一、Pod与容器
- 二、Pod的阶段（状态）
- 三、Pod 状态故障排除
- 3.1 检查 Pod 事件
- 3.2 检查资源可用性
- 3.3 检查污点和容忍度
- 3.4 检查节点亲和性设置
- 3.5 检查持久卷声明
- 3.6 检查配额和限制
- 3.7 验证 Pod 和容器映像
- 3.8 分析调度程序日志
- 四、用于排查 Pending 状态的命令
- 4.1 检查 Pod 事件
- 4.2 检查资源可用性
- 4.3 检查污点和容忍度
- 4.4 检查节点亲和性设置
- 4.5 检查持久卷声明
- 4.6 检查配额和限制
- 4.7 验证 Pod 和容器映像
- 4.8 分析调度程序日志
一、Pod与容器
Pod是可以在Kubernetes中创建和管理的最小可部署单元。Pod是一组（一个或多个）容器的打包，这一组容器共享存储、网络；pod中的容器地位均等且一同调度，在共享的上下文中运行。这些容器在业务上是紧密耦合在一起的。
Pod就像一台“逻辑主机”为这一组紧密相关的容器提供运行上下文。Pod除了正常运行的业务容器外还可以在启动期间运行Init容器。也可以在集群支持临时容器的情况下，以调试为目的注入临时容器。
如下图
可以把Pod看成是一个“豌豆荚”，
里面有很多“豆子”（容器）。
一个豌豆荚里的豆子，它们吸收着共同的营养成分、肥料、水分等，
Pod和容器的关系也是一样，
Pod里面的容器共享pod的空间、资源、网络、存储等。
二、Pod的阶段（状态）
通过kubectl get pod -o yaml 查看pod的信息，其中status.phase字段表示该pod的阶段。 通过kubectl describe pod 查看pod详情，其中State字段表示该pod的状态（阶段）。
kubectl get pod -o yaml
kubectl describe pod
| 阶段(状态) | 描述 |
|---|---|
| Pending | Pod 已被 Kubernetes 系统接受，但有一个或者多个容器尚未创建亦未运行。此阶段包括等待 Pod 被调度的时间和通过网络下载镜像的时间。 |
| Running | Pod 已经绑定到了某个节点，Pod 中所有的容器都已被创建。至少有一个容器仍在运行，或者正处于启动或重启状态。 |
| Succeeded | Pod 中的所有容器都已成功终止，并且不会再重启。 |
| Failed | Pod 中的所有容器都已终止，并且至少有一个容器是因为失败终止。也就是说，容器以非 0 状态退出或者被系统终止。 |
| Unknown 因为某些原因无法取得 Pod 的状态。这种情况通常是因为与 Pod 所在主机通信失败 |
三、Pod 状态故障排除
以下是对 Pending Pod 状态进行故障排除的系统方法：
3.1 检查 Pod 事件
使用kubectl describe pod
查找有关 pod 调度尝试的详细信息。事件部分可能包含来自调度程序或其他组件的消息，指示无法调度 Pod 的原因。例如：
-
FailedScheduling：此事件提供诸如无法满足的约束（例如，污点、关联性）或资源不足之类的原因。
-
FailedAttachVolume或FailedMount：表示附加或安装卷时出现问题，可能是由于缺少 PersistentVolume 或存储类问题。
3.2 检查资源可用性
节点可能缺乏 Pod 所需的必要 CPU 或内存资源。使用 检查节点详细信息时kubectl describe nodes，请考虑：
-
可分配与容量：了解差异；容量是资源总量，而 Allocatable 是 Kubernetes 系统预留量。
-
资源请求和限制：将节点上调度的所有 pod 的请求和限制总和与节点的可分配资源进行比较，以识别潜在的资源短缺。
3.3 检查污点和容忍度
节点可能具有排斥 pod 的污点，除非 pod 具有匹配的容忍度。检查污点时：
-
了解污点效果：NoSchedule、PreferNoSchedule 和 NoExecute 等效果决定污点的严格程度。
-
匹配容忍度：确保 Pod 的容忍度与节点污点的键、值和效果相匹配，以允许调度。
3.4 检查节点亲和性设置
节点关联性规则可能过于严格。查看关联性设置时：
-
必需规则与首选规则：调度必须满足必需规则，而首选规则会影响调度决策，但不是强制性的。
-
标签匹配：确保节点具有与 Pod 的亲和性标签选择器匹配的标签。
3.5 检查持久卷声明
PVC 问题可能会阻止 Pod 被调度，特别是对于有状态应用程序。检查要点：
-
PVC Status：确保 PVC 状态为Bound，表示它已成功附加到PersistentVolume。
-
StorageClass 和 Provisioner：确认 StorageClass 存在并且动态配置器（如果使用）可以运行。
3.6 检查配额和限制
命名空间配额会限制资源分配，影响 Pod 调度。检查配额时：
-
资源配额：在命名空间中查找ResourceQuota对象，并将其限制与当前使用情况进行比较。
-
Pod 计数限制：除了 CPU 和内存之外，配额还可以限制 Pod 的数量，这可能是导致问题的原因。
3.7 验证 Pod 和容器映像
容器映像的问题（例如名称不正确或无法访问的注册表位置）可能会停止 Pod 调度：
-
图像拉取错误：常见问题包括需要身份验证的私有注册表或图像名称/标签中的拼写错误。
-
映像拉取策略：该策略可能需要重新拉取映像，这可能会由于连接问题或速率限制而失败。
3.8 分析调度程序日志
Kubernetes 调度程序日志可以提供对决策过程的深入了解：
-
详细日志记录：增加日志的详细程度可以揭示详细的调度决策和失败。
-
搜索 Pod 名称：按 Pod 名称过滤日志，以跟踪特定的调度尝试以及任何失败背后的原因。
四、用于排查 Pending 状态的命令
4.1 检查 Pod 事件
kubectl describe pod <pod-name> -n <namespace>
在“事件”部分查找可能表明日程安排问题的消息。
4.2 检查资源可用性
kubectl describe nodes
检查“可分配”和“容量”部分，以及“非终止 Pod”下 Pod 请求的资源。
4.3 检查污点和容忍度
列出所有节点上的污点：
kubectl get nodes -o jsonpath='{.items[*].metadata.name}{"\t"}{.items[*].spec.taints}' | tr -s '[[:space:]]' '\n'
确保您的 pod 的容忍度与这些污点相匹配。
4.4 检查节点亲和性设置
检查 pod 定义 (pod.yaml) 中的亲和性部分：
affinity:nodeAffinity:requiredDuringSchedulingIgnoredDuringExecution:nodeSelectorTerms:- matchExpressions:- key: <key>operator: Invalues:- <value>
确保存在带有符合这些要求的标签的节点。
4.5 检查持久卷声明
检查 PVC 的状态：
kubectl get pvc -n <namespace>
确保 pod 所依赖的 PVC 处于 Bound 状态。
4.6 检查配额和限制
查看命名空间中的资源配额：
kubectl describe quota -n <namespace>
检查是否有任何资源配额即将超出。
4.7 验证 Pod 和容器映像
确保 pod 规范中的容器镜像正确。要检查镜像拉取错误，请查看 pod 的事件：
kubectl describe pod <pod-name> -n <namespace> | grep -i "Failed"
这可以帮助识别拉取容器映像时出现的任何问题。
4.8 分析调度程序日志
首先，找到调度程序 pod 的名称：
kubectl get pods -n kube-system | grep kube-scheduler
然后，查看调度器的日志（替换为实际名称）：
kubectl logs <scheduler-pod-name> -n kube-system
磨你的心智，是为了以后不管你遇见任何人和事，都能稳如泰山。
