在Kubernetes(K8s)的世界裏,Pod、Service、Deployment是構建應用的三大核心組件。新手它們分工明確又協同工作,共同支撐着容器化應用的穩定運行。本文將深入解析這三個組件的工作機制,通過示例代碼展示它們如何配合實現應用的部署、訪問與擴縮容。

一、Pod:容器的"最小部署單元"

定義:Pod是K8s中最小的可部署單元,包含一個或多個緊密關聯的容器,共享網絡和存儲資源。

工作機制

  • Pod內的容器共享同一網絡命名空間(即同一IP地址和端口空間),可通過localhost直接通信;
  • 生命週期短暫,一旦銷燬無法恢復(如節點故障時,Pod會被重新調度到其他節點,但已是新實例);
  • 不具備自愈能力,需依賴控制器(如Deployment)管理。

示例:運行Nginx的Pod

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
  labels:
    app: nginx  # 標籤用於關聯Service和Deployment
spec:
  containers:
  - name: nginx
    image: nginx:1.21
    ports:
    - containerPort: 80  # 容器內暴露的端口
    resources:
      requests:
        cpu: "100m"      # 最小CPU需求
        memory: "128Mi"  # 最小內存需求

關鍵特性

  • 當Pod包含多個容器時(如應用容器+日誌收集容器),所有容器共享存儲卷(Volume),實現數據共享;
  • 每個Pod會被分配唯一的IP地址(僅在集羣內部可達),稱為"Pod IP"。

二、Service:Pod的"穩定訪問入口"

定義:Service是Pod的固定訪問點,通過標籤選擇器關聯一組Pod,解決Pod IP動態變化的問題。

工作機制

  • 為關聯的Pod提供固定的集羣內部IP(Cluster IP)和DNS名稱;
  • 實現負載均衡:自動將請求分發到健康的Pod實例;
  • 與Pod的生命週期解耦:當Pod銷燬或重建時,Service無需修改即可繼續提供服務。

示例:關聯Nginx Pod的Service

apiVersion: v1
kind: Service
metadata:
  name: nginx-svc
spec:
  selector:
    app: nginx  # 匹配標籤為app=nginx的Pod
  ports:
  - port: 8080        # Service暴露的端口
    targetPort: 80    # 轉發到Pod的端口
  type: ClusterIP     # 僅集羣內部可訪問(默認類型)

訪問驗證: 在集羣內的任意Pod中,可通過以下方式訪問服務:

# 通過Service名稱(依賴K8s DNS)
curl http://nginx-svc:8080

# 通過Cluster IP(需替換為實際IP)
curl http://10.96.xx.xx:8080

Service類型擴展

  • NodePort:在每個節點開放靜態端口,外部可通過節點IP:NodePort訪問;
  • LoadBalancer:結合雲廠商負載均衡器,提供外部訪問入口。

三、Deployment:Pod的"自動化管理器"

定義:Deployment是聲明式管理Pod的控制器,負責Pod的創建、更新、擴縮容和自愈。

工作機制

  • 通過ReplicaSet管理Pod副本數量,確保實際運行的Pod數與期望數量一致;
  • 支持滾動更新:更新鏡像時,逐步替換舊Pod,避免服務中斷;
  • 支持版本回滾:當新版本出現問題時,可快速回滾到歷史穩定版本。

示例:管理Nginx Pod的Deployment

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deploy
spec:
  replicas: 3  # 期望3個Pod副本
  selector:
    matchLabels:
      app: nginx  # 關聯標籤為app=nginx的Pod
  template:
    # 以下是Pod模板,與單獨定義Pod的spec一致
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.21
        ports:
        - containerPort: 80

核心操作示例

  1. 擴縮容:調整副本數量
# 實時調整為5個副本
kubectl scale deployment nginx-deploy --replicas=5
  1. 滾動更新:升級鏡像版本
# 更新鏡像為1.23版本
kubectl set image deployment nginx-deploy nginx=nginx:1.23

# 查看更新狀態
kubectl rollout status deployment nginx-deploy
  1. 版本回滾:回退到上一版本
# 查看歷史版本
kubectl rollout history deployment nginx-deploy

# 回滾到上一版本
kubectl rollout undo deployment nginx-deploy

四、三者協同關係:從部署到訪問的完整鏈路

  1. 創建流程
  • 用户創建Deployment,K8s自動生成ReplicaSet;
  • ReplicaSet根據Pod模板創建指定數量的Pod;
  • 用户創建Service,通過標籤關聯到這些Pod。
  1. 訪問流程
  • 外部請求通過Service的Cluster IP或DNS名稱進入;
  • Service將請求負載均衡到關聯的多個Pod;
  • 若某個Pod故障,Deployment會自動創建新Pod,Service檢測到新Pod後將其加入負載均衡池。
  1. 動態調整
  • 當流量增加時,通過Deployment擴縮容調整Pod數量;
  • 當需要更新應用時,Deployment執行滾動更新,Service無縫切換到新Pod。

五、總結:核心價值與最佳實踐

  • Pod:作為容器的載體,封裝應用運行環境,強調"緊密關聯的容器組合";
  • Service:提供穩定訪問點,解決Pod動態變化的問題,實現"服務發現與負載均衡";
  • Deployment:實現Pod的自動化管理,提供"自愈、擴縮容、版本控制"能力。

最佳實踐

  1. 避免直接創建Pod,始終通過Deployment管理,確保高可用性;
  2. 為所有Pod添加明確的標籤,便於Service和Deployment關聯;
  3. 利用Deployment的滾動更新策略,實現應用無停機升級;
  4. 根據業務需求選擇合適的Service類型,控制服務訪問範圍。

理解這三個組件的工作機制,是掌握K8s應用部署的基礎。它們的協同設計體現了K8s"聲明式API"和"自愈能力"的核心思想,讓開發者可以專注於業務邏輯,而非基礎設施管理。