上一回我们得出了一个结论：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体系中最核心的一个概念，多接触些常用的字段，就不需要常去查阅了。