.NET Core + Kubernetes：Pod

2020-04-15     sandag

首先當然是 Pod，我相信 Pod 是在接觸 Kubernetes 時聽到較多的一個詞語，Pod 到底是什麼？和容器之間有怎樣的關係？本文將繼續通過對 .NET Core 服務的部署來了解更多關於 Pod 的知識。

為什麼需要 Pod

Pod 從表現上來看更像一台虛擬機，容器則是運行在這台虛擬機中的一個個程序進程，如下圖（ Infra 容器是 Pod 實現中使用的一個中間容器 ）：

在現實的容器調度中，會存在容器間的強依賴情況，也就是多個容器需要運行在同一台機器上，這時如果從容器層面來調度，當機器資源只能滿足部分容器被編排時，這時候就傻逼了，要麼容器運行不正常，要麼通過其他手段使容器重新被正確編排。所以面對這樣的場景，以容器為單位來編排就可能存在問題，所以在 Kubernetes 中提出了 Pod 的概念，Pod 是一組容器的集合，以 Pod 為單位（ 如 CPU、內存等資源定義 ）來編排就顯得更為合理。當然在實際情況下，一個 Pod 下一個容器還是比較常見的使用方式。

創建 Pod

下面依然使用之前製作的 .NET Core API 服務的鏡像 ( beckjin/k8sdemo:1.0.0 ) 在 Kubernetes 中創建 Pod 來演示。

  1. 創建 k8sdemo-pod.yaml 配置文件，定義一個較簡單的 Pod，當然配置欄位遠不止以下這些。另外從 containers 欄位也可以看出 Pod 支持多容器。apiVersion: v1 # 版本號 kind: Pod # Pod 類型 metadata: # Pod meta 信息 name: k8sdemo spec: containers: # 容器欄位 - name: k8sdemo # 容器名稱 image: beckjin/k8sdemo:1.0.0 # 鏡像 ports: - containerPort: 80 # 容器暴露的埠 imagePullPolicy: IfNotPresent # 如果鏡像不存在則拉取
  2. 創建 Pod， kubectl apply -f k8sdemo-pod.yaml
  3. 查看 Pod 狀態， kubectl get pods ，Running 代表啟動已成功

Pod 外部訪問

Pod 啟動後默認是無法直接訪問的，有以下幾種方式可以設置支持外部訪問，這裡暫介紹前兩種方式，其他的涉及 Kubernetes 中更多的模塊內容，後面會逐步涉及。

  1. hostNetwork
  2. hostPort
  3. NodePort
  4. LoadBalancer
  5. Ingress

hostNetwork

在配置文件 spec 欄位下添加 hostNetwork: true ，這種情況下主機上監聽的埠與容器暴露的埠一樣。

spec:
  hostNetwork: true
  containers:
  ...

hostPort

在配置文件 ports 欄位下添加 hostPort: 自定義埠 。

ports:
- containerPort: 80
  hostPort: 8888

以上兩種方式任選一種進行測試即可（ 以下截圖是基於 hostNetwork 方式 ），修改後重啟 Pod kubectl apply --force -f k8sdemo-pod.yaml ，然後通過 kubectl get pods,svc -o wide 查看 Pod 所在的主機IP。

Pod 幾個重要欄位

nodeSelector

nodeSelector 欄位可根據指定的 lable 過濾符合條件的節點，如下給 k8s-node2 這個節點添加了 lable : tag=main

kubectl label nodes k8s-node2 tag=main

配置文件如下調整後，重啟 Pod 就會移到 k8s-node2 節點上運行。

spec:
  containers:
  ...
  nodeSelector:
    tag: main

hostAliases

如果需要給運行在 Pod 增加一些域名的解析（例如宿主機的主機名），但又不想動 DNS 模塊，則可以通過 hostAliases 欄位來配置。

spec:
  containers:
  ...
  hostAliases:
  - ip: "10.10.22.22"
    hostnames:
    - "www.test.com"

lifecycle

lifecycle 欄位可設置在容器狀態發生變化時觸發一些動作。使用方式如下：

spec:
  containers:
  - name: k8sdemo
    ...
    lifecycle:
      postStart:
        exec:
          command: ["echo start"]
      preStop:
        exec:
          command: ["echo stop"]

livenessProbe

livenessProbe 欄位可設置健康檢查需要執行的命令或 HTTP/TCP 請求。以下設置通過發起 HTTP 請求方式，根據 /healthz 接口返回狀態來判斷服務是否正常，目前肯定是失敗，因為接口本身就 404。

spec:
  containers:
  - name: k8sdemo
    ...
    livenessProbe:
      httpGet:
        path: /healthz
        port: 80
      initialDelaySeconds: 15
      periodSeconds: 5
      timeoutSeconds: 1

但由於 Pod 默認自帶恢復機制，也就是 spec.restartPolicy 欄位的默認中是 Always ，所以當健康檢查失敗就會觸發自動恢復機制，這個欄位值還支持 OnFailure (異常時才自動重啟) 和 Never (永不重啟)，實際使用中，需要根據場景設置合理的恢復策略。

但需要注意 Pod 的恢復永遠都發生在當前節點，並不會移到其他節點，這也就意味著如果該 Pod 所在的機器宕機了，這個 Pod 就徹底掛了。至於如何處理這個問題，在後面 Deployment 控制器部分將會介紹。

文章來源: https://twgreatdaily.com/zh-mo/EZDQfXEBnkjnB-0zv7t9.html