引言

對于這種案例，你們的處理思路是怎么樣的呢，是否真正的處理過，如果遇到，你們應(yīng)該怎么處理。

我想大多數(shù)人都沒有遇到過。

最后有相關(guān)的社區(qū)群，有興趣可以加入。

開始

案例：emptyDir 磁盤爆滿引發(fā)的「日志黑洞」

背景與問題場景

在 Kubernetes 集群中，emptyDir 是一種生命周期與 Pod 綁定的臨時存儲卷，常用于緩存、臨時數(shù)據(jù)處理或日志緩沖。然而，由于其默認(rèn)不限制存儲容量且依賴節(jié)點磁盤的剩余空間，一旦配置不當(dāng)，可能迅速耗盡節(jié)點磁盤，引發(fā)級聯(lián)故障。

某金融系統(tǒng)生產(chǎn)環(huán)境曾因此類問題導(dǎo)致日志采集中斷、節(jié)點不可用，最終影響核心業(yè)務(wù)。以下是完整的故障還原與技術(shù)解析。

1. 故障現(xiàn)象：從日志中斷到節(jié)點崩潰

時間線：15分鐘的系統(tǒng)崩塌

? T+0：

監(jiān)控系統(tǒng)觸發(fā) node_storage_usage 告警，顯示節(jié)點 worker-03 的 /var/lib/kubelet 目錄磁盤使用率達(dá) 95%。

運維團隊收到告警但未及時響應(yīng)（正值夜間值班空窗期）。

? T+5分鐘：

? Fluentd DaemonSet Pod 日志出現(xiàn)大量 Errno::ENOSPC (No space left on device) 錯誤。

? 日志采集完全停止，Elasticsearch 中的業(yè)務(wù)日志流中斷，影響實時風(fēng)控系統(tǒng)。

? T+10分鐘：

? 節(jié)點上運行的其他 Pod（如支付網(wǎng)關(guān)）因無法寫入臨時卷（/var/log 目錄）進(jìn)入 CrashLoopBackOff 狀態(tài)。

? kubelet 日志報錯："failed to create container: disk I/O error"。

? T+15分鐘：

? 節(jié)點被標(biāo)記為 NotReady，控制平面觸發(fā) Pod 驅(qū)逐（Eviction）。

? 部分有狀態(tài)服務(wù)（如 Redis）因存儲卷未正確解綁導(dǎo)致數(shù)據(jù)短暫不一致。

關(guān)鍵現(xiàn)象排查記錄

# 檢查節(jié)點磁盤使用情況  
$ df -h /var/lib/kubelet  
Filesystem      Size  Used Avail Use% Mounted on  
/dev/nvme0n1p2  100G   95G   0G  100% /var/lib/kubelet  

