实践案例 | 用Kube-OVN实现跨K8s的统一网络平面部署TiDB

作者：成臣（Sei Jin） PingCAP Marketing & Community

chengchen@pingcap.com Github: it2911

在前不久举办的KubeCon China 2021大会上，来自PingCAP的成臣，根据日本用户“跨K8s网络平面部署TiDB”的需求，所做的方案调研，带来“用Kube-OVN创建一个跨K8s的统一网络平面”的分享。

分享中指出，Kube-OVN具有许多特性，其中集成多个K8s网络以开放和创建一个共同的网络平面的特性是其中最吸引人的特性之一。通过集成多个K8s网络，并允许应用程序在多个K8s集群上运行而无需感知，可以提高节点的使用效率，降低应用程序和体系结构的复杂性；更重要的是，支持数据中心级别的灾难恢复。

在介绍如何使用Kube-OVN构建一个跨K8s网络平面部署TiDB的同时，成臣还对解释类似部署场景的重要性和概念做了详细的解读。

为什么要使用跨集群网络

在我们的认知中，用户使用跨集群网络无非有以下几个诉求：

第一个诉求，是用户对服务可用状态的要求。往往用户期待着自己的服务可以进行两地三中心的部署，尤其在日本这么一个灾害多发国家，很可能一个地震就会造成多个数据公中心的停止运作，所以两地三中心在灾害多发的国家或者地区显得尤为重要。
第二个诉求，是用户期待对服务进行分离。各个云厂商特点不同，比如a和b两个云厂商之间的存储的价格相差10倍，那么在这种情况下，用户就可能希望实现将存储放在a厂商，将计算放在b厂商，同时a和b在一个共治的K8s的网络平面上运作。
第三个诉求：用户希望有”逃生方案”，避免自己被锁定在一个云厂商服务上。
第四个诉求：是用户的合规要求，进行Hybrid Cloud的建设。比如，用户在本地有一个K8s集群，在远程的公有云上也有一个K8s集群，想统一管理，进行一个内网的连接时，一个网络平面的话就显得格外重要。

跨Kubernetes网络集群的几种方案

普通情况下，我们所创建的ipv4的K8s集群内部是一个内网状态，如果想做到跨K8s集群的网络，是有几种方案可以被提供的，在此我调研了三种实现/方案：

实现/方案一：IPv6 K8s集群

众所周知，IPv6有一些它的优势，比如说给IPv6的K8s分配一些IPv6的IP地址之后，它的pod实际上可以在很多情况下直接被外网访问到，甚至不需要提供一些特殊的网络隧道方案.但是如果非常了解IPv6会发现，我们很难通过个人去构筑IPv6的网络，原因是这些IPv6的网段要经过申请机构的申请。

当然你可以通过公有云上去申请IPv6的网段，但是如果在私有云的条件下，IPv6的网段申请，还有整个网络的建设是非常巨大和浩瀚的工程，对网络人员有很高的要求，所以此方案对硬件成本还有软件成本要求非常之高。

实现/方案二：公有云厂商的方案

公有云厂商实际上提供了很多跨K8s集群网络统一平面的方案，这些方案非常不错，但是也无法满足全部诉求：比如目前没有看到这些云厂商的网络方案可以基于IPv6实现。第二，这些云厂商的网络方案实际上无法跨云厂商进行构筑。

实现/方案三：Kube-OVN方案

经过不懈的寻找，我们发现CNCF上的新秀网络方案Kube-OVN,可以满足我们在私有环境下构筑两个K8s集群的统一网络平面的期待。

Kube-OVN功能特性

官网上Kube-OVN对自己的介绍是一个很灵活的企业级的解决方案，在使用的过程中，能够很明显感受到Kube-OVN灵活、高效安全的三个特性。

首先，我们如何看待灵活这个特点？

我们可以基于Kube-OVN建立一个三层的overlay的网络。它可以保证我们的PVC和Acl与现有的物理网络相对独立；同时，我们的子网和主机也就变得无关了，容器的IP可以在整个集群进行漂移。我们还可以根据NameSpace进行绑定，有效的实现多租户。大家知道K8s运维是一个非常麻烦的事情，如果在没有足够的自动化的条件下运维人员肯定希望一个K8s集群可以发挥出它最高的功效，这个时候多租户也就显得极为重要。

关于overlay网络还有一点非常重要的特点，就是它可以有分布式网关和集中式网关两种出口方式。如何理解分布式网关和集中式网关呢？分布式网关就是每一个Node上自己单独分出去一个网关进行通信；集中式网关是我们指定一两个Node，这两个Node带宽可能非常高，作为所有网络流量的出入口。基于overlay网络设计，Kube-OVN灵活的特性给我非常深刻的印象。

Kube-OVN第二个特性，就是它的高效性。

这些特性主要是由于Kube-OVN可以建立一个Underlay的网络，它可以使Pod直接和底层的虚拟机或者物理机直接相通，甚至支持Pod在不同的vlan网络进行通讯，而且还提供了Overlay和Underlay的共存能力。这就意味着，构建网络高效的同时，可以不失灵活；另外，用户可以选择封包或者不封包，把网络流量传给Pod。使用Underlay的网络的能力，就可以为K8s集群提供一个高性能的网络。

第三，我们来说Kube-OVN的安全特性。

自从容器诞生之日起，容器的安全一直被受到极大的关注。过去人们把目光一直聚焦在运行时的安全上，K8s本身的网络安全一直受到很多的诟病，尤其是K8s的network policy设定选项不够丰富，Kube-OVN极大的丰富了容器的网络安全的选项（如图所示）。难能可贵的是，Kube-OVN支持复制容器的全流量，这一点有助于运维人员对流量的安全进行审计和分析工作。

Kube-OVN运行Demo

为了让大家更加了解本方案的一些操作，我们构筑两个K8s集群进行Kube-OVN的Demo演示。

1、为了简化两个集群都仅使用一个Node节点部署，该节点也将同时被作为集群的Gateway节点，负责Kube-OVN的流量进出。

2、准备OVN Interconnection节点

3、各个节点的网络互联互通

*注：本次demo的全部执行代码，可以通过链接取得：https://github.com/it2911/kube ovn-demo