容器的本质是进程.

image.png

image.png

成组调度 (gang scheduling):

  • Mesos, 资源囤积 (resource hoarding): 等所有设置了 Affinity 约束的任务都到达时才统一调度
  • Omega, 乐观调度: 先不管冲突, 当冲突发生时回滚

可是这些方法都谈不上完美。资源囤积带来了不可避免的调度效率损失和死锁的可能性;而乐观调度的复杂程度,也不是常规技术团队所能驾驭的。

  • 在Kubemetes项目中’这样的问题就迎刃而解了: Pod是Kubemetes里的原子调度单位°这就意昧着Kubemetcs项目的调度器是统＿按照Pod而非容器的资源需求进行计算的°

可以把容器间的这种紧密协作称为‘超亲密关系｀,°这些具有‘超亲密关系”的容器的典型特征包括但不限于:

  • 互相之间会发生直接的文件交换
  • 使用localhost或者Sockct文件进行本地通信
  • 会发生非常频繁的远程调用
  • 需要共享某些LinuxNamespace（比如—个容器要加人另—个容器的NetworkNamespace）’等等。

Pod在Kubemetes项目里还有更重要的意义:

  • 容器设计模式

Pod 本质

关于Pod最重要的一个事实是:

  • 它只是一个逻辑概念°也就是说,Kubemetes真正处理的’还是宿主机操作系统上Llnux容器的Namespace和Cgroups’并不存在所谓的Pod的边界或者隔离环境°
  • Pod其实是—组共享了某些资源的容器

image.png

image.png

image.png

理解 Pod 的方式: 尽量尝试使用它来描述一些用单个容器难以解决的问题.

1. WAR 包与 Web 服务器

不应该将 war 与 web 服务器打包成一个容器.


容器设计模式:

  • sidecar: 在一个Pod中启动—个辅助容器’来完成一些独立于主进程（主容器）的工作。
  • initContainers

image.png

2. 容器的日志收集

Istio 微服务治理项目:

  • 使用sldecar容器完成微服务治理

容器设计模式论文: