如何进行容器SDN技术与微服务架构实践

67次阅读

共计 7298 个字符，预计需要花费 19 分钟才能阅读完成。

这期内容当中丸趣 TV 小编将会给大家带来有关如何进行容器 SDN 技术与微服务架构实践，文章内容丰富且以专业的角度为大家分析和叙述，阅读完这篇文章希望大家可以有所收获。

关于 SDN 和容器

作为近年来比较热的一个概念，众所周知 SDN 是 Software Defined Network 的缩写，即软件定义网络。但不同的人对 SDN 有不同的理解。在广义上，只要是你通过软件实现了一个东西，然后那个东西能够灵活地去达到网络上面的部署和伸缩，这就可以被认为是 SDN。在后文中会对 Flannel、Calico、Weave 这三个解决方案进行分析，并从控制层和转发层来着重探讨它们的技术实现，虽然它们并没有宣称自己是 SDN 的解决方案。

由于容器技术给传统的虚拟化网络提出了一些新的挑战，所以围绕 Docker 产生了很多不同的网络解决方案，以弥补 Docker 在这些方面的不足。

围绕容器的开源的 SDN 解决方案

Docker 自己的网络方案比较简单，就是每个宿主机上会跑一个非常纯粹的 Linux Bridge，这个 Bridge 可以认为是一个二层的交换机，但它的能力有限，只能做一些简单的学习和转发。然后出来的流量，出网桥的流量会走 IPTABLES，做 NAT 的地址转换，然后靠路由转发去做一个宿主之间的通信。但是当真正用它的网络模型部署一个比较复杂的业务时，会存在很多问题，比如容器重启之后 IP 就变了；或者是由于每台宿主机会分配固定的网段，因此同一个容器迁到不同宿主机时，它的 IP 可能会发生变化，因为它是在不同的网段；同时，NAT 的存在会造成两端在通讯时看到对方的地址是不真实的，因为它被 NAT 过；并且 NAT 本身也是有性能损耗等。这些问题都对使用 Docker 自己的网络方案造成了障碍。

Flannel

图 1

Flannel 是 CoreOS 团队针对 Kubernetes 设计的一个覆盖网络（Overlay Network）工具，如图 1 所示。它们的控制平面其实很简单，如图 2 所示。

图 2

每个机器上面的 Flannel 进程会监听 ETCD，向 ETCD 申请每个节点可用的 IP 地址段，并且从 ETCD 拿到其他所有宿主机的网段信息，这样它就可以做一些路由。对于它的转发平面（图 3）——转发平面主要表现数据流的流向——它在 Docker 进来的网桥基础之上，又创建了一个新的叫 VXLAN 的设备（图 4），VXLAN 是一个隧道的方案，它可以把一个二层的包，前面加一个包头，然后再把整个包作为物理网络的一个包，去物理网络里面去路由，流转。

图 3

图 4

为什么会要有这个东西呢？因为通常虚拟网络的 IP 和 MAC 在物理的网络其实是不认识的。因为识别 IP 需要物理网络支持，这个其实是个隧道的方案。

总结一下 Flannel 方案，可以看出它并没有实现隔离，并且它也是按照网段做 IP 分配，即一个容器从一台主机迁到另外一台主机的时候，它的地址一定会变化。

Calico

图 5

Calico 的思路比较新，如图 5 所示。它把每个操作系统的协议栈认为是一个路由器，然后把所有的容器认为是连在这个路由器上的网络终端，在路由器之间跑标准的路由协议——BGP 的协议，然后让它们自己去学习这个网络拓扑该如何转发。所以 Calico 方案其实是一个纯三层的方案，也就是说让每台机器的协议栈的三层去确保两个容器，跨主机容器之间的三层连通性。对于控制平面（图 6），它每个节点上会运行两个主要的程序，一个是它自己的叫 Felix，左边那个，它会监听 ECTD 中心的存储，从它获取事件，比如说用户在这台机器上加了一个 IP，或者是分配了一个容器等。接着会在这台机器上创建出一个容器，并将其网卡、IP、MAC 都设置好，然后在内核的路由表里面写一条，注明这个 IP 应该到这张网卡。绿色部分是一个标准的路由程序，它会从内核里面获取哪一些 IP 的路由发生了变化，然后通过标准 BGP 的路由协议扩散到整个其他的宿主机上，让外界都知道这个 IP 在这里，你们路由的时候得到这里来。

图 6

关于 Calico 这里讨论一个问题，因为它跑的是纯三层的协议，所以其实它对物理架构有一定的侵入性。Calico 官方称，你可以跑在一个大二层的网络里面。所谓大二层就是没有任何三层的网关，所有的机器、宿主机、物理机在二层是可达的。这个方案其实有一定的弊端，事实上在很多有经验的网络工程师眼里，一个大二层其实是一个单一的故障率，也就是说任何一个都会有一定的硬件风险会让整个大二层瘫痪。

