本文是《深入剖析k8s》学习笔记的第二篇，主要解析pod的意义及其使用方法。
pod，是k8s中最小的API对象，是原子调度单位。是超亲密关系容器之间组织和部署的单位。类比地说，pod就是虚拟机，其中的容器就是这个虚拟机里面运行的用户进程。
pod中的所有容器共享network、volume、IP地址，在pod启动的时候，需要先启动一个Infra中间容器，而其它容器都是通过join的方式加入到Infra容器的资源中的。Infra容器是一个用汇编语言编写的，永远处于暂停状态的容器，其唯一的作用就是hold住资源，和pod同生命周期。
initcontainers是一种容器类型，相较于containers类型，前者总是先于后者启动，initcontainers如果有多个，则会按照定义的顺序先后启动，只有当所有的initcontainers都启动成功且退出了，containers用户容器才会启动。
sidecar，是一种容器设计模式，指的是我们可以在一个pod中，启动一个辅助容器来完成一些独立于主容器之外的工作。比如initcontainers容器、Infra容器，都属于sidecar。
在进行上云工作的时候，我们可以把虚拟机类同为一个pod，把里面的进程类同为容器镜像，把有顺序关系的容器，定义为initcontainers。如此才是合理的、松耦合的容器编排诀窍，也是传统应用架构演变到微服务架构最自然的过渡方式。
pod有如下几个重要的属性需要掌握。
-
nodeSelector，是一个供用户将pod和node进行绑定的字段。
apiVersion: v1 kind: Pod ... spec: # 该pod只能被调度到含有"disktye: ssd"标签的节点上，否则就调度失败 nodeSelector: disktye: ssd -
hostAliases，定义了pod中的hosts文件。
apiVersion: v1 kind: Pod ... spec: # /etc/hosts文件的内容将增加如下内容： # 10.1.2.3 foo.remote # bar.remote foo.remote # 这是k8s中唯一设置pod中hosts文件内容的方式 hostAliases: - ip: "10.1.2.3" hostnames: - "foo.remote" - "bar.remote" -
shareProcessNamespace，表示pod中的各个容器共享pid namespace。
apiVersion: v1 kind: Pod ... spec: # pod中的nginx容器和shell容器共享进程空间，可以相互看到pod中所有的进程信息 shareProcessNamespace: true containers: - name: nginx image: nginx - name: shell image: busybox stdin: true tty: true -
hostNetwork、hostIPC、hostPID，表示pod中的各个容器共享宿主机的网络、IPC和进程空间资源。
apiVersion: v1 kind: Pod ... spec: # pod中的nginx容器和shell容器共享宿主机的网络 hostNetwork: true # pod中的nginx容器和shell容器可以直接和宿主机进行IPC通信 hostIPC: true # pod中的nginx容器和shell容器共享宿主机的进程空间，可以看到宿主机里面运行的所有进程信息 hostPID: true containers: - name: nginx image: nginx - name: shell image: busybox stdin: true tty: true -
volumes，表示容器需要挂载的数据卷。常用的类型有：
- emptyDir，临时空目录，会在宿主机中特定位置建立匿名目录供pod中的多个容器挂载，从而实现数据共享；
- hostPath，指定宿主机中的具名挂载路径；
-
containers、initContainers，表示容器的类型。其中initContainers是初始化容器，总是先于用户容器containers运行，并且会按照定义的顺序同步执行。
apiVersion: v1 kind: Pod ... spec: # 初始化容器，仅执行cp命令，执行完成就结束，目的是将war拷贝到tomcat的默认目录下 initContainers: - image: zhangxun/sample:v2 name: war command: ["cp", "/sample.war", "/app"] # 挂载到当前容器的/app目录 volumeMounts: - mountPath: /app name: app-volume # 用户容器，等待初始化容器执行完毕后才启动，运行默认目录下的war对外提供服务 containers: - image: zhangxun/tomcat:7.0 name: tomcat command: ["sh","-c","/root/apache-tomcat-7.0.42-v2/bin/start.sh"] # 挂载到当前容器的/root/apache-tomcat-7.0.42-v2/webapps目录 volumeMounts: - mountPath: /root/apache-tomcat-7.0.42-v2/webapps name: app-volume ports: - containerPort: 8080 hostPort: 8001 # 该pod挂载的数据卷，类型是宿主机中的匿名存储路径 volumes: - name: app-volume emptyDir: {}在containers属性下面，又有如下几个需要重点关注的属性：
- image，使用的镜像；
- command，启动命令；
- workingDir，工作目录；
- ports，暴露的容器端口及绑定的宿主机端口；
- volumeMounts，挂载数据卷的信息；
- imagePullPolicy，镜像拉取策略，通常由always、ifNotPresent、never三个级别；
- lifeCycle，生命周期钩子，在容器状态发生改变的时候可以设置触发一些钩子事件；
- postStart，容器启动后立即执行指定操作，虽然在ENTRYPOINT之后执行，但不能保证ENTRYPOINT已经执行完毕；
- preStop，容器被终结之前执行指定操作，容器的终结会因为这个命令被打断，只有当其执行完毕，容器终结才会继续执行；
pod有如下几个状态需要掌握：
- pending，pod创建请求已经提交，但是pod中的某些容器因为某种原因不能被顺利创建；
- running，pod已经成功调度到某个节点，并且其中的容器都已经创建成功，且至少有一个正在运行中；
- succeeded，pod里面的所有容器都正常运行完毕，并且已经退出了，在运行一次性任务时比较常见；
- failed，pod里面至少有一个容器以非正常的状态退出；
- unknown，pod的状态不能被持续地汇报给kube-apiserver，可能是主从节点通信出现了问题；
有几种特殊的volume，它们并不是为了存放容器中的数据，也不是为了进行容器之间或者和宿主机之间进行数据共享，而是为了给容器提供预先定义好的数据。这种数据卷被称为”投射数据卷“，projected volume。
- secret，存放需要加密的数据；
- configmap，存放不需要加密的，但是应用需要的配置信息；
- downward api，让pod里面的容器直接获取到这个api对象的信息；
- service account，让pod里面可以调用k8s的API来控制集群；
pod可以为其中的容器配置探针（probe），用以监控容器的健康检查，而不是以容器镜像是否运行来作为健康检查的依据，因为会存在很多情况，容器是正常运行的，但是无法对外提供服务了，因此探针的健康检查方式更加准确。k8s一旦检测到容器探针发生异常，就会根据设置好的pod恢复机制进行操作，恢复机制restartPolicy有如下几种：
- always，任何时候容器不在运行状态，就进行重新创建；
- onFailure，只在容器异常时才进行重新创建；
- never，从来不重启容器；
默认情况下pod的恢复机制是always，但并不是所有场景下都是合适的，比如initContainers初始化容器执行任务之后就结束了，就不应该设置为always。
如下文档提供了全量的yaml属性，特别是关于PodSpec的属性可以在3050行看到：api/types.go at master · kubernetes/api · GitHub
