01
云原生的背景
随着云计算的蓬勃发展，越来越多的IT设施及架构具备了虚拟化、分布式、多租户的云计算能力，这些能力为高速发展的互联网行业插上了腾飞的翅膀、并为互联网业务的开展提供了极大的便利。
当移动互联网与5G的浪潮奔涌而至，为了满足以应用为中心的业务诉求，需要IT架构具备更加快速的部署效率、更加弹性的扩缩容能力、更加自动化的Devops流程，云原生(Cloud Native)的解决之道就应运而生。
云原生本身不是一种架构，它首先是一种基础设施，运行在其上的应用称作云原生应用。云原生应用应具备以下几个关键特性：敏捷、可靠、高弹性、易扩展、故障隔离保护、不中断业务持续更新，这些特性也是云原生区别于传统云应用的优势特点。
云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API等。利用云原生技术可以在公有云、私有云和混合云等新型动态IT架构中，构建和运行可弹性扩展的应用。
02
云原生对业务编排的要求
云原生基础设施在IaaS之上创建了一个编排层，以抽象出服务模型并促进动态资源分配调度。
编排很关键，虽然配置管理工具可以帮助自动化部分基础设施，但它们无法更好地管理应用程序，为承载应用的基础设施提供全生命周期管理。
容器是云原生应用最核心的技术，Kubernetes是当前最受欢迎的容器编排调度引擎，通过Kubernetes可以实现以容器为中心的资源编排、集群管理以及运维监控等工作。
虽然Kubernetes 的目标旨在消除编排物理/虚拟计算、网络和存储基础设施的负担，并使应用提供商和应用开发将重点放在以容器为中心的自动化运维上，但在Kubernetes实际的部署情况中，容器网络似乎自成一体，与大多数传统IT架构以及云IT架构中的数据中心网络无法融合。
一旦Day0完成后网络架构无法满足容器集群进一步的扩容，必须要通过手工的方式来完成计算与网络基础设施的设备及配置变更。而且容器网络中过多的隧道封装和流量绕行，对于数据中心网络性能的损耗也非常大，实际运维中一旦出现容器层面的网络问题，所涉及的排障流程和工作界面也面临较大挑战。
如何通过Kubernetes创建容器配置资源参数，并与数据中心内现有的IaaS平台整合，实现应用业务端到端的网络开通及配置，充分发挥出服务器和网络设备的效能，是当下亟需解决的技术难点之一。
03
云原生对网络的需求
Kubernetes本身不提供网络功能，只是把容器网络接口CNI开放出来，通过插件的形式来实现。为了实现容器网络的需求，业内出现了一系列不同功能的网络插件与方案，如Flannel、Calico、Contiv、Cilium等。
Pod是Kubernetes中可以创建和部署的最小单位，Pod中封装着应用的容器(有的情况下是好几个容器)，每个Pod都会被分配一个唯一的IP地址。Pod中的所有容器共享网络空间，包括IP地址和端口。云原生网络不只包含单纯的容器网络，还包括了IaaS层的网络虚拟化，若在容器层面再做一层网络虚拟化，对性能损耗太大。另外虽然有各种Overlay的方案来实现容器集群内跨Node节点的Pod间通讯，但也存在容器集群内Pod与集群外Underlay主机直接通讯的需求，所以需要一种与容器外部网络直接通讯的网络方案。
Calico作为一个纯三层的网络方案，可以避免与二层方案相关的数据包封装的操作，中间没有任何的NAT和overlay，所以它的转发效率可能是所有方案中最高的。
另外通过成熟稳定的BGP协议来实现Node间路由信息同步，可以实现超大规模的容器网络，同时可以与硬件网络交换机建立BGP peer，利用BGP的分布式控制平面，充分发挥出现有硬件网络交换机的能力，完成容器集群内部网络与外部网络的路由信息交互。
通过将容器网络与云环境的网络打通，可以为云原生下容器提供与虚拟机、物理机一致的网络性能，同时通过整合云环境下vLB、vFW等网元的能力，将充分发挥出云原生基础设施的敏捷性与可靠性。
04
利用Calico融合物理网络
云原生容器网络与物理交换机融合的网络架构分为Underlay和Overlay两个层面，首先介绍Underlay层面的网络融合：- 容器Node可部署在虚拟机或裸金属服务器上，根据实际业务对性能和管理的要求来选择合适的部署方式，在本次的实例中以虚拟机的部署方式来进行介绍，容器Node部署在虚拟机上可以拥有更加灵活的资源调度机制和更加细致的管理粒度。
- 物理服务器两张网卡采取bond4模式，双上联到一组做VPC或MLAG的Leaf交换机上。
- Leaf与Spine交换机Underlay的路由协议采用OSPF。
▲图一：Underlay网络融合架构
在Overlay层面的网络融合采用标准的EVPN VXLAN方案：
每个容器Node上的Calico BGP进程分别与两台Leaf交换机建立eBGP peer，Node全部采用相同BGP AS号，在本次实例中容器Node均采用AS号65203。
Leaf与Spine交换机Overlay运行iBGP EVPN VXLAN，Leaf交换机作为VTEP，在本次实例中Leaf与Spine采用AS号65201。
Leaf交换机向容器Node只通告默认路由，简化容器Node路由表项，降低Calico路由进程维护表项的性能压力。
Leaf交换机对收到的容器Node路由条目进行汇总，减少容器大规模部署后大量IP对全局路由表的冲击，导致路由效率降低的问题。
▲图二：Overlay网络融合架构
05
云原生容器网络流量模型分析
1)容器内部通信：一组后端业务Pod为一组前端业务Pod提供服务容器内Pod访问另一个Pod
容器内Pod访问一组Service
▲图三：容器内部通信流量模型
2)容器外部通信：容器与外部其他类型资源互访，外部业务访问一组容器提供的应用服务- 容器POD与集群外裸金属资源互访、容器POD与外部网络互访
▲图四：容器与外部资源通信流量模型
- 外部网络访问容器集群内一组Service时的入向负载均衡(创建外部LB，Pod直接挂到LB后端，无需Node上端口再做一层转发)
▲图五：外部访问容器集群流量模型
06
云原生SDN网络业务统一编排
除了通过对云原生容器网络架构层面进行设计，以实现控制平面的融合和数据平面的流量打通，还需要考虑云原生业务统一编排，以实现围绕容器整个生命周期的网络业务的自动化部署。
基本的网络业务编排流程如下：
从K8S为租户创建Pod
Kube监听，并向node创建
Kubelet执行Calico CNI ADD
Calico CNI为Pod创建端口、配置BGP网络，并将网络配置发给网络编排器NO
网络编排器NO收到配置指令，定义相应网络业务模型下发到SDN控制器
SDN控制器在指定交换机上配置Underlay与Overlay网络配置
网络编排器NO调用NFVM，为租户创建vLB、vFW资源
07
结语
大地云网Terra DC解决方案通过部署Terra FC SDN控制器和Terra NO网络编排器，实现对数据中心硬件/软件网络设备的管理和网络业务的编排，并结合Calico的CNI容器网络插件，可以实现上述云原生容器与物理网络的融合架构。
同时，大地云网Terra DC解决方案还包含vSwitch虚拟交换机产品，大地云网vSwitch可以为数据中心服务器的容器和虚拟机提供网络连接，支持如VXLAN EVPN的Overlay技术将数据中心内多个虚拟和物理VTEP之间的流量连接起来，保证容器、虚拟机和裸金属端到端连通性。
大地云网vSwitch同时可以为容器或虚拟机的工作负载提供本地数据交换。这种网络连接实现了服务器之间工作负载的完全移动性，并保留了相同的 IP 地址。同时通过集成优化虚拟交换机转发的DPDK技术，极大的提升了容器场景下的数据转发效率，为大流量应用平台提供了可靠稳定的网络转发平台。
▲ 大地云网Terra DC解决方案
大地云网Terra DC解决方案的优势
与数据中心现有网络架构融合度高，充分发挥出现有网络设备硬件性能和软件特性；
实现数据中心内多种类型的资源池(虚机、容器和裸金属)之间的相互隔离与互访；
为云原生业务打通容器集群内外部网络，实现Pod to Pod、Pod to Service、Pod to External、External to Pod等多种的网络流量模型；
结合数据中心现有负载均衡能力，直接将Pod挂在vLB后端，无需在Node上端口再做一层转发，大大提高网络效率；
使用SDN控制器和网络编排器实现云原生容器网络业务的统一编排。
扫一扫
585
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