另外，Calico 跑在了一个三层网关的物理网络上时，它需要把所有机器上的路由协议和整个物理网络里面的路由器的三层路全部用 BGP 打通。这其实会带来一个问题，这里的容器数量可能是成千上万的，然后你让所有物理的路由学习到这些知识，其实会给物理集群里的 BGP 路由带来一定的压力，这个压力我虽然没有测过，但据专业的网络工程师告知，当网络端点数达到足够大的时候，它自我学习和发现拓扑以及收敛的过程是需要很多的资源和时间的。

转发平面（图 7）是 Calico 的优点。因为它是纯三层的转发，中间没有任何的 NAT，没有任何的 overlay，所以它的转发效率可能是所有方案中最高的，因为它的包直接走原生 TCP/IP 的协议栈，它的隔离也因为这个栈而变得好做。因为 TCP/IP 的协议栈提供了一整套的防火墙的规则，所以它可以通过 IPTABLES 的规则达到比较复杂的隔离逻辑。

图 7

Weave

图 8

Weave 方案比较有趣，如图 8 所示。首先它会在每台机器上跑一个自己写的 Router 程序起到路由器的作用，然后在路由器之间建立一个全打通的 PC 连接，接着在这张 TCP 的连接网里面互相跑路由协议，形成一个控制平面（图 9）。可以看出，它的控制平面和 Calico 一致，而转发平面（图 10）则是走隧道的，这一点和 Flannel 一致，所以 Weave 被认为是结合了 Flannel 和 Calico 这两个方案的特点。

图 9

图 10

图 11 所示是它的服务发现与负载均衡的一个简单的方案，它在每个容器会起两个网卡，一个网卡连着自己起的可以跟其他宿主机联通的网桥；另一个网卡绑在原生 Docker 的一个网桥上，并在这个网桥上监听一个 DNS 的服务，这个 DNS 实际上嵌在 Router 里面，即它可以从 Router 里学习到一些服务的后端的一些配置。所以这时容器如果发起 DNS 查询，实际上会被路由导到宿主机上，DNS Server 上，然后 DNS server 做一些响应。它们官方负载均衡也是靠这个，但是这其实是一个短板，因为我们更偏向于四层或者是七层更精细的负载均衡。

在隔离方面，Weave 的方案比较粗糙，只是子网级的隔离（图 12）。比如说有两个容器都处在 10.0.1-24 网段，那么它会在所有的容器里面加一条路由说该网段会走左边的网桥出去，但是所有非此网段的流量会走 Docker0，这个时候 Docker0 和其他是不联通的，所以它就达到一个隔离的效果。

图 11

图 12

三个方案总结

总结一下：

1. Flannel 仅仅作为单租户的容器互联方案还是很不错的，但需要额外的组件去实现更高级的功能，例如服务发现与负载均衡。

2. Calico 有着良好的性能和隔离策略，但其基于三层转发的原理对物理架构可能会有一定的要求和侵入性。

3. Weave 自带 DNS，一定程度上能解决服务发现，但因隔离功能有限，若作为多租户的联通方案还稍加欠缺。

4. 另外，Calico 和 Weave 都使用了路由协议作为控制面，而自主路由学习在大规模网络端点下的表现其实是未经验证的，曾咨询过相关的网络工程师，大规模端点的拓扑计算和收敛往往需要一定的时间和计算资源。

七牛的具体实践

业务需求

七牛实际上一直在拥抱容器带来的变革，拥抱新型的微服务架构理念。所以构建了一套容器平台，这么做的目的，一方面想推进通过将已有业务容器化简化研发和上线流程，另一方面也想通过这个方式去满足用户的一些计算需求，毕竟计算和数据离得越近越好。

所以我们业务上对网络的需求是：

1. 首先一点，是能够运行在底层异构的基础网络上，这一点对于推进已有业务的容器化来说是很重要的，否则会涉及到基础网络的大规模变更，这是无法接受的。

2. 我们试图构造一个对容器迁移友好的网络结构，允许容器在必要情况下发生调度。

3. 我们认为服务发现和负载均衡对业务来说是个基础而普适的需求，尤其是在倡导微服务架构的今天，一个设计良好的组件应该是可水平伸缩的，因此对于组件的调用方，服务发现和负载均衡是非常必要的功能。当然有人会说这个功能和网络层无关，而应由应用层去实现，这个说法挺有道理，但后面我会讲到由网络层直接支持这两个功能的好处。

