這篇文章記錄了我這些年在 K8s 生產(chǎn)環(huán)境踩過的坑。每一個案例都是血淚教訓，有些甚至導致了生產(chǎn)事故。希望通過分享這些經(jīng)歷，能幫助大家避免重蹈覆轍。

聲明：以下案例均已脫敏處理，部分細節(jié)有所調(diào)整。

一、概述

1.1 背景介紹

K8s 已經(jīng)成為容器編排的事實標準，但它的復雜性也帶來了很多潛在的風險點。根據(jù)我的經(jīng)驗，生產(chǎn)環(huán)境出問題往往不是因為 K8s 本身有 bug，而是：

配置不當

資源規(guī)劃不合理

缺乏監(jiān)控告警

操作流程不規(guī)范

對某些機制理解不深

1.2 文章結(jié)構(gòu)

本文將按照故障嚴重程度，從"集群級災難"到"應用級問題"，逐一復盤 10 個真實案例：

序號	故障類型	影響范圍	嚴重程度
1	etcd 磁盤寫滿	整個集群	P0 - 災難
2	API Server OOM	整個集群	P0 - 災難
3	證書過期	整個集群	P0 - 災難
4	節(jié)點批量 NotReady	多節(jié)點	P1 - 嚴重
5	PDB 配置導致無法驅(qū)逐	應用級	P1 - 嚴重
6	資源配額耗盡	命名空間	P2 - 中等
7	滾動更新卡住	應用級	P2 - 中等
8	ConfigMap 熱更新踩坑	應用級	P2 - 中等
9	HPA 抖動風暴	應用級	P2 - 中等
10	鏡像拉取失敗雪崩	多應用	P2 - 中等

1.3 環(huán)境信息

組件	版本	說明
Kubernetes	1.28 - 1.30	不同案例發(fā)生在不同版本
etcd	3.5.x	集群數(shù)據(jù)存儲
容器運行時	containerd 1.7+	部分老集群還在用 Docker
節(jié)點規(guī)模	50 - 500 節(jié)點	中大規(guī)模集群

二、集群級災難案例

2.1 案例一：etcd 磁盤寫滿，集群癱瘓

故障現(xiàn)象

那是一個周五下午（沒錯，就是最經(jīng)典的周五下午），監(jiān)控突然開始瘋狂告警：

[CRITICAL] API Server 響應超時
[CRITICAL] 多個節(jié)點狀態(tài)變?yōu)?Unknown
[CRITICAL] 新 Pod 無法調(diào)度

登錄 master 節(jié)點一看，kubectl命令卡住不動，整個集群基本癱瘓了。

根因分析

# 檢查 etcd 狀態(tài)
systemctl status etcd
# 輸出：etcd.service: Failed with result 'exit-code'

# 查看 etcd 日志
journalctl -u etcd -n 100
# 關(guān)鍵錯誤：
# "mvcc: database space exceeded"
# "etcdserver: no space"

# 檢查磁盤使用
df -h /var/lib/etcd
# 輸出：100% 使用率

根本原因：etcd 數(shù)據(jù)目錄所在磁盤寫滿了。

為什么會寫滿？排查發(fā)現(xiàn)是因為：

某個 Operator 存在 bug，瘋狂創(chuàng)建 Event 對象

etcd 沒有配置自動壓縮（compaction）

磁盤容量規(guī)劃不足，只給了 20GB

解決過程

# 1. 緊急擴容磁盤（如果是云環(huán)境）
# 或者清理其他文件騰出空間

# 2. 手動壓縮 etcd
# 獲取當前 revision
ETCDCTL_API=3 etcdctl endpoint status --write-out=table

# 壓縮到指定 revision
ETCDCTL_API=3 etcdctl compact 

# 3. 執(zhí)行碎片整理
ETCDCTL_API=3 etcdctl defrag --endpoints=https://127.0.0.1:2379 
 --cacert=/etc/kubernetes/pki/etcd/ca.crt 
 --cert=/etc/kubernetes/pki/etcd/server.crt 
 --key=/etc/kubernetes/pki/etcd/server.key

# 4. 清理過多的 Event
kubectl delete events --all -A

預防措施

