1 为什么要有pod?

Pod 这个词原意是“豌豆荚”，后来又延伸出“舱室”“太空舱”等含义，你可以看一下这张图片，形象地来说 Pod 就是包含了很多组件、成员的一种结构。

容器技术我想你现在已经比较熟悉了，它让进程在一个“沙盒”环境里运行，具有良好的隔离性，对应用是一个非常好的封装。

不过，当容器技术进入到现实的生产环境中时，这种隔离性就带来了一些麻烦。因为很少有应用是完全独立运行的，经常需要几个进程互相协作才能完成任务，比如在“入门篇”里我们搭建 WordPress 网站的时候，就需要 Nginx、WordPress、MariaDB 三个容器一起工作。

WordPress 例子里的这三个应用之间的关系还是比较松散的，它们可以分别调度，运行在不同的机器上也能够以 IP 地址通信。

但还有一些特殊情况，多个应用结合得非常紧密以至于无法把它们拆开。比如，有的应用运行前需要其他应用帮它初始化一些配置，还有就是日志代理，它必须读取另一个应用存储在本地磁盘的文件再转发出去。这些应用如果被强制分离成两个容器，切断联系，就无法正常工作了。

那么把这些应用都放在一个容器里运行可不可以呢？

当然可以，但这并不是一种好的做法。因为容器的理念是对应用的独立封装，它里面就应该是一个进程、一个应用，如果里面有多个应用，不仅违背了容器的初衷，也会让容器更难以管理。

为了解决这样多应用联合运行的问题，同时还要不破坏容器的隔离，就需要在容器外面再建立一个“收纳舱”，让多个容器既保持相对独立，又能够小范围共享网络、存储等资源，而且永远是“绑在一起”的状态。

所以，Pod 的概念也就呼之欲出了，容器正是“豆荚”里那些小小的“豌豆”，你可以在 Pod 的 YAML 里看到，“spec.containers”字段其实是一个数组，里面允许定义多个容器。

如果再拿之前讲过的“小板房”来比喻的话，Pod 就是由客厅、卧室、厨房等预制房间拼装成的一个齐全的生活环境，不仅同样具备易于拆装易于搬迁的优点，而且要比单独的“一居室”功能强大得多，能够让进程“住”得更舒服

2. 为什么Pod 是 Kubernetes 的核心对象？

因为 Pod 是对容器的“打包”，里面的容器是一个整体，总是能够一起调度、一起运行，绝不会出现分离的情况，而且 Pod 属于 Kubernetes，可以在不触碰下层容器的情况下任意定制修改。所以有了 Pod 这个抽象概念，Kubernetes 在集群级别上管理应用就会“得心应手”了。

Kubernetes 让 Pod 去编排处理容器，然后把 Pod 作为应用调度部署的最小单位，Pod 也因此成为了 Kubernetes 世界里的“原子”（当然这个“原子”内部是有结构的，不是铁板一块），基于 Pod 就可以构建出更多更复杂的业务形态了。

下面的这张图你也许在其他资料里见过，它从 Pod 开始，扩展出了 Kubernetes 里的一些重要 API 对象，比如配置信息 ConfigMap、离线作业 Job、多实例部署 Deployment 等等，它们都分别对应到现实中的各种实际运维需求。

从这两张图中你也应该能够看出来，所有的 Kubernetes 资源都直接或者间接地依附在 Pod 之上，所有的 Kubernetes 功能都必须通过 Pod 来实现，所以 Pod 理所当然地成为了 Kubernetes 的核心对象。

3. 如何用YAML描述Pod?

既然 Pod 这么重要，那么我们就很有必要来详细了解一下 Pod，理解了 Pod 概念，我们的 Kubernetes 学习之旅就成功了一半。

还记得吧，我们始终可以用命令 kubectl explain 来查看任意字段的详细说明，所以接下来我就只简要说说写 YAML 时 Pod 里的一些常用字段。

3.1 Pod的基本组成部分

因为 Pod 也是 API 对象，所以它也必然具有 apiVersion、kind、metadata、spec 这四个基本组成部分。