4. 为了满足七牛本身已有的一些对隔离有要求的服务，并满足上层更丰富的权限模型和业务逻辑，我们试图将隔离性做的更加灵活。

在这几个需求的驱动下，我们最终尝试跳出传统网络模型的束缚，尝试去构造一个更加扁平而受控的网络结构。

转发平面

首先，在转发层面，为了包容异构的基础网络，我们选择了使用 Open vSwitch 构造 L2 overlay 模型，通过在 OVS 之间联通 vxlan 隧道来实现虚拟网络的二层互通。如图 13 所示。但隧道通常是有计算成本的，隧道需要对虚拟二层帧进行频繁解封包动作，而通用的 cpu 其实并不擅长这些。我们通过将 vxlan 的计算量 offload 到硬件网卡上，从而将一张万兆网卡的带宽利用率从 40% 提升到 95% 左右。

选择 overlay 的另一个理由是，据我们目前所了解到，当下硬件的设备厂商在对 SDN 的支持上通常更偏向于 overlay 模型。

图 13

控制平面

而在控制层面，我们思考了容器和传统虚机的一些不同：

前面提到，微服务架构下，每个容器的职责相对虚机来说更加细化和固定，而这会造成容器与容器间的依赖关系也相对固定。那么每台宿主机上的容器可能产生的 outbound 其实也是可推演的。如果进一步想的话，其实推演出来的理论范围通常会远大于容器实际产生的 outbound。所以我们尝试使用被动的方式实现控制指令的注入。因此我们引入了 OpenFlow 作为控制面的协议。OpenFlow 作为目前 SDN 控制平面的协议标准，它有着很强的表达能力。从包匹配的角度看，它几乎可匹配包头中的任意字段，并支持多种流老化策略。此外，扩展性也很好，支持第三方的 Vendor 协议，可以实现标准协议中无法提供的功能 OpenFlow 可以按 Table 组织流表，并可在表间跳转（这一点其实和 IPTABLES 很像，但 OpenFlow 的语义会更加丰富）。配合 OpenFlow 的这种 Table 组织方式，可以实现相对复杂的处理逻辑。如图 14 所示。

图 14

选择了 OpenFlow，我们的控制平面会显得很中规中矩，也就是逻辑上的集中式控制，没有 weave/calico 的 P2P 那么炫酷。在这样的结构下，当 ovs 遇到未知报文时，会主动提交包信息给 Controller，Controller 会根据包信息判断后，给 ovs 下发合适的流表规则。为了实现负载均衡和高可用，我们给每组 ovs 配置多个 Controller。如图 15 所示。

例如:

1. 对于非法流量 Controller 会让 ovs 简单丢弃，并在将来一段时间内不要再询问。

2. 对于合法流量，Controller 会告诉 ovs 如何路由这个包并最终到达正确的目的地。

图 15

服务发现和负载均衡

关于服务发现和负载均衡，我们提供了以下几个对象模型：

1. Container，容器实例，多个 Container 构成一个 Pod（实体）。

2. Pod，每个 Pod 共享一个网络栈，IP 地址和端口空间（实体）。

3. Service，多个相同 Pod 副本构成一个 Service，拥有一个 Service IP（逻辑）。

4. 安全组，多个 Service 构成一个安全组（逻辑）。

其中，可动态伸缩的关系是一个 Service 与其后端 Pod 的映射，这一步是靠平台的自动服务发现来完成。只要发起对 Service IP 的访问，那么 Service 本身就会完成服务发现和负载均衡的功能。后端 Pod 如果发生变动，调用方完全无需感知。

从实现上来说，我们将这个功能实现到了每个宿主机上，每个宿主机上的这个组件会直接代理本机产生的 Service 流量，这样可以避免额外的内网流量开销。

功能上，我们实现了 IP 级的负载均衡，什么意思，就是每个 Service IP 的可访问端口与后端 Pod 实际监听的端口是一致的，比如后端 Pod 监听了 12345，那么直接访问 Service IP 的 12345 端口，即可直接访问，而无需额外的端口配置。

这里对比一下常见的几种负载均衡：

1. 比 DNS 均衡更加精细。

2. 比端口级的负载均衡器更容易使用，对业务入侵更小。

另外，7 层的负载均衡实际上有很大的想象空间，我们实现了大部分 Nginx 的常用配置，使用者可以灵活配置。业务甚至还可以指定后端进行访问。

安全组

在隔离层面，我们在逻辑上划分了安全组，多个 service 组成一个安全组，安全组之间可以实现灵活的访问控制。相同安全组内的容器可以互相不受限制的访问。其中最常见的一个功能是，将安全组 A 中的某些特定的 Service Export 给另一组安全组 B。Export 后，安全组 B 内的容器则可以访问这些导出的 Service，而不能访问 A 中的其他 Service。如图 16 所示。

