鸿 网 互 联 www.68idc.cn

Rancher容器网络-Floating IP解决方案推荐

来源:互联网 作者:佚名 时间:2018-01-22 10:04
Rancher网络使用中遇到的问题 首先,在为某一个stack编写Rancher catalog的时候,假设在docker-compose里指定了ports A:B,那么,cattle在调度的时将首先过滤掉所有已经占用了port A的主机。这也就意味着,假设用户只有4台host作为Rancher agent,但是需要运

Rancher网络使用中遇到的问题


首先,在为某一个stack编写Rancher catalog的时候,假设在docker-compose里指定了ports A:B,那么,cattle在调度的时将首先过滤掉所有已经占用了port A的主机。这也就意味着,假设用户只有4台host作为Rancher agent,但是需要运行5个在外网中占用80端口的服务,这显然是不行的。


另一方面,客户端通过主机的IP地址来访问Stack提供的服务,一旦由于系统异常,或者微服务内部程序崩溃导致Service被重新调度到其他主机,势必导致访问Stack服务IP地址的更改。


为了让客户端不被影响,常见的解决方案是通过使用Rancher提供的external-DNS;如果业务在公网,有像AWS的Router-53之类的解决方案;若是自建数据中心也可以通过使用支持RFC-2136的硬件路由器等来实现DNS条目的及时刷新。


从当前Github代码看External-DNS已经支持下面的Provider了:


wKioL1jbGOuQP2plAAAkVCpdZ6M317.jpg


但是,通过刷新DNS的方案要么价格昂贵,要么需要自己维护一个Rancher外部的DNS Server,都存在一定缺陷。


那么,有没有一种方式,既能够解决端口冲突,又能够解决stack对外服务IP变更的问题呢?答案就是今天我们的主角:Floating IP!


Floating IP解决方案


上一次Alan为大家分享的「关于在Rancher中使用keepalived」中就有提到VIP的概念,只是keepalived需要在Active+Passive的主机之间周期性发送心跳报文,然后基于优先级来判断将VIP绑定到哪一个host,它解决了服务迁移后访问的目标IP地址变化的问题。


而Floating IP却是从另一个角度来解决问题。熟悉OpenStack的人对Floating IP应该都不会陌生,所谓Floating IP就是为某台虚拟机绑定的一个外网IP地址。绑定之后,无论该虚拟机在OpenStack内被迁移到哪一台hypervisor,外网都可以通过Floating IP来访问到该虚拟机。我们来看Rancher中是怎么引入Floating IP的。首先上一张总体模块框图:


wKiom1jbGQqDXj9IAAAjg3ntqP8041.jpg


从图上我们可以看到,整个Floating IP的实现,只需要两个模块,或者说两个微服务:Metadata-confd和Network-plugin。至于IPAM为什么不需要重新实现,我们后面会讲到。接下来我们讲一下各个模块功能和作用。


Metadata-confd:


这是一个使用了Rancher managed网络的service,通过managed网络,它按照一定的周期从Agent-Instance上polling metadata信息。采用分布式架构,每一个Metadata-confd只关注属于自己host上的容器。


但是,也并非所有的container都会触发后续行为,只有该host上带有“io.rancher.container.floating.ip” 标签的容器有被新增、删除或更新IP的时候,Metadata-confd才会通过docker client向docker daemon发送操作命令。


wKiom1jbGSKiegRwAAAaJWKy9Tw648.jpg


需要注意的是,这里的network均是指Floating IP所在的网络。


对于Metadata-confd的实现方式,除了通过通过周期性polling之外,也可以采用支持Rancher backend的confd来生成map文件(包含ip — floating ip映射),然后使用confd里面的reload-cmd参数,指定脚本去解析和做后续处理。当然,这种方法存在不少坑,大家可以下来自己研究。


FIP Network Plugin:


FIP Network Plugin是按照CNM的定义来实现的一个libnetwork的remote driver。该service使用host网络,遵照docker deamon发送过来的请求指令,实现网络相关的操作。Network plugin所做的事情,我们可以通过下图来理解:


wKiom1jbGUfykZK6AAAXQMH2Ot8483.jpg

wKioL1jbGVOgtYQvAAAecriEpCc078.jpg


原生的docker bridge driver创建了docker0网桥,然后将所有的container通过link pair挂到桥上。在network root namespace内,通过NAPT规则将对Host上特定port的访问DNAT到container的内部port。而在Floating IP网络中,FIP network plugin创建了一个新的bridge,然后将label含Floating IP的container连接到该bridge上。


由于使用了与docker0 共享的“default” driver的IPAM,FIP network bridge的IP地址段不会与docker0所在的网段重叠,从而保障container在连接了两个网段后,路由不会冲突。


按照CNM的定义,Docker Network Plugin主要需要实现以下方法:


create network

delete network

create endpoint

delete endpoint

join endpoint to network

leave endpoint from network


而FIP Network Plugin除了要实现基本的功能外,还需要为Floating IP添加以下功能:


当收到join endpoint to network请求时,将Floating IP配置到host IP所在的接口上;

更新主机的NAT规则,将所有destination IP为FIP的报文DNAT到container的内网IP;

当container销毁时,执行反向的操作。


