一、Pod 基礎核心概念

1. 什麼是 Pod？

Pod 是 Kubernetes 中最小部署單元，代表集羣中的一個運行進程，可包含一個或多個緊密耦合的容器，這些容器共享網絡、存儲資源和 Linux 命名空間。

• 不是直接管理容器，而是通過 Pod 封裝容器；
• 其他控制器（Deployment、StatefulSet 等）均圍繞 Pod 擴展。

2. Pod 中的容器分類

Pod 包含三類容器，各司其職：

3. Pod 存在的核心意義

1. 資源共享：多容器共享 IP（Pod IP）、端口、存儲卷，避免容器間網絡隔離帶來的通信複雜問題；
2. 生命週期綁定：同一 Pod 內的容器 “同生共死”（如日誌容器與業務容器同時啓動 / 停止）；
3. 簡化管理：將緊密耦合的組件封裝為一個單元，降低調度和運維複雜度。

4. Pod 實現機制（Pause 容器的作用）

在 Kubernetes 中，Pause 容器（也叫 “基礎容器” 或 “暫停容器”）是每個 Pod 啓動時自動創建的特殊容器，它不運行業務邏輯，而是為 Pod 內的所有應用容器提供 網絡、存儲和命名空間的基礎支撐，是 Pod 實現 “多容器資源共享” 的核心載體。

Pause 容器的核心作用

Pause 容器的本質是通過 “搶佔” Pod 的基礎資源配置，讓後續啓動的應用容器能共享這些配置，具體作用可拆解為 3 點：

1. 提供 Pod 統一的網絡命名空間

• 當 Pod 啓動時，Kubernetes 會先創建 Pause 容器，由它初始化一個 獨立的網絡命名空間（包含唯一的 Pod IP、端口範圍等）；
• 後續 Pod 內的所有應用容器（如 Nginx、日誌收集容器）會 “加入” 這個網絡命名空間，共享同一個 Pod IP 和端口資源；
• 這就實現了 “Pod 內多容器用 localhost 通信”（如日誌容器通過 localhost:80 訪問 Nginx 容器），且對外僅暴露一個 Pod IP，避免多容器網絡隔離的複雜問題。

2. 維護 Pod 統一的存儲命名空間

• Pause 容器會先掛載 Pod 定義的所有存儲卷（如 EmptyDir、PVC）；
• 應用容器通過 “複用相同的存儲掛載配置”，可以訪問同一個卷中的數據（如 Nginx 容器寫入日誌到 /var/log/nginx，日誌容器從同一個路徑讀取日誌）；
• 確保 Pod 內多容器的數據共享和持久化（即使某個應用容器重啓，數據仍保存在共享卷中）。

3. 作為 Pod 的 “根進程”，穩定管理容器生命週期

• Pause 容器的核心進程是 pause（一個極簡的睡眠進程，幾乎不佔用資源），它會成為 Pod 內所有容器的 “父進程”；
• 當 Pod 需終止時，Kubernetes 只需終止 Pause 容器，就能觸發所有應用容器的優雅退出（避免部分容器遺漏終止）；
• 同時，Pause 容器的穩定運行（幾乎不會崩潰）也確保了 Pod 網絡 / 存儲命名空間的持續存在，避免應用容器重啓導致資源配置丟失。

Pause 容器的特點

1. 資源佔用極低：Pause 容器的鏡像體積極小（僅幾 KB 到幾十 KB），運行時僅佔用微量 CPU 和內存（幾乎可忽略），不會對集羣資源造成負擔。
2. 用户透明：Pause 容器由 Kubernetes 自動創建和管理，用户無需手動配置（通過 docker ps 可在 Node 節點上看到，但在 kubectl get pods 中不會顯示，僅顯示應用容器）。
3. 與 Pod 生命週期綁定：Pause 容器與 Pod 同生共死 ——Pod 創建時它先啓動，Pod 刪除時它最後終止，確保整個 Pod 生命週期內資源配置的一致性。

如何查看 Pause 容器

1. 在 Node 節點上查看 Pause 容器進程

Pause 容器本質是一個 Docker 容器（或其他容器運行時的容器），可通過容器運行時命令查看：

# 1. 使用 docker 查看（若用 Docker 作為容器運行時）
docker ps | grep pause
# 輸出示例（鏡像名通常含 pause-amd64 或 pause）
# a1b2c3d4e5f6   registry.cn-hangzhou.aliyuncs.com/google-containers/pause-amd64:3.0   "/pause"   2h ago   Up 2h   k8s_POD_nginx-pod_default_123456-7890_0

