NCI（云杉NSP容器网络方案）原理篇（上）
0. 背景
随着对业务快速交付、迭代、扩展以及资源利用率最大化等方面愈发迫切的需求，越来越多的企业倾向于将业务微服务化和云化。而因为轻量、封装简单、应用无缝对接、易于部署和变更等多方面的特性，容器以及Kubernetes容器管理平台正在得到越来越广泛的应用。Gartner预测[1]，到2022年将有超过75%的全球组织机构会部署容器化的生产业务应用。
然而根据2018年的一份市场调研[2]结果来看，网络和安全问题是Kubernetes用户目前面临的最突出的两大挑战。
1. 现有容器网络方案缺陷
目前常见的容器网络方案包括：Flannel、Calico、Weave Net、Contiv、NSX-T Container Plugin (NCP)、OpenShift-SDN等，其中Flannel-VXLAN、Calico-IPIP、Weave Net、Contiv-VXLAN、NCP、OpenShift-SDN都是基于Overlay隧道实现，而Flannel-HostGW、Calico-BGP、Contiv-BGP都是基于路由方式实现。此外，还有完全依赖Underlay实现的网络方案，如SR-IOV、MACVLAN、IPVLAN等。
企业在容器网络方案的选型上会综合考虑业务特点、技术能力、现有IT环境及规模等多种因素。虽然现有的容器网络方案众多，但通过与我们所服务的客户在容器网络安全性、弹性扩展、可管理性、性能等方面的深入探讨，发现当前技术架构在如下诸多方面对于企业业务支撑并不够好，希望有更好的解决方案来满足业务持续变化的要求。
1.1 业务隔离
一个Kubernetes集群中往往会运行不止一个业务，为了不相互影响，同时也为了更可靠的安全防护，不同的业务之间需要相互隔离。然而Kubernetes在网络层面没有提供不同业务之间PoD隔离的逻辑，所有PoD默认都是能互通的，PoD之间的隔离需要通过额外配置Policy来按需实现。
因为Kubernetes中子网网段通常是按照Node粒度来划分的，在不同的Node上PoD所分配的IP地址属于不同的子网网段。当这些不同的Node上的PoD按照不同的需求组合来提供不同业务时，业务隔离所需要创建的PoD之间的Policy将会非常复杂，并且势必在大规模业务场景下要求数量庞大的Policy，这样就会导致Policy配置速度慢、运维复杂度高、处理性能低等诸多问题。
业界也有通过部署多个Kubernetes集群并且每个集群中只运行一个业务来实现业务隔离的方案，不同的集群之间通过二层广播域、或者三层路由域、或者防火墙ACL等方式来进行隔离。虽然隔离边界清晰，但多集群在管理上更加复杂，而且在业务规模扩展以及资源利用上也有很大的限制。
1.2 弹性扩展
企业IT的发展一般来说都是循序渐进而非一蹴而就的，早先的企业基本上经历了从裸机演变至虚拟化的阶段，后续再规划从虚拟化过渡到容器化。对于这种逐步演进，为了保证业务的连续性并能平滑迁移至新资源池中，新上线的Kubernetes容器资源池需要能够和现有的裸机或者虚拟化资源池业务互通。此外，一些业务本身就需要基于混合资源池来部署提供，比如超算、共享存储之类。由此可见，PoD、虚拟机以及裸金属服务器之间的资源互通需求普遍存在。
另外，Kubernetes集群自身的容器规模也受限于容器网络方案的可扩展性。对于Calico-BGP路由方案，每个Node上都会运行BGP实例，并且依赖于Underlay网络提供BGP RR和路由隔离能力，在这种大规模场景下对于Underlay网络设备的RR和路由规格要求非常高，并且管理的复杂度也会超线性上升。而对于Overlay隧道方案，其采用的主机Overlay本身就存在性能限制，如果所有Node上的PoD都需要互通，那么就需要建立full-mesh的隧道，n个Node的集群规模将会产生O(n2)的隧道数要求，不利于规模扩展。
除上述提到的资源弹性扩容之外，Kubernetes的规模扩展需求还体现在业务域多活、异地容灾等场景中，具体包含如下：
资源池弹性扩展
如前文所述，Kubernetes资源池内Node规模扩展时网络也需要能线性扩展。
跨资源池弹性扩展
当在不同的可用域（AZ）部署多个Kubernetes资源池以实现业务域多活时，需要支持跨Kubernetes资源池互通。
异构资源池弹性扩展
企业在不同时期有不同的资源池类型，业务演化过程中不同类型资源池共存，但业务是一个整体，并且有些业务就是要依赖异构资源池来实现的，因此需要异构资源池之间支持互通。
跨数据中心扩展
为了实现业务异地容灾，并且有些弹性业务也要求实现资源无地域差异扁平化，需要支持跨数据中心互通。
混合云弹性扩展
企业业务因为各种限制，资源可能会按要求部署在不同位置，比如一部分部署在公有云上，另一部分部署在私有云中，因而需要实现混合云互通扩展。
因此容器网络方案还需要结合数据中心Fabric网络和DCI网络以形成整体方案。
1.3 地址管理和策略配置
IaaS云平台中的子网网段通常是根据业务构建需求来划分的，对于有二层互通需求的业务虚拟机会被添加到同一子网中并分配对应同一网段的IP地址，对于仅需要三层互通的业务虚拟机会被添加到不同的子网中、分配不同网段的IP地址。这种按业务划分网段的方式的好处在于能够清晰地对应出一个虚拟机所属的业务，并且在出现互通问题的时候能够明确是哪个层面网络不通。
而Kubernetes是基于Node来划分子网网段的，在不同的Node上会根据该Node所配置的子网网段来给其上的PoD自动分配对应网段中的IP地址，无法做到按照业务来划分网段和分配IP地址。这种方式下PoD所对应的业务无法直接通过IP地址看出，并且PoD属于的业务层级也无法明确。另外，在某些金融场景中，为了满足合规性要求，业务是需要与IP地址绑定的，对此基于Node粒度的网段划分将无法满足。
不仅如此，PoD的地址分配也影响到PoD之间互访时的隔离以及安全防护Policy的配置。除了业务之间的隔离之外，业务内部不同应用之间互访时也有安全限制需求，比如一个由Web应用、App应用和DB应用组成的业务中，Web应用不能直接访问DB应用。而按照Kubernetes的PoD地址分配方式，这些场景对应的Policy配置粒度需要非常细，从而导致Policy非常多且复杂，一旦配置出错出现业务不通问题，定位起来将会耗时耗力。
1.4 服务访问
Kubernetes服务分为用于集群外部访问的南北向服务和用于集群内部访问的东西向服务。
南北向服务主要通过Ingress方式来实现，其本质是通过反向代理（如Nginx、traefik等）来提供对外的访问代理以及实现负载均衡。一般来说，企业都会通过专业厂商的硬件防火墙或者负载均衡设备来对外提供业务访问，因此一方面为了利旧，一方面为了性能，南北向服务需要能按需引入专业服务，而Kubernetes本身未提供此能力。
东西向服务主要通过ClusterIP方式来实现，底层是基于iptables或者ipvs来进行地址转换以及实现负载均衡。一方面ClusterIP没有隔离，不相关业务的PoD都可以访问，另一方面所有流量都需要走复杂的内核协议栈和netfilter/ipvs进行转换和发送处理，效率低的同时出现问题也不方便定位，因此东西向服务需要支持业务隔离的同时也需要实现得更轻量高效。
2. NCI是什么
针对Kubernetes在实际部署应用时所面临的网络方案问题及挑战，我们设计并提出了Kubernetes网络插件NCI（NSP Container Infrastructure）。NCI是NSP-DCN对Kubernetes提供的统一网络编排和服务管理解决方案，并与NSP-DCN控制器实现联动，对Kubernetes的PoD网络、东西向和南北向服务网络实现统一纳管，同时支持Kubernetes的资源弹性扩容和跨资源池互联，并满足高性能网络需求。
NCI组件包含了运行在Kubernetes Node上的NCI-Controller和NCI-OpenvSwitch模块，运行在Kubernetes Master上的NCI-Supervisor模块，以及运行在NSP-DCN控制器上的NCI-Provider模块。其中NCI-Controller实现了CNI，负责响应PoD以及服务的增删改，并执行相应的组网和服务配置；NCI-OpenvSwitch负责运行OvS（OpenvSwitch）网桥，NCI-Controller中的组网和服务配置就是通过下发OvS的接口和流表配置来实现的；NCI-Supervisor负责资源（namespaces、subnets、ips、node-subnets等）的管理，一方面对NCI-Controller申请的资源执行分配，一方面向NCI-Provider同步资源信息；NCI-Provider则负责根据NCI-Supervisor同步过来的信息去配置Kubernetes Node所上联的Leaf交换机，完成Kubernetes资源池内部的整体组网配置。
2.1 NCI的基础：NSP-DCN
NSP-DCN是一款面向企业云数据中心，为混合云以及混合资源池提供网络虚拟化、网络服务编排的SDN超级控制器，是实现NCI的基础。
因为技术不断演进、客户需求多样、避免厂商绑定等多重考虑，云数据中心往往会提供多种类型的资源池，比如OpenStack资源池，VMware vSphere资源池、裸金属服务器资源池等等，并且为了扩容、多活、灾备，资源池还可能会分布在多地多数据中心。而客户购买的同类型或者不同类型的计算/存储资源可能是分散在不同数据中心不同资源池中的，因此当客户想要基于这些混合的资源去部署业务的时候，就需要能够按照业务需求进行多数据中心混合资源池的组网编排，同时也需要引入边界服务来对外提供业务访问。NSP-DCN作为超级控制器的目的就是来解决上述云数据中心资源池网络统一纳管的问题的。
具体来说，NSP-DCN所支持的网络虚拟化主要是在资源池区为资源池提供虚拟网络服务；NSP-DCN所支持的混合云网络编排则是面向多资源池场景，提供统一的逻辑网络，能够为数据中心内部相同资源池，数据中心内部异构资源池，数据中心之间异构资源池及和公有云资源提供统一可互连的二层、三层虚拟网络；NSP-DCN所支持的边界服务则为数据中心的网络边界（包括ISP和DCI接入）提供统一纳管的服务平台，能够对客户现有的网络、安全网元设备进行统一管理，实现服务化交付，解耦不同厂商网元设备带来的复杂性。
如图所示，NSP-DCN基于Logical Switch（LS）和Logical Router（LR）来实现同Fabric网络下多资源池的组网互联，通过Virtual Routing Bridge（VRB）来实现边界服务接入以及跨Fabric网络或者跨数据中心的组网互联。而NSP-DCN在结合了NCI之后，进一步实现了对Kubernetes资源池的统一纳管支持，即Kubernetes资源池的网络虚拟化，Kubernetes资源池自身扩容以及同其他异构资源池以及混合云互通，还有边界服务。
2.2 NCI-VPC
在云资源池中，用户的业务基本都是以虚拟私有云（VPC）的粒度来部署的。划分到同一个VPC中的资源，按照二层网络、三层网络、四层及以上的服务这样的层级结构进行组网编排，最终对外提供整套业务访问，而VPC之间的业务在网络层面是默认隔离的。对于Kubernetes资源池来说，业务也是有隔离需求的，并且其资源在和云资源池内的资源跨池互通时，也需要按照不同的业务实现网络隔离，因此在Kubernetes资源池中引入VPC的概念延续了企业的使用习惯，降低了使用成本。
在NCI的设计实现中，一个VPC就对应Kubernetes集群中的一个Namespace，隶属于同一个Namespace的PoD是可以互通的，而不同Namespace的PoD之间默认是隔离的。相应地，一个Namespace中的PoD通过组网编排，最终可以对外提供完整的业务。多个业务则对应由多个Namespace提供。
具体来说，NCI会允许在Namespace中创建多个子网（Subnet，对应NSP-DCN中的Logical Switch），同一子网的PoD二层互通，不同子网的PoD通过Router（对应NSP-DCN中的Logical Router）三层互通。此外，通过对应VPC中的VNF设备（vGW、vFW、vLB...），Namespace中的PoD可以进一步对外提供业务访问。上面图中展示的就是两个Namespace各自以VPC粒度对外提供业务，对应独立的PoD资源以及LS、LR、VNF等实例，业务相互隔离。
2.3 K8S为什么需要VPC？
以VPC为核心，NCI可以为Kubernetes平台提供业务划分及隔离的能力。因为VPC也是对应到租户的最大逻辑单元，所以可以进一步提供多租户支持。此外，在资源弹性扩展以及跨资源池互联上，VPC提供了统一的资源纳管粒度，使得Kubernetes资源池网络和云资源池网络一样能够被SDN控制器统一管理和编排。
如图中所示，无论对于Kubernetes跨资源池扩容，还是跨异构资源池组网，抑或是跨数据中心互联，基于VPC都能实现，同时保证业务隔离。当VPC之间需要打破隔离实现业务互通时，可以利用VPC对等连接来实现东西向互通或者通过接入大内网来实现南北向互通，在能互相访问的同时也能提供安全防护。
[1]https://www.gartner.com/smarterwithgartner/6-best-practices-for-creating-a-container-platform-strategy
[2]https://thenewstack.io/top-challenges-kubernetes-users-face-deployment/
NSP是北京云杉世纪网络科技有限公司（简称：云杉网络）推出的数据中心网络互联与网络服务产品。NSP软件基于开放架构设计，通过对接和纳管数据中心已有的系统和设备，为客户提供了灵活的组建多场景VPC网络和网络服务虚拟化（NFV）的自动交付，并提供混合云场景下异构资源池的安全互联服务，使客户在现有的IT基础设施和网络架构下，真正实现业务网络的统一和自动化管理、分钟级部署、弹性伸缩等目标，帮助客户打造可靠、灵活、敏捷、安全和高可用的云原生的数据中心网络，确保云端业务网络的一致性和安全性。