目錄

基本概念

?一、Pod 的原理?

?二、Pod 的特性?

?三、Pod 的意義?

狀態碼詳解

?一、Pod 核心狀態詳解?

?二、其他關鍵狀態標識?

?三、狀態碼運維要點?

?探針

?一、探針的核心原理?

?二、三大探針的特性與作用?

?參數詳解?

?三、探針的核心意義?

?四、配置建議與風險規避?

?鏡像拉取策略

?一、鏡像拉取策略（Image Pull Policy）?

?二、重啟策略（Restart Policy）?

?三、聯合應用場景?

---

基本概念

?一、Pod 的原理?

Pod 的原理基于容器共享機制，將一組緊密關聯的容器組織為一個邏輯單元，實現資源隔離與協同調度：

• ?最小調度單元?：每個 Pod 是 Kubernetes 中最小的可部署對象，包含一個或多個容器，這些容器總是被并置（colocated）在同一節點上，共享存儲、網絡命名空間和控制組（CGroup），確保它們在同一上下文中運行；這避免了容器間的通信延遲和資源沖突。
• ?根容器設計?：每個 Pod 包含一個特殊的 Pause 容器（根容器），用于設置 Pod 的 IP 地址、評估健康狀態，并為其他業務容器提供共享網絡棧和存儲卷；業務容器通過掛載根容器的資源實現高效數據交換。
• ?調度機制?：Pod 被一次性調度到節點后，由 kubelet 管理其生命周期；如果調度失敗（如節點崩潰），Pod 將被刪除并重新創建，確保高可用性。

?二、Pod 的特性?

Pod 具備多個核心特性，支持高效、靈活的容器管理：

• ?資源共享環境?：
  • 網絡共享：Pod 內所有容器共享同一個 IP 地址和網絡命名空間，可通過?localhost?直接通信，外部訪問需通過 IP + 端口方式；不同 Pod 間的通信則依賴虛擬網絡層（如 Calico）。
  • 存儲共享：容器可掛載共享存儲卷（如 emptyDir、configMap），實現數據持久化或配置同步，簡化了狀態管理。
• ?生命周期管理?：
  • Pod 狀態包括 Pending（容器未啟動）、Running（容器運行中）、Succeeded（所有容器成功終止）、Failed（容器異常終止）和 Unknown（狀態未知）；狀態變化由 kubelet 監控和報告。
  • 重啟策略（通過?spec.restartPolicy?定義）：支持 Always（默認自動重啟）、OnFailure（僅在異常退出時重啟）和 Never（不重啟），確保容器故障時 Pod 能自我修復。
• ?容器組織靈活性?：
  • 支持單容器或多容器模式：單容器 Pod 適用于簡單應用，多容器 Pod 適用于緊密耦合服務（如 Web 服務器與日志代理），容器間通過共享資源減少通信開銷。
  • 擴展機制：如 Init 容器（用于啟動前初始化任務）和臨時容器（用于調試），增強 Pod 的功能適應性。

?三、Pod 的意義?

Pod 在 Kubernetes 體系中的意義在于解決容器化應用的設計與管理痛點：

• ?支持緊密耦合應用?：允許將多個關聯進程（如 Web 服務與日志處理器）封裝在同一 Pod 中，共享上下文環境；這避免了單容器多進程模式下的監控失效問題（如輔助進程崩潰無法被檢測），提升應用整體穩定性。
• ?提升編排效率?：作為最小部署單元，Pod 簡化了調度和資源分配；控制器（如 Deployment 或 ReplicaSet）基于 Pod 實現自動化擴縮容、滾動更新，降低了運維復雜性。
• ?優化資源利用率?：通過共享網絡和存儲，減少了冗余資源開銷（如獨立 IP 分配），同時支持原子性調度（容器作為整體部署），提高了集群資源利用率和應用性能。

Pod 的設計體現了 Kubernetes 對“邏輯主機”的抽象，解決了分布式系統中容器協同的挑戰，是現代云原生架構的基礎組件。

狀態碼詳解

?一、Pod 核心狀態詳解?

1. ?Pending（掛起中）?

   • ?觸發條件?：Pod 已被 API Server 接受，但未完成調度或容器啟動。
   • ?典型原因?：
     • 節點資源不足（CPU/內存）
     • 鏡像拉取中（特別是大體積鏡像）
     • 存儲卷未綁定（如 PVC 掛載延遲）
   • ?關鍵子狀態?：
     • ContainerCreating：容器創建中（鏡像拉取/存儲掛載）
     • ImagePullBackOff：鏡像拉取失敗后的重試等待

