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