基于 Docker 1.12 Swarm 的集群管理开发实践

KarrySpearm 8年前
   <p>Mesos/Marathon 折腾久了,我们一直希望有机会深入到 Swarm 内部一探究竟。 另外, Mesos 这一套东西虽然是久经企业级考验的, 但是安装、部署和使用相对复杂,上手有门槛。同时,在今年的 DockerCon 上,内置了Swarm 功能的 Docker 1.12 发布。基于以上背景,数人云计划围绕 Docker 1.12 Swarm 开发一版轻量级的集群管理工具,也借此与 Mesos/Marathon 对比下。目前,我们第一版数人云容器管理面板 <strong>Crane</strong> 已经开发完毕,过程也是磕磕绊绊,这里趁机总结几篇技术分享。</p>    <p>正文开始前先八卦一下,关注 Docker 技术的小伙伴们应该清楚 Docker 1.12 的 Swarm mode 颇受争议:首先是有人认为 Docker 公司 Market Drive Develop,违背了 Linux 信徒恪守的哲学——一个工具只干一件事情;其次, 有人认为 Swarm mode 的功能不及 Mesos 和 K8S,还不适合生产环境使用,这一点我倒认为稳定性而不是功能才是 Swarm 目前不适合生产环境的原因;最后, Docker 的向后兼容性不足也引来口水无数,毕竟 Docker 还在 active develop。其它的像容器网络标准的争议, Runc 的争议这些都把 Docker 推到了风口浪尖。当然,不辩不明,相信 Docker 给我们提供的不止眼前这些。</p>    <p>我们首先从 <strong>应用编排( Application Stack)</strong> 谈起,应用编排是 Docker 1.12 引入的概念,目前还是 experimental 的功能,必须得安装 experimental 的包才可以尝试。除去编排 (stack), Docker 1.12 还引入了 <strong>服务 (service) 和任务 (task)</strong> 的概念, Docker 借此重新阐述了应用与容器 (container) 之间的关系。上述几个概念的关系如下图所示:</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/d5509c8f289f6be44d025c9eb53d8b27.jpg"></p>    <p>即:一个应用编排代表一组有依赖关系的服务,服务之间可以相互发现(后面详细介绍),每个服务由多个任务组成,任务的数量可以扩缩 (scale),而任务则物化为一个具体的 Docker 容器及其配置。</p>    <p>Docker 通过扩展名为 dab( Distributed application bundles) 的文件来描述一个应用编排,下图是一个带有两个服务的 dab 文件例子:</p>    <p><img src="https://simg.open-open.com/show/1f0bae68909e8b70f6a84019a70bf7b7.png"></p>    <p>这里有dab文件的详细介绍:</p>    <p>https://github.com/docker/docker/blob/master/experimental/docker-stacks-and-bundles.md</p>    <p>其中 Image 这里推荐使用 image@digest 而不是 image:tag,原因是为了避免这种情况 : 在集群中部署服务时, image:tag 无法保证镜像是全局一致的,本地的 image:tag 可能与镜像仓库里面的 image:tag 数据不一致,这个问题在跨机环境中被放大。而 image@digest 这种方式通过中心化仓库设置全局唯一的 digest 值,避免了上述问题。</p>    <p>除此之外,还有下述几个关键特性值得分享:</p>    <ul>     <li> <p>滚动更新: 服务的镜像更新是一个基本诉求。 Docker 可以通过关键词 update-parallelism 和 update-delay 来控制并行更新的频率。 Marathon 也提供了类似的功能。这个特性很关键,如果无法控制更新频率,成百上千的镜像拉取和任务调度会导致严重的资源波峰。 Docker 文档还声称支持更新失败回滚,尝试了下,目前没发现怎么玩,还没来得及看底层代码。</p> </li>     <li> <p>服务模式 (service mode): Docker 1.12 提供了两种方式控制任务数量—— replicated 和 global,在 replicated 方式下,我们需要提供期望的任务数量, Swarm 将一直尝试维护这个任务数;而在 global 方式下, Swarm 尝试在每个节点上启动一个任务,这种方式特别适合向每个节点下发 agent 的场景。</p> </li>     <li> <p>stop-grace-period 参数: 在服务缩容时,我们比较关心容器被强制 kill 而带来的事务 (transaction) 问题,配合该参数 stop-grace-period( 强制杀死容器前的等待时间 ) 和容器内部的退出信号监听,可以达到容忍程序友好退出和快速回收资源之间的平衡。 Mesos / Marathon 也采用了类似的策略来解决这个问题。</p> </li>     <li> <p>with-registry-auth 参数: 在服务创建时,该参数声明将管理节点 (Swarm manager) 上的 registry authentication 信息带到工作节点 (worker node) 上,从而为工作节点提供从 registry 拉取镜像的认证信息。在 Docker 的非 Swarm 场景下, Docker-client 负责 registry 认证信息的管理,但在 Swarm 方式下,不再是 Docker-client 触发镜像拉取动作,所以服务无法使用工作节点本地的 registry 认证信息了,必须要通过上述方式从管理节点分发认证信息。同时节点间的加密通信也保证了认证信息传输的安全性。</p> </li>     <li> <p>任务的生命周期: 在容器的生命周期之上, Docker 1.12 引入了任务 (task) 的生命周期。某任务下的容器异常退出时,带有同样任务编号 (slot) 的新容器将会被尝试启动。不同于容器的生命周期只囿于一台固定主机上,任务的生命周期是与主机无关的,我们可以依此对容器的日志进行聚合得到任务的日志。这一点正好是 Mesos / Marathon 所欠缺的。</p> </li>     <li> <p>重启策略: Docker 1.12 提供了三种重启条件 -any, none, on-failure,其中 none 指的是退出不重启, on-failure 指的是失败( exit code 不是零)时重启,而 any 指的是无论任务正常或是异常退出,都重启。 any 方式配合参数重启间隔 (restart-delay) 可以满足定时任务的场景; none 方式则可以满足批处理任务场景。另外参数评估间隔 (restart-window) +参数尝试次数 (restart-max-attempts) 可以控制在一段时间内的任务重启次数,避免异常任务频繁重启带来的集群资源失控。</p> </li>    </ul>    <p>当然,Swarm mode 还有很多问题亟待解决:</p>    <ul>     <li> <p>dab 文件的表达能力有限: 当前版本的 dab 文件只有寥寥数个关键词,服务 (service) 创建的诸多参数 dab 都无法支持。在我们的实践中,为了解决这个问题, team 不得不二次开发引入服务的其它参数,以期对服务的参数全量支持。</p> </li>     <li> <p>容器回收问题: 按照目前的设计,只要服务 (service) 还在,退出的容器是不会被自动回收掉的,在某些场景下,这会导致集群失控,各主机的文件描述符被耗尽。</p> </li>     <li> <p>容器的健康检查 (healthcheck): 在我看来,这是 Swarm mode 之外, Docker 1.12 引入的最关键功能,有了 healthcheck 这个 feature,我们可以将业务内部真正的健康状况暴露出来了。这个功能落后于 Marathon 足足一年的时间。但可惜的是,服务( service)创建目前还不支持这个关键词,这就限制了服务 (service) 异常重启的能力,从而间接降低了服务容错能力。这一点 Marathon 做的特别好。</p> </li>     <li> <p>资源控制: 1.12 目前支持单个任务 CPU / mem 的资源控制。还无法像 Mesos 那样,自由的配置管理磁盘, GPU,端口等资源。</p> </li>     <li> <p>无法使用主机网络: 通过服务( service)启动的容器是无法使用主机网络的 (network host is not eligible for Docker services),但同时按照网络上 Percona 提供的压测结果, overlay 网络相较于主机网络有 60% 的性能损耗。这严重局限了 Swarm 的应用场景,我们可以认为这是编排功能带来的架构副作用。而 Mesos 从资源维度管理集群很好的规避了这个问题。</p> </li>    </ul>    <p>接下来让我们看看下一层: Docker 是怎样在 stack, service, task container 之间建立联系的?同一个 stack 内的 service 又是如何相互发现的?</p>    <p>第一个问题很好回答, service label 和 container name, Docker 通过在 service 上添加 label: com.Docker.stack.namespace=XXX 来标示这个 service 属于哪一个 stack。我们可以 inspect 一个 service 看下:</p>    <p><img src="https://simg.open-open.com/show/9b8c7b5a4328cbc0ddb172965916580f.jpg"></p>    <p>Docker 通过特定格式的 container name 标示这个 container 隶属于哪一个 service 下面,如下图所示:</p>    <p><img src="https://simg.open-open.com/show/c6dd787eef96ba44ed90a674aa075ac7.png"></p>    <p>容器名称 merryfox_mysql.1.by842qrj7xhsne93yzfpjp367 代表该容器是服务 merryfox_mysql 的任务 1 的容器。Docker 在很多地方使用了这种技巧来处理数据。而第二个问题就引出了我们下面的——服务发现。</p>    <h2><strong>服务发现</strong></h2>    <p>在谈服务发现之前,我们简单讨论下 Docker overlay 网络的性能问题,根据 https://www.percona.com/blog/2016/08/03/testing-Docker-multi-host-network-performance/ 的网络压测结果, <strong>相较于 host 网络, overlay 有 60% 的网络性能损耗</strong> ,问题主要出在多 CPU 下网络负载不均。同时容器无法在 Swarm 编排模式下使用 host 网络,这带来的问题就是: <strong>在 Docker 1.12 Swarm mode 下网络性能损耗无法避免</strong> 。</p>    <p>与 Marathon / Mesos 的 Mesos-DNS、 bamboo 类似, Swarm 的服务发现也分为内部服务发现 (internal service discovery) 与外部服务发现 (ingress service discovery),这两种服务发现使用了不同的技术。</p>    <p>如果想让一个服务暴露到集群之外,我们需要借助 service create 的参数 publish,该参数显式的声明将集群特定端口 PORT_N(集群端口 PORT_N 代表集群中所有主机的端口 PORT_N)分配给这个服务。这样无论该服务的容器运行在哪台主机上,我们都可以通过集群中任何主机的 PORT_N 端口访问这个服务了。下图可以形象的描述这个场景:</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/cae6b69556bfcd203220cc285521b26a.jpg"></p>    <p>接下来,我们就可以把集群中部分或所有主机的 IP 加上述端口配置到我们的前置负载均衡器上对公网提供服务了。一般称这种分布式的负载均衡策略为 routing mesh,在 Calico 网络方案中也提到了类似的概念。由于没有了中心化的负载均衡器,集群不会因某台机器异常而导致整个服务对外不可用,很好的避免了单点问题,同时也带了可扩展性。关于routing mesh这个概念的详细介绍可以参考该链接( https://en.wikipedia.org/wiki/Mesh_networking )。</p>    <p>这里摘抄一个简短解释:</p>    <p>A mesh network is a network topology in which each node relays data for the network. All mesh nodes cooperate in the distribution of data in the network.</p>    <p>上述就是 Swarm 的外部负载均衡(也可以称为routing mesh),那么 Docker 在底层做了什么来实现上述功能的呢?如下图所示:</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/d847f20a130e0a7f03737956a9b0f19e.png"></p>    <ol>     <li> <p>在 Swarm 集群初始化时, Docker 会创建一个 overlay 网络 ingress,同时在每个节点上创建与 ingress 关联的 sandbox 网络命名空间,这样集群中的每个主机都变为了 ingress 网络的一部分;</p> </li>     <li> <p>当我们创建 service 申请一个 publish port 时, Docker 会通过 Iptables rules 建立 主机 IP:Port 到 sandbox IP:Port 间的映射,即 : 将对应端口的包转发给 ingress 网络;</p> </li>     <li> <p>同时在 sandbox 网络命名空间内, Docker 通过 Iptables rules + IPVS 控制对应 端口/ Port 的包负载均衡到不同的容器。这里 IPVS(IP virtual server) 的功能与 HAproxy 类似,承担着 Swarm 集群内部的负载均衡工作。</p> </li>    </ol>    <p>对于只供集群内部访问的服务,无需使用上述 routing mesh,Swarm 还提供了一套内部服务发现 + 负载均衡。如下图所示(这里我们只讨论基于 VIP 的负载均衡方法):</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/d791bbd0d4bc1057e2e17490546294d9.png"></p>    <ol>     <li> <p>manager 会为该 service 分配一个 VIP(Virtual IP),并在内部 DNS 上建立一条 VIP 与 service name 的映射记录。注意这里的 DNS server 也是分布式的,每一个主机上都有一个 DNS server ;</p> </li>     <li> <p>Iptables 配合 IPVS 将 VIP 请求负载到 service 下面的一个具体容器上。</p> </li>    </ol>    <p>另外,主机间 routing mesh,load balancing rule 等信息是利用gossip协议进行数据同步的,限于篇幅,这里不再深究这个问题。</p>    <p>最后友情提示几个雷区:</p>    <p>Q1:为什么我的机器无法加入 (join) 到 Swarm 集群中?终端报错:加入集群超时。</p>    <p>A1:这个问题极有可能是主机间时钟不同步导致的,建议开启 ntp 服务,同步主机时间。</p>    <p>Q2:为什么我在 manager A 上通过命令 Docker network create 的 overlay 网络无法在集群另外的机器 B 上通过 Docker network ls 发现?</p>    <p>A2: 这有可能是正常的。按 Swarm 当前的设计,只有使用相应网络的容器被调度到了机器 B 上, overlay 网络信息才会更新到机器 B 上去。</p>    <p>Q3: 为什么我的服务的 publish port 在有些机器上不生效?我使用 netstat – lnp 方式看不到端口监听。</p>    <p>A3: 与问题 1 一样,这也可能是时钟不同步导致的问题。</p>    <p> </p>    <p> </p>    <p>来自:http://mp.weixin.qq.com/s?__biz=MzA3MDg4Nzc2NQ==&mid=2652134137&idx=1&sn=cea9f4f5cf604670c3868e9a94f3e363&scene=4</p>    <p> </p>