图 16

介绍完了我们网络的基础功能，这里通过分析两个七牛的实际案例来说明这样的结构是如何推动业务的架构演变的。

案例分析 1——七牛文件处理 FOP 架构演变

第一个是七牛的文件处理架构（File OPeration），如图 17 所示。文件处理功能一直是七牛非常创新、也是很核心的一个功能，用户在上传了一个文件后，通过简单地在资源 url 中添加一些参数，就能直接下载到按参数处理后的文件，例如你可以在一个视频文件的 url 中添加一些参数，最终下载到一张在视频某一帧上打了水印并旋转 90 度并裁剪成 40×40 大小的图片。

图 17

而支撑这样一个业务的架构，在早期是非常笨拙的。图 17 左侧是业务的入口，右侧是实际进行计算的各种 worker 集群，里面包含了图片处理，视频处理，文档处理等各种处理实例。

1. 集群信息写死在入口配置中，后端配置变更不够灵活。

2. 业务入口成为流量穿透的组件（业务的指令流与数据流混杂在一起）。

3. 突发请求情况下，应对可能不及时。

后面负责文件处理的同事将架构进化成了这样（如图 18）。

1. 增加 Discovery 组件，用于集群中 worker 信息的自动发现，每个 worker 被添加进集群都会主动注册自己。

2. 业务入口从 Discovery 获取集群信息，完成对请求的负载均衡。

3. 每个计算节点上新增 Agent 组件，用于向 Discovery 组件上报心跳和节点信息，并缓存处理后的结果数据（将数据流从入口分离），另外也负责节点内的请求负载均衡（实例可能会有多个）。

4. 此时业务入口只需负责分发指令流，但仍然需要对请求做节点级别的负载均衡。

图 18

图 19 描述的是文件处理架构迁移到容器平台后的早期结构，较迁移之前有如下变更。

1. 每个 Agent 对应一个计算 worker，并按工种独立成 Service，比如 Image Service，Video Service。

2. 取消业务的 Discovery 服务，转由平台自身的服务发现功能。

3. 每个 Agent 的功能退化：

无需和 Discovery 维护心跳，也不在需要上报节点信息。

由于后端只有一个 worker，因此也不需要有节点内的负载均衡逻辑。

4. 业务入口无需负载均衡，只需无脑地请求容器平台提供的入口地址即可。

图 19

图 20 是迁移后发生的另一次演变，实际上上一个阶段中，每个 Agent 仍然和计算实例绑定在一起，而这么做其实只是为了方便业务的无痛迁移，因为 Agent 本身的代码会有一些逻辑上的假设。

这张图中，我们进一步分离了 Agent 和 worker，Agent 独立成一个 Service，所有的 worker 按工种独立成 Service，这么分离的目的在于，Agent 是可能会有文件内容缓存、属于有状态的服务，而所有的 worker 是真正干活、无状态的服务。分离之后的好处在于，worker 的数量可以随时调整和伸缩，而不影响 Agent 中携带的状态。

好处：

1. 可以看到，相比于最早的架构，业务方只需集中精力开发业务本身，而无需重复造轮子，实现各种复杂的服务发现和各种负载均衡的代码。

2. 另外，自从部署到容器平台之后，平台的调度器会自动更具节点的资源消耗状况做实例的迁移，这样使得计算集群中每个节点的资源消耗更加均衡。

案例分析 2——用户自定义文件处理 UFOP 架构演变

另一个案例是七牛的用户自定义文件处理。

用户自定义文件处理（User-defined File OPeration，UFOP）是七牛提供的用于运行用户上传的文件处理程序的框架。他的作用实际上和前面介绍的是一致的，只是允许用户自定义他的计算实例。例如七牛现有的鉴黄服务，就是一个第三方的 worker，可以用于识别出一个图片是否包含黄色内容。而正是由于引入了用户的程序，所以 UFOP 在架构上和官方的 FOP 的不同在于，UFOP 对隔离有要求。

图 20 是原本 UFOP 的架构，事实上，这里已经使用了容器技术进行资源上的隔离，所有的容器通过 Docker Expose 将端口映射到物理机，然后通过一个集中式的注册服务，将地址和端口信息注册到一个中心服务，然后入口分发服务通过这个中心服务获取集群信息做请求的负载均衡。

而在网络的隔离上，由于 Docker 自身的弱隔离性，这个架构中选择了禁止所有的容器间通信，而只允许入口过来的流量。这个隔离尺度一定程度上限制了用户自定义程序的灵活性。

图 20