SDN 介绍

最新推荐文章于 2024-09-03 15:39:58 发布

老哥776

最新推荐文章于 2024-09-03 15:39:58 发布

阅读量2.1k

点赞数 25

文章标签：云计算 kubernetes 云原生

本文链接：https://blog.csdn.net/qq_42944740/article/details/136697712

版权

SDN 定义

核心本质

传统网络中的路由器也存在控制平面和转发平面，高级路由器或交换机还采用物理分离，主控板上的 CPU 不负责报文转发，专注于系统的控制；而业务板则专注于数据报文转发。所以路由器或交换机内的控制平面与转发平面相对独立又协同工作，如图所示：

这种分离是封闭在被称为“盒子”的交换机或路由器上，不可编程；另一方面，从IP网络的维度来考虑，采用的是分布式控制的方式：在控制面，每台路由器彼此学习路由信息，建立各自的路由转发表；在数据面，每台路由器收到一个IP包后，根据自己的路由转发表做IP转发；IP网络的这种工作方式带来了运维成本高、业务上线慢等问题。

传统的网络架构已经无法继续演进和发展，因此在 2006 年，由美国斯坦福大学提出了 OpenFlow（一种网络通信协议，用于 SDN 架构中控制器和转发器之间的通信）的概念用于校园网络的试验创新，后续基于 OpenFlow 给网络带来可编程的特性，SDN（Software Defined Network）的概念应运而生。全称为 Software Defined Network，中文解释为软件定义网络， SDN 将原来封闭在“盒子”的控制平面抽取出来形成一个网络部件，称之为SDN 控制器，这个控制器完全由软件来实现，控制网络中的所有设备，如同网络的大脑，而原来的“盒子”只需要听从 SDN 控制器的命令进行转发。盒子与 SDN 控制器直接通过 OpenFlow 网络协议进行通信。

SDN 有以下 3 个特征：

转控分离：控制器上的网元控制平面负责协议计算，生成流表；转发平面仅在网络设备上
集中控制：设备网元通过控制器集中管理和发布流表，转发平面仅在网络设备上
开发接口：通过编程定义新的网络功能，在控制器上作为网元运行，第三方只需调用控制器提供的开放接口

路线分类

随着SDN在产业界设备制造商和运营商的实践不断展开，SDN的概念不断模糊，任何允许软件对网络可以进行编程或者配置的网络架构都被称为 SDN，并且具体实现的技术和接口协议是各种各样的。面向应用层的北向接口虽然没有统一的标准，但使用的是标准的 RESTful 风格接口，还是有统一的格式。其差异主要体现在南向接口的网络协议上。

首先，采用 OpenFlow 标准，转控分离、集中控制，主张硬件标准化，控制上移到由软件实现的控制器上，打破原有网络的封闭状态，受到初创公司和学院科研单位的欢迎，可以看作为革命型或狭义 SDN。

其次，设备提供商感受到压力，希望在市场继续保持优势，另一方面，运营商即想拥抱新理念，也想保护现有的投资，希望针对现有网络进行平滑的过渡，所以采取大多不动设备上的控制智能，控制器（只能说是一种伪控制器）与转发设备间的接口采用 NETCONF/SNMP 协议，提出更为广泛的 SDN 架构，可以看作演进型或广义 SDN。

最后，还有一种发展路线，它以现有IP网络为基础设施，在其上建立叠加的逻辑网络，实现网络资源的虚拟化，本质上属于软件定义的虚拟网络。这一思路被称为 Overlay 方案。

SDN 架构

SDN 典型架构

ONF（开放网络基金会）定义的 SDN 的典型架构包括三层：应用层、控制层和基础设施层，这些层使用北向和南向应用编程接口 (API) 进行通信。其中，应用层聚焦网络业务逻辑开发，负责资源编排；控制器层进行全局网络的管理；基础设施层为各种网络设备，负责数据的转发。

