什么是Pod

  1. Pod是 K8S 中最小的 API 对象。
  2. 换一个更专业的说法：Pod是 K8S 的原子调度单位。是 K8S 能够描述和编排各种复杂应用的基石

为什么需要 Pod

  1. 假设 K8S 集群上有两个节点：node-1 上有 3 GB 可用内存，node-2 有 2.5 GB 可用内存
  3. 如果用 Docker Swarm 来运行这个 rsyslogd 程序：
  4. 为了让这三个容器都运行在同一台机器上，必须在另外两个容器上设置一个 
  5. affinity=main（与 main 容器有亲密性）的约束，即：它们俩必须和 main 容器运行在同一台机器上。
  7. 然后，顺序执行："docker run main""docker run imklog"和"docker run imuxsock"，
  8. 创建这三个容器。
  9. 这样，这三个容器都会进入 Swarm 的待调度队列。
  10. 然后，main 容器和 imklog 容器都先后出队并被调度到了 node-2 上（这个情况是完全有可能的）。
  11. 可是，当 imuxsock 容器出队开始被调度时，
  12. Swarm 就有点懵了：node-2 上的可用资源只有 0.5 GB 了，并不足以运行 imuxsock 容器；
  13. 可是，根据 affinity=main 的约束，imuxsock 容器又只能运行在 node-2 上。
  14. 这就是一个典型的成组调度（gang scheduling）没有被妥善处理的例子。
  16. 各种解决方案
  17. 1. Mesos 中使用资源囤积（resource hoarding）机制
  19.      会在所有设置了 Affinity 约束的任务都达到时，才开始对它们统一进行调度。
  21. 1. Google Omega 则提出了使用乐观调度处理冲突的方法
  23.      即：先不管这些冲突，而是通过精心设计的回滚机制在出现了冲突之后解决问题。
  25. 可是这些方法都谈不上完美：
  26. 资源囤积带来了不可避免的调度效率损失和死锁的可能性
  27. 而乐观调度的复杂程度，则不是常规技术团队所能驾驭的
  29. K8S 项目里，这问题就迎刃而解了：
  30. K8S 项目的调度器，是统一按照 Pod 而非容器的资源需求进行计算的。
  32. 超亲密关系
  33. 像这样容器间的紧密协作，称为"超亲密关系"。
  35. Pod 在 K8S 项目里还有更重要的意义，那就是：容器设计模式。

Pod 的实现原理

  1. Pod 只是一个逻辑概念
  3. 关于 Pod 最重要的一个事实是：它只是一个逻辑概念
  4. K8S 真正处理的，还是宿主机上 Linux 容器的 Namespace 和 Cgroups，
  5. 并不存在一个所谓的 Pod 的边界或者隔离环境。
  8. Pod 是如何被"创建"出来的
  9. Pod 其实是一组共享了某些资源的容器。
  10. Pod 里的所有容器，共享的是同一个 Network Namespace，并且可以声明共享同一个 Volume。