陌陌基于K8s和Docker容器管理平台的架构实践

   <p>容器集群管理系统与容器云平台的选择非常重要，因为容器管理系统是否先进智能、容器云管理平台是否灵活易用且高效，直接影响企业开发运维的效率与速度、资源利用率的高低。在这个竞争激烈，风云突变的时代，应用的开发效率、稳定性、扩展性和安全性，决定了企业的竞争力与市值。</p>    <p>当下，K8s凭借在扩展性、管理、大数据分析、网络场景、兼容性、负载均衡、灰度升级、失败冗余、容灾恢复、 DevOps 等方面的优势，受到部分企业的青睐。近日，由51CTO 主办的第十六期以“Tech Neo”为主题的技术沙龙活动中，来自陌陌科技SRE团队负责人王景学分享了陌陌在K8s容器方面的一些应用实践。</p>    <h3>为什么选择使用K8s？</h3>    <p>在使用k8s之前，陌陌在应用发布和运行环境方面遇到的具体问题，如下：</p>    <ul>     <li>应用发布时间很长，主要是因为发布过程中需要做隔离、恢复等动作，还需要登录查看实际状态、日志。</li>     <li>当遇到晚高峰情况这样的突发状况，需要紧急扩容。这时业务方会申请机器，可新机需要进行环境初始化、相关配置，这样导致效率非常低。</li>     <li>应用运行环境的软件版本不一致，配置复杂，维护成本比较高。</li>     <li>硬件资源利用率不足，总体成本比较高。</li>    </ul>    <p>针对以上遇到的问题，我们决定对架构进行改造，同时制定了一系列架构改进目标，如下：</p>    <ul>     <li>提高服务可用性，可管理性。可用性是当某一台机器出现宕机，会自动切换到其他机器。可管理性是在应用需要扩容时，自动化去部署运行环境、相关配置。开发不需要再去考虑服务器的问题。</li>     <li>提高资源隔离性，实现服务混合部署。</li>     <li>应用级别的监控，当机器需要扩容时，自动排查是哪个应用所致。</li>     <li>服务平滑迁移。</li>    </ul>    <p>综合这些问题和目标，陌陌选择使用 Kubernetes来管理 Docker 集群，当 Kubernetes 满足不了需求时，可在部署平台开发相应的功能来满足开发查看日志、监控和报警等需求，尽量避免登录主机和容器。</p>    <h3>陌陌容器管理平台的架构演进</h3>    <p>陌陌从2015年下半年开始对Docker进行调研和实践，2016年初开始调研k8s，尝试架构方面的改进工作，基于自研发布系统及K8s、OVS和Docker构建容器管理平台。实现了基于Docker集群的部署系统，便于开发者便捷地部署自己的应用程序。最终达到部署环境干净一致，可重复部署、迅速扩容和回滚。</p>    <p>如下图，是 容器管理平台的架构图 ：</p>    <p><img src="https://simg.open-open.com/show/086f728ecc204853ec07fa2fef022cab.jpg"></p>    <p>容器管理平台主要功能有集群管理和状态展示、灰度发布和代码回退、组件模板、应用管理、镜像仓库和权限管理等。它采用前后端分离的架构，前端使用 JS 渲染，后端使用 Python 提供 API。这样开发者可以快速的进行发布和回退操作。</p>    <p>容器管理平台在应用发布流程，集群调度策略，k8s节点网络架构，阿里云支持，基础监控指标等方面进行了优化改进。</p>    <p>应用发布流程</p>    <p>陌陌之前老版本发布系统是串行的，需要单台进行替换。如下图，是 新架构下应用的发布流程 ：</p>    <p><img src="https://simg.open-open.com/show/df32c5938d47010e5a55c5dcb8f85875.jpg"></p>    <p>新的发布系统是用户提交代码后，在发布系统选择要部署的commit，点击构建以后，系统会自动编译，打包成镜像，推送镜像仓库。如果构建成功，用户点击发布新版本的实例，灰度没有问题，全量，下线老版本的实例。回退时代码不需要构建，直接发布老版本实例。在某段时间内，新老版本是同时存在的。</p>    <p>集群调度策略</p>    <p>陌陌的集群调度策略是为应用配置默认的location（集群标签），如果是线上应用，应用需要申请location，部署到正式的集群（机房要求，资源充足）。这里应用都不能独占集群，均采用的是混合部署的方式。</p>    <p>同一个集群下，分成不同组并组定义标签，应用支持独占机器，同一个组之间的应用实例可以随意飘移。</p>    <p>IDC网络节点</p>    <p>在IDC网络节点构建部分，陌陌使用的是全局IP地址，容器与容器之间、容器与主机之间都是互通的。这样一来，通信可以不使用任何封装等技术，相对来说比较高效且对现有网络变动影响小（仅需封装trunk，无其他协议，mtu等变化）。</p>    <p>如下图，是 IDC网络节点架构图 ：</p>    <p><img src="https://simg.open-open.com/show/e8dcd00dfb6bfaf2ec7d78e4d2ca6d2c.jpg"></p>    <p>在这样的架构下，网络部署和扩展相对简单，因为每台机器的IP地址段是预先静态配置的。</p>    <p>这里值得注意的是，服务器双链路上联，trunk上联物理交换机需要合理避免二层环路。</p>    <p>这样的方式存在的不足是，当容器较多时，mac地址数量增多，给物理交换机Mac地址表带来压力，广播域扩大就是需要严谨的规划vlan 角色相关信息。</p>    <p>阿里云支持</p>    <p>当前，陌陌K8s master集群下节点包含IDC、阿里云及两者混合三种方式，如下图：</p>    <p><img src="https://simg.open-open.com/show/2e1ce506839688ff1b2419ff119bd336.jpg"></p>    <p>阿里云采用的网络模式是Host-gw，陌陌搭建了一条IDC与阿里云的VPC专线和VPC的虚拟路由进行静态配置。无论是IDC节点，还是阿里云节点上的应用都要适应IP动态变化。</p>    <p>基础监控指标</p>    <p>陌陌的监控方案大多是基于Kublet cadvisor metrics接口去做的数据汇总。最初陌陌采用的方式是利用Python脚本，去调用接口，在取到一些CPU内存、网络、流量的数据，存入ES，分析之后进行展示。之后的报警系统，是利用Java应用去调取Kublet cadvisor metrics接口，进行数据的收集。</p>    <p>基础监控指标主要有内存(total,rss,cache)、流量(incoming,outgoing)、网络packets(drop，error, total)等。</p>    <h3>应用迁移</h3>    <p>应用迁移方面，陌陌做了很多适配工作，使得应用不需要太多的改动就可以无缝迁移。具体适配细节如下：</p>    <ul>     <li>应用适应动态ip变化。</li>     <li>自定义构建过程（build.sh）。</li>     <li>应用使用不同的服务发现框架（nginx，rpc）（start.sh）。</li>     <li>应用销毁过程中做一些额外处理(stop.sh)。</li>    </ul>    <p>在应用迁移过程中，也遇到了一些问题，如Swap、cpu软中断优化、资源利用率、Ip白名单、适用于内网等问题。</p>    <p>当前，陌陌的容器业务规模服务器约400台、线上容器6000、应用700+。应用的类型是java+php+node+python+tomcat。</p>    <h3>未来展望</h3>    <p>希望运维可以实现对应用请求量，线程数，流量等指标的监控。基准值部分，达到单实例可承载请求量，线程数，流量。伸缩方面，做到最小保留实例数，最大扩容实例数，根据监控反馈和基准值计算需要扩容和缩容的实例数, 按照各个集群资源余量按比例伸缩。</p>    <p>【嘉宾简介】</p>    <p style="text-align:center"><img src="https://simg.open-open.com/show/4e491478737b10b3f4c0d3c54b3ab838.jpg"></p>    <p>陌陌王景学，现任SRE团队负责人，以前运维相关工作都做过，自动化，虚拟化，docker，k8s相关都非常熟悉。</p>    <p> </p>    <p> </p>    <p>来自：http://developer.51cto.com/art/201711/558515.htm</p>    <p> </p>