应用层（Application）指商业应用，开发者可以通过 SDN 控制器提供的北向接口实现应用和网络的联动，例如网络拓扑的可视化、监控等。
北向接口（Northbound Interface），北向接口是通过上层应用开放的接口，其目标是使得应用能够便利地调用底层的网络资源和能力。因为北向接口是直接为应用服务的，其设计需要密切联系应用的业务需求，比如从用户、运营商或产品的角度去考量，因此目前还缺少业界公认的北向接口的标准，对于上层的应用开发者来说，RESTful API 是比较乐于采用的北向接口形式
控制层（Control Layer）网路转发的控制管理平面，负责管理网络的基础设施，主要组成部分为 SDN 控制器。SDN 控制器是整个网络的大脑、控制中心，主要是按照配置的业务落户，产生对应的数据平面的流转发规则，则通过下发给网络设备，控制器进行数据转发。
南向接口（Sorthbound Interface），SDN 控制器对网络的控制主要通过 OpenFlow 南向接口的实现，包括链路发现、拓扑管理、策略指定、表项下发等。其中，链路发现和拓扑管理主要是控制其南向接口的上行通道对底层交换设备进行统一的监控和统计，而策略指定和表项下发则是利用南向接口的下行通道对网络设备进行统一的控制。
基础设施层（Infrastructure Layer）：主要承担数据转发功能，由各种网络设备构成，如数据中心的网络路由器，支持 OpenFlow 的硬件交换机等。

SDN 实现框架

学术界提出的正统 SDN，在产业界和运营商的不断实践下，南向接口不仅仅局限在 OpenFlow，也包含了NETCONF、SNMP 等协议。SDN 不同的发展路线决定了 SDN 开发技术架构如图所示：

不同类型 SDN 的区别主要体现在控制器和南向接口上，控制器层进行全局网络的管理，南向接口负责控制器与数据平面的通信，可以理解成数据平面的编程接口，直接决定了 SDN 架构的可编程能力。

目前主流的开源SDN控制器包括：

OpenDaylight 控制器：现今最具影响力、使用度最高的控制器项目，现在大多数商用控制器是在此基础上进行创造的，它拥有大量的子项目，而且在商业范围内已经应用，带来了非常好的效果。
ONOS 控制器：ONOS（Open Network Operating System，开放网络操作系统）是一个分布式 SDN 操作系统，它是专门面向服务提供商的，该控制器能够实现集群的思想，并且能够扩展其他功能，可用性也非常高，使得服务提供商能轻松地采用模块化结构来开发应用提供服务。
Floodlight 控制器：Floodlight 控制器被创造的时间相对来说更早，并且得到广大群众的支持，它是一款开源的控制器。它能够对网络实现搜寻以及管理的功能集，同时该控制器上存在应用集，它可以实现每个用户所想达到的目的。
Ryu 控制器：Ryu 是一个基于组件的SDN网络框架，它是由日本 NTT 公司使用 Python 语言研发完成的开源软件，采用 Apache License 标准。Ryu 提供了包含良好定义的API接口的网络组件，通过这些接口可以轻易的实现对新网络形成之后的维护工作。Ryu支持管理网络设置的多种协议。
NOX 控制器：NOX 控制器作为第一个支持 OpenFlow 的控制器，是在2008年由斯坦福大学提出，NOX 控制器是第一个实现的 SDN 控制器，它先前的版本(NOX-Classic)通过C++以及Python语言来完成，其中 NOX 核心架构及其关键部分都是使用 C++ 实现的。
POX 控制器：POX 控制器是由 NQX 控制器分割演变出来的一款基于 OpenFlow 控制器，POX 控制器能够对协议包进行传送，把交换机发送的协议包传给制定软件模块。
OneContrller 控制器：OneContrller 控制器是Extreme公司在开源控制器 Open Daylight 的 Helium SR1.1 版本基础上创建的。OneContrller 控制器目的在于创建了一个开放、功能灵活加载或卸载、可拓展的平台，使得 SDN 和 NFV 的规则可以无限制的进行规模的控制

目前主流的南向接口协议包括：

OpenFlow：第一个开放的南向接口协议，也是目前最流行的协议。它提出了控制与转发分离的架构，规定了SDN 转发设备的基本组件和功能要求，以及与控制器通信的协议。
OF-Config：提供开放接口用于控制和配置 OpenFlow 交换机，但不影响流表的内容和数据转发行为。OF-CONFIG 在 OpenFlow 架构上增加了一个被称作 OpenFlow Configuration Point 的配置节点。这个节点既可以是控制器上的一个软件进程，也可以是传统的网管设备。OF-Config 基于 NETCONF 与设备通信。
P4：协议无关的数据包处理编程语言，提供了比 OpenFlow 更出色的编程能力。它不仅可以指导数据流进行转发，还可以对交换机等转发设备的数据处理流程进行软件编程定义。
OVSDB：Open vSwitch 数据库协议。
NET-CONF：用于替代 CLI、SNMP 等配置交换机。
OpFlex：思科 ACI 使用的一种声明式南向接口协议。

SDN 优势