# 1. 配置 etcd 自動壓縮（在 etcd 啟動參數(shù)中）
--auto-compaction-mode=periodic
--auto-compaction-retention=1h

# 2. 設置配額告警
--quota-backend-bytes=8589934592# 8GB

# 3. 添加磁盤監(jiān)控告警
# Prometheus 告警規(guī)則
-alert:EtcdDiskSpaceLow
expr:(etcd_mvcc_db_total_size_in_bytes/etcd_server_quota_backend_bytes)>0.8
for:5m
labels:
 severity:critical
annotations:
 summary:"etcd 磁盤空間即將耗盡"

“

教訓：etcd 是 K8s 的心臟，一定要重點監(jiān)控。建議磁盤至少預留 50GB，并配置自動壓縮。

2.2 案例二：API Server OOM，集群失聯(lián)

故障現(xiàn)象

某天早上 9 點，業(yè)務高峰期，突然收到告警：

[CRITICAL] kube-apiserver 進程重啟
[CRITICAL] 大量 Pod 狀態(tài) Unknown
[WARNING] kubectl 命令響應緩慢

查看監(jiān)控發(fā)現(xiàn) API Server 內(nèi)存使用率飆升到 100%，然后被 OOM Killer 干掉了。

根因分析

# 查看 API Server 日志
journalctl -u kube-apiserver -n 200 | grep -i"oom|memory|killed"

# 查看系統(tǒng)日志
dmesg | grep -i"out of memory"
# 輸出：Out of memory: Killed process 12345 (kube-apiserver)

# 檢查 API Server 內(nèi)存配置
ps aux | grep kube-apiserver
# 發(fā)現(xiàn)沒有設置內(nèi)存限制

根本原因：有人寫了一個腳本，用kubectl get pods -A -o json獲取所有 Pod 的完整信息，而且是每 10 秒執(zhí)行一次。集群有 5000+ Pod，每次請求返回的 JSON 數(shù)據(jù)量巨大，API Server 內(nèi)存被撐爆了。

更坑的是，這個腳本還是在多個節(jié)點上并行運行的...

解決過程

# 1. 找出問題請求
# 開啟 API Server 審計日志
# 在 kube-apiserver 配置中添加：
--audit-log-path=/var/log/kubernetes/audit.log
--audit-policy-file=/etc/kubernetes/audit-policy.yaml

# 2. 分析審計日志，找出大請求
cat /var/log/kubernetes/audit.log | jq'select(.responseStatus.code == 200) | {user: .user.username, verb: .verb, resource: .objectRef.resource}'| sort | uniq -c | sort -rn | head -20

# 3. 限制 API Server 資源
# 對于 kubeadm 部署的集群，修改 /etc/kubernetes/manifests/kube-apiserver.yaml
resources:
 requests:
  cpu:"500m"
  memory:"1Gi"
 limits:
  cpu:"2"
  memory:"4Gi"# 根據(jù)實際情況調(diào)整

# 4. 配置請求限流
--max-requests-inflight=400
--max-mutating-requests-inflight=200

預防措施

# 1. API 優(yōu)先級和公平性配置（APF）
apiVersion:flowcontrol.apiserver.k8s.io/v1beta3
kind:FlowSchema
metadata:
name:restrict-list-all
spec:
priorityLevelConfiguration:
 name:low-priority
matchingPrecedence:1000
rules:
-subjects:
 -kind:ServiceAccount
  serviceAccount:
   name:"*"
   namespace:"*"
 resourceRules:
 -verbs:["list","watch"]
  apiGroups:["*"]
  resources:["pods","events"]
  namespaces:["*"]

# 2. 監(jiān)控 API Server 內(nèi)存
# Prometheus 告警規(guī)則
- alert: APIServerHighMemory
 expr: process_resident_memory_bytes{job="kube-apiserver"} > 3e9
for: 5m
 labels:
  severity: warning
 annotations:
  summary:"API Server 內(nèi)存使用過高"

“

教訓：永遠不要在生產(chǎn)環(huán)境無限制地 list 所有資源。使用 label selector、field selector 或分頁查詢。

2.3 案例三：證書過期，一夜回到解放前

故障現(xiàn)象

周一早上來上班，發(fā)現(xiàn)所有 kubectl 命令都報錯：

