在生產(chǎn)環(huán)境中遇到Pod卡在Pending狀態(tài)，就像外賣小哥找不到配送地址一樣讓人焦慮。作為踩坑無數(shù)的老司機，今天帶大家拆解這個經(jīng)典問題的排查思路，附贈真實戰(zhàn)場經(jīng)驗。（配圖：一個卡在加載狀態(tài)的Pod圖標）

一、資源不足：最經(jīng)典的"堵車"場景

典型癥狀：kubectl describe顯示"0/3 nodes are available: 3 Insufficient cpu, 2 Insufficient memory"

深層原因：

• 節(jié)點資源耗盡（真實案例：某次促銷活動忘記擴容，節(jié)點CPU利用率達98%）
• Pod資源請求過高（常見于新人配置requests=limits）

排查武器庫：

kubectl top nodes  # 查看節(jié)點資源水位
kubectl describe node <節(jié)點名> | grep -A 10 Allocated  # 查看具體分配情況

生存指南：

• 緊急擴容：kubectl scale deploy/<名稱> --replicas=0先止血
• 合理配置：遵循黃金法則 - requests=limits的80%
• 自動擴縮容：安裝cluster-autoscaler實現(xiàn)節(jié)點自動伸縮

二、調(diào)度約束：K8S版的"落花有意流水無情"

高階踩坑現(xiàn)場：

• nodeSelector選了不存在的標簽
• 親和性設置過于嚴格（反例：必須調(diào)度到SSD+GPU節(jié)點）
• 節(jié)點污點未配置容忍（生產(chǎn)環(huán)境常見：專用GPU節(jié)點）

診斷秘籍：

kubectl get nodes --show-labels | grep <關鍵標簽>
kubectl describe pod | grep -i 'affinity'  # 查看親和性配置

避坑姿勢：

tolerations:  # 污點容忍配置示例
- key: "gpu"
  operator: "Exists"
  effect: "NoSchedule"

三、存儲依賴：等待永久的約會

經(jīng)典連環(huán)坑：

• PVC找不到匹配的PV（尤其StatefulSet場景）
• StorageClass配置錯誤（測試環(huán)境用local-path，生產(chǎn)用ceph）
• 云盤配額不足（AWS EBS類型選錯）

排查三連擊：

kubectl get pvc
kubectl describe storageclass
aws ec2 describe-volumes --region <區(qū)域>  # 云平臺檢查

實戰(zhàn)技巧：

• 預創(chuàng)建PV池應對突發(fā)流量
• 使用動態(tài)供應StorageClass
• 監(jiān)控云平臺配額：aws service-quotas get-service-quota --service-code ec2 --quota-code L-XXXX

四、鏡像問題：你以為的下載不是下載

隱蔽陷阱：

• 私有倉庫認證失?。╧ubelet報x509證書錯誤）
• 鏡像tag不存在（latest標簽被覆蓋）
• 國內(nèi)拉取gcr.io鏡像超時

診斷組合拳：

kubectl describe pod | grep -i 'image'
docker pull <鏡像地址>  # 在節(jié)點上手動測試
journalctl -u kubelet | grep -i 'image'  # 查看kubelet日志

救命方案：

imagePullSecrets:  # 私有倉庫認證配置
- name: regcred

五、配額限制：看不見的天花板

多維限制矩陣：

• Namespace資源配額（ResourceQuota）
• Service配額（AWS的NLB數(shù)量限制）
• RBAC權限不足（ServiceAccount無create權限）

排查工具箱：

kubectl describe quota -n <命名空間>
aws service-quotas list-service-quotas --service-code ec2  # 檢查云配額

破局之道：

apiVersion: v1
kind: ResourceQuota
metadata:
  name: team-quota
spec:
  hard:
    requests.cpu: "20"
    requests.memory: 100Gi

六、網(wǎng)絡暗礁：沉默的殺手

高危場景：

• 網(wǎng)絡插件異常（Calico的IP池耗盡）
• 安全組配置錯誤（AWS節(jié)點間端口未開放）
• CNI配置沖突（多網(wǎng)絡插件混用）

診斷七傷拳：

kubectl get pods -n kube-system  # 檢查網(wǎng)絡組件狀態(tài)
calicoctl ipam show --show-blocks  # Calico IP地址檢查
telnet <節(jié)點IP> 10250  # 檢查節(jié)點間通信

終極防御：

• 定期清理IP池：calicoctl ipam release --ip=<廢棄IP>
• 使用網(wǎng)絡策略白名單
• 啟用NetworkPolicy審計

七、系統(tǒng)級異常：底層的暴擊

魔鬼藏在細節(jié)里：

• kube-scheduler進程崩潰
• 節(jié)點磁盤inode耗盡
• 內(nèi)核版本不兼容（尤其使用ebpf網(wǎng)絡插件時）

深度檢測：

systemctl status kube-scheduler  # 調(diào)度器狀態(tài)
df -i  # 檢查inode使用
uname -r  # 核對內(nèi)核版本

生存法則：

• 部署kube-scheduler的多實例
• 啟用節(jié)點自動修復功能
• 定期內(nèi)核漏洞掃描

八、冷門陷阱：那些年我們踩過的神坑

奇葩問題集錦：

• 時區(qū)設置導致cronjob異常
• 節(jié)點時間不同步引發(fā)證書驗證失敗
• kube-proxy的conntrack表溢出

診斷冷兵器：

chronyc tracking  # 檢查時間同步
cat /proc/sys/net/netfilter/nf_conntrack_max  # 連接追蹤表大小

防御矩陣：

• 全集群NTP時間同步
• 調(diào)整conntrack參數(shù)：

sysctl -w net.netfilter.nf_conntrack_max=1048576

終極排查路線圖（思維導圖見文末）

• 看事件：kubectl describe pod <名稱>
• 查調(diào)度：kubectl get events --field-selector involvedObject.kind=Pod
• 核配置：kubectl get pod <名稱> -o yaml
• 檢資源：kubectl top系列命令
• 追日志：kubelet和容器運行時日志
• 測網(wǎng)絡：節(jié)點間通信測試
• 審配額：云平臺和K8S雙重檢查

武器庫升級：

• 可視化工具：Lens、K9s
• 日志系統(tǒng)：ELK+Filebeat
• 監(jiān)控體系：Prometheus+Alertmanager+Grafana黃金組合

寫給開發(fā)者的生存建議：

• 給每個Pod配置合理的requests/limits
• 重要服務添加PreStopHook實現(xiàn)優(yōu)雅終止
• 生產(chǎn)環(huán)境Always指定鏡像tag
• 使用PDB（PodDisruptionBudget）防止意外驅(qū)逐
• 定期進行混沌工程演練

記?。篜ending不是錯誤，而是K8S在說"我盡力了，但..."。掌握這套排查心法，下次遇到問題時你就能淡定地說："讓子彈飛一會兒，我先看看調(diào)度日志。"

到此這篇關于K8s中Pod處于Pending狀態(tài)的八種原因的文章就介紹到這了,更多相關K8s中Pod處于Pending狀態(tài)的八種原因內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家！

最新評論