控制面与转发面分离：使得转发面设备可以采用不同的硬件来实现，也可以采用不同厂家的设备来实现，只要转发面与控制面的接口一致，就可以实现一致的转发能力，转控分离使得组网更加灵活。
集中配置、高效维护：通过SDN控制器可以集中预先设计与规划好网络，然后把相关的命令集中下发到转发面，就可以快速实现网的配置。集中配置可以减少维护人员，提高工作效率。
灵活、快速调整网络：通过SDN控制器可以快速重新配置网络，对网络的架构进行灵活的调整。
网络透明度高：SDN控制器作为网络的集中管理点，对网络的整体架构控制力很强，可以看到网络的全貌，便于在网络面进行整体设计与优化，提高整体的网络性能与网络透明度，也可提高了网络故障定位能力。
5G网络中，SDN优势更加明显：5G网络中引入了网络切片，网络切片是在物理网络中构建的虚拟化的网络，通过SDN进行切片网络的灵活调整，可以满足行业用户的差异化，快速组络需求，发挥5G切片的优势。
可扩展性：SDN网络架构中的中央控制器可以管理整个网络，从而提供了更高的可扩展性。管理员可以通过添加新的网络设备或修改控制器程序来扩展网络，而无需对整个网络进行重构。
高性能和可靠性：SDN网络可以使用高性能交换机和路由器进行数据传输，同时通过中央控制器进行优化和调整，从而提高了网络的性能和可靠性。此外，SDN网络架构中的控制器可以监控和管理整个网络，及时发现和解决故障，从而提高了网络的可靠性。
安全性：SDN网络可以通过集中式的安全策略管理和控制，实现对网络流量的深度检查和过滤，从而提高了网络的安全性。此外，SDN网络的可编程性也使得管理员可以很容易地实现新的安全策略和应对新的安全威胁。
成本更低：由于SDN采用虚拟化网络服务，大大降低了对硬件层面的依赖，可以有效节约基础设施成本，降低企业运营支出，提高对已有资源的使用效率，改善网络管理效果。

K8S 中的 SDN 网络方案

K8S 场景下实现 Pod 互联等的 SDN 容器网络主要以 OpenShift-SDN 及 Neutron 等为典型代表的二层 SDN/OVS模型的实现

二层SDN/OVS模型：这类模式的转发面是指采用 OVS 设计与实现 Overlay 二层和流表流水线，支持与各种Underlay 模式的对接，可扩展实现 DVR、广播抑制特性等。这是当前比较典型和成熟的转发面 SDN 模式方案；三层采用网络名字空间的 Linux 路由器；安全策略以及 NAT 功能采用 Netfilter/IPtables 实现。

基于这种参考架构实现的方案的优点是兼容了传统网络二层交换、三层路由、策略控制，可以通过 VLAN 实现多租户隔离；可以采用典型的 SDN 套路对容器网络的访问做到细粒度控制；Overlay 与 Underlay 的解耦设计，具备良好的混合云、公有云的互联能力；逻辑结构清晰，可适应不同场景和规模的网络方案；有成熟的开发部署运维实践经验，稳定性经过生产环境验证。

K8S 的 SDN 控制器的部署首先是创建 SDN 控制器和节点代理及 CNI-Plugin 部署和运行所需的服务账号、角色和角色绑定。定义角色的访问对象涉及哪些资源以及相应许可的操作。定义访问的主体，即服务账号，在特定名字空间中对相应角色、对象的访问授权；然后以 Deployment 的方式在主节点上部署 SDN 控制器，可采用ConfigMap 实现 SDN 控制器的相关配置管理；在每个集群工作节点上以 DaemonSet 的方式部署 SDN 代理，其中的 CNI-Plugin 安装脚本容器负责在部署时安装 CNI-Plugin 插件和相应的网络配置等；以及通过 CRD 机制扩展相关的资源对象管理，实现相应的定制控制器进行 K8S 与 SDN 间的封装、对接、适配。

Openshift-SDN

Openshift-SDN 是红帽推出的一款容器集群网络方案。一直集成于 OpenShift 平台中。但红帽将项目代码进行了开源。Openshift-SDN 依赖于 OpenvSwitch 技术，也就是虚拟交换机。

详解 Openshift-SDN，这篇文章说是能够从源码中还原出部署的过程，但是好像也没有详细介绍如何将 Openshift-SDN 组件部署到集群中的

Neutron（kuryr-kubernetes）

Kubernetes Kuryr 是 OpenStack Neutron 的子项目，该项目在 Kubernetes 中实作了原生 Neutron-based 的网络，将 Openstack Neutron 集成到 K8S 网络

