网络应用场景
现在我们已经有了一个 Kubernetes 集群，先来思考一下，容器网络除了让集群正常运行，能让安装 Kubernetes 后 Pending 的 CoreDNS running 起来（抖个鸡灵-_-）以外还有哪些使用场景？
这里我通过一张图总结了七个主要使用的场景，应该也涵盖大部分运维人员网络需求。
固定 IP。对于现存虚拟化 / 裸机业务 / 单体应用迁移到容器环境后，都是通过 IP 而非域名进行服务间调用，此时就需要 CNI 插件有固定 IP 的功能，包括 Pod/Deployment/Statefulset。
网络隔离。不同租户或不同应用之间，容器组应该是不能互相调用或通信的。
多集群网络互联。 对于不同的 Kubernetes 集群之间的微服务进行互相调用的场景，需要多集群网络互联。这种场景一般分为 IP 可达和 Service 互通，满足不同的微服务实例互相调用需求。
出向限制。对于容器集群外的数据库 / 中间件，需能控制特定属性的容器应用才可访问，拒绝其他连接请求。
入向限制。限制集群外应用对特定容器应用的访问。
带宽限制。容器应用之间的网络访问加以带宽限制。
出口网关访问。对于访问集群外特定应用的容器，设置出口网关对其进行 SNAT 以达到统一出口访问的审计和安全需求。 理完需求和应用场景，我们来看看如何通过不同的 CNI 插件解决以上痛点。
网络插件功能实现
固定 IP
基本上主流 CNI 插件都有自己的 IPAM 机制，都支持固定 IP 及 IP Pool 的分配，并且各个 CNI 插件殊途同归的都使用了 Annotation 的方式指定固定 IP。对于 Pod，分配固定 IP，对于 Deployment，使用 IP Pool 的方式分配。对于有状态的 Statefulset，使用 IP Pool 分配后，会根据 Pool 的分配顺序记好 Pod 的 IP，以保证在 Pod 重启后仍能拿到同样的 IP。
Calico
“cni.projectcalico.org/ipAddrs”: “[“192.168.0.1”]”
Kube-OVN
ovn.kubernetes.io/ip_address: 192.168.100.100
ovn.kubernetes.io/ip_pool: 192.168.100.201,192.168.100.202
1
Antrea
Antrea IPAM 只能在 Bridge 模式下使用，因此可以在 Multus 的辅佐下，主网卡使用 NodeIPAM 分配，副网卡使用 Antrea IPAM 分配 VLAN 类型网络地址。
ipam.antrea.io/ippools: 'pod-ip-pool1'
ipam.antrea.io/pod-ips: '<ip-in-pod-ip-pool1>'
1
Cilium
Not Yet!
多集群网络互联
对于多集群网络互联，假设有现有多个集群，不同的微服务运行在不同的集群中，集群 1 的 App01 需要和集群 2 的 App02 进行通信，由于他们都是通过 IP 注册在集群外的 VM 注册中心的，所以 App01 和 App02 只能通过 IP 通信。在这种场景下，就需要多集群 Pod 互联互通。
Calico
对于 Calico 这种原生对 BGP 支持很好的 CNI 插件来说，很容易实现这一点，只要两个集群通过 BGP 建立邻居，将各自的路由宣告给对方即可实现动态路由的建立。若存在多个集群，使用 BGP RR 的形式也很好解决。但这种解决方式可能不是最理想的，因为需要和物理网络环境进行配合和联调，这就需要网络人员和容器运维人员一同进行多集群网络的建设，在后期运维和管理上都有不大方便和敏捷的感觉。
那 Calico VxLAN 模式呢？
既然说到 VxLAN，可以和 Kube-OVN、Antrea、Cilium 放到一起来看，四种 CNI 都支持 Overlay 的网络模型，都支持通过 VxLAN/GENEVE 的形式建立隧道网络打通容器网络通信。这就赋予运维人员较高的灵活性，对于容器网络的调教、IPAM 分配、网络监控和可观察性、网络策略调整都由容器集群运维人员负责，而网络人员则只需要提前划好物理网络大段，保证容器集群 Node 之间网络互通即可。
那如何去实现 overlay 网络的多集群互联呢？
Submariner
CNCF 有个沙箱项目叫 Submariner，它通过在不同集群建立不同的网关节点并打通隧道的形式实现多集群通信。从官方这张架构图来说明：
简单来说，Submariner 由一个集群元数据中介服务（broker）掌握不同集群的信息（Pod/Service CIDR），通过 Route Agent 将 Pod 流量从 Node 导向网关节点（Gateway Engine），然后由网关节点打通隧道丢到另一个集群中去，这个过程就和不同主机的容器之间使用 VxLAN 网络通信的概念是一致的。 要达成集群连接也很简单，在其中一个集群部署 Broker，然后通过 kubeconfig 或 context 分别进行注册即可。
Cilium
Cilium Cluster Mesh 和 Submariner 有异曲同工之妙，可以通过隧道形式或 NativeRoute 形式实现集群互联。
Cilium 开启多集群网络连接也很简单：
KubeOVN
Kube-OVN 还提供一个 OVNIC 的组件，它运行一个路由中继的 OVN-IC 的 Docker 容器，作为两个集群的网关节点，将不同集群的 Pod 网络进行连通。
多集群服务互访
除了 Pod IP 的互联互通，多集群网络还可考虑集群间的 Service 互访，Submariner、Cilium，Antrea 都能实现。Submariner 和 Antrea 都使用了 Kubernetes 社区的 MultiCluster Service 并在此之上结合自身组件实现多集群的服务访问。MultiCluster Service 通过 ServiceExport 和 ServiceImport 的 CRD，ServiceExport 将需要公开的服务导出，然后通过 ServiceImport 将此服务导入到另一个集群。
Submariner
拿 Submariner 实现举例，有两个集群 ks1 和 ks2，ks1 在 test 命名空间有一个服务 nginx，此时通过 ServiceExport 将 nginx 服务进行导出，Submariner 会把这个 nginx.test.svc.cluster.local 服务发现为 nginx.test.svc.clusterset.local，两个集群的 coredns 都会建立一个新的 clusterset.local 的存根域，将所有匹配 cluster.set 的请求发送给 submariner 的服务发现的组件。同时 ServiceImport 导入到 ks2 集群，ks2 集群的 Pod 就可以通过 nginx.test.svc.clusterset.local 解析到 ks1 集群的 nginx Service。如果两个集群都有 nginx 的同名服务，此时 submariner 就可以优先本地进行访问，本地服务端点有故障后再访问其他集群的 nginx 服务，是不是可以开始构建双活服务了哈哈。
Antrea
Antrea 实现方式类似，也是结合 ServiceExport 和 ServiceImport 并进行封装成 ResourceExport 和 ResourceImport 构建多集群服务，在每个集群选择一个节点作为网关，通过网关打通不同集群隧道来实现多集群服务的访问。
Cilium
Cilium 没有用 MultiService 的概念，Cilium 通过 Global Service 的概念构建多集群访问服务访问。
创建一个 kubernetes 集群并安装 KubeSphere，在此之上体验不同的 CNI 在 Kubernetes 的功能应用。毕竟，哪个运维人员不喜欢页面友好的容器管理平台呢？
