Rancher容器网络－Floating IP解决方案

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了：

但是，通过刷新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的。首先上一张总体模块框图：

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

Metadata-confd：

这是一个使用了Rancher managed网络的service，通过managed网络，它按照一定的周期从Agent-Instance上polling metadata信息。采用分布式架构࿰