25、数据中心网络开放性与容器技术解析

最新推荐文章于 2025-08-24 02:03:26 发布

d6e7f8

最新推荐文章于 2025-08-24 02:03:26 发布

阅读量56

点赞数

CC 4.0 BY-SA版权

分类专栏：解读云数据中心网络架构与技术文章标签：数据中心网络 SDN 转发器开放性

本文链接：https://blog.youkuaiyun.com/d6e7f8/article/details/149967392

解读云数据中心网络架构与技术专栏收录该内容

30 篇文章 ¥499.90

订阅专栏¥69.90

会员秒杀 ¥9.9 重磅福利

超级会员免费看

数据中心网络开放性与容器技术解析

转发器的北向开放性

转发器的北向开放性指的是其与以下对象的互联开放性：
1. 网络控制器
- 作为软件定义网络（SDN）的核心组件，控制器负责管理物理和虚拟网络设备，并自动将网络服务配置推送给转发器。以与VMware NSX控制器的互联为例，NSX控制器部署在三台服务器上，作为NSX控制平面，管理NSX - vSwitches、边界路由器和硬件交换机的VXLAN配置。它包含API模块、交换机管理模块、逻辑网络管理模块和目录服务模块。
- DC交换机通过标准的OVSDB协议与VMware NSX控制器互联，并由该控制器管理。在华为SDN控制器和VMware NSX控制器的联合解决方案架构中，NSX控制器统一管理NSX - vSwitches、边缘服务网关（ESG）和CloudEngine交换机；DC交换机作为二层VXLAN网关，裸金属（BM）服务器通过DC交换机连接到VXLAN隧道；NSX - vSwitches作为二层VXLAN网关，虚拟机（VM）通过它连接到VXLAN隧道；ESG是实现VM和物理机（PM）之间三层通信的路由器。
2. 网络编排器
- 网络编排器作为SDN组件，实现对虚拟和物理网络的可视化运维（O&M）。以与VMware vRNI的互联为例，VMware vRNI对私有云、分支机构和公共云的网络服务进行统一管理、分析和故障定位。它可以管理和扩展VMware NSX控制器集群，设计、部署和提供VDS流量分析、NSX防火墙和微分段服务，还能分析VM之间的流量路径，以及分析和定位AWS VPC、安全组和防火墙策略中的故障。
- DC交换机通过SSH和SNMP接口将服务信息上传到VMware vRNI。其中，SSH接口用于上传设备的当前配置、路由表、MAC地址表、FIB表和QoS策略信息；SNMP接口用于上传收发数据统计、出入向丢包统计、系统错误信息和接口状态信息。
3. 云管理平台
- 云管理平台作为SDN组件，负责在云上部署、运行和管理虚拟和物理网络应用。以与Azure Stack的互联为例，Azure Stack是Microsoft Azure的扩展，在基础设施和平台层集成了混合云解决方案。基础设施层提供计算虚拟化、网络虚拟化、存储虚拟化管理、服务部署和运维，平台层支持企业服务在私有云和公共云之间的无缝部署和迁移。
- DC交换机支持Azure Stack所需的数据中心桥接（DCB）和远程直接内存访问（RoCE）协议，并可由Azure Stack解决方案管理。此外，DC交换机还能完成Azure Stack集群部署和运行所需的底层网络配置。
4. GitHub项目
- GitHub是开源和私有软件项目的托管平台。目前，针对CloudEngine交换机已经完成了多个GitHub开源项目，为与第三方应用集成提供了开放和标准化的接口。
- HuaweiSwitch/CloudEngine - Ansible ：基于Ansible框架，CloudEngine交换机开放了用于交换机管理和配置的基本Playbook库的源代码，包括AAA认证、ACL、BGP、DHCP、EVPN、NetStream、VRF和VXLAN等模块。
- HuaweiSwitch/Puppet ：基于Puppet框架，CloudEngine交换机提供了二层/三层接口、VLAN、CAR和Difserv、QoS、SSH和Telnet等开源模块。
- HuaweiSwitch/OVSDB ：基于Open vSwitch 2.5.0框架，CloudEngine交换机实现了五个子项目：ovsdb - server、ovsdb - client、ovs - pki、vtep - ctl和huaweiswitch - key。这些交换机可以由第三方控制器使用OVSDB进行管理。其中，ovsdb - server作为OVSDB的标准实现，存储控制器通过OVSDB通道发送的配置；ovsdb - client提供ovsdb - server和控制器之间的通道；ovs - pki、vtep - ctl和huaweiswitch - key是辅助工具，为控制器和CloudEngine交换机之间的交互提供密钥管理和OVSDB查询功能。

转发器互联开放性

转发器必须使用标准协议与第三方设备通信。目前，CloudEngine交换机已经通过了CTTL、IPv6 Ready和Tolly Lab认证，这证明这些交换机符合IETF标准，支持包括BGP、以太网、IPv4&IPv6、VXLAN、MPLS和FCoE等在内的2000多种标准协议。
1. CTTL认证 ：通过CTTL认证的CloudEngine交换机支持VXLAN、EVPN VXLAN、IPv6上的VXLAN和NetStream等数据中心特性，并可以使用OSPF和BGP与Cisco设备连接。
2. IPv6 Ready认证 ：CloudEngine交换机通过了IPv6 Ready认证，支持IPv6 RFC 1981、RFC 2460、RFC 2474、RFC 3168、RFC 4191、RFC 4291、RFC 4443、RFC 4861、RFC 4862和RFC 5095等标准，支持数据中心网络（DCN）向IPv6的平滑演进。
3. Tolly Lab认证 ：通过Tolly Lab认证的CloudEngine交换机支持标准的OpenFlow1.3协议，并可以使用OpenFlow协议与第三方控制器互联（测试中使用的是Ryu）。交换机支持VXLAN和NVGRE硬件网关，以及TRILL、EVN、FCoE、FCF、DCB、VS和ISSU等特性。

容器技术概述

容器技术是一种基于主机共享操作系统内核提供隔离操作系统环境的操作系统虚拟化技术。每个容器包含独立的文件系统命名空间（MNT NS）、主机和域名命名空间（UTS NS）、进程间通信命名空间（IPC NS）、进程ID命名空间（PID NS）、网络协议栈命名空间（NET NS）和用户命名空间（user NS）。容器通过虚拟网络接口卡（vNIC）挂载到虚拟交换机（vSwitch），vSwitch通过物理网络接口卡（pNIC）接入网络。

容器技术的发展分为两个阶段：独立容器和容器集群。在独立容器阶段，基于UNIX或Linux操作系统开发了多种操作系统隔离技术，为单个容器的虚拟化技术奠定了基础。主要的操作系统隔离技术包括：
1. chroot ：也称为chroot jail，于1979年在UNIX第7版中首次开发。它通过将进程及其子进程的根目录更改为特定的文件系统目录，为每个进程提供独立的文件系统空间，并限制进程及其子进程只能访问该特定目录。
2. FreeBSD jail ：由托管服务提供商R&D Associates于2000年开发，用于在共享的FreeBSD系统上为客户提供独立、干净的服务运行环境。它可以将基于FreeBSD的计算系统划分为多个相互隔离的独立迷你系统，每个系统具有独立的文件系统、普通用户、管理员和网络空间。
3. Solaris Containers ：也称为Solaris Zones，是Solaris系统上的独立虚拟服务器，支持x86和SPARC架构。每个Solaris容器有自己的主机名、vNIC或pNIC以及独立的存储空间。
4. Open Virtuozzo（OpenVZ） ：由Virtuozzo于2005年发布的开源容器平台，也称为VPS或虚拟环境。每个OpenVZ包含独立的文件系统、用户和用户组、进程树、网络设备和IPC对象。
5. Linux容器（LXC） ：基于开源Linux系统上的CGroup和Linux NameSpace的开源容器引擎。与基于UNIX的FreeBSD jail、Solaris Containers和OpenVZ不同，LXC基于Linux内核开发，易于在行业中推广。
6. Docker ：最初是dotCloud创始人Solomon Hykes发起的内部项目，于2013年开源。在Docker 0.9及更早版本中，使用LXC作为容器执行引擎；在Docker 0.9之后的版本中，使用Libcontainer作为执行引擎。基于Linux CGroup和命名空间技术，Docker提供容器镜像打包和管理以及容器生命周期管理。
7. Kubernetes ：由Google开发的开源容器编排系统，通过容器网络接口（CNI）为容器提供容器集群管理、容器集群扩展和主机间通信。目前由Linux基金会管理。
8. Docker Swarm ：由Docker于2014年发布的容器编排系统，提供Docker集群管理、容器集群扩展、服务发现、负载均衡和主机间容器网络通信等功能。与Kubernetes相比，Docker Swarm不能灵活支持用户定义的接口，开放性有限。
9. Mesos ：于2009年首次作为分布式集群管理平台发布，随着容器技术的发展，于2014年开始支持容器集群。Mesos比Kubernetes和Docker Swarm更大，适用于超大型集群系统（容器数量超过100,000个）。