• “apiVersion”和“kind”
  这两个字段很简单，对于 Pod 来说分别是固定的值 v1 和 Pod。

• “metadata”
  一般来说，里应该有 name 和 labels 这两个字段。
  < 我们在使用 Docker 创建容器的时候，可以不给容器起名字，但在 Kubernetes 里，Pod 必须要有一个名字，这也是 Kubernetes 里所有资源对象的一个约定。在课程里，我通常会为 Pod 名字统一加上 pod 后缀，这样可以和其他类型的资源区分开。>

  • name 只是一个基本的标识，信息有限。
  • labels 字段就派上了用处。它可以添加任意数量的 Key-Value，给 Pod“贴”上归类的标签，结合 name 就更方便识别和管理了。
    比如说，我们可以根据运行环境，使用标签 env=dev/test/prod，或者根据所在的数据中心，使用标签 region: north/south，还可以根据应用在系统中的层次，使用 tier=front/middle/back ……如此种种，只需要发挥你的想象力。

    apiVersion: v1
    kind: Pod
    metadata:
    name: busy-pod
     labels:
       owner: chrono
       env: demo
       region: north
       tier: back
    		
    

• spec
  “spec”字段由于需要管理、维护 Pod 这个 Kubernetes 的基本调度单元，里面有非常多的关键信息，今天我介绍最重要的“containers”，其他的 hostname、restartPolicy 等字段你可以课后自己查阅文档学习。

3.1.1 最重要的 spec.containers 字段使用

“containers”是一个数组，里面的每一个元素又是一个 container 对象，也就是容器。

和 Pod 一样，container 对象也必须要有一个 name 表示名字，然后当然还要有一个 image 字段来说明它使用的镜像，这两个字段是必须要有的，否则 Kubernetes 会报告数据验证错误。

container 对象的其他字段基本上都可以和“入门篇”学过的 Docker、容器技术对应，理解起来难度不大，我就随便列举几个：

• ports：列出容器对外暴露的端口，和 Docker 的 -p 参数有点像。
• imagePullPolicy：指定镜像的拉取策略，可以是 Always/Never/IfNotPresent，一般默认是 IfNotPresent，也就是说只有本地不存在才会远程拉取镜像，可以减少网络消耗。
• env：定义 Pod 的环境变量，和 Dockerfile 里的 ENV 指令有点类似，但它是运行时指定的，更加灵活可配置。
• command：定义容器启动时要执行的命令，相当于 Dockerfile 里的 ENTRYPOINT 指令。
• args：它是 command 运行时的参数，相当于 Dockerfile 里的 CMD 指令，这两个命令和 Docker 的含义不同，要特别注意。

举个栗子：
Pod 指定使用镜像 busybox:latest，拉取策略是 IfNotPresent ，然后定义了 os 和 debug 两个环境变量，启动命令是 /bin/echo，参数里输出刚才定义的环境变量。

把这份 YAML 文件和 Docker 命令对比一下，你就可以看出，YAML 在 spec.containers 字段里用“声明式”把容器的运行状态描述得非常清晰准确，要比 docker run 那长长的命令行要整洁的多，对人、对机器都非常友好。

spec:
  containers:
  - image: busybox:latest
    name: busy
    imagePullPolicy: IfNotPresent
    env:
      - name: os
        value: "ubuntu"
      - name: debug
        value: "on"
    command:
      - /bin/echo
    args:
      - "$(os), $(debug)"

3.1.1.1为什么要定义容器启动时要执行的命令？

官方链接：为容器设置启动时要执行的命令和参数
为什么要定义容器启动时要执行的命令？不设置会怎么样？

4. 如何使用kubectl 操作Pod?

有了描述 Pod 的 YAML 文件，现在我就介绍一下用来操作 Pod 的 kubectl 命令。
它们可以使用 -f 参数指定 YAML 文件创建或者删除 Pod，例如：

4.1 创建pod

kubectl apply -f busy-pod.yml

4.2 删除pod

kubectl delete -f busy-pod.yml

