PaaS网络模型选型的三个硬性需求，及主流方案各自的共性痛点

用Docker构建PaaS平台时，网络模型的选型必须同时满足三个硬性需求：每个容器要有自己独立的网络栈和IP地址；容器间要能跨服务器通信，且不依赖特定的网络硬件设备；要有访问控制机制，能让不同应用之间彼此隔离，同时允许确实存在调用关系的应用互相通信。围绕这三个需求评估当时的主流方案，会发现每一种都在某个维度上有明显短板：Docker原生的Bridge模型基于NAT机制，导致没办法直接用容器自己的IP做跨服务器通信（虽然后来发现自定义网桥能绕开这个限制，但方案本身变得比较复杂）；Docker原生的Host模型让所有容器直接共用宿主机的IP，端口冲突问题会变得很麻烦，多个容器如果都想用同一个端口就没法共存；基于隧道技术的方案（如Weave、OVS）需要在用户态做封包解包，这个额外的处理层带来了明显的性能折损，而且一旦出问题，做网络抓包调试会因为多了一层隧道封装而变得相当麻烦。这个评估过程揭示了容器网络方案选型的一条共性规律：几乎所有试图”绕过”物理网络原生能力、靠额外软件层（NAT转换、隧道封装）去实现跨主机通信的方案，都会在性能或调试复杂度上付出代价——这也是为什么团队最终转向寻找一个能直接利用三层路由能力、不需要额外封包解包层的方案（Calico），选型时清楚列出每个候选方案在核心需求维度上具体的短板，比笼统地说”这个方案不好用”更有说服力，也更容易发现候选方案里被忽视的新选项。