银行容器云建设的网络插件的选择？

1、underlay和overlay是两种网络方案。多数CNI插件两种都支持，能力各有侧重。
underlay特点：实现容器集群内外直通，网络性能高，但会占用内网地址。大规模场景下，需要提前规划好IP资源。
overlay特点：容器集群内使用私网地址，网络性能损耗较高，但不会占用内网地址。没有IP资源限制。
开源的CNI插件有Calico、Flannel、Cilium、kube-ovn等。我了解的到情况，Calico-overlay使用的会比较多些（underlay需要BGP支持，对网络影响比较大）。

2、固定IP地址
金融场景下，基本都会有业务或应用有固定IP地址的需求。一个是技术改造应用的代价问题，另一个是上容器应用需求与现在技术栈的融合对接的问题，都会涉及到固定IP。
如果我没记错， Calico支持固定IP，但不支持固定Mac；Flannel、Cilium好像都不支持固定IP和Mac

3、对于运维的挑战
如果选择的CNI插件网络设计的比较复杂，后期运维排错会非常困难。
一般来讲，最下面是物理网络，然后是虚拟化网络（如果容器部署在虚拟机上），最后是容器网络。多层网络本身就已经造成网络排查困难了，如果容器网络过于复杂，会放大排查难度，对运维人员相当不友好。
结合上面说的underlay、overlay网络方案，个人看法尽量让集群网络简单，如A集群underlay网络、B集群overlay网络，即满足业务多种网络场景需求，又简化网络的复杂性。现阶段不推荐单集群多CNI的方案，太复杂了，排错能搞死人。

  银行容器云建设的网络插件选择，和平台的定位和依赖的IAAS服务强相关。

 1、如果定位是承载稳态业务应用，则平台建设规划是技术架构以简洁为主，不依赖的IAAS的SDN，通常宿主机采用underlay, 且容器有固定IP的需求。 容器网络方案，宜选择host network模式：不会创建容器的网卡，不会再虚拟出自己的网卡、IP、网关、路由等信息，而是和宿主机共享IP和端口等信息。 kubenets 网络插件配置为 network=none 。

 2、如果定位是承载敏态业务应用，则平台建设规划是技术架构以能力丰富、敏捷交付和大规模支撑为主。另外需要看依赖的IAAS服务， 通常宿主机采用overlay, 少有固定iP需求。容器网络选型是要结合IAAS的能力和K8S CNI的实现（注：少量固定IP需求，可以选用集成外部LB负载均衡器的方式实现），另外，容器插件也可以评估采用第三方实现方案，比如 Flannel、Calico、 Cilium，但是存在2层overlay网络的性能损耗。

 3、网络管理部门建议设置云网络岗位，专职于IAAS的SDN （overlay）和容器网络的运维管理。 之前的传统网工的职责不变。二者的管理边界以云上和云下进行区别。

1、原生NAT方案.2、隧道方案（Overlay）.3、路由方案.4、自定义网络方案.5无线通信联网方案.银行一般选择无线通信联网方案.