由于容器比虚拟机更灵活、高效，软件应用正逐渐从虚拟机迁移到容器。容器集群技术具有诸多优势，如解决独立容器的单点故障问题，为大规模容器应用提供计算、存储和网络资源的统一编排能力，加速容器技术的发展。主要的容器平台包括Google的Kubernetes、Docker的Docker Swarm和美国加州大学伯克利分校的Mesos，其中Kubernetes经过多年发展已成为容器平台的事实上的标准。

行业主流容器网络解决方案

在典型的基于容器的Web、应用程序（apps）和数据库（DB）三层架构中，客户端通过URL访问前端负载均衡器（LB）集群，LB Pod集群根据服务类型进行七层负载均衡，并将请求转发到Web前端的服务集群。Web集群的Pod根据服务逻辑访问后端应用集群的Kubernetes服务，经过NAT和负载均衡后，实际服务流量转换为东西向流量在Pod之间直接交换。同样，应用集群的Pod访问数据库集群服务时，应用程序访问数据库服务，使用Kubernetes服务将NAT和LB服务流量转换为东西向流量在Pod之间交换。

根据上述服务场景，Kubernetes网络有以下典型要求：
1. 承载Pod之间东西向流量的网络必须可达，并且支持东西向负载均衡或NAT。
2. 支持服务和Pod之间的相互访问、南北向负载均衡，以及客户端对容器集群的访问。

为满足这些要求，Kubernetes社区定义了Kubernetes网络的三个原则：
1. 所有容器可以在不进行NAT的情况下与所有其他容器通信。
2. 所有节点可以在不进行NAT的情况下与所有容器通信（反之亦然）。
3. 容器自身看到的IP地址与其他容器看到的IP地址相同。

常见的开源容器网络解决方案包括Contiv、Calico、Flannel和华为CNI - Genie，可分为以下三种类型：
1. 主机覆盖解决方案
- 在主机覆盖解决方案架构中，物理服务器上的vSwitch作为Pod网关和VTEP连接到覆盖或底层网络。同一物理服务器上的Pod间流量由vSwitch直接转发，不同物理服务器上的Pod间流量通过vSwitch之间的VXLAN隧道转发。开源或容器平台供应商通过提供Kubernetes API服务器监听器和Kubernetes CNI插件来自动化容器覆盖网络的配置。
- Flannel是典型的主机覆盖解决方案，它本身不提供IP地址分配，需要第三方组件ETCD来实现。在控制平面，Flannel使用ETCD在每个节点上配置路由表；在数据平面，它使用隧道模式（如VXLAN和GRE）进行流量转发。Flannel在每个主机上运行一个名为Flanneld的守护进程，当主机加入集群时，Flanneld向ETCD申请一个IP子网，并获取其他主机的IP子网信息。
- Flannel以Pod为基本网络管理单元，即每个Pod分配一个IP地址，每个节点（主机或VM）分配一个子网。具体实现步骤如下：
- Kubernetes节点的Flannel将其信息（子网10.0.9.0/24和10.0.19.0/24）注册到ETCD。
- Kubernetes节点定期从ETCD查询网络信息，如果有子网添加，节点更新本地路由表中的子网和IP地址信息。
- 当Kubernetes容器需要访问子网10.0.19.0/24时，它发送目的地址为10.0.19.2的数据包，并根据本地路由表将数据包路由到本地VXLAN隧道进行封装和转发。目标Kubernetes节点接收到VXLAN封装的数据包后，解封装并根据本地路由表将其转发到目标Pod。
- Flannel主机覆盖解决方案实现了Kubernetes网络模型，允许Pod跨Kubernetes节点通信。但在高并发集群场景下大量数据传输时，vSwitch的转发能力可能会限制整体性能。可以通过部署基于Kubernetes开源架构的网络覆盖解决方案来消除这一瓶颈，该方案使用硬件交换机代替vSwitch进行VXLAN数据包的封装和解封装。
2. 网络覆盖二层桥接解决方案
- 在网络覆盖二层桥接解决方案架构中，网络结构中的硬件交换机作为Pod网关和VTEP，Pod通过VLAN连接到覆盖网络。同一物理服务器上的Pod间流量通过vSwitch交换，不同物理服务器上的Pod间流量通过三层的VXLAN转发。开源或容器平台供应商通过提供Kubernetes API服务器监听器和Kubernetes CNI插件来完成容器的服务器端网络配置。
- Contiv是典型的二层桥接解决方案，它包括部署在Kubernetes主节点上的Netmaster（Kubernetes API服务器监听器）和部署在Kubernetes节点上的Netplugins（Kubernetes CNI插件）。Netmaster监控Kubernetes API服务器，为Pod分配VLAN和IP地址，并将信息存储在ETCD中。每个Netplugin实现Kubernetes使用的CNI网络模型。Contiv使用JSON - RPC将端点信息从Netplugin分发到Netmaster，Netplugin处理Pod的Up/Down事件并配置vSwitch。
3. 网络覆盖三层路由解决方案
- 在网络覆盖三层路由解决方案架构中，物理服务器的vRouter上部署Pod网关，硬件交换机作为VTEP将物理服务器连接到覆盖网络。物理服务器使用EBGP将Pod路由通告到覆盖VRF。同一物理服务器上的Pod间流量通过vRouter交换，不同物理服务器上的Pod间流量通过三层的VXLAN转发。硬件交换机提供大量的VXLAN集成路由和桥接（IRB）路由，开源或PaaS供应商通过提供Kubernetes API服务器监听器和Kubernetes CNI插件来实现容器服务器上的Pod网络配置和路由配置。
- Calico是典型的开源三层路由解决方案，它包括Calico控制器、Felix和BGP客户端。Calico控制器（Kubernetes API服务器监听器）监控API服务器，检测服务、Pod和入口的事件，分配IP地址，并将IP地址存储在ETCD中。BGP客户端使用开源BGP项目中的bird Internet路由守护进程（BIRD）实现BGP，通过路由反射器（RR）通告本地Pod的路由，并学习其他Kubernetes节点上的Pod路由。vRouter基于Linux操作系统的路由功能实现。Felix作为Kubernetes CNI插件，部署在每个Kubernetes节点上，监听ETCD，检测Pod和服务的事件，创建Pod vNIC，为Pod配置IP地址，并更新Linux内核路由表和安全策略。

