.NET Core + Kubernetes：Pod 技术頭條網

2020-04-15 10:42:07 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 來演示。

創建 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 # 如果鏡像不存在則拉取
創建 Pod， kubectl apply -f k8sdemo-pod.yaml
查看 Pod 狀態， kubectl get pods ，Running 代表啟動已成功

Pod 外部訪問

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

hostNetwork
hostPort
NodePort
LoadBalancer
Ingress

hostNetwork

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

<code>spec:
  hostNetwork: true
  containers:
  ...
/<code>

hostPort

在配置文件 ports 字段下添加 hostPort: 自定義端口。

<code>ports:
- containerPort: 80
  hostPort: 8888
/<code>

以上兩種方式任選一種進行測試即可（以下截圖是基於 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

<code>kubectl label nodes k8s-node2 tag=main
/<code>

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

<code>spec:
  containers:
  ... 

  nodeSelector:
    tag: main
/<code>

hostAliases

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

<code>spec:
  containers:
  ...
  hostAliases:
  - ip: "10.10.22.22"
    hostnames:
    - "www.test.com"
/<code>

lifecycle

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

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

livenessProbe

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

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

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