Unable to connect to the server: x509: certificate has expired or is not yet valid

整個集群完全無法操作，業(yè)務雖然還在跑（已有的 Pod），但無法進行任何變更。

根因分析

# 檢查證書有效期
openssl x509 -in/etc/kubernetes/pki/apiserver.crt -noout -dates
# 輸出：
# notBefore=Jan 15 0000 2025 GMT
# notAfter=Jan 15 0000 2026 GMT # 已過期！

# 檢查所有證書
kubeadm certs check-expiration

根本原因：kubeadm 創(chuàng)建的證書默認有效期是 1 年，我們忘記續(xù)期了。更慘的是，這個集群是一年前搭建的，當時沒有設置證書過期告警...

解決過程

# 1. 備份現(xiàn)有證書
cp -r /etc/kubernetes/pki /etc/kubernetes/pki.bak

# 2. 續(xù)期所有證書
kubeadm certs renew all

# 3. 重啟控制平面組件
# 對于 static pod 方式部署的組件
mv /etc/kubernetes/manifests/*.yaml /tmp/
sleep 30
mv /tmp/*.yaml /etc/kubernetes/manifests/

# 4. 更新 kubeconfig
kubeadm kubeconfig user --client-name=admin --org=system:masters > /etc/kubernetes/admin.conf
cp /etc/kubernetes/admin.conf ~/.kube/config

# 5. 驗證
kubectl get nodes

預防措施

# 1. 設置證書過期監(jiān)控
# 使用 kube-prometheus-stack 自帶的證書監(jiān)控
# 或者自定義腳本

#!/bin/bash
# check-cert-expiry.sh
CERT_PATH="/etc/kubernetes/pki/apiserver.crt"
EXPIRY_DATE=$(openssl x509 -in$CERT_PATH-noout -enddate | cut -d= -f2)
EXPIRY_EPOCH=$(date -d"$EXPIRY_DATE"+%s)
NOW_EPOCH=$(date +%s)
DAYS_LEFT=$(( ($EXPIRY_EPOCH-$NOW_EPOCH) / 86400 ))

if[$DAYS_LEFT-lt 30 ];then
 echo"WARNING: Certificate expires in$DAYS_LEFTdays"
 # 發(fā)送告警
fi

# 2. Prometheus 告警規(guī)則
-alert:KubernetesCertificateExpiration
expr:apiserver_client_certificate_expiration_seconds_count{job="kube-apiserver"}>0andhistogram_quantile(0.01,rate(apiserver_client_certificate_expiration_seconds_bucket{job="kube-apiserver"}[5m]))<604800
for:5m
labels:
? ??severity:critical
annotations:
? ??summary:"Kubernetes 證書即將過期"

“

教訓：部署集群后第一件事就是設置證書過期告警！建議在證書過期前 30 天就開始告警。

三、節(jié)點級嚴重故障

3.1 案例四：節(jié)點批量 NotReady，業(yè)務雪崩

故障現(xiàn)象

某天下午，監(jiān)控大屏突然一片紅：

[CRITICAL] Node node-01 狀態(tài)變?yōu)?NotReady
[CRITICAL] Node node-02 狀態(tài)變?yōu)?NotReady
[CRITICAL] Node node-03 狀態(tài)變?yōu)?NotReady
... (持續(xù)告警)

5 分鐘內(nèi)，集群 30% 的節(jié)點都變成了 NotReady，大量 Pod 被驅(qū)逐重建，業(yè)務出現(xiàn)嚴重抖動。

根因分析

# 查看節(jié)點狀態(tài)
kubectl get nodes
kubectl describe node node-01

# 關(guān)鍵信息：
# Conditions:
#  Ready  False  KubeletNotReady  container runtime is down

# 登錄問題節(jié)點
ssh node-01
systemctl status containerd
# 輸出：containerd.service: Failed

# 查看 containerd 日志
journalctl -u containerd -n 100
# 發(fā)現(xiàn)大量 "too many open files" 錯誤

根本原因：containerd 進程打開的文件描述符超過了系統(tǒng)限制，導致 containerd 崩潰。而 containerd 崩潰后，kubelet 無法與容器運行時通信，節(jié)點就變成 NotReady 了。

為什么會打開這么多文件？排查發(fā)現(xiàn)是某個應用瘋狂寫日志，每秒產(chǎn)生上千個日志文件...

解決過程

# 1. 臨時提高文件描述符限制
ulimit-n 1048576

# 2. 永久修改系統(tǒng)限制
cat >> /etc/security/limits.conf << EOF
* soft nofile 1048576
* hard nofile 1048576
root soft nofile 1048576
root hard nofile 1048576
EOF

# 3. 修改 containerd 服務配置
mkdir -p /etc/systemd/system/containerd.service.d/
cat > /etc/systemd/system/containerd.service.d/limits.conf << EOF
[Service]
LimitNOFILE=1048576
LimitNPROC=1048576
EOF

# 4. 重啟服務
systemctl daemon-reload
systemctl restart containerd

# 5. 清理問題應用的日志
find /var/log/pods -name?"*.log"?-size +100M -delete

預防措施

# 1. 監(jiān)控文件描述符使用
# node_exporter 自帶此指標
node_filefd_allocated / node_filefd_maximum > 0.8

# 2. 配置日志輪轉(zhuǎn)
# 在 kubelet 配置中
--container-log-max-size=100Mi
--container-log-max-files=5

“

教訓：系統(tǒng)級資源限制（ulimit）很容易被忽視，但一旦觸發(fā)就是災難性的。建議在節(jié)點初始化時就配置好。

3.2 案例五：PDB 配置不當，節(jié)點無法維護

故障現(xiàn)象

計劃對集群節(jié)點進行內(nèi)核升級，需要逐個驅(qū)逐節(jié)點上的 Pod。執(zhí)行kubectl drain時卡住了：

kubectl drain node-05 --ignore-daemonsets --delete-emptydir-data
# 輸出：
# evicting pod default/web-app-xxx
# error when evicting pods/"web-app-xxx" -n "default" (will retry after 5s):
# Cannot evict pod as it would violate the pod's disruption budget.

等了半小時還是這樣，節(jié)點維護工作完全無法進行。

根因分析

# 查看 PDB 配置
kubectl get pdb -A
kubectl describe pdb web-app-pdb

# 輸出：
# Min Available: 3
# Current: 3
# Desired: 3
# Allowed Disruptions: 0 # 問題在這里！

根本原因：PDB（Pod Disruption Budget）配置了minAvailable: 3，而 Deployment 的副本數(shù)也是 3。這意味著任何時候都不允許少于 3 個 Pod，所以一個都驅(qū)逐不了。

解決過程

# 方案一：臨時增加副本數(shù)
kubectl scale deployment web-app --replicas=4
# 等待新 Pod Ready 后再 drain

# 方案二：臨時調(diào)整 PDB
kubectl patch pdb web-app-pdb -p'{"spec":{"minAvailable":2}}'

# 方案三：刪除 PDB（不推薦，有風險）
kubectl delete pdb web-app-pdb

正確的 PDB 配置

# 推薦使用百分比而不是絕對數(shù)值
apiVersion:policy/v1
kind:PodDisruptionBudget
metadata:
name:web-app-pdb
spec:
# 方式一：最少可用百分比
minAvailable:"50%"

# 方式二：最大不可用數(shù)量（推薦）
# maxUnavailable: 1

selector:
 matchLabels:
  app:web-app

“

教訓：PDB 的 minAvailable 不要設置成和副本數(shù)相等！建議使用百分比或 maxUnavailable。

四、應用級常見問題

4.1 案例六：資源配額耗盡，新 Pod 無法創(chuàng)建

故障現(xiàn)象

開發(fā)同學反饋新部署的應用一直處于 Pending 狀態(tài)：

kubectl get pods
# NAME           READY  STATUS  RESTARTS  AGE
# new-app-xxx        0/1   Pending  0     30m

kubectl describe pod new-app-xxx
# Events:
#  Warning FailedScheduling pod didn't trigger scale-up:
#  1 Insufficient cpu, 1 Insufficient memory

根因分析

# 檢查命名空間配額
kubectl describe resourcequota -n dev

# 輸出：
# Name:      dev-quota
# Resource     Used  Hard
# --------     ----  ----
# limits.cpu    8    8   # 已用完！
# limits.memory  16Gi  16Gi  # 已用完！
# requests.cpu   4    4
# requests.memory 8Gi   8Gi

根本原因：命名空間的資源配額已經(jīng)用完了，但沒有人注意到。

解決過程

# 1. 查看當前資源使用情況
kubectl top pods -n dev

# 2. 找出資源占用大戶
kubectl get pods -n dev -o custom-columns=
NAME:.metadata.name,
CPU_REQ:.spec.containers[*].resources.requests.cpu,
MEM_REQ:.spec.containers[*].resources.requests.memory

# 3. 清理不需要的資源或擴大配額
kubectl patch resourcequota dev-quota -n dev 
 -p'{"spec":{"hard":{"limits.cpu":"16","limits.memory":"32Gi"}}}'

“

教訓：配置 ResourceQuota 后一定要配套監(jiān)控告警，在使用率達到 80% 時就應該告警。

4.2 案例七：滾動更新卡住，新舊版本并存

故障現(xiàn)象

發(fā)布新版本后，Deployment 一直卡在更新中：

kubectl rollout status deployment/api-server
# Waiting for deployment "api-server" rollout to finish: 2 out of 3 new replicas have been updated...

根因分析

kubectl get pods -l app=api-server
# NAME             READY  STATUS       RESTARTS  AGE
# api-server-old-xxx      1/1   Running      0     2d
# api-server-new-xxx      0/1   CrashLoopBackOff  5     10m
# api-server-new-yyy      0/1   CrashLoopBackOff  5     10m

kubectl describe pod api-server-new-xxx
# Events:
#  Warning Unhealthy Readiness probe failed: HTTP probe failed with statuscode: 500

根本原因：新版本代碼有 bug，健康檢查一直失敗。由于默認的滾動更新策略，舊 Pod 不會被刪除，導致更新卡住。

解決過程

# 1. 回滾到上一版本
kubectl rollout undo deployment/api-server

# 2. 查看回滾狀態(tài)
kubectl rollout status deployment/api-server

# 3. 修復代碼后重新發(fā)布

預防措施

# 配置合理的更新策略和超時
apiVersion:apps/v1
kind:Deployment
spec:
progressDeadlineSeconds:600# 10分鐘超時
strategy:
 type:RollingUpdate
 rollingUpdate:
  maxSurge:1
  maxUnavailable:0

“

教訓：發(fā)布前一定要在測試環(huán)境驗證健康檢查配置！

4.3 案例八：ConfigMap 熱更新踩坑

故障現(xiàn)象

更新了 ConfigMap 中的配置，但應用沒有生效：

kubectl edit configmap app-config
# 修改了數(shù)據(jù)庫連接字符串

# 但應用還是連接舊的數(shù)據(jù)庫
kubectl logs app-xxx | grep"database"
# 輸出還是舊的連接地址

根因分析

根本原因：ConfigMap 更新后，已經(jīng)運行的 Pod 不會自動重新加載配置。這是 K8s 的設計行為，不是 bug。

有兩種掛載方式，行為不同：

環(huán)境變量方式：永遠不會自動更新

Volume 掛載方式：會自動更新文件，但應用需要自己監(jiān)聽文件變化

解決方案

# 方案一：重啟 Pod（最簡單）
kubectl rollout restart deployment/app

# 方案二：使用 Reloader 自動重啟
# 安裝 stakater/Reloader
kubectl apply -f https://raw.githubusercontent.com/stakater/Reloader/master/deployments/kubernetes/reloader.yaml

# 在 Deployment 上添加注解
kubectl annotate deployment app reloader.stakater.com/auto="true"

“

教訓：ConfigMap 更新不會自動觸發(fā) Pod 重啟，需要額外機制處理。

4.4 案例九：HPA 抖動風暴

故障現(xiàn)象

配置了 HPA 后，Pod 數(shù)量瘋狂波動：

10:00 - 副本數(shù): 3
10:01 - 副本數(shù): 10
10:02 - 副本數(shù): 3
10:03 - 副本數(shù): 8
...

根因分析

kubectl describe hpa web-app
# 發(fā)現(xiàn) CPU 使用率在閾值附近波動
# 每次擴容后負載下降，然后縮容，負載又上升...

根本原因：HPA 配置的閾值太敏感，加上默認的擴縮容行為，導致抖動。

解決方案

apiVersion:autoscaling/v2
kind:HorizontalPodAutoscaler
spec:
behavior:
 scaleDown:
  stabilizationWindowSeconds:300# 縮容穩(wěn)定窗口
  policies:
  -type:Percent
   value:10
   periodSeconds:60
 scaleUp:
  stabilizationWindowSeconds:60
  policies:
  -type:Percent
   value:100
   periodSeconds:15

“

教訓：HPA 一定要配置 behavior 字段，控制擴縮容速度。

4.5 案例十：鏡像拉取失敗雪崩

故障現(xiàn)象

某天早上，大量 Pod 啟動失?。?/p>

kubectl get pods
# NAME          READY  STATUS       RESTARTS  AGE
# app-a-xxx        0/1   ImagePullBackOff  0     5m
# app-b-xxx        0/1   ImagePullBackOff  0     5m
# app-c-xxx        0/1   ErrImagePull    0     3m

根因分析

kubectl describe pod app-a-xxx
# Events:
#  Warning Failed  Failed to pull image "registry.example.com/app:v1":
#  rpc error: code = Unknown desc = failed to pull and unpack image:
#  unexpected status code 503 Service Unavailable

根本原因：內(nèi)部鏡像倉庫掛了，所有需要拉取鏡像的 Pod 都失敗了。

解決方案

# 1. 配置鏡像拉取策略，減少不必要的拉取
spec:
containers:
-name:app
 image:registry.example.com/app:v1
 imagePullPolicy:IfNotPresent# 本地有就不拉取

# 2. 配置多鏡像倉庫備份
# 使用 Harbor 的鏡像復制功能

“

教訓：鏡像倉庫是單點故障，必須做高可用或備份。

五、故障預防清單

5.1 必備監(jiān)控告警

監(jiān)控項	告警閾值	說明
etcd 磁盤使用率	> 80%	防止磁盤寫滿
API Server 內(nèi)存	> 80%	防止 OOM
證書有效期	< 30 天	防止證書過期
節(jié)點 Ready 狀態(tài)	NotReady > 5min	及時發(fā)現(xiàn)節(jié)點問題
Pod 重啟次數(shù)	> 5 次/小時	發(fā)現(xiàn)應用問題
資源配額使用率	> 80%	防止配額耗盡

5.2 運維檢查清單

# 每日檢查腳本
#!/bin/bash

echo"=== 集群健康檢查 ==="

# 1. 節(jié)點狀態(tài)
echo"--- 節(jié)點狀態(tài) ---"
kubectl get nodes | grep -v"Ready"

# 2. 系統(tǒng) Pod 狀態(tài)
echo"--- 系統(tǒng)組件 ---"
kubectl get pods -n kube-system | grep -v"Running|Completed"

# 3. 證書有效期
echo"--- 證書檢查 ---"
kubeadm certs check-expiration 2>/dev/null ||echo"非 kubeadm 集群"

# 4. etcd 健康
echo"--- etcd 狀態(tài) ---"
kubectl get componentstatuses 2>/dev/null

# 5. 資源使用
echo"--- 資源使用 ---"
kubectl top nodes

六、總結(jié)

6.1 十大教訓回顧

案例	核心教訓
etcd 磁盤滿	配置自動壓縮，監(jiān)控磁盤使用
API Server OOM	限制大查詢，配置 APF
證書過期	設置過期告警，定期續(xù)期
節(jié)點 NotReady	配置系統(tǒng)資源限制
PDB 配置錯誤	使用百分比或 maxUnavailable
資源配額耗盡	監(jiān)控配額使用率
滾動更新卡住	測試環(huán)境驗證健康檢查
ConfigMap 不生效	使用 Reloader 或手動重啟
HPA 抖動	配置 behavior 穩(wěn)定窗口
鏡像拉取失敗	鏡像倉庫高可用

6.2 參考資料

Kubernetes 官方故障排查指南

etcd 運維最佳實踐

Kubernetes 生產(chǎn)最佳實踐

寫在最后：每一次故障都是成長的機會。希望這些血淚教訓能幫助大家少走彎路。記住，生產(chǎn)環(huán)境沒有小事，任何配置變更都要三思而后行。