云计算】从Serverless谈边缘计算的未来；从物理机到Kubernetes的那些坑与启示
本文根据谭霖老师在〖2017 GdevOps全球敏捷运维峰会北京站〗现场演讲内容整理而成。
讲师介绍
谭霖，滴滴出行弹性云架构师、云计算专家，曾任职于英特尔从事云计算方向研究。OpenStack Ironic 项目核心开发者，《OpenStack设计与实现》作者，多次在OpenStack Summit SRECon峰会上分享Topic。目前从事基于Kubernetes的私有云平台的研发，专注提高服务的稳定性和研发、运维效率。
今天我将带来一些关于滴滴弹性云的分享，标题是从物理机到Kubernetes的那些坑与心得。
先简单自我介绍下，我叫谭霖，之前曾在Intel从事于Open Stack相关的工作，也花了很大精力在开源社区这一方面，后来我来到滴滴的弹性云团队，主要从事基于Kubernetes的基础平台建设，可以说是从一个做菜的“厨师”变成了一个“食客”。
主题简介：
1. 整体架构
2. 产品功能
3. 方案细节
4. 心得展望
在我们准备做弹性云时，我们问了自己三个问题：
1. 为什么要做私有云
2. 为什么选容器
3. 为什么选Kubernetes
这个其实是最好回答的。因为滴滴的集群规模太大，有数万台物理机（这样的规模量要求我们做一个私有云平台），结果因为之前没有一个比较好的方案，造成了资源使用率特别低、资源浪费大的问题。
另一个主要原因是滴滴的发展太快，总有新的业务，隔一段时间就听说成立了一个新的部门，而且随着新需求的出现，更新迭代异常频繁，这些都对平台的稳定性提出了特别高的要求。这个问题靠堆人是解决不了的，所以需要有一个好的平台和机制来解决它。
这个问题也比较好回答。KVM / Xen这样的传统虚拟化已经出现多年了，很稳定，但大家也知道其弊端，就是损耗比较大。另外，传统混部也就是滴滴现在在用的方案（即继续保持原有的传统混部），虽然能够部分解决资源使用率低的问题，但因为完全没有隔离，导致程序之间容易互相影响。
而容器是一个相对折中的方案，具有一定的隔离性、损耗更少，这是我们选择它的最主要原因。同时，更重要的是容器的镜像所带来新的玩法，因为镜像的环境是一致的，对运维人员特别友好，因此他们不用再关心那些纷繁复杂的配置文件，也不用频繁地走初始化流程，更不用每次上线更新都提心吊胆，担心会对新的服务造成影响。
现在这个问题就比较容易回答，但一年前是个比较艰难的选择。大家都知道现在比较著名的容器平台有Mesos、Kubernetes 和Swarm，一年前我们在Mesos和Kubernetes之间犹豫过很久，后来主要觉得因为我们要做的是一个基于容器的平台，相比Mesos，Kubernetes更专注容器。
而Swarm当时还很年轻，很多功能不够完善，相较之下Kubernetes更成熟。当然更关键的原因是Kubernetes的社区更有活力，设计架构也更清晰，可拓展性也高。
现在回过头来看一年前的选择，非常很庆幸我们做了正确的选择，因为之前相较于两者，Kubernetes还只是旗鼓相当，而现在则有一统*的趋势。我们目前还是基于Kubernetes1.6版本做的改造，接下来1.8版本release之后，我们会尽量跟上保持和社区同步。
滴滴弹性云的目标就是基于容器技术，为滴滴提供稳定高效、可伸缩的服务管理平台。先简单看看弹性云的项目历程。
2016年7月，弹性云项目正式启动，然后10月份出了第一版，2017年4月，发布了第二版。在几个月的使用体验中，我们根据用户的反馈，不管是产品形式还是底层网络方案都经过大规模优化。目前第三版也正在开发中，这一版会更侧重用户交互和可视化上。
截止到目前为止，我们总共有300多台宿主机，2000+的容器实例，不算很多，但目前有多条滴滴核心业务线跑在我们的平台上，预见2018年规模会有指数型的上升。
我们的整体目标有四点，主要是为了解决先前提出的三个问题，如下：
实现资源按需分配，提高资源利用率；
实现资源的弹性伸缩，可以快速响应负载变化；
基础环境保持一致，实现服务的快速交付；
保证服务的容错性，实现基础设施免运维。
针对不同的产品线和需求，我们具体落地的产品解决方案主要分为两大块：一个是基于容器构建的轻量级虚拟机，叫做静态容器组；第二个是更纯粹的微服务类容器，我们称之为弹性伸缩组。同时我们还整合了滴滴现有的部署监控和日志收集系统。
这是整体的架构图，中间最大的一块就是我们的K8S集群，它主要分成控制节点和工作节点两部分。上面一块是我们的控制台和管理员入口，左边是滴滴的一些现有的权限认证系统和服务树，右边是我们的网络方案。
所以按照流程我们主要做的操作有用户先通过权限系统认证后，创建服务（也就是K8S的实例），实现容器的扩容缩容和部署更新。之后我们平台就会进行实时监控和日志收集，完成监控数据的上报和镜像拉取。
刚才说的主要是管理员相关的工作流程，现在看看用户流量。首先我们这边实现了每个容器通过IPAM组件，都能获取一个独立的IP，这个IP可以和物理机双向互通，所以允许用户的流量可以直接通过容器IP访问实例。同时我们也提供了一个4层的LB，允许用户可以通过只访问一个VIP，自动把流量打到后面的容器里。
接下来详细讲讲滴滴弹性云具体的产品功能。
正如之前所说，我们主要提供静态容器和动态伸缩两大产品，同时伸缩组方面又细分为有状态和无状态伸缩组。
其实在刚开始时，我们只想提供K8S支持得最好的Deployment，也就是无状态伸缩，这也是最符合容器使用习惯的产品形式。但在实际落地的过程中，我们发现完全不是那么一回事。
首先，不是所有程序都能比较轻易地改造成Cloud-Native的服务，所以针对这样的传统服务，我们还是需要提供一个比较贴近物理机的用户体验的产品，它的问题就是不能弹性伸缩，但好处是可以挂载本地存储，IP是恒定的。
同时为了支持有状态的服务，我们也提高了有状态伸缩组。既支持弹性伸缩又支持挂载网络存储。不过比较出人意料的是，用户选择有状态伸缩组的很大一部分原因并不是因为挂载Ceph，而是因为有状态伸缩组的容器IP/HostName是不变的，这样不管是从监控和日志上，都是更友好的。
而无状态伸缩我们这个当初最想推动的服务，也就只有在一些对弹性伸缩速度有特别高的要求的场景下才会用到。
具体到产品功能的特性上，我们主要有三大块：复杂配置简单化、上线流程标准化和服务管理。
1.复杂配置简单化
了解过K8S的朋友们都清楚，它上手很难，有特别多的配置，有时候反而给用户带来了困扰。所以我们做了减法，简化了很多配置，只留给用户一些接口，避免不必要的困扰。比如我们支持多种接入方式，既可以一键完成从Git代码仓库到上线镜像的转换过程，也支持直接通过自定义镜像。
同时我们也对镜像做了分层（基础镜像→环境镜像→服务镜像），实现RD和SRE每个角色负责不同的镜像制作，这样分工更合理、层次更清晰，做到比较好的权责分明、高效有序。监控日志自动配置关联也是做了减法，希望用户较少关注这一点，从而得到更好的体验。
2.上线流程标准化
相对于减法来说，我们也做了很多的加法，因为我们是一个严肃的运维平台，之所以强调严肃，是因为只要有人参与的地方就容易犯错。一方面我们要尽量减少人工参与的地方，另一方面又要尽量通过各种规范来减少人犯错的机会。
比如变更审批系统，每一次上线变更都需要开发leader的审核；同时也对它进行了改造，使其每次分组小流量灰度；每次发布更新的过程中都有强制的观察时间，如果在观察过程中，比如说你发布了第二组后，发现你的更新过程中代码出了BUG，我们还支持了一键回滚。
3.服务管理
在服务管理方面，我们实现了服务不可用自动重启、一键扩容和负载均衡等，最为重要的就是对用户强制异地多活，必须在我们的两个机房都有实例。
上一篇：
基于 Java 的网吧计费管理系统的设计和开业报告的实施
下一篇：
代码