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

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

一、概述

1.1 背景介紹

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

配置不當(dāng)

資源規(guī)劃不合理

缺乏監(jiān)控告警

操作流程不規(guī)范

對(duì)某些機(jī)制理解不深

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

本文將按照故障嚴(yán)重程度，從"集群級(jí)災(zāi)難"到"應(yīng)用級(jí)問題"，逐一復(fù)盤 10 個(gè)真實(shí)案例：

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

1.3 環(huán)境信息

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

二、集群級(jí)災(zāi)難案例

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

故障現(xiàn)象

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

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

登錄 master 節(jié)點(diǎn)一看，kubectl命令卡住不動(dòng)，整個(gè)集群基本癱瘓了。

根因分析

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

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

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

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

為什么會(huì)寫滿？排查發(fā)現(xiàn)是因?yàn)椋?/p>

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

etcd 沒有配置自動(dòng)壓縮（compaction）

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

解決過程

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

# 2. 手動(dòng)壓縮 etcd
# 獲取當(dāng)前 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

預(yù)防措施

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

# 2. 設(shè)置配額告警
--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 磁盤空間即將耗盡"

“

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

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

故障現(xiàn)象

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

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

查看監(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)沒有設(shè)置內(nèi)存限制

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

更坑的是，這個(gè)腳本還是在多個(gè)節(jié)點(diǎn)上并行運(yùn)行的...

解決過程

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

# 2. 分析審計(jì)日志，找出大請(qǐng)求
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 資源
# 對(duì)于 kubeadm 部署的集群，修改 /etc/kubernetes/manifests/kube-apiserver.yaml
resources:
 requests:
  cpu:"500m"
  memory:"1Gi"
 limits:
  cpu:"2"
  memory:"4Gi"# 根據(jù)實(shí)際情況調(diào)整

# 4. 配置請(qǐng)求限流
--max-requests-inflight=400
--max-mutating-requests-inflight=200

預(yù)防措施

# 1. API 優(yōu)先級(jí)和公平性配置（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)存使用過高"

“

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

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

故障現(xiàn)象

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

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

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

根因分析

# 檢查證書有效期
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)建的證書默認(rèn)有效期是 1 年，我們忘記續(xù)期了。更慘的是，這個(gè)集群是一年前搭建的，當(dāng)時(shí)沒有設(shè)置證書過期告警...

解決過程

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

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

# 3. 重啟控制平面組件
# 對(duì)于 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. 驗(yàn)證
kubectl get nodes

預(yù)防措施

# 1. 設(shè)置證書過期監(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 證書即將過期"

“

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

三、節(jié)點(diǎn)級(jí)嚴(yán)重故障

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

故障現(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é)點(diǎn)都變成了 NotReady，大量 Pod 被驅(qū)逐重建，業(yè)務(wù)出現(xiàn)嚴(yán)重抖動(dòng)。

根因分析

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

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

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

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

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

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

解決過程

# 1. 臨時(shí)提高文件描述符限制
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 服務(wù)配置
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. 重啟服務(wù)
systemctl daemon-reload
systemctl restart containerd

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

預(yù)防措施

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

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

“

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

3.2 案例五：PDB 配置不當(dāng)，節(jié)點(diǎn)無法維護(hù)

故障現(xiàn)象

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

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.

等了半小時(shí)還是這樣，節(jié)點(diǎn)維護(hù)工作完全無法進(jìn)行。

根因分析

# 查看 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。這意味著任何時(shí)候都不允許少于 3 個(gè) Pod，所以一個(gè)都驅(qū)逐不了。

解決過程

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

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

# 方案三：刪除 PDB（不推薦，有風(fēng)險(xiǎn)）
kubectl delete pdb web-app-pdb

正確的 PDB 配置

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

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

selector:
 matchLabels:
  app:web-app

“

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

四、應(yīng)用級(jí)常見問題

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

故障現(xiàn)象

開發(fā)同學(xué)反饋新部署的應(yīng)用一直處于 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. 查看當(dāng)前資源使用情況
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. 清理不需要的資源或擴(kuò)大配額
kubectl patch resourcequota dev-quota -n dev 
 -p'{"spec":{"hard":{"limits.cpu":"16","limits.memory":"32Gi"}}}'

“

教訓(xùn)：配置 ResourceQuota 后一定要配套監(jiān)控告警，在使用率達(dá)到 80% 時(shí)就應(yīng)該告警。

4.2 案例七：滾動(dòng)更新卡住，新舊版本并存

故障現(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，健康檢查一直失敗。由于默認(rèn)的滾動(dòng)更新策略，舊 Pod 不會(huì)被刪除，導(dǎo)致更新卡住。

解決過程

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

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

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

預(yù)防措施

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

“

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

4.3 案例八：ConfigMap 熱更新踩坑

故障現(xiàn)象

更新了 ConfigMap 中的配置，但應(yīng)用沒有生效：

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

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

根因分析

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

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

環(huán)境變量方式：永遠(yuǎn)不會(huì)自動(dòng)更新

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

解決方案

# 方案一：重啟 Pod（最簡(jiǎn)單）
kubectl rollout restart deployment/app

# 方案二：使用 Reloader 自動(dòng)重啟
# 安裝 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"

“

教訓(xùn)：ConfigMap 更新不會(huì)自動(dòng)觸發(fā) Pod 重啟，需要額外機(jī)制處理。

4.4 案例九：HPA 抖動(dòng)風(fēng)暴

故障現(xiàn)象

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

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 使用率在閾值附近波動(dòng)
# 每次擴(kuò)容后負(fù)載下降，然后縮容，負(fù)載又上升...

根本原因：HPA 配置的閾值太敏感，加上默認(rèn)的擴(kuò)縮容行為，導(dǎo)致抖動(dòng)。

解決方案

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

“

教訓(xùn)：HPA 一定要配置 behavior 字段，控制擴(kuò)縮容速度。

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

故障現(xiàn)象

某天早上，大量 Pod 啟動(dòng)失?。?/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)部鏡像倉(cāng)庫(kù)掛了，所有需要拉取鏡像的 Pod 都失敗了。

解決方案

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

# 2. 配置多鏡像倉(cāng)庫(kù)備份
# 使用 Harbor 的鏡像復(fù)制功能

“

教訓(xùn)：鏡像倉(cāng)庫(kù)是單點(diǎn)故障，必須做高可用或備份。

五、故障預(yù)防清單

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

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

5.2 運(yùn)維檢查清單

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

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

# 1. 節(jié)點(diǎn)狀態(tài)
echo"--- 節(jié)點(diǎn)狀態(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 十大教訓(xùn)回顧

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

6.2 參考資料

Kubernetes 官方故障排查指南

etcd 運(yùn)維最佳實(shí)踐

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

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