1.我们为什么需要pod？
1.1. 解决具有超亲密关系容器之间的成组调度问题：比如在存在A、B、C三个容器，这三个容器之间基于socket和文件交换进行通信，在docker swarm中，可以在这三个容器之间设置affinity约束来要求这三个容器必须调度
到同一个节点，但是往往就存在容器A和B调度在某个节点，而这个节点剩余的资源却又不足与调度容器C的情况。Mesos中有一个资源囤积（resource hoarding）的机制，会在所有设置了 Affinity 约束的任务都达到时，才开始对它们统一进行调度，但是调度效率
难免降低。在 Google Omega 论文中，则提出了使用乐观调度处理冲突的方法，即：先不管这些冲突，而是通过精心设计的回滚机制在出现了冲突之后解决问题，而这种复杂的机制却难于掌握。pod作为Kubernetes里的原子调度单位，统一按照Pod而非容器的资源需求计算来执行调度。
1.2. 支持容器设计模式：pod作为一个逻辑概念，通过一个中间容器pause，让业务容器通过join namespace的方式加入到pause中的namespace。比如多个业务容器之间由于都加入到了Network Namespace中，所以他们可以使用localhost进行通信，如果需要为kubernetes
开发一个网络插件，也只需要关心如何配置pause容器的Network Namespace，而不是各个业务容器如何使用你的网络配置。（如果你的网络插件需要在容器里安装某些包或者配置才能完成的话，是不可取的：Infra 容器镜像的 rootfs 里几乎什么都没有，没有你随意发挥的空间。当然，这同时也意味着你的网络插件完全不必关心用户容器的启动与否，而只需要关注如何配置 Pod，也就是 Infra 容器的 Network Namespace 即可)
通过init container来做一些初始化工作，典型的例子是利用pod中容器共享volume信息，通过init container将war包放入volume中，tomcat容器则从volume中取出war包进行发布。
pod中运行两个容器分别是sidecar容器和业务容器，业务容器将业务日志输出到volume中，sidecar容器中部署日志收集器不断收集日志发到es中。
2.我们知道Deployment控制下的运行中的pod的个数尽量被维持在其Replicas字段定义的个数，那么Deployment中的PodTemplate中的restartPolicy字段的值可以是Never吗？
不行，Deployment控制下的pod的restartPolicy字段只能是Always。因为只有容器能保证自己始终是Running的情况下，Deployment控制下的ReplicaSet对pod的个数的调整才有意义。
同理的是Job的restartPolicy只能是Never。
3.推荐单个容器中只运行一个进程（单进程模型），但是我们经常会通过exec等方式进入容器（的namespace）中执行一些其他进程如tail -f命令，tail进程将作为容器中1号进程的子进程，当1号进程异常退出后，如何
确保tail进程不会变成僵尸进程？
containerd-shim 作为容器进程的父进程, 负责收集容器进程的状态, 上报给 containerd, 并在容器中 pid 为 1 的进程退出后接管容器中的子进程进行清理, 确保不会出现僵尸进程
4.不管是docker还是k8s中网桥类型的cni插件，在同一主机内的容器间通信时都会在宿主机创建网桥设备，并把容器内的eth0和宿主机的veth@xxx组成的veth peer中的veth@xxx一端插在网桥上，这一过程具体用命令实现时怎样的？
4.1 在宿主机创建bridge设备并启动： ip link add cni0 type bridge && ip link set cni0 up
4.2 进入容器net ns中创建veth网卡对并启动eth0：ip link add eth0 type veth peer name veth@xxx && ip link set eth0 up
4.3 将容器中创建的veth网卡对的veth@xxx一端移到宿主机net ns并在宿主机上启动：ip link set veth@xxx netns {HOST_NET_NS} && ip netns exec {HOST_NS} ip link set veth@xxx up
4.4 将宿主机的veth@xxx网卡插在cni0上：ip link set veth@xxx master cni0
4.5 为容器中的eth0网卡配置ip和默认路由：ip addr add 10.244.0.2/24 dev eth0 && ip route add default via 10.244.0.1 dev eth0
5. 在4中描述了容器eth0与宿主机veth@xxx组成的veth peer的创建过程，veth@xxx被插在bridge后，还会为它开启hairpin（发夹）模式，作用时什么?
首先，插在bridge上的veth@xxx设备作为从设备，将失去处理数据包的资格，仅作为bridge上的一个数据流入流出的接口，但是bridge默认是不允许一个数据包从一个端口进来后，再从这个端口发出去的，开启发夹模式就可以取消这个限制。
比如在docker run时可以通过-p 8080:80指定访问宿主机的8080端口映射到容器的80端口，这样就可以通过宿主机的ip加8080端口来访问容器，而这是通过添加iptables来实现DNAT的，即访问nodeIp:8080最终被DNAT成containerIp:80，而如果是在容器内
发出的这个访问请求，那么就会是上面说的包将从veth@xxx流到宿主机，DNAT并查完路由表又想从veth@xxx流回到容器中。
