pod是k8s项目中的最小编排单位。将这个设计落实API对象上，container就成了pod属性里的一个普通的字段。那么，到底哪些属性属于pod对象，哪些属于container的？

上一回我们得出了一个结论：pod扮演的是传统部署环境里“虚拟机”的角色。这样的设计，是为了使用户从传统环境（虚拟机）向k8s环境（容器）的迁移更方便。

如果我们能把pod看成传统环境里的“机器”，把容器看做是运行在这个“机器”里的“用户程序”，理解pod就非常容易了。

比如，调度、网络、存储，以及安全相关的属性，基本上是pod级别的

这些属性的共同特征是，它们描述的是“机器”这个整体，而不是里面运行的“程序”。比如，配置网卡（pod的网络定义），配置磁盘（pod的存储定义），配置防火墙（pod的安全定义）。更不用说，运行在哪个服务器上（pod的调度）。

接下来，先了解pod中几个重要字段的含义和用法。

NodeSelector：是一个供用户将pod与node进行绑定的字段

apiVersion: v1
kind: Pod
...
spec:
 nodeSelector:
   disktype: ssd

这样的配置，意味着这个pod永远只能运行在携带了“disktype:ssd”标签（label）的节点上；否则，它将会调度失败。

NodeName：一旦pod的这个字段被赋值，k8s项目将会被认为这个pod已经经过了调度，调度的结果就是赋值的节点名字。所以，这个字段一般由调度器负责设置，但用户也可以设置它来“骗过”调度器，当然这个做法一般是在测试或者调试的时候才会用到。

HostAliases:定义了pod的hosts文件（比如/etc/hosts）里的内容

apiVersion: v1
kind: Pod
...
spec:
  hostAliases:
  - ip: "10.1.2.3"
    hostnames:
    - "foo.remote"
    - "bar.remote"
...

在这个pod的yaml文件中，我设置了一组IP和hostname的数据。这样，这个pod启动后，/etc/hosts文件的内容将如下显示：

cat /etc/hosts
# Kubernetes-managed hosts file.
127.0.0.1 localhost
...
10.244.135.10 hostaliases-pod
10.1.2.3 foo.remote
10.1.2.3 bar.remote

其中，最下面两行记录，就是我通过HostAliases字段为pod设置的。需要指出的是，在k8s项目中，如果要设置hosts文件里的内容，一定要通过这种方法。否则，如果直接修改了hosts文件的话，在pod被删除重建之后，kubelet会自动覆盖掉被修改的内容。

除了上述相关配置，凡是跟容器的linux  namespace相关的属性，也一定是pod级别的。pod的设计，就是要让它里面的容器尽可能多地共享linux namespace，仅保留必要的隔离和限制能力。这样，pod模拟出的效果，就跟虚拟机里程序间的关系非常类似了。

例子：在下面这个pod的yaml文件中，我定义了shareProcessNamespace=true:

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  shareProcessNamespace: true
  containers:
  - name: nginx
    image: nginx
  - name: shell
    image: busybox
    stdin: true
    tty: true

这就意味着这个pod里的容器要共享PID Namespace。

在这个yaml文件中，我还定义了两个容器：一个是nginx容器，一个是开启了tty和stdin的shell容器。

tty和stdin在yaml文件里面声明开启他们俩，其实等同于设置了docker run 里的 -it (-i:stdin;-t:tty)

这个pod被创建后，你就可以使用shell容器的tty跟这个容器进行交互了。

$ kubectl create -f nginx.yaml

接下来，我们使用kubectl attach命令，连接到shell容器的tty上：

$ kubectl attach -it nginx -c shell

这样，我们就可以在shell容器里执行ps指令，查看所有正在运行的进程：

$ kubectl attach -it nginx -c shell
/ # ps ax
PID   USER     TIME  COMMAND
    1 root      0:00 /pause
    8 root      0:00 nginx: master process nginx -g daemon off;
   14 101       0:00 nginx: worker process
   15 root      0:00 sh
   21 root      0:00 ps ax

可以看到，在这个容器里，我们不仅可以看到它本身的ps ax指令，还可以看到nginx容器的进程，以及Infra容器里/pause进程。这就意味着，整个pod里的每个容器的进程，对于所有容器来说都是可见的：他们共享了同一个PID Namespace。

凡是pod中的容器要共享宿主机的Namespace，也一定是pod级别的定义：

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  hostNetwork: true
  hostIPC: true
  hostPID: true
  containers:
  - name: nginx
    image: nginx
  - name: shell
    image: busybox
    stdin: true
    tty: true

