没有Docker还能玩转DevOps吗？

启迪云-解决方案部蒋运龙

网络链接

微服务架构成功的一个主要因素是实现所有组件如何相互通信，以及共享资源（如数据库或存储服务）。由于方法可能意味着容器及其工作负载不断被扩张，并且在某些时候缩容，因此确保每个容器都具有所需的网络连接，可能微服务一个巨大的挑战。

在容器部署中，容器可以运行在物理服务器群集上，也可以运行在这些服务器群集上运行的虚拟机（VM）实例上。主机都有自己的网络连接，需要将其映射到运行在它们之上的每个容器。这意味着分配IP地址，并使用安全策略来锁定数量巨大的容器实例。

提出了四种网络支持模式：桥接（）模式、主机（Host）模式、容器（）模式和无网络（None）模式。

Ø 桥接模式：是的默认网络模式，通过创建一个虚拟网络，链接主机及其外部网络端口上的所有容器。

Ø 主机（Host）模式：容器通过使用主机的 IP 和端口将容器链接到主机的网络堆栈，容器将不会获得一个独立的 ，而是和宿主机共用一个 。但是在其他方面， 如文件系统、进程列表等还是和宿主机隔离。

Ø 容器（）模式：重用现有容器的网络命名空间，即指定新创建的容器和已经存在的一个容器共享一个 ，而不是和宿主机共用一个 。

Ø 无网络（None）模式：为每个容器提供自己的网络堆栈， 容器拥有自己的 ，但不配置任何接口，也就是说，这个容器没有网卡、IP、路由等信息，但允许用户设置自己的自定义配置，如为容器添加网卡、配置 IP 等。

使用虚拟以太网桥实现容器间的网络互联，这意味着我们正在处理一种简单的软件定义网络（SDN）。如果运行独立的容器或所有容器仅在单个主机上运行，则此支持很好；但当大量应用程序可能需要在服务器群集上运行容器， 其中许多容器需要与在另一台主机上运行的容器通信。

这就是容器网络开始变得复杂的地方，因为一个容器需要知道其它容器的端口和IP地址，才能访问在其他主机上运行的那些容器。虽然IT工程师可以手动配置，但在环境中这样做太慢而且复杂。我们需要的是一些机制，可以在创建和部署容器时自动配置容器的网络接口。这种类型的自动化称为编排，因此容器的实际部署依赖于某种编排工具也就不足为奇了。

目前大多数企业已经确定采用作为编排工具。起源于谷歌，但现在是由云原生计算基金会（CNCF） 监管的开源项目。替代方案有 Swarm和 Mesos。

崛起的同时是还推广了容器网络接口（CNI），这是一个标准的应用程序编程接口（API），用于配置网络层。CNI实际上是由（开发了rokt容器的公司）开发的。虽然开发了自己的容器网络模型（CNM），但同时也支持CNI。

CNI基本上是一种插入网络服务的方法，它将处理IP地址管理（IPAM）等任务，并且在的环境下，应用定义的网络策略来管理容器组如何相互通信。

的NSX是一个支持CNI的平台，这是一个SDN系统，可以创建和管理在现有物理以太网基础设施上运行的多个虚拟网络，主要用作数据包转发背板来承载虚拟网络流量。这些虚拟网络可以各自具有自己的IP地址范围和其他特征。

NSX实际上有两种方式。初始的版本是为了与的虚拟机管理程序紧密集成，也称为NSX-V。第二个版本NSX-T已经开发用于与其他虚拟机管理程序一起运行，例如KVM（这是支持Linux和云框架的关键）。两个版本都可以充当虚拟交换机，直接处理在同一节点上运行的VM或容器之间的流量。如果目标是在不同节点上运行的VM或容器，则将虚拟网络数据包封装到标准以太网数据包中，并通过网络发送到在相关节点上运行的虚拟交换机。

其他平台具有类似的功能。自 2016以来，具有内置SDN功能，包括在每个节点上运行的Hyper-V网络虚拟化（HNV）以及从三个Hyper-V VM集群运行的网络控制器中央管理服务。

在中，网络服务提供了一个API，允许用户设置和定义网络连接。它包括一个服务器以及在服务器节点上运行的代理，其插件允许与Open ， ， 和Cisco的NX-OS以及的NSX等网络平台连接。 通过其服务支持和其他容器编排工具，而也符合CNI标准。

安全性是容器部署中的另一个重要因素，尤其是在以集群的规模运行容器。与物理网络一样，需要防火墙和其他安全策略来保护应用程序免受以某种方式设法进入基础架构的任何攻击。但是，在某些部署中，容器之间的流量通常根本不受保护。互连容器的虚拟网络的复杂性意味着，业务层或SDN层最好能够监控容器网络流量中发生的情况。

SDN供应商并没有忽略这一点。例如，正在推广NSX以保护基础架构，就像虚拟化网络一样。这是因为它有效地提供了在每个计算节点中运行的分布式防火墙，能够像从外部进入的数据包一样轻松地过滤基础设施内的流量。

轻量级软件

回到微服务，这个架构的一个关键特性是组件是轻量级的。通常实现单个功能，但多个组件链接在一起以提供完整的应用程序功能。这意味着容器中的代码需要能够发现其他可用服务，以及在虚拟网络上找到它们的位置。

有多种方法可以实现这一点，但最常见的方法之一是使用DNS服务器，通过名称而不是IP地址来定位服务。这允许更改IP地址，因为如果容器实例不断启动和停用，它们将会这样做。实际上，在 1.10版本中为此版本实现了嵌入式DNS，而在1.11也内嵌了这种方式。

另一个因素是负载均衡。微服务架构旨在通过生成另一个相同的实例来使应用程序横向扩展，但基础架构需要确保将流量路由到这些应用程序中的每个实例。在其kube-proxy模块中实现了一种基本形式的负载均衡，该模块执行将数据包循环转发到同一服务的副本。但这可能不够充分，企业可能需要使用其他基于软件的工具实现负载均衡，例如，NGINX或Istio。

尚未解决的复杂问题

因此，对容器的网络支持是个麻烦，随着基于容器的部署变得更加成熟普遍，它会变得更加复杂。因此许多企业正在转向现成的平台，这些平台集成了基于容器的基础架构所需的大部分或全部功能。其中包括支持Red Hat 等容器的平台即服务（PaaS），以及的 （PKS）等平台。后者包括NSX-T和，以及一个名为BOSH的工具，为整个平台提供监控和生命周期管理。

但是，PKS侧重于容器操作，并没有为开发人员工具提供太多帮助，而提供了开箱即用的持续集成支持。

无论您选择自己集成，还是选择可以消除大部分复杂性的现成的平台；可以在软件控制下配置和重新配置的网络，都将是任何容器和微服务架构的重要组成部分。

本文由启迪云解决方案部蒋运龙译，原文出自。