数据中心网络开放性与容器技术解析（续）

容器网络解决方案的技术细节与应用分析

为了更深入地理解不同容器网络解决方案的特点和应用场景，我们进一步分析它们的技术细节和实际应用中的表现。

主机覆盖解决方案的深入分析

Flannel作为主机覆盖解决方案的典型代表，其核心在于利用ETCD进行子网管理和路由配置。以下是Flannel在实际应用中的详细流程：
1. 节点加入集群 ：当一个新的Kubernetes节点加入集群时，Flanneld守护进程会向ETCD申请一个IP子网。例如，新节点可能获得子网10.0.20.0/24。
2. 子网信息同步 ：Flanneld会从ETCD获取其他节点的IP子网信息，更新本地的路由表。这样，每个节点都知道如何将数据包路由到其他节点上的Pod。
3. 流量转发 ：当一个Pod需要与另一个节点上的Pod通信时，它会根据本地路由表将数据包发送到本地的VXLAN隧道进行封装。封装后的数据包通过网络传输到目标节点，目标节点的Flanneld解封装数据包，并将其转发到目标Pod。

然而，Flannel在高并发场景下存在性能瓶颈。由于vSwitch的转发能力有限，大量数据传输时会导致网络延迟增加。为了解决这个问题，可以采用基于硬件交换机的网络覆盖解决方案。以下是一个简单的mermaid流程图，展示了Flannel的工作流程：

graph LR
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px

    A(新节点加入集群):::process --> B(Flanneld向ETCD申请子网):::process
    B --> C(Flanneld从ETCD获取其他节点子网信息):::process
    C --> D(更新本地路由表):::process
    E(Pod通信请求):::process --> F(根据路由表发送到本地VXLAN隧道):::process
    F --> G(数据包封装):::process
    G --> H(网络传输):::process
    H --> I(目标节点接收):::process
    I --> J(Flanneld解封装):::process
    J --> K(转发到目标Pod):::process

网络覆盖二层桥接解决方案的优势与挑战

Contiv作为网络覆盖二层桥接解决方案的代表，其优势在于易于部署和较高的转发性能。以下是Contiv的工作流程：
1. Netmaster监控 ：Netmaster部署在Kubernetes主节点上，监控Kubernetes API服务器。当有新的Pod创建或删除时，Netmaster会检测到这些事件。
2. 资源分配 ：Netmaster为新创建的Pod分配VLAN和IP地址，并将这些信息存储在ETCD中。
3. Netplugins配置 ：Netplugins部署在Kubernetes节点上，实现CNI网络模型。Netplugins从ETCD获取Pod的配置信息，处理Pod的Up/Down事件，并配置vSwitch。