在这个pod中，我定义了共享宿主机的network，ipc和pid namespace。这就意味着，这个pod里的所有容器，会直接使用宿主机的网络、直接与宿主机进行ipc通信，看到宿主机里正在运行的所有进程。

pod里最重要的字段“container”，之前，我们还接触过 “Init Containers”。其实，这两个字段都属于pod对容器的定义，内容也完全相同，只是Init Container的生命周期，会先于所有的containers，并且严格按照定义的顺序执行。

k8s项目中对container的定义，和docker差不多。image、command、wordingDir、Ports、volumeMounts都是构成k8s项目中container的主要字段。

首先，是ImagePullPolicy字段。它定义了镜像拉取的策略。而它之所以是一个container级别的属性，是因为容器镜像本来就是container定义中的一部分。

ImagePullPolicy的值默认是Always，即每次创建pod都重新拉取一次镜像。另外，当容器的镜像是类似于nginx或者nginx:latest这样的名字时，ImagePullPolicy也会被认为Always。

而如果它的值被定义为Never或者IfNotPresent，则意味着pod永远不会主动拉取这个镜像，或者只在宿主机上不存在这个镜像时才拉取。

其次，是Lifecycle字段。它定义的是Container Lifecycle Hooks。是在容器状态发生变化时触发一系列“钩子”。

apiVersion: v1
kind: Pod
metadata:
  name: lifecycle-demo
spec:
  containers:
  - name: lifecycle-demo-container
    image: nginx
    lifecycle:
      postStart:
        exec:
          command: ["/bin/sh", "-c", "echo Hello from the postStart handler > /usr/share/message"]
      preStop:
        exec:
          command: ["/usr/sbin/nginx","-s","quit"]

这是一个来自k8s官方文档pod的yaml文件。它其实非常简单，只是定义了一个nginx镜像的容器。不过，在这个yaml文件的容器部分，你会看到这个容器分别设置了一个postStart和preStop参数。

postStart：在容器启动后，立刻执行一个指定的操作。需要说明的是，postStart定义的操作，虽然是在docker容器ENTRYPOINT执行之后，但它并不严格保证顺序。也就是说，在postStart启动时，ENTRYPOINT有可能还没有结束。当然，如果postStart执行超时或者错误，k8s会在该pod的events中报出该容器启动失败的错误信息，导致pod也处于失败的状态。

preStop：容器被杀死之前（比如，收到了SIGKILL信号）。而需要明确的是，preStop操作的执行，是同步的。所以，它会阻塞当前的容器杀死进程，直到这个hook定义操作完成之后，才允许容器被杀死。

上面的例子，我们在容器成功启动之后，在/usr/share/message里写入了依据“欢迎信息”(postStart定义的操作)。而在这个容器被删除之前，我们则先调用了nginx的退出指令（即preStop定义的操作），从而实现了容器的“优雅退出”。

然后，我们了解一下pod对象在k8s中的生命周期

pod生命周期的变化，主要体现在Pod API对象的Status部分，这是它除了Metadata和Spec之外的第三个重要字段。其中，pod.status.phase，就是pod的当前状态，它有如下几种可能的情况：

1. Pending。这个状态意味着，Pod的yaml文件已经提交给了k8s，API对象已经被创建并保存在etcd当中。但是，这个pod里有些容器因为某种原因而不能被顺利创建。比如，调度不成功。

2. Running。这个状态下，Pod已经调度成功，跟一个具体的节点绑定。它包含的容器都已经创建成功，并且至少有一个正在运行中。

3. Succeeded。这个状态意味着，Pod里的所有容器都正常运行完毕，并且已经退出了。这种情况在运行一次性任务时最为常见。

4. Failed。这个状态下，pod里至少有一个容器以不正常的状态（非0的返回码）退出。这个状态，意味着你要想办法debug这个容器的应用，比如查看pod的events和日志。

5. Unknown。这是一个异常状态，意味着pod的状态不能持续地被kubelet汇报给kube-apiserver，这很有可能是主从节点（master和kubelet）间的通信出现了问题。

更进一步地，pod对象的status字段，还可以再细分出一组conditions。这些细分状态的值包括：PodScheduled、Ready、Initialized，以及Unschedulable。只要用于描述造成当前Status的具体原因是什么。

比如，pod当前的status是pending，对应的condition是unschedulable，这就意味着它的调度出现了问题。

而其中，Ready这个细分状态非常值得我们关注：它意味着pod不仅以及正常启动（running），而且已经可以对外提供服务了。这两者之间是有区别的。

总结

Pod API对象是整个k8s体系中最核心的一个概念，多接触些常用的字段，就不需要常去查阅了。