因为我们在 YAML 里定义了“name”字段，所以也可以在删除的时候直接指定名字来删除：

kubectl delete pod busy-pod

4.3 输出pod 日志

和 Docker 不一样，Kubernetes 的 Pod 不会在前台运行，只能在后台（相当于默认使用了参数 -d），所以输出信息不能直接看到。我们可以用命令 kubectl logs，它会把 Pod 的标准输出流信息展示给我们看，在这里就会显示出预设的两个环境变量的值：

kubectl logs busy-pod

4.4 获取pod 列表和运行状态

kubectl get pod

4.5 调试排错pod

kubectl describe pod busy-pod
kubectl logs busy-pod

通常需要关注的是末尾的“Events”部分，它显示的是 Pod 运行过程中的一些关键节点事件。对于这个 busy-pod，因为它只执行了一条 echo 命令就退出了，而 Kubernetes 默认会重启 Pod，所以就会进入一个反复停止 - 启动的循环错误状态

因为 Kubernetes 里运行的应用大部分都是不会主动退出的服务，所以我们可以把这个 busy-pod 删掉，用上次课里创建的 ngx-pod.yml，启动一个 Nginx 服务，这才是大多数 Pod 的工作方式。

kubectl apply -f ngx-pod.yml启动之后，我们再用 kubectl get pod 来查看状态，就会发现它已经是“Running”状态了：

4.6 kubectl 拷贝命令

kubectl 也提供与 docker 类似的 cp 和 exec 命令，kubectl cp 可以把本地文件拷贝进 Pod，kubectl exec 是进入 Pod 内部执行 Shell 命令，用法也差不多。

比如我有一个“a.txt”文件，那么就可以使用 kubectl cp 拷贝进 Pod 的“/tmp”目录里：

echo 'aaa' > a.txt
kubectl cp a.txt ngx-pod:/tmp

4.7 kubectl 进入pod

不过 kubectl exec 的命令格式与 Docker 有一点小差异，需要在 Pod 后面加上 --，把 kubectl 的命令与 Shell 命令分隔开，你在用的时候需要小心一些：

kubectl exec -it ngx-pod -- sh

5. Pod小结

1. 现实中经常会有多个进程密切协作才能完成任务的应用，而仅使用容器很难描述这种关系，所以就出现了 Pod，它“打包”一个或多个容器，保证里面的进程能够被整体调度。
2. Pod 是 Kubernetes 管理应用的最小单位，其他的所有概念都是从 Pod 衍生出来的。
3. Pod 也应该使用 YAML“声明式”描述，关键字段是“spec.containers”，列出名字、镜像、端口等要素，定义内部的容器运行状态。
4. 操作 Pod 的命令很多与 Docker 类似，如 kubectl run、kubectl cp、kubectl exec 等，但有的命令有些小差异，使用的时候需要注意。

虽然 Pod 是 Kubernetes 的核心概念，非常重要，但事实上在 Kubernetes 里通常并不会直接创建 Pod，因为它只是对容器做了简单的包装，比较脆弱，离复杂的业务需求还有些距离，需要 Job、CronJob、Deployment 等其他对象增添更多的功能才能投入生产使用。

6. 思考

6.1 如果没有 Pod，直接使用容器来管理应用会有什么样的麻烦？

可以把pod 看作是介于容器之上的一层抽象，之所以需要这一层抽象是因为容器与容器之间有着不确定的关系。
有的容器需要彼此隔离，而有的容器却需要彼此交互。当容器规模增大，容器之间的作用关系就会变得及其复杂，难于管理。
pod 的出现就是为了解决容器管理的问题。让大规模应用下的容器编排变得更加清晰有序，易于维护。

6.2 你觉得 Pod 和容器之间有什么区别和联系？

不管是容器还是pod，都是虚拟概念。把普通进程或应用加上权限限制就成了容器，再把容器加上权限限制就成了pod。
说白了，就是不断地抽象封装，这也是软件中解决复杂问题的唯一手段。
容器之于Pod,就好比线程之于进程、函数之于类、文件之于文件夹等等