为了将 Openstack Neutron 集成到 K8S 网络，引入了两个组件：控制器和 CNI 驱动程序。Controller 是一个管理组件，负责维护将网络相关的 Kubernetes 模型转换为 OpenStack（即 Neutron）模型。这可以被认为是一种集中式服务（未来支持HA模式）。CNI 驱动程序负责将工作节点上的 Kubernetes pod 绑定到 Neutron 端口，以确保所要求的隔离级别。

Kube-OVN

OVS 是一个单机的虚拟网络交换机，同时支持 OpenFlow，可以实现复杂的网络流量编程，这也是网络虚拟化的基础。通过 OVS 和 OpenFlow 可以实现细粒度的流量控制。如果做个类比，OVS 相当于网络虚拟化里的 Docker。

OVS 只是个单机程序，想生成一个集群规模的虚拟网络就需要一个控制器，这就是 OVN。OVN 和 OVS 的关系就好比 Kubernetes 和 Docker 的关系。OVN 会将高层次的网络抽象转换成具体的网络配置和流表，下发到各个节点的 OVS 上，实现集群网络的管理。

借助 OVS/OVN 在 SDN 领域成熟的能力，Kube-OVN 将网络虚拟化的丰富功能带入云原生领域。目前已支持子网管理，静态 IP 分配，分布式/集中式网关，Underlay/Overlay 混合网络，VPC 多租户网络，跨集群互联网络，QoS 管理，多网卡管理，ACL 网络控制，流量镜像，ARM 支持，Windows 支持等诸多功能。

Kube-OVN 的组件可以大致分为三类：

上游 OVN/OVS 组件

该类型组件来自 OVN/OVS 社区，并针对 Kube-OVN 的使用场景做了特定修改，Kube-OVN 使用 OVN 的北向接口创建和调整虚拟网络，并将其中的网络概念映射到 Kubernetes 之内。所有 OVN/OVS 相关组件都已打包成对应镜像，并可在 Kubernetes 中运行。
Ovn-central Deployment 运行 OVN 的管理平面组件，包括 ovn-nb, ovn-sb, 和 ovn-northd

ovn-nb：保存虚拟网络配置，并提供 API 进行虚拟网络管理。kube-ovn-controller 将会主要和 ovn-nb 进行交互配置虚拟网络。
ovn-sb：保存从 ovn-nb 的逻辑网络生成的逻辑流表，以及各个节点的实际物理网络状态。
ovn-northd：将 ovn-nb 的虚拟网络翻译成 ovn-sb 中的逻辑流表。
多个 ovn-central 实例会通过 Raft 协议同步数据保证高可用。

ovs-ovn

ovs-ovn 以 DaemonSet 形式运行在每个节点，在 Pod 内运行了 openvswitch, ovsdb, 和 ovn-controller。这些组件作为 ovn-central 的 Agent 将逻辑流表翻译成真实的网络配置。

核心控制器和 Agent

该部分为 Kube-OVN 的核心组件，作为 OVN 和 Kubernetes 之间的一个桥梁，将两个系统打通并将网络概念进行相互转换。大部分的核心功能都在该部分组件中实现。
kube-ovn-controller

该组件为一个 Deployment 执行所有 Kubernetes 内资源到 OVN 资源的翻译工作，其作用相当于整个 Kube-OVN 系统的控制平面。 kube-ovn-controller 监听了所有和网络功能相关资源的事件，并根据资源变化情况更新 OVN 内的逻辑网络。主要监听的资源包括： Pod，Service，Endpoint，Node，NetworkPolicy，VPC，Subnet，Vlan，ProviderNetwork。
以 Pod 事件为例， kube-ovn-controller 监听到 Pod 创建事件后，通过内置的内存 IPAM 功能分配地址，并调用 ovn-central 创建逻辑端口，静态路由和可能的 ACL 规则。接下来 kube-ovn-controller 将分配到的地址，和子网信息例如 CIDR，网关，路由等信息写会到 Pod 的 annotation 中。该 annotation 后续会被 kube-ovn-cni 读取用来配置本地网络。

kube-ovn-cni

该组件为一个 DaemonSet 运行在每个节点上，实现 CNI 接口，并操作本地的 OVS 配置单机网络。
该 DaemonSet 会复制 kube-ovn 二进制文件到每台机器，作为 kubelet 和 kube-ovn-cni 之间的交互工具，将相应 CNI 请求发送给 kube-ovn-cni 执行。该二进制文件默认会被复制到 /opt/cni/bin 目录下。
kube-ovn-cni 会配置具体的网络来执行相应流量操作，主要工作包括：
配置 ovn-controller 和 vswitchd。
处理 CNI add/del 请求：