软件定义网络入门

软件定义网络 (SDN) 是一种动态、可管理、经济高效且适应性强的网络技术，适合当今应用的高带宽、动态特性。 通过使用 SDN 架构，IT 运营团队可以通过集中式面板控制复杂网络拓扑中的网络流量，而不是手动处理每个网络设备（例如路由器和交换机）。

快速增长的移动内容、服务器虚拟化和混合云服务是导致网络行业重新考虑网络架构的一些趋势。 传统的网络架构主要建立在分层拓扑中的多个网络交换机层上。 但是，在分层架构中，更难处理来自多个和混合基础设施（如云）的快速增长的应用程序工作负载。

许多公司都在积极采用 Linux 容器，因为它们是隔离进程的集合，可以处理 Linux 操作系统之上的意外增长的应用程序工作负载。 Linux 容器是一种二进制镜像文件，包含应用程序、运行时和依赖库，因此在从开发到测试并最终到生产的整个过程中，它既具有可移植性又具有一致性。 最终，Linux 容器使 IT 运营团队能够比传统的应用程序交付环境更快、更轻松地构建应用程序交付管道。

与此同时，企业非常关注如何隔离跨许多不同数据中心和云服务的多个应用程序容器的安全性并实现网络连接。 自 1.10 版本以来，Docker 容器提供了安全计算模式配置文件来删除权限； 默认设置还不错，但它们仍然留下容器可以执行的 270 个系统调用。 例如，如果在容器中启用 CAP_NET_ADMIN 以便向其路由表添加路由，那么如果您搜索足够长的时间，将有很多方法可以利用该系统。

使用 SDN 隔离 Linux 容器

相反，您可以使用 SDN 来处理 Linux 容器的网络隔离。

容器网络接口 (CNI) 是一个库定义和一组工具，用于通过许多支持的插件在 Linux 容器中配置网络接口。 CNI 项目隶属于 云原生计算基金会 (CNCF)。 多个插件可以同时运行在参与由不同插件驱动的网络的容器中。 网络以 JSON 格式写入配置文件，并在调用 CNI 插件时实例化为新命名空间。

许多流行的容器运行时，例如 Kubernetes、OpenShift、Cloud Foundry 和 Apache Mesos，正在使用 CNI 来定义网络插件和 Linux 上应用程序容器的容器执行之间的通用接口。 有很多方法可以实现 CNI，以下九个 CNI 插件（按字母顺序排列）通常用于在 Kubernetes 上实现网络连接功能。

• Calico 在 Kubernetes、Docker 和 OpenStack 等分布式架构上提供高可扩展性。

• Cilium 提供应用程序工作负载（例如应用程序容器和进程）之间的网络连接和负载平衡，并确保透明安全性。

• Contiv 基于容器网络，使用单一网络结构集成容器、虚拟化和物理服务器。

• Contrail 通过网络策略执行为多云和混合云提供覆盖网络。

• Flannel 使开发人员可以更轻松地为 Kubernetes 配置 Layer 3 网络结构。

• Multus 支持 Kubernetes 上单个 pod 中的多个网络接口，用于 SRIOV、SRIOV-DPDK、OVS-DPDK 和 VPP 工作负载。

• Open vSwitch (OVS) 在 OpenShift 和 OpenStack 上提供具有标准管理接口的生产级 CNI 平台。

• OVN-Kubernetes 使用覆盖功能为不同主机上的多个容器启用虚拟网络。

• Romana 使云网络功能的构建成本更低、操作更简单，并且比传统云网络性能更好。

一些 Linux 供应商为 Linux 容器提供网络隔离的功能和组件。 例如，Red Hat Enterprise Linux (RHEL) 提供网络命名空间，允许容器使用单独的虚拟网络堆栈、环回设备和进程空间。 您可以将虚拟或真实设备添加到容器，为其分配 IP 地址，甚至可以使用完整的 iptables 规则。

除了网络命名空间之外，SDN 还应通过提供具有多租户插件的多个命名空间之间的隔离来提高安全性。 这意味着默认情况下，来自一个命名空间的包对其他命名空间不可见，因此来自不同命名空间的容器无法向不同命名空间的 pod 和服务发送或接收包。 这些功能对于隔离开发人员、测试和生产网络非常有用。

结论

Linux 容器是用于在混合云中开发、部署和管理企业应用程序的最流行技术。 跨多个开发人员协调端口非常难以大规模完成，并且使用户面临他们无法控制的集群级别问题。 幸运的是，许多开源 CNI 项目正在发展或合并，因为企业开发人员需要消除容器化环境中的手动网络配置，而网络工程师已准备就绪（除非那些对工作保障有误解的人）。 选择上面列出的 CNI 插件之一，以获得更快、更轻松、更方便的动态端口分配、网络隔离和安全方法。