# 2. 使用 crictl 查看（若用 containerd 作為容器運行時）
crictl ps | grep pause

2. 查看 Pause 容器的配置來源

Kubernetes 通過 kubelet 的啓動參數指定 Pause 容器的鏡像，可在 Node 節點上查看：

# 查看 kubelet 配置，找到 Pause 鏡像參數
cat /etc/kubernetes/kubelet.conf | grep pod-infra-container-image
# 或直接查看 kubelet 啓動命令（不同部署方式路徑可能不同）
cat /opt/kubernetes/cfg/kubelet | grep pod-infra-container-image

# 輸出示例（使用阿里雲鏡像源，避免國外鏡像拉取失敗）
--pod-infra-container-image=registry.cn-hangzhou.aliyuncs.com/google-containers/pause-amd64:3.0

為什麼需要 Pause 容器？

如果沒有 Pause 容器，Pod 內的多容器將面臨兩個核心問題：

1. 網絡混亂：每個容器會有獨立的 IP，多容器間通信需跨網絡，且對外暴露多個 IP，無法實現 “Pod 作為單一網絡單元”；
2. 資源管理失控：多容器的網絡 / 存儲配置需單獨維護，容器重啓後配置可能丟失，無法保證資源共享的穩定性。

Pause 容器通過 “統一資源配置 + 極簡進程” 的設計，完美解決了這些問題，是 Kubernetes 實現 “Pod 作為最小部署單元” 的關鍵技術之一。

每個 Pod 啓動時，Kubernetes 先創建 Pause 容器，再啓動應用容器：

• 網絡隔離：Pause 容器創建 Pod 專屬的網絡命名空間，應用容器共享該命名空間（統一 Pod IP）；
• 存儲共享：Pause 容器掛載存儲卷，應用容器通過掛載同一卷實現數據共享；
• 進程管理：Pause 容器作為 Pod 的 “根進程”，統一管理應用容器的生命週期。

示例：Node 節點查看 Pause 容器

# 查看 Pause 容器配置（kubelet 啓動參數）
cat /opt/kubernetes/cfg/kubelet | grep pod-infra-container-image
# 查看運行中的 Pause 容器
docker ps | grep pause-amd64

5. Pod 的兩種使用方式

二、Pod 關鍵配置（鏡像 / 重啓 / 健康檢查）

1. 鏡像拉取策略（imagePullPolicy）

定義容器啓動時如何拉取鏡像，可選值：

示例配置：

spec:
  containers:
  - name: nginx
    image: nginx:1.14
    imagePullPolicy: Always  # 每次啓動拉取鏡像

2. 重啓策略（restartPolicy）

定義容器退出後 Kubernetes 是否重啓，作用於 Pod 內所有容器：

示例配置：

spec:
  restartPolicy: OnFailure  # 僅異常退出時重啓
  containers:
  - name: busybox
    image: busybox
    args: ["/bin/sh", "-c", "sleep 30; exit 3"]  # 30秒後異常退出（狀態碼3）

3. 健康檢查（探針 Probe）

kubelet 定期診斷容器狀態，避免 “假活”（容器運行但服務不可用）或 “僵死”（容器退出未重啓），支持三種探針：

3.1 探針類型及作用

每次探測都將獲得以下三種結果之一

• 成功：容器通過了診斷。
• 失敗：容器未通過診斷。
• 未知：診斷失敗，因此不會採取任何行動

3.2 探針檢查方式

3.3 探針核心參數

3.4 示例：存活探針（exec 方式）

apiVersion: v1
kind: Pod
metadata:
  name: liveness-exec
spec:
  containers:
  - name: busybox
    image: busybox
    args: ["/bin/sh", "-c", "touch /tmp/live; sleep 30; rm -rf /tmp/live; sleep 3600"]
    livenessProbe:
      exec:
        command: ["test", "-e", "/tmp/live"]  # 檢查 /tmp/live 是否存在
      initialDelaySeconds: 5  # 啓動 5 秒後開始探測
      periodSeconds: 3        # 每 3 秒探測一次

• 前 30 秒：文件存在，探測成功；
• 30 秒後：文件被刪除，探測失敗，kubelet 重啓容器。

三、Pod 進階配置（資源限制 / 生命週期鈎子）

1. 資源限制（Requests & Limits）

為容器分配 CPU / 內存資源，避免資源爭搶，保障集羣穩定性：

