俄罗斯云主机,大洋洲裸金属_
大家好，欢迎大家来参加CNBPS 2020云原生技术实践峰会，我是灵雀云的资深开发工程师刘梦馨，本次分享将由我和天翼云边缘计算的高级开发工程师范日明一起为大家带来如何构建多租户的VPC容器网络，重点介绍我们是如何将开源项目Kube-OVN在天翼边缘云的场景中进行落地。
01 如何构建多租户VPC容器网络
为什么需要多租户网络？
如果大家对公有云网络演化的趋势有印象，应该记得AWS最早用的网络其实是一个大二层网络，并非VPC网络。所谓的大二层网络，就是所有租户共享同一个地址空间，公有云在下面加一层防火墙来做多租户之间的隔离。但是随着用户的增加，地址空间不断耗尽，更为重要的是出于安全上的考虑，AWS最终采用了VPC网络来进行未来的架构。现在，国内、外的公有云基本上也都从原来的经典网络向VPC网络进行迁移，可以说主流趋势已经是VPC了。用户如果在公有云上新建网络，一般默认也都是VPC网络。
为什么要用VPC网络呢？主要有两点好处：第一个更好的隔离机制，纯大二层的网络，底层必须依赖防火墙的隔离，做一些比较细粒度的复杂控制。随着租户增多和需求的增加，防火墙的复杂度也会增加。但如果通过VPC网络，每个租户可以有一个完全独立的地址空间，可以做到天然逻辑上的隔离，会防火墙的机制更加简单，逻辑上也更加清晰。第二，VPC能提供更好的用户抽象，大二层网络，所有租户的IP地址空间都必须由下面的公有云预先进行分配，用户不能对自己的地址空间进行控制。
这对于一些大规模的场景，一些特殊应用来说，是很难接受的，而VPC提供了更好的灵活性，用户可以自定义地址空间，只要在自己的地址空间内不冲突即可，也扩充了整个系统可以使用的地址。比如，两个租户之间的地址是可以重叠的，这样很多事情就变得方便了，这也是公有云的演化趋势。
如果我们再把目光放回到Kubernetes，会发现Calico、Flannel，或者其他网络插件，大部分遵循的还是大二层的网络趋势，也就是所有容器其实是共享同一个地址空间，我们需要通过Network Policy来做访问控制。我们认为，未来Kubernetes网络一定会从经典大二层，向着多租户的VPC方向演进。
使用场景
再来看一下今年遇到的多租户网络需求的场景，究竟是哪些场景开始对Kubernetes多租户网络有了需求？
首先是公有云提供的容器服务。对于公有云来说，多租户的安全隔离是必备条件，强隔离需求是必备的，而且每个公有云用户在现有VPC网络的习惯下，倾向于自己有一个独立的网络空间，所以用户也需要定义自己的地址空间。
第二，也是我们今年看到的比较多的趋势，企业还是想给用户提供虚拟机的服务，但底层基础设施已经不再是OpenStack或者VMware，而是希望通过Kubernetes来提供虚拟机的虚拟化场景，这样对传统业务的兼容性比较好。对于虚拟机来说，他们其实也需要多租户网络，传统的大二层网络不符合他们的需求。
第三，我们在金融场景碰到越来越多的多租户的需求。大家前几年上容器云，对网络的需求是只要能打通，业务可以上就可以了，但随着越来越多的业务迁移到容器云，发现原来的一些安全审计和隔离的需求也会从虚拟机时代转移到容器云时代。金融场景对隔离有很强的管控，对流量需要细粒度的控制，原有的那种大二层所有IP地址空间混在一块的方式，显然不符合监管和安全的诉求。
对多租户的主要需求
第一点最基础的，是多租户之间的地址空间隔离，也就是说不同租户的地址可以重叠。你在一个租户下有个192.168.0的网段，在另一个租户下也可以有192.168.0的网段，每个租户之间只要不进行互访，都是可以在租户内部进行正常IP通信的。
第二，在IP地址可重叠的基础上，每个租户之间有一些相互独立的网络应用，比如每个租户要有自己的LB、NAT、EIP和DNS等网络应用层面的控制。用户在Kubernetes上多租户网络应用的需求在不断涌现。
第三，对于每个租户要有细粒度的控制，我们原有的Kubernetes的网络监控都是主机或者Pod级别的监控，但是随着多租户的场景，每个租户的监控也需要隔离，而且每个租户需要有不同的监控选项。在多租户上，还要进行细粒度的资源隔离，比如QoS，每个租户的带宽是怎样的，如果是提供EIP服务，公网带宽又应该如何给每个租户进行限制，此外，对于多租户，不管是公有云还是企业内部，会有一些计费或成本核算的需求，对网络这块也有计费的要求。
Kubernets上的多租户网络挑战
那么Kubernetes和现有多租户网络上的一些难点是什么样子的？首先，Kubernetes本身的多租户方案，不只是网络，所有资源层面的多租户，上游的方案都没有非常明确。大家如果关注Kubernetes上游社区的发展，会知道Kubernetes的多租户SIG里面，有两种方案争论的比较激烈，一种是HNC，参考namespace的多租户方案，还有一种Virtual Cluster方案，在Kubernetes大集群上虚拟出无数个Kubernetes虚拟节点，再加上一层虚拟的Kubernetes集群，相当于是Kubernetes on Kubernetes的架构。目前两个方向在同步进行，上游多租户方案的不确定，会影响到网络多租户服务的设计，如何与Kubernetes对接的过程。
除了上述多租户在整体架构上面临的问题，还有很多细粒度上的问题。
Kubernetes本身在设计之初没有考虑多租户网络的情况，现有Kubernetes架构，默认的一个行为是IP地址是不重叠的，一旦把多租户的网络上去了，IP重叠的现象会引发很多问题。
首先就是API校验的问题，现有Kubernetes的一些Pod，会对IP的唯一性进行校验。如果IP重叠，现有API会出现问题。再有我们碰到了一个比较直接的问题，在多租户网络下，主机和容器网络的互通其实是会存在问题的，因为IP是重叠的，主机直接去访问IP而没有租户信息的话，其实是没有办法访问的。现有的健康检查就会出现问题，比如TCP和HTTP的健康检查，其实默认的行为是kubelet会从主机的网络栈去往容器的网络栈，这种情况下，如果是多租户就会有一定问题。同样像Nodeport模式也会出现一些影响，因为现有的Nodeport也是通过主机网络栈直接往容器网络栈，通过IP映射，但是没有租户之间的关联关系，也会出现类似的问题。此外DNS、监控、容器访问、APIServer等等都需要考虑多租户网络和主机网络交互的情况。
第二，Cluster IP目前由Controller Manager集中分配，没有隔离机制。也就是说即使做到了底层IP可重叠，但由于Kubernetes现有的Cluster IP分配机制，是没有办法做到Cluster IP的租户隔离的。其实最理想的情况应该是每个租户，除了自己的IP地址，pod的IP地址空间和service的IP地址空间也是应该隔离的，这样Cluster IP也是可以重叠的。
第三点，租户级别的网络服务，比如LB/DNS/ACL/EIP/NAT，原来所有的设计方案都是为整个集群提供LB或者NAT服务，多租户情况下需要为每个租户分别考虑，网络的控制粒度会变得更细一层，不是从集群的粒度，而是从租户的粒度去看各个层面的网络组件方案。
02 天翼云边缘计算多租户网络实践
前面我们介绍了一些关于Kubernetes的网络多租户需求和现有的一些问题。下面有请天翼云的高级开发工程师范日明带来天翼云在多租户网络实践方面的分享。
我是范日明，主要做云计算相关的研发和解决方案落地相关的工作，目前主要负责中国电信天翼云边缘计算方案的集成和落地。在边缘计算这块，我们坚持使用云原生的解决方案，走了一些弯路，也积累了一些经验。特别是在多租户网络方面的突破对我们来说尤为重要，我今天要分享的内容是如何在边缘计算进行多租户的网络管理。
边缘计算：算力下沉的优势与难题
边缘计算的场景有什么特点呢？首先聊到边缘计算，大家听的最多的应该就是大带宽、低时延、大连接、靠近用户，能非常好地利用5G 的特点来去做场景化的业务构建。包括智慧园区、车路协同、物联网、视频汇聚、直播、工业控制等一些业务场景。下沉到边缘的业务，它往往不是一个简单的Web应用，而是各种垂直行业比较复杂的业务，纯粹的容器化其实是没有办法满足需求的。
同时相比大云，边缘计算的资源比较受限，大的节点可能有几十台的机器，小的只有几台，有些试点刚开始就给你一台，没有办法像大云那样，各个能力模块都用一个单独的集群来承载，只能把所有的能力融合来建设，做超融合架构，网络/存储/计算/管理等所有的能力都在一个集群里面。我们的解决方案是all in Kubernetes，要支撑边缘复杂的业务场景，Kubernetes就必须要同时承载安全、容器、虚拟机、函数计算这些能力。好在，这些都有相应的开源项目支持，我们也都把这些方案集成到我们的平台上来了。
最难的部分就是网络SDN。容器有代表性的网络方案Newton CNI和Openshift SDN，其实各有各的局限。OpenStackSDN非常强大，但是太重了，必须部署到OpenStack，这跟我们的原则是相背的，因为我们在边缘要尽量做到轻量化。Openshift SDN有一部分的多租户能力，但是不够丰富，没有做到强隔离，租户也没有主网能力。
Kube-OVN基础网络编排
最初我们在云原生网络方案的选型时，关注到Kube-OVN这个开源项目，它具备比较丰富和实用的功能，以及一些运维手段。底层采用了OVN，OVN本身有非常强的SDN能力，在OpenStack上也得到了充分验证，我们基于Kube-OVN开始构建了天翼云整个边缘计算的SDN能力。
一开始的方向是支持容器化应用，先下沉到边缘，这块是相对容易的，因为容器化应用大部分经过了微服务改造，能很好地适应Kubernetes的环境，基本上只要保证租户之间的网络在ACL层面的隔离，就能满足需求。在网络规划上，我们用了Kube-OVN自定义网络，还有固定IP的能力，为不同租户分配不同的网络段，租户也可以给自己的容器实例分配固定IP。
在网络隔离方面，我们使用Kubernetes的Network Policy的网络策略，租户之间可以做到ACL层面的隔离。入口流量方面使用了Ingress和MetalLB两个方案。Ingress负责七层的流量，不同租户之间分配不同的域名，就可以区分到不同租户的流量。MetalLB负责四层流量，有些业务要有自己的独立IP，MetalLB可以做到给不同租户使用自己的独立公网IP的能力。但它也有一些局限——仅限于入网流量可以走IP，出网的话，如果容器主动要访问外部的一些网站，或者自己部署在其他公有云的服务，是没办法走MetalLB同样的一个回路出去的。进网和出网是不同的IP，对一些业务来说是受限的。
总体来说，这些能力可以承载一般的容器应用，这是我们第一步首先去落地的方向。但它存在很多不够完善的地方，首先看网络隔离，租户之间网络三层，共用一个逻辑路由，没有强隔离，肯定不支持重叠网络。缺乏一些比较细粒度的QoS管控，出入网没无法使用同样的公网IP等，这一套的解决方案里面还是不能满足的。
目前来看，大部分客户其实是选择虚机而非容器，同时一些其他的业务还提出了专线组网等能力，目前这套方案是没有办法满足的。所以，我们还是考虑把中心云上VPC这一套的网络能力下沉到边缘，于是在Kube-OVN开源项目的基础上进行了升级改造，实现了强隔离，制定VPC的网络能力。
能力增强 回馈开源
首先来看两个架构图，左边是Kube-OVN 1.5版本以前的架构，Kube-OVN子网对应的其实是一个逻辑交换机，所有的逻辑交换机连接到同一个逻辑路由上面。这样所有的子网是三层，默认互通。子网隔离采取的是，在逻辑交换机上设置ACL的规则来实现隔离。
右边的架构是我们扩展的自定义VPC的能力，租户网络有独立的三层路由，VPC之间的网络是天然强隔离的，这就解决了常规容器网络在多租户隔离上的一个痛点。目前这个feature我们已经提交，并且合并到master的分支，大家可以提前去尝试体验一下。VPC解决了我们租户网络的隔离问题。从架构上来看，因为要做租户的强隔离，自定义VPC没有出口网关，没有利用原有的那套网络出入口的逻辑。
基于VPC的网络能力扩展
那么在自定义VPC的基础上，怎么去构建边界网络的流量？VPC的概念相信大家如果熟悉公有云的玩法，对其概念和周边扩展的能力应该比较熟悉了。有了VPC之后，我们可以对网络进行更精细的管控，把更多的大云上的网络能力下沉到边缘，但是云和边的实现是有区别的。
云上的每一个能力都可以用独立的集群去承载，但在边缘由于资源稀缺，只能把所有的能力做融合，单集群内所有的节点既是计算节点，也是网络节点，还有可能是存储节点，所以，VPC网络边界这块也进行了容器化的实现，包括NET网关，SLB、VPN网关、专线接入等功能，也可以用弹性IP，基本上把所有大云上的网络能力都下沉到边缘了，所以如果你是大云上IaaS的深度用户，要迁移到边缘，是可以无缝迁移的，切换成本非常低。
SLB这块其实可以替代Ingress的七层能力和MetalLB的四层负载均衡能力。这样每个租户有自己的SLB，而不需要像最初的容器应用一样，所有的流量共用一个Ingress，同时可以提供更多负载均衡的策略，这和云上的网络产品是基本保持一致的。
容器化可以带来更多的好处是轻量和灵活，可以在Kubernetes上的任意节点去部署网络能力，单点如果出现故障，可以做到秒级迁移，同时各个节点的带宽分配也可以做到非常灵活，因为它是容器化运行。我们可以根据业务的带宽负载压力，在所有节点上去根据自己的调度策略去均匀地做分布。
以上就是我要分享的全部内容，很高兴能跟大家分享我们的实践过程和思路，谢谢大家。