在 .NET Core + Kubernetes：快速體驗 文章中，已經實現將一個 .NET Core API 服務部署在 Kubernetes 集群中，接下來將逐步了解 Kubernetes 中各核心模塊。首先當然是 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 # 資源類型 metadata: # 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，這種情況下主機上監聽的端口與容器暴露的端口一樣。

spec:hostNetwork: truecontainers:...

hostPort

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

ports: - containerPort: 80hostPort: 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: /healthzport: 80initialDelaySeconds: 15periodSeconds: 5timeoutSeconds: 1

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

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

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的.NET Core + Kubernetes：Pod的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。