银行的容器网络如何规划？

在金融实践中，我们经常遇到此类话题，这也是每一个金融客户都绕不开的话题。 在演讲中，我也提到了关于平台化思维和条线式思维的矛盾，这个矛盾在银行业是特别突出的。

我提几个比较落地的建议：

1. underlay和overlay一起搞：目前容器网络两个基本技术思路是overlay和underlay，overlay是建设虚拟网络，容器采用虚拟IP；underlay是复用下层物理网络，容器像虚拟机一样使用下层网络。从某种意义上说，overlay是平台化思维的产物，underlay是条线式管理思维的产物。某些银行可以允许大规模overlay，个别场景采用underlay（例如多播、运管功能等），这样两个一起搞，同时兼顾。另外还有些银行目前基本没有overlay的空间，更多采用underlay管理；而还有些银行在虚拟化上建设容器平台，underlay不能用（underlay可能会和iaas网络有冲突），导致只能用overlay。鉴于这些情况，我的建议是两个都上，不同的集群采用不同的方案，甚至通过多网卡同时采用underlay和overlay。即便仅有一种需求，也两种方案都规划到位，保证未来拓展的可能性。
2. 可以参考IaaS的网络建设思维：IaaS典型的网络思维是三网分离、四网分离，容器网络目前规划中，以前不太考虑这种方案，这是因为以前更多是IaaS负责基础设施网络，但是如果一旦在裸金属上部署容器平台，那么IaaS原来遇到的问题，今天容器平台也会遇到。
3. 容器网络与外部网络通信管控：通过统一的接入点（ingress、egress）管控容器内网的网络互访，加强到“稳态”和“敏态”之间的安全交互
4. networkpolicy管理：如果有可能，更多采用networkpolicy为每个应用设置安全管控策略，这也是更“云原生”的一种做法。

最后，容器网络是金融客户非常关注的话题，灵雀云的Kube-OVN网络方案已经开源，应该是目前业界比较活跃的方案，有兴趣可以尝试一下。