纵然在高成熟度级别 Kubernetes 集群中 pod pending 也是无处不在。
如果您随机讯问任何利用 Kubernetes DevOps 工程师来确定折磨他们噩梦的最常见缺点，pod pending 可能是非常常见的问题（可能仅次于 CrashLoopBackOff）。
考试测验推送更新并看到它卡住会使 DevOps 紧张。纵然办理方案相称大略，找到 pod 挂起的缘故原由并理解您须要运用的变动也很主要（Kubernetes 故障打消很少是微不足道的）。
在本文中，我们将阐明导致此问题的不同情形，让 DevOps 团队能够快速找到办理方案，最主要的是，尽可能避免它。
Kubernetes Pod pending 是什么意思？Kubernetes 中的 Pod 的生命周期由几个不同的阶段组成：
创建 pod 时，它从Pending阶段开始。一旦 pod 被调度并且容器已经启动，pod 就会进入Running阶段。大多数 pod 只须要几秒钟就可以从 Pending 到 Running 并在该状态下度过大部分韶光。
至此，Pod 已被 Kubernetes 集群接管。但是一个或多个容器尚未准备好对外供应做事。这包括 Pod 等待调度所花费的韶光以及通过网络下载容器镜像所花费的韶光。
当 pod 无法从 PendingtoRunning 阶段提高时，生命周期将停滞并保留 pod，直到阻挡它提高的问题得到修复。
如果我们利用 kubectl 列出 pod，我们将看到显示 Kubernetes pod 挂起情形的输出：
$ kubectl -n troubleshooting get podsNAME READY STATUS RESTARTS AGEstress-6d6cbc8b9d-s4sbh 0/1 Pending 0 17s1.2.3.
除非我们办理问题，否则 pod 被卡住并且不会运行。
排查 Kubernetes pod Pending 的常见缘故原由有几个缘故原由可以阻挡 Pod 运行，但我们将描述三个紧张问题：
调度问题：无法在任何节点上调度 Pod。镜像问题：下载容器镜像时涌现问题。依赖性问题：Pod 须要一个卷、Secret 或 ConfigMap 才能运行。第一个是最常见的，末了一个很少见。让我们详细解释每种情形。
调度问题导致 Kubernetes Pod Pending创建 Pod 后，Kubernetes 集群做的第一件事便是考试测验调度 Pod 在个中一个节点上运行。这个过程常日非常快，并且 pod 被快速分配给具有足够资源来运行它的节点。
为了放置它，集群中的 Pod 被分配给具有更多未要求资源的节点，并连续其快乐而美好的生活，个中充满了对要求的符合 SLO 的回答。
但是，如果此过程每次都有效，有几个成分可能导致集群无法分配 pod。
让我们回顾一下最常见的。
任何节点中都没有足够的资源来分配 pod
Kubernetes 利用调度要求来决定fits节点中是否有 pod。资源的真正利用无关紧要，只有其他 pod 已经要求的资源。
effective requests当一个 pod 有足够的可要求资源来参与该 pod 的内存和 CPU 时，它将被调度到一个节点中。并且节点必须没有达到它可以运行的最大 pod 数。
当没有任何节点知足 pod 的所有哀求时，它将保持在 Kubernetes pod 挂起状态，直到开释一些资源。
不可调度的节点
由于不同的问题（节点压力）或人为行为（节点封锁），节点可能会变为不可调度的状态。这些节点在状态发生变革之前不会调度任何 pod。
污点和容忍度
污点是 Kubernetes 的一种机制，它许可我们限定可以分配给不同节点的 pod。当节点具有 taint 时，只有匹配容忍度的 pod 才能在该节点中运行。
这种机制许可 Kubernetes 的分外用场，例如为不同的事情负载利用不同类型的节点（具有 GPU 的节点，具有不同的 CPU/内存比率等）。
纵然我们分别描述每个缘故原由，调度问题也每每是由这些问题的组合引起的。常日，您无法调度，由于某些节点已满而其他节点已被污染，或者某个节点可能由于内存压力而无法调度。
为了找出调度问题是什么，您须要查看调度程序天生的关于 pod 的事宜，个中将详细描述阻挡节点分配的缘故原由。我们可以利用 kubectl describe 查看事宜，例如：
$ kubectl -n troubleshooting describe pod stress-6d6cbc8b9d-s4sbhName: stress-6d6cbc8b9d-s4sbhNamespace: troubleshootingPriority: 0Node: <none>Labels: app=stress pod-template-hash=6d6cbc8b9dAnnotations: <none>Status: PendingIP:IPs: <none>Controlled By: ReplicaSet/stress-6d6cbc8b9dContainers: stress: Image: progrium/stress Port: <none> Host Port: <none> Args: --cpu 1 --vm 2 --vm-bytes 150M Limits: cpu: 300m memory: 120000Mi Requests: cpu: 200m memory: 100000Mi Environment: <none> Mounts: /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-snrww (ro)Conditions: Type Status PodScheduled FalseVolumes: kube-api-access-snrww: Type: Projected (a volume that contains injected data from multiple sources) TokenExpirationSeconds: 3607 ConfigMapName: kube-root-ca.crt ConfigMapOptional: <nil> DownwardAPI: trueQoS Class: BurstableNode-Selectors: <none>Tolerations: node.kubernetes.io/not-ready:NoExecute op=Exists for 300s node.kubernetes.io/unreachable:NoExecute op=Exists for 300sEvents: Type Reason Age From Message ---- ------ ---- ---- ------- Warning FailedScheduling 4m17s (x41 over 34m) default-scheduler 0/5 nodes are available: 1 node(s) had taint {node-role.kubernetes.io/master: }, that the pod didn't tolerate, 4 Insufficient memory.1.2.3.4.5.6.7.8.9.10.11.12.13.14.15.16.17.18.19.20.21.22.23.24.25.26.27.28.29.30.31.32.33.34.35.36.37.38.39.40.41.42.43.44.45.46.47.48.49.50.51.
我们可以在输出中看到中的确切缘故原由：
0/5 nodes are available: 1 node(s) had taint {node-role.kubernetes.io/master: }, that the pod didn't tolerate, 4 Insufficient memory.1.个中一个节点被污染。个中四个节点没有足够的可要求内存。
为理解决这个问题，我们有两个选择：
减少 pod 定义中的资源要求大小。通过添加更多节点或增加每个节点的大小来增加集群的容量。如果要更新当前运行的事情负载，还须要考虑另一个主要成分：升级策略。
由于此策略，Kubernetes 可以许可事情负载在更新过程中创建比平时更多的 Pod，在创建新 Pod 时保留旧 Pod 一段韶光。这意味着事情负载可能会在一段韶光内要求比预期更多的资源。如果集群没有足够的备用资源，更新将被壅塞，留下一些 pod 待处理，直到进程被解除壅塞（或回滚超时停滞更新）。
由于镜像问题，Pod Pending一旦在一个节点等分配了 pod，kubelet就会考试测验启动 pod 中的所有容器。为此，它将考试测验下载镜像并运行它。
有几个缺点会阻挡镜像被下载：
镜象名称缺点。缺点的镜像标签。缺点的存储仓库。存储仓库须要身份验证。Kubernetes Pod 由于依赖问题而挂起在 pod 启动之前，kubelet将考试测验检讨与其他 Kubernetes 元素的所有依赖关系。如果无法知足这些依赖项之一，则 pod 将保持挂起状态，直到知足依赖项。
在这种情形下，kubectl 将像这样显示 pod：
$ kubectl -n mysql get pods NAME READY STATUS RESTARTS AGE mysql-0 0/1 ContainerCreating 0 97s1.2.3.
在事宜中，我们可以看到如下内容：
Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Scheduled 3m19s default-scheduler Successfully assigned mysql/mysql-0 to ip-172-20-38-115.eu-west-1.compute.internal Warning FailedMount 76s kubelet Unable to attach or mount volumes: unmounted volumes=[config], unattached volumes=[kube-api-access-gxjf8 data config]: timed out waiting for the condition Warning FailedMount 71s (x9 over 3m19s) kubelet MountVolume.SetUp failed for volume "config" : configmap "mysql" not found1.2.3.4.5.6.
该 Message 列将为您供应足够的信息，以便能够查明缺失落的元素。常见的缘故原由有：
尚未创建 ConfigMap 或者 Secret，或供应的名称禁绝确。无法在节点中挂载卷，由于它尚未被另一个节点开释。这尤其发生在更新 statefulset 的过程中，挂载的卷必须与旧 pod 相同。结论理解 pod 保持在该 Pending 阶段的缘故原由是在 Kubernetes 中安全支配和更新事情负载的关键。能够快速定位问题并加快支配进度将为您省去一些麻烦并减少停机韶光。
--END--
欢迎关注【辉哥传书vlog】头条号，喜好记得点赞、收藏、评论、转发哦！