2. ?Running（運行中）?

   • ?觸發條件?：Pod 已調度到節點，至少一個主容器正在運行或啟動中。
   • ?注意?：
     • 不保證容器已就緒（需結合 Readiness Probe 檢測）
     • 可能包含已終止的初始化容器

3. ?Succeeded（成功終止）?

   • ?觸發條件?：所有容器正常退出（exit code = 0）。
   • ?典型場景?：Job/CronJob 任務完成

4. ?Failed（失敗終止）?

   • ?觸發條件?：至少一個容器異常退出（exit code ≠ 0）或被系統終止（如 OOMKilled）。
   • ?排查工具?：
     • kubectl logs --previous?查看崩潰前日志
     • kubectl describe pod?分析事件詳情

5. ?Unknown（未知狀態）?

   • ?原因?：節點失聯或 API Server 與 kubelet 通信中斷。
   • ?處理建議?：檢查節點狀態并重啟 kubelet

---

?二、其他關鍵狀態標識?

?狀態名稱?	?中文譯名?	?觸發條件?	?典型原因?
?CrashLoopBackOff?	崩潰循環回溯	容器反復崩潰，kubelet 按指數退避策略重啟	應用配置錯誤、依賴缺失、啟動崩潰
?ContainerCreating?	容器創建中	Pod 已調度，但容器尚未啟動完成	鏡像拉取延遲、存儲/網絡配置未就緒
?Terminating?	終止中	Pod 收到刪除指令但未完全停止	優雅終止耗時過長、終止鉤子阻塞
?Evicted?	已驅逐	節點資源不足（如內存、磁盤）時主動驅逐 Pod	節點壓力過大（OOM、磁盤滿）
?ImagePullBackOff?	鏡像拉取重試中	拉取鏡像失敗后進入重試循環	鏡像不存在、倉庫認證失敗、網絡中斷
?PodInitializing?	Pod 初始化中	Init 容器正在執行初始化任務	Init 容器未完成（如數據預加載）
?CreateContainerError?	容器創建錯誤	kubelet 無法創建容器	鏡像格式損壞、運行時配置沖突

---

?三、狀態碼運維要點?

1. ?退出碼解析?：

   • ?0?：正常退出
   • ?1-128?：應用自身錯誤（如配置異常）
   • ?129-255?：系統中斷導致（如?SIGKILL?對應 137）
   • 轉換規則：負退出碼按?256 - (|code| % 256)?轉換（如?exit(-1)?→ 255）

2. ?調試建議?：

   • 使用?kubectl describe pod?查看 ?Events? 段定位根本原因；
   • CrashLoopBackOff?需檢查容器日志及資源請求限制；
   • Evicted?狀態需監控節點資源水位并優化調度策略。

?探針

?一、探針的核心原理?

探針本質是 ?kubelet 定期執行的健康檢查機制?，通過三種探測方式判斷容器狀態，并觸發相應控制器行為：

1. ?檢測執行者?：
   • 由節點上的 ?kubelet? 直接發起（非 Master 或 Pod 自身），頻率通過?periodSeconds?控制。
2. ?探測類型?：
   • ?HTTP GET?：向容器 IP 發送 HTTP 請求，狀態碼 2xx/3xx 視為成功（如?httpGet: { path: /healthz, port: 8080 }）。
   • ?TCP Socket?：嘗試與容器指定端口建立 TCP 連接，成功即通過（如數據庫服務）。
   • ?Exec?：在容器內執行命令，退出碼為 0 視為健康（如?command: ["sh", "-c", "pgrep nginx"]）。
3. ?狀態反饋機制?：
   • 探測結果實時反饋給 kubelet，觸發 Pod 狀態變更或控制器動作（如重啟容器、調整流量）。

---

?二、三大探針的特性與作用?

?探針類型?	?核心目標?	?觸發動作?	?關鍵配置參數?
?LivenessProbe? (存活探針)	檢測容器?是否僵死?（如死鎖、內存泄漏）	失敗時 ?重啟容器?（依據 Pod 的?restartPolicy）	failureThreshold（連續失敗次數閾值） timeoutSeconds（單次探測超時時間）
?ReadinessProbe? (就緒探針)	判斷容器?是否準備好接收流量?	失敗時 ?從 Service 的 Endpoints 移除 IP?，暫停流量轉發	initialDelaySeconds（啟動后首次探測延遲） successThreshold（標記就緒的最小成功次數）
?StartupProbe? (啟動探針)	確保?慢啟動容器完成初始化?	成功前?禁用 Liveness/Readiness 探針?；失敗時重啟容器	periodSeconds（探測間隔） failureThreshold（允許的最大失敗次數）