• Requests（請求）：容器啓動時最少需要的資源（調度依據，如節點必須有足夠資源才能調度）；
• Limits（限制）：容器運行時最多允許使用的資源（超出則 CPU 被限制、內存被 OOM 殺死）。

1.1 資源單位

1.2 示例配置

apiVersion: v1
kind: Pod
metadata:
  name: frontend
spec:
  containers:
  - name: app  # 業務容器
    image: my-app:v4
    resources:
      requests:  # 最少需求：0.25 CPU + 64Mi 內存
        cpu: "250m"
        memory: "64Mi"
      limits:   # 最大限制：0.5 CPU + 128Mi 內存
        cpu: "500m"
        memory: "128Mi"
  - name: log-aggregator  # 日誌容器
    image: log-collector:v6
    resources:
      requests:
        cpu: "250m"
        memory: "64Mi"
      limits:
        cpu: "500m"
        memory: "128Mi"

1.3 查看資源使用情況

# 查看節點資源分配
kubectl describe node node01
# 查看 Pod 資源配置
kubectl describe pod frontend

2. 容器生命週期鈎子（Lifecycle Hooks）

在容器啓動後 / 終止前執行自定義操作，支持 postStart（啓動後）和 preStop（終止前）：

示例配置

apiVersion: v1
kind: Pod
metadata:
  name: lifecycle-demo
spec:
  containers:
  - name: nginx
    image: soscscs/myapp:v1
    lifecycle:
      postStart:  # 啓動後執行：寫入啓動日誌
        exec:
          command: ["/bin/sh", "-c", "echo '容器啓動' >> /var/log/nginx/start.log"]
      preStop:   # 終止前執行：寫入停止日誌
        exec:
          command: ["/bin/sh", "-c", "echo '容器停止' >> /var/log/nginx/stop.log"]
    volumeMounts:  # 掛載存儲卷，持久化日誌
    - name: log-volume
      mountPath: /var/log/nginx
  volumes:
  - name: log-volume
    hostPath:
      path: /data/nginx/log
      type: DirectoryOrCreate  # 目錄不存在則創建

四、Pod 狀態與容器生命週期

1. Pod 狀態（Phase）

Pod 從創建到終止的完整生命週期包含 5 種狀態：

2. 容器生命週期狀態

容器在 Pod 內的狀態細分，反映容器內部進程狀態：

Pod 生命週期（從創建到終止的完整流程）

1. Pause 容器（基礎容器） Pod 創建時，Kubernetes 先啓動一個 pause 容器， 它相當於 Pod 的“根容器”，負責：

• 維持 Pod 的 網絡命名空間（NetNS）；
• 讓 Pod 中其他容器（Init、Main）共享網絡與 IPC。

2. Init 容器階段（Init C） 在 Pause 容器建立環境後，依次執行各 Init 容器，完成初始化任務（如配置下載、權限檢測等）。
3. 主容器階段（Main C） Init 全部成功後，啓動主容器（Main C），並執行以下探針：

• Startup Probe（START）：確認應用是否成功啓動。
• Readiness Probe（readiness）：檢測應用是否可對外提供服務。
• Liveness Probe（Liveness）：檢測應用是否存活，否則重啓。

4. 停止階段（STOP） 當 Pod 終止時，主容器和 Init 容器會依次退出， 最後由 pause 容器 釋放 Pod 的網絡與資源。

一句話總結：

Pause 容器打底建環境，Init 容器做準備，Main 容器跑業務，探針全程保健康。

Pod生命週期狀態圖（簡化版）

Pending
  │
  ▼
Init Containers (按順序執行)
  │
  ▼
ContainerCreating
  │
  ▼
Running
  │
  ├─ Readiness Probe → 控制流量接入
  └─ Liveness Probe → 重啓失敗容器
  │
  ▼
Termination (SIGTERM → SIGKILL)
  │
  ▼
Succeeded / Failed

五、核心操作命令（Pod 管理）

# 1. 創建 Pod（基於 YAML）
kubectl apply -f pod.yaml

# 2. 查看 Pod 列表
kubectl get pods [-n 命名空間] [-o wide]  # -o wide 顯示 Pod IP、所在節點

# 3. 查看 Pod 詳細信息（含事件、容器配置）
kubectl describe pod <pod-name> [-n 命名空間]

# 4. 進入 Pod 內容器（-c 指定容器，多容器時必填）
kubectl exec -it <pod-name> [-c <container-name>] -- bash