Contiv的缺点是支持的部署规模有限。随着容器数量的增加，VLAN的数量也会增加，可能会导致网络管理变得复杂。以下是Contiv的工作流程列表：
1. Netmaster监控Kubernetes API服务器。
2. 检测Pod的创建或删除事件。
3. 为Pod分配VLAN和IP地址。
4. 将配置信息存储在ETCD中。
5. Netplugins从ETCD获取配置信息。
6. 处理Pod的Up/Down事件。
7. 配置vSwitch。

网络覆盖三层路由解决方案的高性能实现

Calico作为网络覆盖三层路由解决方案的代表，通过BGP协议实现高效的路由通告和学习。以下是Calico的工作流程：
1. Calico控制器监控 ：Calico控制器监控Kubernetes API服务器，检测服务、Pod和入口的事件。
2. IP地址分配 ：Calico控制器为Pod分配IP地址，并将这些信息存储在ETCD中。
3. BGP客户端工作 ：BGP客户端使用BIRD实现BGP协议，通过RR通告本地Pod的路由，并学习其他Kubernetes节点上的Pod路由。
4. Felix配置 ：Felix作为Kubernetes CNI插件，部署在每个Kubernetes节点上。Felix监听ETCD，检测Pod和服务的事件，创建Pod vNIC，为Pod配置IP地址，并更新Linux内核路由表和安全策略。

Calico的优点是转发性能高，适用于需要高性能网络的场景。以下是Calico的工作流程mermaid流程图：

graph LR
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px

    A(Calico控制器监控API服务器):::process --> B(检测服务、Pod和入口事件):::process
    B --> C(为Pod分配IP地址):::process
    C --> D(将IP地址存储在ETCD中):::process
    E(BGP客户端):::process --> F(使用BIRD实现BGP):::process
    F --> G(通过RR通告本地Pod路由):::process
    F --> H(学习其他节点Pod路由):::process
    I(Felix监听ETCD):::process --> J(检测Pod和服务事件):::process
    J --> K(创建Pod vNIC):::process
    K --> L(为Pod配置IP地址):::process
    L --> M(更新Linux内核路由表和安全策略):::process

容器技术的未来发展趋势

随着云计算和大数据的发展，容器技术将在未来发挥更加重要的作用。以下是容器技术的一些未来发展趋势：
1. 与人工智能的融合 ：容器技术可以为人工智能模型的训练和部署提供高效的环境。通过容器化，可以实现人工智能模型的快速部署和资源隔离，提高训练和推理的效率。
2. 安全性能的提升 ：随着容器技术的广泛应用，安全问题变得越来越重要。未来，容器技术将加强安全性能，包括容器镜像的安全、容器运行时的安全和网络安全等方面。
3. 跨云平台的支持 ：企业越来越倾向于使用多个云平台来满足不同的业务需求。容器技术将支持跨云平台的部署和管理，实现企业应用在不同云平台之间的无缝迁移。
4. 自动化运维的增强 ：容器技术将与自动化运维工具深度集成，实现容器集群的自动化部署、监控和扩展。通过自动化运维，可以提高容器集群的可靠性和效率。

总结

本文详细介绍了数据中心网络转发器的北向开放性和互联开放性，以及容器技术的概述和行业主流容器网络解决方案。转发器的开放性使得它可以与网络控制器、网络编排器、云管理平台和GitHub项目等进行互联，为数据中心网络的集成和管理提供了便利。容器技术作为一种新兴的虚拟化技术，具有灵活、高效的特点，正逐渐成为软件应用部署的首选方案。不同的容器网络解决方案适用于不同的应用场景，企业可以根据自身的需求选择合适的解决方案。未来，容器技术将与人工智能、安全、跨云平台和自动化运维等领域深度融合，为企业的数字化转型提供更强大的支持。

通过对容器网络解决方案的深入分析，我们可以看到每种方案都有其优缺点。在实际应用中，企业需要根据自身的业务需求、网络规模和性能要求等因素，综合考虑选择合适的容器网络解决方案。同时，随着技术的不断发展，容器技术和数据中心网络也将不断创新和完善，为企业带来更多的机遇和挑战。