?參數詳解?

livenessProbe:httpGet: { path: /health, port: 80 }initialDelaySeconds: 10 # 容器啟動10秒后開始探測periodSeconds: 5 # 每5秒探測一次timeoutSeconds: 3 # 超時3秒視為失敗failureThreshold: 3 # 連續失敗3次觸發重啟 

---

?三、探針的核心意義?

1. ?提升服務自愈能力?
   • 存活探針自動重啟異常容器（如進程阻塞但未退出），減少人工干預，保障服務持續可用。
2. ?保障流量精確調度?
   • 就緒探針確保流量僅轉發至已初始化完成的 Pod，避免請求打到未就緒實例導致 5xx 錯誤。
3. ?兼容復雜應用場景?
   • 啟動探針為慢啟動應用（如 Java）提供保護窗口，防止存活探針誤判初始化過程為故障。
4. ?優化滾動更新體驗?
   • 就緒探針與 Deployment 結合，實現“新 Pod 就緒 → 舊 Pod 終止”的平滑更新，避免服務中斷。

---

?四、配置建議與風險規避?

• ?存活探針禁用場景?：
  避免對執行單次任務的 Job 配置存活探針，否則任務完成后容器退出可能觸發誤重啟。
• ?參數調優原則?：
  • initialDelaySeconds?> 應用啟動時間（如 Spring Boot 設 30 秒以上）。
  • timeoutSeconds?需大于應用平均響應時間（建議 2-5 秒）。
• ?探針輕量化設計?：
  檢測接口應獨立于核心邏輯（如專用?/healthz），避免資源競爭或級聯故障。

?鏡像拉取策略

?一、鏡像拉取策略（Image Pull Policy）?

1. ?原理?

   • 由?imagePullPolicy?字段控制，kubelet 根據策略決定是否從鏡像倉庫拉取鏡像。
   • 優先級規則：若未顯式指定策略，鏡像標簽為?:latest?時默認為?Always，否則為?IfNotPresent。

2. ?特性?

   ?策略類型?	?行為?	?適用場景?
   Always	每次創建 Pod 都強制拉取最新鏡像（即使本地已存在）	開發/測試環境，需頻繁更新鏡像
   IfNotPresent	僅當本地不存在鏡像時拉取（優先使用本地緩存）	生產環境，減少網絡開銷
   Never	僅使用本地鏡像，不主動拉取（需手動預加載）	離線環境或安全敏感場景

3. ?意義?

   • 平衡?鏡像一致性?與?啟動效率?：Always?確保版本嚴格一致，IfNotPresent?加速啟動。
   • 支持?離線部署?：通過?Never?策略實現無外網依賴的容器化部署。

---

?二、重啟策略（Restart Policy）?

1. ?原理?

   • 由?restartPolicy?字段定義，kubelet 根據容器退出狀態決定是否重啟。
   • ?關鍵機制?：
     • 檢測容器進程退出碼（0 為正常，非 0 為異常）。
     • 結合探針（如?livenessProbe）綜合判斷容器健康狀態。

2. ?特性?

   ?策略類型?	?行為?	?適用場景?
   Always	無論退出碼如何均重啟（默認策略）	長期運行服務（如 Nginx）
   OnFailure	僅當容器異常退出（非 0 退出碼）時重啟	批處理任務（失敗后重試）
   Never	永不重啟（即使異常退出）	一次性任務或調試場景

3. ?意義?

   • ?自愈能力?：Always?策略保障服務持續可用，自動恢復崩潰的容器。
   • ?資源優化?：OnFailure?避免無意義的重啟（如成功退出的 Job）。

---

?三、聯合應用場景?

• ?生產環境典型配置?：

  spec:containers:- image: nginx:1.25 # 固定版本標簽imagePullPolicy: IfNotPresent # 減少拉取延遲restartPolicy: Always # 確保服務高可用 

  • 鏡像策略選擇?IfNotPresent?提升啟動速度，重啟策略選擇?Always?實現故障自愈。

• ?調試任務配置?：

  spec:containers:- image: debug-tool:latestimagePullPolicy: Never # 依賴預加載鏡像restartPolicy: Never # 避免干擾調試過程 

  • 通過?Never?策略完全控制容器生命周期。

---

通過鏡像拉取與重啟策略的靈活組合，Kubernetes 實現了?部署效率?與?運行穩定性?的平衡。