在 .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 来演示。

1. 创建 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   # 如果镜像不存在则拉取
   

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: 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 控制器部分将会介绍。