流程圖

具體生成過程

用戶提交 Pod 定義

用戶通過提交 Pod 的 YAML/JSON 配置文件發送到 kube-apiserver。

kubectl apply -f pod.yaml 

API Server 處理請求

• 認證與授權：API Server 驗證用戶身份（如 TLS 證書、Token）并檢查權限（RBAC）。
• 準入控制（Admission Control）：
  • Mutating Admission Controllers：可能修改 Pod 配置（例如注入 Sidecar 容器）。
  • Validating Admission Controllers：驗證配置的合法性（如資源限制是否合規）。
• 持久化存儲：驗證通過后，Pod 的元數據寫入 etcd 數據庫，此時 Pod 狀態為 Pending。

調度器分配節點（Scheduling）

• kube-scheduler 監聽 API Server，發現未綁定的 Pod。
• 根據調度策略選擇合適節點：
  • 資源需求（CPU/內存）。
  • 節點選擇器（nodeSelector）、親和性（affinity）、污點與容忍（tolerations）。
• 更新 Pod 的 nodeName 字段并寫入 etcd，觸發事件（如 Scheduled）。

目標節點上的 Pod 創建

• kubelet 監聽 API Server，發現分配到本節點的 Pod。
• Pod 配置同步：kubelet 從 API Server 獲取 Pod 定義。
• 存儲卷掛載：按配置掛載持久卷（PV）、ConfigMap、Secret 等。
• 容器運行時交互：
  • 拉取鏡像：通過容器運行時（如 containerd）拉取鏡像，失敗時狀態為 ImagePullBackOff。
  • 創建容器：
    • 先創建 pause 容器（共享網絡命名空間）。
    • 按順序啟動 Init 容器（若有），全部成功后繼續。
    • 啟動主容器，執行生命周期鉤子（如 postStart）。

網絡配置

• CNI 插件調用：kubelet 調用 CNI 插件為 Pod 分配 IP、設置網絡（如 Calico、Flannel）。
• 網絡策略（NetworkPolicy）可能由 CNI 插件或其他組件（如 Cilium）實施。

狀態上報與監控

• kubelet 持續監控容器狀態，定期向 API Server 上報：
  • 容器啟動成功 → Pod 狀態變為 Running。
  • 容器崩潰或探針失敗 → 狀態為 CrashLoopBackOff 或 Unhealthy。
• 事件流記錄：各組件（調度器、kubelet）通過 API Server 記錄事件（如 Pulled, Started），可通過 kubectl describe pod 查看。

控制器管理（Controller Manager）

• 若 Pod 屬于高層資源（如 Deployment、ReplicaSet）：
  • 控制器確保實際狀態與期望狀態一致（例如重啟失敗的 Pod 或維持副本數）。
  • 自愈機制：自動替換不健康的 Pod（如節點故障時重新調度）。

就緒與服務發現

• 就緒探針（Readiness Probe） 通過后，Pod IP 被加入 Service 的 Endpoints。
• kube-proxy 更新節點上的 iptables/ipvs 規則，允許流量路由到新 Pod。

關鍵錯誤場景

• 調度失敗：無合適節點 → Pod 保持 Pending，需檢查資源請求、節點標簽或污點。
• 鏡像拉取失敗：私有鏡像權限問題 → 狀態為 ImagePullBackOff。
• 容器崩潰：應用啟動錯誤 → CrashLoopBackOff，需檢查日志（kubectl logs）。

高級特性

• Init 容器：按順序運行，全部成功后才啟動主容器。
• Sidecar 注入：通過 Admission Controller（如 Istio 的自動注入）動態修改 Pod 配置。