1. 概念

Pod 是 Kubernetes 项目里定义的最小可调度单元，是 Kubernetes 对应用程序的抽象。
Pod 组成可以是一个或者多个容器，属于同一个 Pod 的容器会共享：

网络资源
相同的 IP
存储
应用到 Pod 的自定义配置

2. Pod 的模型

根据组成 Pod 的容器数量可以将 Pod 分为两种类型：

单容器模型：Pod是Kubernetes可识别的最小对象，Kubernetes管理调度Pod而不是直接管理容器，所以即使只有一个容器也需要封装到Pod里
多容器模型：在这个模型中，Pod可以容纳多个紧密关联的容器以共享Pod里的资源。这些容器作为单一的，凝聚在一起的服务单元工作。比如：在Pod中有一个应用程序容器和一个日志记录容器。日志记录容器的唯一工作是从应用程序容器中提取日志。将两个容器放置同一个Pod里可消除额外的通信时间，因为它们位于同一个"主机"，因此所有内容都是本地的并且它们共享所有资源，就跟在同一台物理服务器上执行这些操作一样。

Pod 本身不具备调节功能，如果 Pod 所在的节点发生故障，Pod 是不能自动调度到其他节点，需要使用控制器来完成 pod 的调度问题。Deployment就是最基础的控制器。通常我们都是在定义的控制器的配置里通过PodTemplate定义要控制的Pod，让控制器和所管控的Pod一起被创建出来。

3. Pod 的生命周期

Pod的生命周期有5个阶段：

Pending：pending 表示当 pod 中至少存在一个容器未创建的情况。
Running：容器已经创建完成，并且Pod已经被调度到了一个Node上。此时Pod内的容器正在运行，或者正在启动或重新启动。
Succeeded：Pod中的所有容器均已成功终止，并且不会重新启动。
Faild：所有容器均已终止，至少有一个容器发生了故障。失败的容器以非零状态退出。
Unknown：无法获得Pod的状态。

4. Pod 的 yaml 文件解析

Kubernetes 里所有的 API 对象都由四部分组成：

apiVersion: 当前使用的 Kubernetes 的 API 版本
kind：想创建的对象的种类
metadata：元数据，用来唯一表示当前的对象，比如 name，namespace 等
spec：Pod 的指定配置，例如镜像名称、容器名称、数据卷等

apiVersion，kind 和 metadata 是必填字段，适用于所有 Kubernetes 对象，而不仅仅是 pod。spec 里指定的内容（spec 也是必需字段）会因对象而异。

Pod 文件示例：

apiVersion: "api version"
kind: "Object to create"
metadata: 
  name: "Pod name"
  labels: 
    app: "label value"
spec:
  containers:
  - name: "container name"
    image: "image to use for container"

5. 示例：

5.1 单容器 Pod

apiVersion: v1 # kubernetes 的 API 版本
kind: Pod # 创建的对象为 Pod
metadata:  # 元数据
  name: first-pod # pod 的名称
  labels: 
    app: myapp
spec: # 指定的配置信息
  containers:
   - name: my-first-pod #容器名
     image: nginx # 指定的镜像

将 Pod 的清单文件部署到本地的 Kubernetes 集群中：

kubectl create -f pod-1.yaml

查看 Pod 的运行情况：

kubectl get pods

执行命令查看容器情况：

kubectl exec first-pod  -- service nginx status

在Pod里执行service nginx status指令，类似docker exec命令。

删除创建的 Pod

kubectl delete pod first-pod

5.2 多容器的 Pod

一个拥有两个容器的Pod，这些容器相互协作作为一个实体工作。其中一个容器每10秒将当前日期写入一个文件，而另一个Nginx容器则为我们展示这些日志。

apiVersion: v1
kind: Pod
metadata: 
  name: multi-container-pod
spec:
  volumes:
  - name: shared-data-logs # 为 Pod 中创建一个共享的数据卷
    emptyDir: {}
  containers:
  - name: container-writing-datas # 第一个容器的名称
    image: alpine
    command: ["/bin/sh"]
    args: ["-c", "while true; do date >> /var/log/output.txt; sleep 10; done"] # 每10秒写入当前时间
    volumeMounts:
    - name: shared-data-logs
      mountPath: /var/log
  - name: container-serving-dates # 第二个容器的名字
    image: nginx:1.7.9 # 镜像
    ports:
      - containerPort: 80 # 定义容器提供服务的端口
    volumeMounts:
    - name: shared-data-logs
      mountPath: /usr/share/nginx/html

通过运行如下命令连接到Nginx容器里：

kubectl exec -it multi-container-pod -c container-serving-dates -- bash

在容器内运行curl'http://localhost:80/output.txt'，它应该返回时间日志文件的内容给我们。

5.3 SideCar模式

可以在一个 Pod 中按照顺序启动一个或多个辅助容器，来完成一些独立于主进程（主容器）之外的工作，完成工作后这些辅助容器会依次退出，之后主容器才会启动，这种容器设计模式叫做 sidecar。

比如对于前端Web应用，如果把构建后的Js项目放到Nginx镜像的/usr/share/nginx/html目录下，Nginx和Js应用做成一个镜像运行容器，每次应用有更新或者Nginx要做升级、更新配置操作都需要重新做一个镜像，非常麻烦。

有了Pod之后，这样的问题就很容易解决了。我们可以把前端Web应用和Nginx分别做成镜像，然后把它们作为一个Pod里的两个容器"组合"在一起。这个Pod的配置文件如下所示：

apiVersion: v1
kind: Pod
metadata:
  name: web-2
spec:
  initContainers:
  - image: kevinyan/front-app:v2
    name: front
    command: ["cp", "/www/application/*", "/app"]
    volumeMounts:
    - mountPath: /app
      name: app-volume
  containers:
  - image: nginx:1.7.9
    name: nginx
    ports:
      - containerPort: 80 # 定义容器提供服务的端口
    volumeMounts:
    - mountPath: /usr/share/nginx/html
      name: app-volume
  volumes:
  - name: app-volume
    emptyDir: {}

所有spec.initContainers定义的容器，都会比spec.containers定义的用户容器先启动。并且，Init容器会按顺序逐一启动，直到它们都启动并且退出了，用户容器才会启动。所以，这个Init类型的容器启动后，执行了一句"cp /www/application/* /app"，把应用包拷贝到"/app"目录下，然后退出。这个"/app"目录，挂载了一个名叫app-volume 的Volume。接下来Nginx容器，同样声明了挂载app-volume到自己的"/usr/share/nginx/html"目录下。由于这个Volume 是被Pod里的容器共享的所以等Nginx容器启动时，它的目录下就一定会存在前端项目的文件。这个文件正是上面的Init容器启动时拷贝到Volume里面的。

2.Pod