K8s为何需要Pod

Pod是K8s中的最小API对象，更专业的表述是，Pod是K8s项目的原子调度单位，Pod可以看做是一个进程组，K8s则是操作系统

一， 问题

        现在有三个服务需要部署在同一个节点上，A占用1G内存，B ，C也都占用1 G内存，如果用Docker Swarm来部署，需要在B ， C容器上设置affinity=A 的约束，即他们必须和A在同一台机器上运行，这样这三个容器都会进入Swarm的待调度队列，然后A先调度到了node-1上，但是node1上只有2.5G内存，轮到C时，Swarm懵了，可用资源只有0,5G了，不足以运行C，可以根据亲密性约束，C又必须在node-1上运行，这就是成组调度没有妥善处理

        但是在K8s中，因为Pod是原子调度单位，也就是说，K8s会按照pod而非容器的资源需求进行计算，那么一开始就不会考虑资源不够的节点进行调度

        

        如果容器A和容器B需要共享网络和Volume资源，如何实现，在docker中可以县启动A，然后将B加入A的网络和volume中，但是这么做的话，A就必须在B之前启动，那么就形成了依赖关系，也就是一个拓扑关系

        但是在K8s中，Pod使用一个中间容器，infra容器，这是一个用汇编语言写的，并且很小的，一启动就会永远处于暂停状态的容器，而且infra容器永远是第一个被创建的。对于同一个Pod中的所用用户容器来说，他们的进出流量也可以认为都是通过infra容器完成的，