得到App是较早践行微服务架构设计的技术团队，众所周知，微服务带来最大的挑战是管理和运维。从2017年初开始调研，经历VM、Swarm、Kubernetes的两次变迁，到现在已经有两年的时间，目前容器平台运行了约70%的服务，支撑了约80%的流量。本次分享将围绕降低容器和Kubernetes使用门槛、项目标准化和容器设施的易用性展开，希望我们的经验对有计划使用Kubernetes和打算将服务容器化的企业有所帮助。
罗辑思维作为一家创业公司，产品得到App的后端服务目前主要运行在阿里云。由于技术选型比较“激进”，并且践行微服务架构设计，目前的语言栈按照占比排名有：Golang、Node.js、Python、Java、PHP、C++，之前使用云主机（ECS）带来的运行环境管理复杂、发布过程不统一等问题。所以，将应用容器化以及微服务治理，一直是较为迫切的需求。
从2013年底Docker开源，到现在已经发展了超过5年的时间，大家已经听说容器技术的优势和收益并逐渐接受准备拥抱之。但想要落地容器以及容器管理系统Kubernetes这种新一代基础设施，远没有想象中容易，在新技术落地的过程中，阻碍往往不是来自于技术本身，而在于观念的更新、生态的丰富以及易用性。
容器技术的应用
想要落地容器技术，首先是目标的确立，类似“把大象放进冰箱”分为三步：打开冰箱，放进大象，关上冰箱。我们将容器技术落地的目标也简化为三步：代码镜像化，容器化部署，微服务治理。
其次离不开大量的内部推广、布道，以及不厌其烦的各种支持，这对运维团队的要求很高，需要有人能够对编程语言栈和容器技术以及运维工具有较深了解，才能打通整个流程。在概念层面简单化，在内部我们统一将容器类比为“进程”，Kubernetes类比为管理进程的“操作系统”，工具平台简单易用，使开发人员只关注业务。
最后由运维牵头，开发协助，制定出一系列规范和流程，阶段性总结和周知，收集反馈、改进工具，总而言之，微服务治理，是一个从上到下的系统工程。
目前状态
目前得到App的主要运行环境是Docker + Kubernetes，包括测试（联调等）、预发布、线上几个环境。少量不适合容器化和历史项目运行在ECS（云主机）中。约70%项目和80%流量已经运行在Kubernetes管理的容器中，还有Swarm集群也在运行服务，即将结束的2019年Q1完成全面落地Kubernetes，到时候下线Swarm集群。
里程碑
回顾容器在得到App落地的过程，有几个关键的时间节点，希望能对大家评估落地时间有所帮助。
2017年3月，立项
2017年5月，Swarm集群方案
2017年8月，配套建设，开始小范围业务迁移
2017年11月，商城业务完成迁移，经历高并发考验
2018年3月，调研Kubernetes
2018年5月，Kubernetes设计方案
2018年8月，围绕Kubernetes配套建设，开始小范围业务迁移
2018年11月，部分业务迁移，经历高并发考验 2019年3月，完成落地
因2015下半年到2016年期间以Docker为首的容器技术火爆，我们在2016下半年进行前期关注，2017年初开始立项，2017年5月份完成基于Swarm的容器管理方案设计，2017年8月份完成集群及周边建设、发布系统初版开发，开始小范围业务迁移，2017年11月份完成商城业务的迁移，经历了全链路压测和跨年活动的考验。2018年3月份开始调研Kubernetes，5月份完成设计方案，8月份完成集群搭建和新发布系统初版开发，开始小范围业务迁移，11月份完成部分业务迁移，经历全链路压测和跨年活动的考验，即将结束的2019年Q1将完成全部项目迁移工作。
前置条件
这里简单罗列了一下前置的规范制定：
统一各语言运行时版本（建议最多3个），汇总各种模块列表
统一base镜像操作系统发行版、版本、汇总默认安装的常用工具
制定命名规范，使用能够描述项目用途的名字，域名≈项目名=发布系统内名字
镜像分3层：OS、runtime、code
编写OS、runtime的base image
编写Dockerfile和entrypoint模板
框架中提供探活API，Liveness、Readiness、Graceful Shutdown等
统一日志格式，建议access日志为单行json，相对Nginx或httpd默认的空格分割字段方式，字段较容易扩展，反序列化友好，并且能够支持命令行工具分析。
服务分级，对项目根据重要程度和影响面进行分级，不同级别服务的发布流程、SLA要求各不相同。
有了这些前提条件的加持，后续容器落地效率会有很大提升。
技术方案
架构
从2018年起，得到App的技术团队对于微服务治理和DevOps推进做了大量工作，产出了很多工具，右上角的Tools矩阵，大部分是2018年诞生的，目前看已经有了很大的成绩。
Kubernetes在底层基础设施跟上层微服务治理工具中间，起到了承接作用。
网络
网络组件使用Flannel + alivpc Backend，目前我们的服务全在阿里云VPC网络，该方案设计简洁，比较稳定，通过写入vRouter路由表方式，来达成容器网络与ECS网络对等，实现了容器IP与ECS IP互通。
服务治理
Artemis框架
服务发现
APM（tracing）
API Gateway
对于服务治理，我们是在2018年初启动，这方面我们的思路是：用规范和约定来将编程框架和基础设施打通、应用以编程框架的形式连接基础设施。
自研的框架Artemis，集成了服务注册和配置中心以及tracing功能。
服务发现和配置存储使用Consul，每个容器中主服务进程启动前会启动一个Agent，该Agent会将IP地址及模块信息注册到服务发现中心，并跟Consul保持心跳，Agent启动时会拉取全量数据并缓存到本地，同时接受服务发现中心的push。当容器挂掉时，由Consul的监控程序进行剔除，但容器主动退出时，Artemis框架会捕获SIGNTERM、SIGNKILL、SIGNQUIT信号，通过Agent进行服务注销。服务间所有调用需要经过本地的Agent，使用IP直连的方式，多实例的负载均衡也在本地的Agent中实现。
API Gateway基于服务发现服务发现中心的数据，进行后端实例的注册。
APM作为链路追踪、问题分析的首要工具，给开发人员提供便捷的排障支持。
配置管理
两部分：配置中心，配置文件
对于配置，没有使用ConfigMap来存放应用配置，因为目前正在推进配置中心，现状是配置文件和配置中心共存的方式，应用启动时默认去配置中心查找，查找失败时会降级使用项目代码中的配置文件。使用配置中心的方式，切换不同环境的配置文件较为灵活，对于配置文件方式，不同环境的配置文件通过entrypoint.sh切换，entrypoint.sh脚本中接收RUN_ENV变量，激活（mv、cp）配置文件。
服务间调用
DDNS（自研服务发现，容器间直接IP调用）
Service（LoadBalancer）阿里云SLB（作为降级方案）
Ingress（未接入DDNS的）
服务间调用，目前得到App内部正在落地服务发现，未来较多的是Pod间直接IP:Port调用；LoadBalancer类型的Service作为服务发现的降级方案使用；Ingress主要作为节省LoadBalancer资源，以及调试和测试环境使用。
Ingress
Ingress Controller Backend，对比了Nginx、HAProxy、Traefik等方案，最后选择了Nginx，原因是：稳定、性能好，支持协议多（TCP、UDP、HTTP、HTTP2），运维人员熟悉。
部署方式是：每个生产集群配置3台低配节点（4核8GB），通过nodeSelector或者taint功能，使Nginx独享节点，跟应用节点资源隔离。
Nginx Ingress Controller缺点是设计较为复杂，分为3层：Golang、Nginx Lua，较难定制和修改。
虽然Traefik相较Nginx Ingress Controller设计简单不少，并且是Golang开发，易于二次开发，但通过压力测试结果来看，在资源管理上，跟Nginx差距很大。
Nginx可以使用split_clients模块进行灰度发布（Canary Deployment）。
监控方案
Prometheus
AlertManager
cAdvisor
Node-exporter
Kube-state-metrics
Geb（自研）
得到App的Prometheus是部署在独立的服务器，以运行在Kubernetes集群外部的方式，通过APIServer获取资源信息，然后进行metrics pull。使用了Node-exporter，Kube-state-metrics，以及自研的收集程序Geb，来导出不同维度的度数。使用Grafana做监控数据展示，展示维度有Pod、Deployment、Node、Cluster、大盘。
当数据量大、查询较慢时，可使用Prometheus alert中的record语句，进行数据预处理，即将查询产生的结果存入新的metrics，使用新metric绘制图表和报警的rules检查，速度会有较大提升。
触发阈值后发往AlertManager，在AlertManager中根据不同的级别对告警进行路由、沉默和收敛。
通知通道有：邮件、企业微信、短信。
Prometheus
目前的监控项有：
Ingress中的url探活
CPU、内存、load
TCP连接数
文件描述符
nf_conntrack
部分监控数据收集使用了Prometheus push gateway，此种方式可以将程序中的实时数据发给push gateway，然后由Prometheus进行收集、存储。图中的Geb为开发的监控Agent，目前主要收集容器中的网络连接数据。
日志方案
ILogTail
阿里云日志服务
Filebeat
Kafka
ElasticSearch
由于自建的日志系统需要较多服务器资源，后续要花费很多精力去优化，考虑到投入产出比，使用阿里云日志服务（SLS）比较有优势，目前我们容器内产生的日志都是使用ILogTail收集发往SLS，使用阿里云监控的日志关键字监控功能监控错误日志中的特定关键字。
Filebeat目前只负责收集APM产生的Trace日志，发往Kafka，由日志处理程序来进行消费，处理后序列化到ElasticSearch。
日志收集
DaemonSet
持久化stdout日志
Pod更新后删除原始日志文件
日志收集Agent使用HostPath
Pod使用EmptyDir易失性存储方式，将日志写入磁盘，filebeat和ilogtail通过HostPath挂载形式收集，以DaemonSet方式部署，每个Worker节点上部署一个Agent。
发布系统演进
up（Git）
Dozer（Swarm）
Chons（Kubernetes）
得到App创立初期，运维同学编写shell脚本（rsync等工具）进行发布。后来引入开源项目walle（瓦力）发布系统，使得发布不再需要运维人员参与，并且引入了发布审核机制，大大提高了发布效率。进入容器化时代后，围绕Docker Swarm和阿里云资源开发了Dozer系统以及新一代围绕Kubernetes、支持CI/CD的Chons平台。
up
开源项目walle 1.x
Git SSH
Git Hooks
从shell脚本时代进入工具时代
需要手工管理的节点IP和ssh key
难于调试、排错
up发布系统，基于开源发布系统walle（瓦力）二次开发，其核心是围绕Git Hook。每个项目需要运维人员和开发人员协作，须经历购买服务器，初始化服务器环境，项目发版配置，调试部署过程脚本几个步骤，较为繁琐。并且发布过程调试较难。作为第一代发版系统，虽然有一些问题，但一直服役到现在，管理少量使用ECS的服务发布。
Dozer
GitLab
Jenkins
Docker Swarm
Docker Registry
阿里云监控
阿里云日志服务
阿里云LoadBalancer
阿里云OpenAPI（节点管理）
Dozer是基于Docker Swarm集群API的容器发版系统，其底层是阿里云容器服务全家桶，上层根据发布流程和规范开发了相关功能。
使用的组件有GitLab（代码管理），Jenkins（调用其API进行docker build，并回调Dozer），Swarm API（发布、调整容器数量等核心功能），阿里云监控（容器监控）、阿里云日志服务（日志收集 存储 分析）、阿里云SLB（多容器实例的汇聚和负载均衡）、阿里云OpenAPI（添加集群Worker节点）。
该方案的优点是：简单，快速，较为稳定，有容器底层技术的支持，可以将精力投在内部的落地上。缺点也是明显的，即限制较多，强依赖阿里云，有时候业务的需求由于阿里云暂未开放相关功能，不得不进行取舍。
Dozer界面（服务详情）
打包、发布
调整实例数
重启容器
进入容器
监控链接
日志链接
系统事件
Dozer的服务详情页面，比较简陋，基本上是一些链接的入口页面，但在容器落地的第一个阶段支撑了几乎所有需求，目前随着Swarm集群即将下线，它也即将停用。
Chons平台
内部PaaS
注重易用性
开发人员工作中必用的系统
构建、发布、监控、日志
屏蔽Kubernetes中的概念，但又对Manifes有所展现
抽象出Stack和Component概念
Chons项目，设计之初，目标就是一款私有容器云产品，它的竞争对手是业内容器云公司的产品。在开发迭代过程中广泛借鉴了各个产品的优点，避免它们的缺点。
它定位是：开发人员在工作中必须使用的系统，资源申请、开发、问题排查，Chons都是第一入口。
在易用性方面，屏蔽了Kubernetes中的各种概念，简化为两个概念Stack和Component。不给用户造成困扰，开发人员只关注Coding、监控数据和日志。
同时对Manifests有所展现，给希望了解Kubernetes的用户查看。
Stack
一套环境
一整套独立的服务栈
每个人可以创建
可以多套共存
基于namespace
版本化管理，可以复制、导出、导入
Component
一个服务
Deployment或StatefulSet
Service
Ingress
弹性伸缩 HPA（未来）
资源配额
域名
日志仓库
监控项
虽然Chons的设计支持一个Pod运行多个容器，但目前大部分服务的运行方式是，一个Pod中只有一个容器，容器内部有两个进程：服务发现Agent，和业务进程。
容器内无持久化数据。
Chons（Component详情）
Component详情页，为最高频使用页面。
参考多个云商产品，合并Deployment|StatefulSet、Pod、Service、Ingress、日志、监控、灰度发布、构建历史、部署历史、事件等功能。
Web Console
Web Console是把开源项目Kubernetes-dashboard中的Console前后端代码引入，原因是：该Web终端功能完善，支持颜色主题，支持bash快捷键，鼠标选取复制、粘贴，较为稳定。我们加入了iterm2中的badge功能，提示用户当前所在容器。不过该终端的后端服务单个实例负载能力有限，我们部署了多个后端服务，使用tengine的session_sticky功能进行负载均衡和调度。该Console在公司内满意度较高。
监控（Component）
监控数据展示使用Grafana，数据来自Prometheus，目前展示两个层次的数据：Component级别（即多个Pod的汇总），Pod级别。数据维度为CPU、内存、IO、TCP连接，开发人员从Chons平台中点击链接跳转过来，自助进行查询、分析。
大盘
监控大盘，主要展示资源水位，整体的状态，运维人员使用监控大盘，关注资源的分配情况，进行节点的增减。
Dockerfile模板
Golang
multi-stage构建
产出精简镜像
添加到Git中即可
简单到只需要将Dockerfile和entrypoint.sh两个模板文件添加到项目代码中即可，无需要任何修改。
entrypoint模板
Chons系统在创建Component时会默认注入一个RUN_ENV变量，entrypoint.sh脚本根据该变量值进行配置文件切换。
CI/CD
CI和CD系统是自研的，目前功能比较简单，通过接收GitLab的push和merge request hook的通知，触发CI流程。
CI系统调用Chons封装的构建API，Chons处理后转发到Jenkins进行构建，产出image，push到Registry存储，然后Chons回调CI系统API，CI系统调用Chons封装的部署API，Chons处理后转发到Kubernetes进行更新，Watch到更新完成的event后回调CI系统，CI系统继续出发后续任务节点。
在得到App内部，目前使用较多的是测试和预发布环境。
总结
遇到的问题
初期由于我们的服务器还运行在阿里云经典网络（IaaS的早期多租户网络），在Swarm集群中我们使用了overlay网络，每个容器创建或删除时，由于需要集群内部广播该容器IP等信息，随着容器数量的增加，会有同步失败情况，造成服务容器间不通问题。
得到App的服务，大部分是Golang语言开发，由于我们的服务多为HTTP短连接形式，并且如果请求的是域名的话，Golang会直接发起DNS查询，当查询量过大时会遇到“lookup failed”相关报错，需要在容器内部运行nscd服务。
内核中的TCP参数，尤其是netfilter相关，对于容器网络稳定性影响较大，图中为目前我们在使用的内核参数。
收益
分钟级部署
秒级伸缩、恢复
迭代速度成倍增长
TCO节省
简化资源管理
为微服务治理打下基础
过去，使用ECS扩容，需要人工登录阿里云管理界面 （磁盘快照、克隆节点、系统启动，预计5分钟扩容完毕）（新买实例、配置发版系统、发版，预计需要10分钟扩容完毕）。现在，自助点击修改实例数，30秒内扩容完毕。
得益于Kubernetes的优秀设计，现在运维人员不需要关注节点用途，运行环境配置等功能，每个节点都只是资源池的一部分，只需关注集群资源水位，管理工作只剩下增减节点。
通过容器的落地，简化了环境管理，统一了发布流程，屏蔽发布细节，基础设施只关注服务运行状态和端口，开放了运维能力，打通了开发和运维间屏障，是践行DevOps的基础，最终使生产效率得到提升。
未来
未来我们将会进行混合云建设，Kubernetes和容器技术的特性，使得从公有云迁到线下，以及多公有云的支持，是必不可少的前提。
后续也会在Chons中强化混合云和多云的容器调度、强化CI/CD的功能等。
希望我们的方案对创业公司有所帮助，愿大家都能够落地感受容器的便利，拥抱Kubernetes“云操作系统”！