使用使用gorouter+haproxy作为流量入口，confd作为配置更新
Gorouter
项目地址：https://github.com/cloudfoundry/gorouter/
Gorouter来源于CloudFoundry。是一个高性能、轻量级的路由器及负载，它是整个平台的流量入口，负责分发所有的http请求到对应的instance。它在内存中维护了一张路由表，记录了域名与实例的对应关系，所谓的实例自动迁移，靠得就是这张路由表，某实例宕掉了，就从路由表中剔除，新实例创建了，就加入路由表。
Gnatsd
Gnatsd来源cloudfoundry，是一个开源轻量高性能的消息系统，gorouter依赖它来作为消息系统，进行PUB/SUB操作。
官方地址：http://nats.io/
项目地址：https://github.com/apcera/gnatsd
Confd
Confd是一个轻量级的配置管理工具。通过查询Etcd，结合配置模板引擎，保持本地配置最新，同时具备定期探测机制，配置变更自动reload。其后端支持的数据类型有：etcd、consul、vault、environment variables、redis、zookeeper、dynamodb、stackengine、rancher。不过一般使用Confd和etcd的配合使用比较多。
项目地址：https://github.com/kelseyhightower/confd
HAProxy
HAProxy是一个免费的负载均衡软件，可以运行于大部分主流的Linux操作系统上。HAProxy提供了L4(TCP)和L7(HTTP)两种负载均衡能力，具备丰富的功能。HAProxy的社区非常活跃，版本更新快速，最关键的是，HAProxy具备媲美商用负载均衡器的性能和稳定性。
项目地址：https://github.com/haproxy/haproxy
etcd
etcd是Go编写，是一个分布式一致性键值存储系统，用于共享配置和服务发现，专注于：· 简单:良好定义的，面向用户的API (gRPC)。· 安全：带有可选客户端证书认证的自动TLS。· 快速:测试验证，每秒10000写入。· 可靠:使用Raft适当分布。项目地址：https://github.com/etcd-io/etcd
今天简单分享下公司大规模容器应用中的数据流架构。
我们公司项目都是采用微服务架构设计，现服务对外访问支持两种模式如下：
-
使用的NodePort方式暴露应用端口至宿主机，上层通过配置nginx代理到这台机器的端口，然后外网SLB在代理这个nginx。这种模式下带来了一个麻烦，就是每次新上个应用都得去配置Nginx。:)
流量走向: SLB->Nginx>node(kube-proxy)>pod
-
域名分发模式，使用gorouter+haproxy作为流量的入口，域名通过泛解析到SLB上，SLB解析到内部的haproxy，haproxy代理gorouter，gorouter内部维护了一张应用的路由表，会进行匹配。这样我们在平台上一个应用创建好后，啥也不用做，就可以访问。
架构示意
选择两个Node节点作为流量节点，上面跑了confd，haproxy，gorouter容器，gorouter需要依赖nats（我们是部署在了另一个命名空间下）控制器使用的DaemonSet，开放了80,443端口。
其中原理就是
-
创建应用后如果使用域名分发模式，就会通过nats客户端注册一条消息到gorouter中，内容包含使用的域名+加上这应用的service IP
-
confd监听etcd中的key变化，如果有更新就同步修改haproxy配置规则并重新加载。
-
SLB绑定到这流量节点上的80端口（haproxy开的端口）
-
泛域名解析到SLB，用户通过域名
test.a.com请求，会经过gorouter路由匹配，匹配成功进行代理，反之访问会提示未注册路由错误。