徹底搞懂 K8S Pod Pending 故障原因及解決方案
即使在高成熟度級別 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 pods
NAME READY STATUS RESTARTS AGE
stress-6d6cbc8b9d-s4sbh 0/1 Pending 0 17s除非我們解決問題，否則 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-s4sbh
Name: stress-6d6cbc8b9d-s4sbh
Namespace: troubleshooting
Priority: 0
Node: <none>
Labels: app=stress
pod-template-hash=6d6cbc8b9d
Annotations: <none>
Status: Pending
IP:
IPs: <none>
Controlled By: ReplicaSet/stress-6d6cbc8b9d
Containers:
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 False
Volumes:
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: true
QoS Class: Burstable
Node-Selectors: <none>
Tolerations: node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:
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.我們可以在輸出中看到消息中的確切原因：
0/5 nodes are available: 1 node(s) had taint {node-role.kubernetes.io/master: }, that the pod didn't tolerate, 4 Insufficient memory.- 其中一個節點被污染。
- 其中四個節點沒有足夠的可請求內存。
為了解決這個問題，我們有兩個選擇：
- 減少 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 97s在事件中，我們可以看到如下內容：
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 found該 Message 列將為您提供足夠的信息，以便能夠查明缺失的元素。常見的原因有：
- 尚未創建 ConfigMap 或者 Secret，或提供的名稱不正確。
- 無法在節點中掛載卷，因為它尚未被另一個節點釋放。這尤其發生在更新 statefulset 的過程中，掛載的卷必須與舊 pod 相同。
結論
了解 pod 保持在該 Pending 階段的原因是在 Kubernetes 中安全部署和更新工作負載的關鍵。能夠快速定位問題并加快部署進度將為您省去一些麻煩并減少停機時間。