这些修改之后,container其实还无法通过FIP回包,为什么呢?有兴趣的可以研究一下挂载了两个network后container的路由表条目。至于还需要如何配置,大家可以下来自己实验。


演示


现在我们来做一个实验,看看Floating IP的报文转发是如何工作的。


1. 首先在Rancher catalog中选择“Wise2C Floating IP”,从详细页面看,Floating IP这个stack不需要添加任何配置参数:


wKiom1jbGY3zJqM3AAAmYHMi-vA679.jpg

wKiom1jbGY2x2V3YAAAZbTHfRng745.jpg


启动过程中,可以看到:该stack在一个host ”vm-153-5”上启动了两个containers(在每个host上均会被调度):


wKiom1jbGZ_QVGy9AAAYbDOcbcc498.jpg


2. 服务启动成功后,我们到host里面可以看到已经初始化好的network(其网段是172.18.0.0/16):


wKioL1jbGb7xfsf9AAAnYriBQ9c098.jpg


3. 然后我们再通过Rancher创建一个带有标签为“io.rancher.container.floating.ip=192.168.99.200”的container。这里的IP地址就是我们希望为该container绑定的Floating IP:


wKioL1jbGb-xKPflAAAY552kOnU887.jpg


4. 当container启动成功后,metadata-confd会检测到该label,然后向docker daemon发送请求将该container加入到wise2c network。我们可以进入container查看interface详情来了解到:


wKiom1jbGd3Cu-coAAAy4LdBrAI271.jpg


上图中接口eth1@if9就是接入到wise2c network的接口,其IP地址属于172.18.0.0/16网段。


5. 再来看host上的IP地址和NAT规则


wKioL1jbGd3S8gk8AAA9FNsDMTo117.jpg


其中enp0s8就是我们host的default gw对应的出口网卡,可以看到floating ip:192.168.99.200已经被添加到上面了。


主机的NAT表:


wKiom1jbGgWRdREMAAAI55IicpU593.jpg


上图就是我们的network-plugin为Floating IP创建的基于destination IP的DNAT规则,其中br-d62debee292b是FIP network plugin为wise2c network创建的bridge。


下面的DNAT规则是将所有不来自br-d62debee292b,且目标IP地址为192.168.99.200的报文DNAT到172.18.0.2容器。


6. 接下来就是验证网络,在客户机(192.168.99.1)上ping Floating IP:


wKiom1jbGgXjHy7fAAA0BOBPbXk677.jpg


到wise2c network的bridge上抓包:


wKioL1jbGgbyz6rcAAAqDaTCows120.jpg


可以看到,DNAT规则已经生效。


总结


我们再来整理一下使用场景。


初始化:


首先FIP catalog指定在所有运行了Rancher agent的主机上均启动Floating IP service;


在服务启动后,Metadata-confd向docker daemon请求创建FIP network,然后开始polling Rancher metadata信息;


一旦发现本机上存在带FIP标签的容器,Metadata-confd就向docker daemon请求将容器接入FIP network;


接下来network-plugin从docker daemon收到创建FIP network和将容器接入FIP network的请求后,执行操作。


在这个过程中,Floating IP被添加到host上默认网关对应的网卡,并更新NAT规则,保障外网访问Floating IP的流量被DNAT到容器。


容器迁移:


当容器从Host-A迁移到Host-B,Host-A上的docker-daemon会发起将container移出FIP network。network-plugin只需要按照leave endpoint from network的流程,逐一删除NAT规则,并移除host上的Floating IP address。


在Host-B上执行的操作除少了初始化时候的创建FIP network外,其他操作流程同“初始化”。


Q A

Q:其他编排引擎怎么支持?

A:除了通过CNM来实现外,还可以通过外部实现,只需要能够为主机配置IP地址和NAT规则就能够支持的了。只是如果通过CNM实现,对资源的释放可以由docker daemon来触发,不需要完全自主控制。


Q:Metadata-confd poll metadata service的间隔是不是需要很短?否则是不是可能存在旧的host IP还没有移除,新的host已经在尝试添加IP的情况,导致IP冲突?

A:如果采用poll的方式来实现肯定是有一定的时间间隔的缺陷的,如果无法接受,就可以采用支持Rancher backend的confd来实现。


Q:今天讲的FIP在k8s环境下也可以用吗?

A:其实理论上是可用的,但我们还没测试。因为方案只用了docker label, Rancher metadata service 和 docker libnetwork,这些在Rancher 的k8s 环境都是有的。


Q:managed网络还是基于ipsec的隧道网络吗?性能上怎么样呢?

A:是的,基于ipsec,在很多生产环境的实际使用中,没什么性能问题,性能就是和普通VPN 一样。

在Docker本身提供的几种网络基础上提供了一种叫做Managed的网络特性,官方说法如下:The Rancher network uses IPsec tunnelling and encryption for security。


简单理解就是在容器之间构建了一条私有网络,只有容器与容器之间可以访问。


Rancher会为每个容器分配一个 10.42.*.* 的私有网络地址,这个地址只在容器之间是可达的,对外不可见,有点类似一种纯软件上的VPC方式。从路由上可以看出,对于10.42网段的路由是通过docker0接口,docker0的特殊的配置了IP也包含了10.42网段。


网友评论
<