# 5. 查看容器日誌（-f 實時跟蹤）
kubectl logs <pod-name> [-c <container-name>] [-f]

# 6. 刪除 Pod
kubectl delete pod <pod-name> [-n 命名空間]
# 強制刪除（卡在 Terminating 狀態時）
kubectl delete pod <pod-name> --force --grace-period=0

# 7. 查看 Pod 資源使用情況
kubectl top pod <pod-name>

Pod 的創建是一個多組件協同工作的過程，基於 Kubernetes 核心的 List-Watch 事件驅動模型，確保集羣狀態始終與期望狀態一致。以下是完整流程解析：

一、核心前提：組件監聽機制（List-Watch）

Kubernetes 集羣啓動後，三大核心組件通過 HTTPS 6443 端口 持續監聽 API Server 的資源事件變化，形成閉環控制：

二、Pod 創建完整流程（13 步驟）

1. 用户發起創建請求

用户通過 kubectl 或 API 客户端提交 Pod 配置（如 kubectl apply -f pod.yaml），請求發送至 API Server。

2. API Server 驗證與存儲

API Server 校驗請求合法性（如字段格式、權限），通過後將 Pod 元數據（名稱、標籤、規格等）寫入 etcd。

寫入成功後，API Server 向客户端返回確認信息。

3. etcd 觸發創建事件

etcd 存儲 Pod 信息後，觸發 Create 事件，並將事件推送至 API Server。

4. Controller Manager 處理事件

Controller Manager 通過 Watch 機制感知到新 Pod 創建事件。

若 Pod 由控制器（如 Deployment）管理，ReplicaSet 會檢查當前副本數是否符合期望，自動創建 / 刪除 Pod 以補全數量（擴縮容邏輯）。

5. API Server 更新 etcd 信息

Controller Manager 完成副本調整後，API Server 將 Pod 詳細信息（副本數、容器規格等）更新至 etcd。

6. etcd 觸發更新事件

etcd 確認信息更新後，再次向 API Server 發送 Update 事件。

7. Scheduler 調度 Pod

Scheduler 監聽至處於 Pending 狀態（未分配節點）的 Pod。

基於調度算法（節點資源、親和性、污點容忍度等）篩選最優節點，確定 Pod 運行位置。

8. 記錄調度結果

Scheduler 將選定的節點信息提交至 API Server，API Server 更新 etcd 中 Pod 的 Node 綁定關係。

9. etcd 確認調度結果

etcd 同步 Pod 與節點的綁定信息，返回確認給 API Server。

10. kubelet 接收 Pod 任務

目標節點的 kubelet 通過 Watch 機制發現分配給自己的新 Pod。

11. kubelet 啓動容器

kubelet 調用容器運行時（Docker/containerd）執行以下操作：

拉取容器鏡像（根據 imagePullPolicy 策略）；

創建並啓動 Pause 容器（初始化網絡和存儲命名空間）；

啓動應用容器（共享 Pause 容器的網絡和存儲）。

12. 上報 Pod 狀態

容器啓動成功後，kubelet 將 Pod 狀態（如 Running）上報至 API Server。

13. 同步最終狀態

API Server 將 Pod 最新狀態（Running/Failed 等）寫入 etcd，集羣狀態完成同步。

三、kubelet 持續監聽的原因

Pod 創建完成後，kubelet 仍持續監聽 Pod 事件，核心目的是 保證集羣狀態的動態一致性：

1. 應對副本變化：當用户通過控制器（如 Deployment）調整副本數時，kubelet 會感知新 Pod 並在節點上創建，或刪除多餘 Pod。
2. 處理鏡像更新：若 Pod 配置中的鏡像版本更新（如 nginx:1.14 → nginx:1.21），kubelet 會自動拉取新鏡像並重啓容器。
3. 維護容器健康：通過存活探針（livenessProbe）檢測容器狀態，異常時按 restartPolicy 重啓容器。
4. 響應節點資源變化：若節點資源不足或故障，kubelet 會上報狀態，觸發 Scheduler 重新調度 Pod。

總結

Pod 的創建流程是 Kubernetes 聲明式 API 和 事件驅動模型 的典型體現：

• 所有操作通過 API Server 作為統一入口，確保數據一致性；
• 組件間通過 List-Watch 機制鬆耦合協作，無需直接通信；
• 最終由 kubelet 負責在節點上落地執行，完成容器生命週期管理。

這種設計保證了集羣的高可用性和動態擴展性，即使面對節點故障、資源變化等場景，也能自動恢復至期望狀態。