Pod的原子性调度用最小调度粒度规避了协同调度的复杂性

[[Pod是容器编排中进程组概念的对应物用来实现超亲密协作]]解决了单机内多 容器共享名称空间的问题，但集群环境下容器可能被跨机器调度——一旦两台机器 物理隔离、只靠网络连接，名称空间共享、cgroups配额共享就都失去意义了。 如果坚持以容器为最小调度单位，两个互相依赖的容器（如Filebeat必须和它 采集的Nginx跑在同一节点）就有可能被分别调度到不同节点，这正是传统多 线程/多进程并发调度中”协同调度”（Coscheduling）要解决的老问题——如果 两个强依赖的任务只分配资源给其中一个、另一个被挂起，整个工作就无法 进行。协同调度实现起来要么低效（如Apache Mesos的Resource Hoarding 策略，必须等所有需调度任务都齐备才开始分配资源），要么复杂（如Google 为Borg下一代Omega系统设计的乐观并发+冲突回滚机制）。Kubernetes的解法 是把资源需求声明定义在Pod而非容器上，直接以Pod为最小的原子调度单位—— 由于多个Pod之间必定不存在超亲密关系、只会通过网络非亲密协作，也就 不存在”必须绑在一起调度”的说法，协同调度的复杂性因此被从根源上消解。 这个设计再次印证了Pod在Kubernetes体系里的双重职责：既是[[Pod是容器编排 中进程组概念的对应物用来实现超亲密协作]]里的容器组角色，又是资源调度 的最小原子单位。