Rancher技术特性全解及容器网络解决方案

《Rancher技术特性全解及容器网络解决方案》要点：
本文介绍了Rancher技术特性全解及容器网络解决方案，希望对您有用。如果有疑问，可以联系我们。

作者简介：

刘力
Rancher 资深架构师
主负责容器云平台产品架构及设计,10年以上的企业级 IT 解决方案和服务经验,在多个行业如运营商、政府、金融、大中型企业网络及应用交付解决方案上有着丰富经验.管理过国内对容器技术在实际生产环境中的大型项目.

1、前言

本文目的在于和大家一起了解一下容器网络以及如何在容器云管理平台上实现扁平网络.

内容包括：

1. 什么是 CNI 接口；
2. 容器网络基于 CNI 的实现—-IPsec 及 VXLAN；
3. 容器网络基于 CNI 的实现—-直接路由访问容器；

2、容器时代

2.1 容器时代背景简介

自2013年 Docker 出现以来,全球已经有越来越多的企业用户在开发测试或生产环境中采用 Docker 容器技术.

然而,如下图所示,在企业内部将容器技术真正用于生产时,很多用户发现面临的最大的问题仍然是在 VM 虚拟化时代曾经面临并已经解决的问题.

例如,如何将容器中的数据进行持久化存储,如何选择合适的网络方案,跨云和跨数据中心的部署和管理如何解决?

业内有款开源的容器云管理平台—— Rancher,短短1年里,已经供全球 4000 多个用户部署及试用、超过 1800 万次的下载量(注：统计来自 DockerHub 官方镜像下载数量).

使用场景覆盖金融、互联网、运营商、教育等各个领域.在本次交流中我们将基于该开源容器云平台进行探讨,同时针对容器面临的网络问题的解决方案进行分享.

2.2 容器的网络类型

2.2.1 原始容器网络

最早的容器网络模型,利用的是容器宿主机内部的网络,同时其 IPAM 管理也是基于容器宿主机的,所有容器宿主机上的容器都会连接到容器宿主机内的 Linux Bridge,叫 Docker0,它默认会分配 172.17 网段中的一个 IP,因为有 Docker0 这个网桥,所以在一个容器宿主机上的容器可以实现互联互通.

但是因为 IPAM 范围是基于单容器宿主机的,所以在其他容器宿主机上,也会出现完全相同的IP地址.这样一来这两个地址肯定没办法直接通信.

为了解决这个问题一般采用的就是 NAT 的方法.比如说我有一个应用,它有 Web 和 Mysql,分别在不同的容器宿主机上,Web 需要去访问 Mysql,我们会把这个 Mysql 的3306端口映射到容器宿主机上的3306这个端口,然后这个服务实际上是去访问容器宿主机 IP 10.10.10.3 的3306端口 .同时如果想要把服务暴露出去需要做端口映射.

下面就是主要的三种容器原始网络模式,这些模式在企业环境基本无法采用：

• Bridge 模式
• HOST 模式
• Container 模式

2.2.2 容器网络的进化

随着用户对容器的网络要求的不断提高,容器界涌现了很多新的网络规范,其目的也都是帮助大家解决在使用容器时的网络问题,现在最主流就是下面这两个：

• Container Networking Model (CNM)
• Container Networking Interface (CNI)

需要注意的是 CNM 和 CNI 并不是网络实现而是网络规范和网络体系,CNM 和 CNI 关心的是网络管理的问题.

这两个模型全都是插件化的,用户可以以插件的形式去插入具体的网络实现.其中 CNM 由 Docker 公司自己提出,而 CNI 则是 Google ?的 Kubernetes 主导.

总体上说 CNM 比较不灵活,也不难么开放,但是确是 Docker 的原生网络实现.而 CNI 则更具通用性,而且也十分的灵活.

目前主流的插件如：Calico、Weave、Mesos 基本上是对 CNI 和 CNM 两种规范都提供支持.

2.3 CNI和CNM简介

2.3.1 CNM接口：

CNM 是一个被 Docker 提出的规范.现在已经被 Cisco Contiv,Kuryr,Open Virtual Networking (OVN),Project Calico,VMware 和 Weave 这些公司和项目所采纳.

其中 Libnetwork 是 CNM 的原生实现.它为 Docker daemon和网络驱动程序之间提供了接口.网络控制器负责将驱动和一个网络进行对接.

每个驱动程序负责管理它所拥有的网络以及为该网络提供的各种服务,例如 IPAM 等等.由多个驱动支撑的多个网络可以同时并存.

网络驱动可以按提供方被划分为原生驱动(libnetwork内置的或Docker支持的)或者远程驱动 (第三方插件).

原生驱动包括 none,bridge,overlay 以及 MACvlan.驱动也可以被按照适用范围被划分为本地(单主机)的和全局的 (多主机).

Network Sandbox：容器内部的网络栈,包含interface、路由表以及DNS等配置,可以看做基于容器网络配置的一个隔离环境(其概念类似“network namespace”)

Endpoint：网络接口,一端在网络容器内,另一端在网络内.一个 Endpoints 可以加入一个网络.一个容器可以有多个 endpoints.

Network：一个 endpoints 的集合.该集合内的所有endpoints可以互联互通.(其概念类似：Linux bridge、VLAN)

最后,CNM 还支持标签(labels).Lable 是以 key-value 对定义的元数据.用户可以通过定义 Label 这样的元数据来自定义 libnetwork 和驱动的行为.

2.3.2 CNI网络接口

CNI 是由 Google 提出的一个容器网络规范.已采纳改规范的包括 Apache Mesos,Cloud Foundry,Kubernetes,Kurma 和 rkt.另外 Contiv Networking,Project Calico 和 Weave 这些项目也为 CNI 提供插件.

CNI 的规范比较小巧.它规定了一个容器runtime和网络插件之间简单的契约.这个契约通过JSON的语法定义了CNI插件所需要提供的输入和输出.

一个容器可以被加入到被不同插件所驱动的多个网络之中.一个网络有自己对应的插件和唯一的名称.

CNI 插件需要提供两个命令：一个用来将网络接口加入到指定网络,另一个用来将其移除.这两个接口分别在容器被创建和销毁的时候被调用.

在使用 CNI 接口时容器 runtime 首先需要分配一个网络命名空间以及一个容器ID.然后连同一些 CNI 配置参数传给网络驱动.接着网络驱动会将该容器连接到网络并将分配的 IP 地址以 JSON 的格式返回给容器 runtime.

Mesos 是最新的加入 CNI 支持的项目.Cloud Foundry 的支持也正在开发中.当前的 Mesos 网络使用宿主机模式,也就是说容器共享了宿主机的 IP 地址.

Mesos 正在尝试为每个容器提供一个自己的 IP 地址.这样做的目的是使得IT人员可以自行选择适合自己的组网方式.

目前,CNI 的功能涵盖了 IPAM,L2 和 L3.端口映射(L4)则由容器 runtime 自己负责.CNI 也没有规定端口映射的规则.这样比较简化的设计对于 Mesos 来讲有些问题.端口映射是其中之一.

另外一个问题是：当 CNI 的配置被改变时,容器的行为在规范中是没有定义的.为此,Mesos在 CNI agent 重启的时候,会使用该容器与 CNI 关联的配置.

3、Rancher的Overlay网络实现

说完了网络规范,我们下面谈一下 Rancher 是怎么利用 CNI 规范完成容器环境下的 overlay 网络实现.众所周知,网络是容器云平台中很重要的一环,对于不同的规模、不同的安全要求,会有不同的选型.

（编辑：ASP站长网）