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

为什么选择使用Kubernetes？

在使用Kubernetes之前，陌陌在应用发布和运行环境方面遇到的具体问题，如下：

针对以上遇到的问题，我们决定对架构进行改造，同时制定了一系列架构改进目标，如下：

陌陌从2015年下半年开始对Docker进行调研和实践，2016年初开始调研Kubernetes，尝试架构方面的改进工作，基于自研发布系统及Kubernetes、OVS和Docker构建容器管理平台。实现了基于Docker集群的部署系统，便于开发者便捷地部署自己的应用程序。最终达到部署环境干净一致，可重复部署、迅速扩容和回滚。

如下图，是容器管理平台的架构图：

容器管理平台主要功能有集群管理和状态展示、灰度发布和代码回退、组件模板、应用管理、镜像仓库和权限管理等。它采用前后端分离的架构，前端使用JS渲染，后端使用Python提供API。这样开发者可以快速的进行发布和回退操作。

应用发布流程

陌陌之前老版本发布系统是串行的，需要单台进行替换。如下图，是新架构下应用的发布流程：

新的发布系统是用户提交代码后，在发布系统选择要部署的commit，点击构建以后，系统会自动编译，打包成镜像，推送镜像仓库。如果构建成功，用户点击发布新版本的实例，灰度没有问题，全量，下线老版本的实例。回退时代码不需要构建，直接发布老版本实例。在某段时间内，新老版本是同时存在的。

集群调度策略

陌陌的集群调度策略是为应用配置默认的Location（集群标签），如果是线上应用，应用需要申请Location，部署到正式的集群（机房要求，资源充足）。这里应用都不能独占集群，均采用的是混合部署的方式。

IDC网络节点

在IDC网络节点构建部分，陌陌使用的是全局IP地址，容器与容器之间、容器与主机之间都是互通的。这样一来，通信可以不使用任何封装等技术，相对来说比较高效且对现有网络变动影响小（仅需封装Trunk，无其他协议，MTU等变化）。

如下图，是IDC网络节点架构图：

在这样的架构下，网络部署和扩展相对简单，因为每台机器的IP地址段是预先静态配置的。

这里值得注意的是，服务器双链路上联，Trunk上联物理交换机需要合理避免二层环路。

阿里云支持

当前，陌陌Kubernetes Master集群下节点包含IDC、阿里云及两者混合三种方式，如下图：

基础监控指标

陌陌的监控方案大多是基于Kublet cAdvisor Metrics接口去做的数据汇总。最初陌陌采用的方式是利用Python脚本，去调用接口，在取到一些CPU内存、网络、流量的数据，存入ES，分析之后进行展示。之后的报警系统，是利用Java应用去调取Kublet cAdvisor Metrics接口，进行数据的收集。

基础监控指标主要有内存（total、rss、cache）、流量（incoming、outgoing）、网络packets（drop、error、total）等。

应用迁移方面，陌陌做了很多适配工作，使得应用不需要太多的改动就可以无缝迁移。具体适配细节如下：

在应用迁移过程中，也遇到了一些问题，如Swap、CPU软中断优化、资源利用率、Ip白名单、适用于内网等问题。

当前，陌陌的容器业务规模服务器约400台、线上容器6000、应用700+。应用的类型是Java + PHP + Node + Python + Tomcat。

希望运维可以实现对应用请求量，线程数，流量等指标的监控。基准值部分，达到单实例可承载请求量，线程数，流量。伸缩方面，做到最小保留实例数，最大扩容实例数，根据监控反馈和基准值计算需要扩容和缩容的实例数, 按照各个集群资源余量按比例伸缩。