# 定位占用最大的 Pod 存儲目錄  
$ du -sh /var/lib/kubelet/pods/* | sort -rh | head -n 3  
78G    /var/lib/kubelet/pods/7d8e12a3-.../volumes/kubernetes.io~empty-dir/fluentd-buffer  
12G    /var/lib/kubelet/pods/3fb2a1c1-.../volumes/kubernetes.io~empty-dir/tmp  

# 檢查 Fluentd Pod 日志  
$ kubectl logs fluentd-abcde -n logging  
2023-10-01 02:15:03 +0000 [warn]: [output_es] failed to write data: Elasticsearch::Transport::Transport::Error::NoSpace  
2023-10-01 02:15:04 +0000 [error]: no space left on device @ dir_write - /var/log/fluentd/buffer/...

2. 根因分析：從日志洪峰到存儲雪崩

emptyDir 的“沉默殺手”特性

? 默認(rèn)無容量限制：Kubernetes 不會自動限制 emptyDir 的存儲使用量，僅依賴節(jié)點磁盤的物理空間。

# 錯誤配置示例：未設(shè)置 sizeLimit  
volumes:
  - name: fluentd-buffer
    emptyDir: {}  # 隱患點！

? 存儲路徑集中化：所有 Pod 的 emptyDir 數(shù)據(jù)集中在 /var/lib/kubelet，單點故障風(fēng)險極高。

Fluentd 緩沖機制的致命缺陷

1. Buffer 配置詳解：Fluentd 使用文件緩沖（File Buffer）時，會將日志數(shù)據(jù)暫存到磁盤，直到成功發(fā)送到下游（如 Elasticsearch）。

<buffer>
  @type file
  path /var/log/fluentd/buffer  # 掛載到 emptyDir 卷
  chunk_limit_size 32MB         # 單個塊大小
  total_limit_size 512MB        # 錯誤！此參數(shù)不控制總大小（僅控制內(nèi)存中的隊列長度）
  retry_max_interval 30s
</buffer>

誤區(qū)：開發(fā)者誤認(rèn)為 total_limit_size 會限制磁盤總使用量，實際該參數(shù)僅控制內(nèi)存中的隊列長度。

后果：磁盤緩沖區(qū)可能無限增長，直到占滿節(jié)點空間。

2. 業(yè)務(wù)日志的異常洪峰：

• ? 觸發(fā)條件：某訂單處理服務(wù)因循環(huán)邏輯錯誤，在 1 分鐘內(nèi)持續(xù)打印 DEBUG 日志，生成速率達(dá)到 1GB/s。
• ? 日志內(nèi)容示例：

[DEBUG] Processing order ID: 12345, details: {"items": [...]}  # 單條日志約 10KB，每秒寫入 10 萬次

故障鏈推演

圖片

圖片

3. 解決方案：分層防御與彈性設(shè)計

階段一：緊急止血（5分鐘恢復(fù)）

1. 快速釋放磁盤空間：

? 強制清理：

# 找到占用最高的 emptyDir 目錄  
du -sh /var/lib/kubelet/pods/* | grep G  
# 手動刪除數(shù)據(jù)（需確認(rèn)無關(guān)鍵數(shù)據(jù)）  
rm -rf /var/lib/kubelet/pods/<pod-id>/volumes/kubernetes.io~empty-dir/fluentd-buffer/*

? 風(fēng)險：直接刪除文件可能導(dǎo)致 Fluentd 數(shù)據(jù)丟失，需評估日志重要性。

2. 臨時擴容與調(diào)度：

? 垂直擴容：臨時為節(jié)點掛載云盤并擴展文件系統(tǒng)（如 AWS EBS 卷擴容）。

? Pod 遷移：

kubectl cordon worker-03          # 停止調(diào)度新 Pod  
kubectl drain worker-03 --force   # 驅(qū)逐現(xiàn)有 Pod

階段二：根因修復(fù)（配置與架構(gòu)優(yōu)化）

1. emptyDir 容量硬限制：

volumes:
  - name: fluentd-buffer
    emptyDir:
      sizeLimit: 10Gi  # 關(guān)鍵！超出此限制時，Pod 會被驅(qū)逐并自動清理數(shù)據(jù)

? 驅(qū)逐機制：當(dāng) emptyDir 卷超過 sizeLimit，Kubelet 會標(biāo)記 Pod 為 Evicted，釋放存儲空間。

2. Fluentd 緩沖層加固：

? 啟用內(nèi)存緩沖優(yōu)先：

<buffer>
  @type hybrid         # 混合緩沖模式
  <memory>
    chunk_limit_size 256MB
    total_limit_size 8GB   # 內(nèi)存緩沖上限
  </memory>
  <file>
    path /var/log/fluentd/buffer
    chunk_limit_size 512MB
  </file>
</buffer>

? 流量熔斷機制：

<match **>
  @type elasticsearch
  # 當(dāng)日志堆積超過閾值時，丟棄新日志（根據(jù)業(yè)務(wù)需求選擇）  
  overflow_action throw_exception  
  # 或降級到本地文件  
  overflow_action block  
</match>

3. 日志管道的彈性設(shè)計：

圖片

? 動態(tài)采樣與降級：

<filter app.logs>  
  @type sample  
  interval 10  
  # 當(dāng)日志速率超過閾值時，僅每10條記錄1條  
</filter>

? 引入消息隊列：在 Fluentd 與 Elasticsearch 之間增加 Kafka，解耦生產(chǎn)與消費速率。

階段三：防御體系構(gòu)建（監(jiān)控與自動化）

1. 存儲配額與 LimitRange：

apiVersion: v1
kind: LimitRange
metadata:
  name: storage-limiter
spec:
  limits:
  - type: Container
    maxLimitRequestRatio:
      ephemeral-storage: "2"  # 限制臨時存儲超售比例
    defaultRequest:
      ephemeral-storage: "1Gi"

2. 精細(xì)化監(jiān)控：

? Prometheus 規(guī)則示例：

- alert: HighEmptyDirUsage
  expr: (kubelet_volume_stats_used_bytes{persistentvolume="~empty-dir.*"} / kubelet_volume_stats_capacity_bytes) > 0.7  
  for: 5m  
  labels:  
    severity: critical  
  annotations:  
    summary: "EmptyDir volume usage exceeds 70% on {{ $labels.node }}"

? Grafana 看板：監(jiān)控每個 Pod 的 emptyDir 使用量排名。

3. 混沌測試驗證：

? 使用 Chaos Mesh 模擬日志洪峰，驗證防御機制是否生效：

apiVersion: chaos-mesh.org/v1alpha1  
kind: IOChaos  
metadata:  
  name: disk-pressure-test  
spec:  
  action: "latency"  
  volumePath: "/var/lib/kubelet"  
  path: "/var/lib/kubelet/**/*.log"  
  delay: "100ms"  
  duration: "10m"

4. 深度總結(jié)：云原生存儲的防御哲學(xué)

從故障中學(xué)到的教訓(xùn)

1. “默認(rèn)安全”并不存在：

? Kubernetes 的靈活性需要顯式的防護(hù)約束，如 sizeLimit、資源配額等。

2. 日志系統(tǒng)的容錯性優(yōu)先級：

? 日志管道需設(shè)計降級策略（如本地緩存、動態(tài)采樣），避免影響核心業(yè)務(wù)。

3. 監(jiān)控的顆粒度決定響應(yīng)速度：

? 不僅要監(jiān)控節(jié)點級指標(biāo)，還需細(xì)化到 Pod 的臨時存儲使用量。

擴展風(fēng)險場景

? CI/CD 流水線：Jenkins Pod 的臨時構(gòu)建目錄可能因大文件占滿磁盤。

? 機器學(xué)習(xí)訓(xùn)練：訓(xùn)練任務(wù)的臨時模型緩存需限制 emptyDir 大小。

? 臨時數(shù)據(jù)庫：Redis 或 SQLite 若使用 emptyDir，需設(shè)置存儲閾值。

防御體系的金字塔模型

熔斷降級  
          ▲  
彈性存儲架構(gòu)  
          ▲  
資源限制（sizeLimit）  
          ▲  
實時監(jiān)控告警  
          ▲  
默認(rèn)安全配置

通過分層防御，將存儲風(fēng)險從“事后補救”轉(zhuǎn)變?yōu)椤笆虑邦A(yù)防”，確保云原生系統(tǒng)的韌性。