数人云|当K8S赶上微服务-京东金融PaaS平台思考与实践

8月19日的数人云Container Meetup上，张龙老师作了《基于Kubernetes的PaaS平台的设计和思考》的精彩分享，分别介绍了PaaS平台的意义，为何选择Kubernetes，PaaS平台上的微服务架构应用，如何设计和快速构建PaaS平台，PaaS平台的功能组件这几个内容。

如下为现场实录内容——

今天跟你们分享下基于Kubernetes的PaaS平台设计和思考，主要分为五个部分：

• PaaS平台的意义
• 为何选择Kubernetes
• PaaS平台上的微服务架构应用
• PaaS平台架构设计
• PaaS平台功能组件

PaaS平台的意义

不少公司技术支持岗位的工做，如配置域名，部署环境，修改复位配置，服务重启，扩容缩容，梳理和完善监控，根据开发的须要查找日志等工做，须要和开发进行大量的沟通，如什么是外网域名，什么是内网域名、A name、C name，防火墙规则该如何设定，操做系统等基础环境须要什么依赖。由于不少研发不了解运维的术语和知识点，致使沟通困难，效率很低。并且这样的需求还不少，把运维压的喘不过气，占用了几乎全部的时间，可是开发的需求可能仍是迟迟不能知足。

这样的公司可能遇到了如下问题：

• 系统架构过于陈旧，性能、可靠性没法知足现有的需求；
• 原有IT架构不灵活，业务模块新增或变动带来巨大成本压力；
• 系统功能繁杂，结构紊乱，定制的代码与系统耦合性极高；
• 服务种类繁多，各类技术栈横行；
• 人员流动交接不充分，新接手的团队对部署环境不了解，只能作周边的修补，不敢迁移 。

如何才能解决？答案是流程化、标准化、自动化、平台化。

流程化

即主动梳理运维工做任务，造成标准化的操做流程，尤为是针对须要多人协做完成的任务，好比应用的发布部署，把流程固化到流程平台系统中，保证每一个人执行都能按照流程严格执行，不会有哪些环节遗漏，并且当前的流程状态对全部人均可见，能清晰的看到谁正在处理，处理人也会更主动尽快的完成该任务。

标准化

从架构角度按照应用类别制定应用的部署标准，好比Web类型的应用，服务化的应用（咱们内部用的JSF），或者是比较新的微服务的应用（Springboot等），部署脚本和工具平台按照约定好的规范进行设计开发，减小了由于应用种类繁多致使工具和平台的复杂。

自动化

早期写了很是多的脚本，任务执行机到要执行任务的服务器之间经过SSH免密钥认证，再根据须要批量执行命令。随着服务器规模和应用数量的扩张，很快脚本执行的方式没法知足业务发展，难以理解，同一个类型的任务多个脚本并存，存在误操做，缺少清晰的操做历史记录和回滚机制，即便后续替换了如Puppet，Saltstack，Ansible这样的配置管理工具，但根本问题并无解决。

※ 平台化

平台化是此次分享的重点，必定要在前面三条的基础上进行建设，若是没有清晰的流程，明确的标准，平台建设起来也只是自动化工具的集成，解决不了公司核心问题。

如下说的平台化内容主要是PaaS平台化，即主要从应用和中间件的角度，这里不讨论IaaS的内容。

PasS平台化将问题的关注点从基础资源上升到了应用层面，目标是提供一个帮助开发人员运行、管理应用的平台，让使用者更关注运行的代码（业务逻辑）。

PaaS能解决的问题：

• 应用聚合：如开发须要一个Redis，直接启动一个Redis容器便可
• 服务发现、快速伸缩、状态管理等
• 服务监控、恢复、容灾
• 费用统计：提供计算资源信息汇总，针对不一样项目收费
• 安全管控：无论什么平台，安全都很是重要，例如A应用能够访问B,B不容许访问A以及安全审计等。
• 快速部署。

随着Docker容器技术的出现，让咱们有了更合适的工具建设PaaS平台，具有了基于应用构建服务的能力。

在Docker容器调度框架上，咱们又选择了Kubernetes平台。

为何选择Kubernetes

先列一下目前三大主流的容器调度框架的功能和特色：

〓 Kubernetes

资源调度、服务发现、服务编排、资源逻辑隔离、服务自愈、安全配置管理、Job任务支持、自动回滚、内部域名服务、健康检查、有状态支持、运行监控/日志、扩容缩容、负载均衡、灰度升级、容灾恢复、应用HA。

〓 Mesos

Mesos是一个分布式内核，目前的发展方向是数据中心操做系统（DCOS），它同时支持 Marathon、 Kubernetes 和 Swarm 等多种框架，Mesosphere 也是 Kubernetes 生态的一员。

注意Marathon的技术栈是Scala语言，而Docker和Kubernetes的技术栈都是Go语言。

〓 Swarm

从Docker1.12版本开始，Swarm 随Docker一块儿默认安装发布，也因为随Docker引擎一块儿发布，无需额外安装，配置简单。

支持服务注册、服务发现，内置Overlay Network以及Load Balancer。

与Docker CLI很是相似的操做命令，对熟悉Docker的人很是容易上手学习。

每一种工具都有本身的核心理念。

Mesos理念是数据中心操做系统（DCOS），为了解决IaaS层的网络、计算和存储问题，因此Mesos的核心是解决物理资源层的问题。

Kubernetes的核心是如何解决自动部署，扩展和管理容器化（containerized）应用程序。

因此，我的认为Mesos和Kubernetes是两种维度，对于咱们的场景来讲，关心应用的状态多于物理资源层管理，所以更关心的是容器化应用程序管理，这是咱们选择Kubernetes的主要缘由。

另外选择Kubernetes还考虑了其它优点，如：

• 出身名门Google，其开发和设计受到了Google著名的Borg系统的影响；
• GitHub上关注Kubernetes项目和提交代码的开发者很是多，社区活跃，若是遇到问题，经过社区咨询和解决 问题速度也会比较快。
• Kubernetes能够很好的支持有状态的服务。

PaaS平台上的微服务架构应用

再来看一下我眼中的基于当前最流行的微服务架构的设计是什么样的，即咱们PaaS平台上要运行的典型应用是什么样的。

用户端的请求进来之后，首先进入前端的Nginx服务器，再进入Zuul代理网管上，由Zuul将这些任务下发到不一样的服务上去。Eureka集群做为注册中心服务，提供服务的发现和注册的功能。服务后端再去调用依赖的其余服务，数据库集群，Redis集群等服务。

微服务架构由于有注册中心自动解决了服务注册发现的问题，因此对内部服务来说就不用依赖传统的负载均衡器等工具，很容易将各个服务Docker化，迁移到PaaS平台里统一管理。

PaaS平台架构设计

平台建设原则

在建设PaaS平台以前，参考《高效人士的七个习惯》设定了PaaS平台建设的原则：

1. 以终为始：作一件事情要知道想达成什么样的目的，知道这个目的以后，就可以围绕这个目标采起一些措施。
2. 知己解彼：做为一个运维人员，须要有一个比较大的知识面。只有如此才可以去制定一些适合本身的方案和产品。
3. 积极主动：由于要作PaaS因此要把本身的主观能动性都调起来。
4. 要事第一：上面说了不少PaaS相关的内容，因为时间、人员的限制。如何从众多的基础组建中挑选出来最重要的一些事情，着手建设。
5. 共赢：作出来的系统最好是可以达到对开发、运维、公司都有利。
6. 统合综效：对待一样的一件事，每一个人都会有本身的看法。同时也要问同伴，要把全部的观点都收集起来作一个综合分析对比，以收到更好的效果。
7. 持续更新：时刻提醒本身持续学习，拥抱变化，这样才能看到平台的不足。持续迭代出更好的产品。

基于以上的原则，咱们团队勾勒了一个最小化的PaaS图：

1. 最上面的Ingress服务跟传统的负载均衡器的功能相似，提供请求分发的功能。
2. Service至关于后端Pod的一个代理服务器，Service须要经过Ingress服务才能被外部Client访问。
3. Pod则至关于咱们传统的一个服务。
4. 最小化PaaS平台还用到了DNS组件，在内部服务运行起来以后，咱们会经过DNS组件分配一个内部域名供访问时使用。

Kubernetes对外提供服务，用的是Lvs+Ingress，每次添加一个新的服务以后会调用一次DNS的API，按照规则生成一个内部域名供访问使用。

平台关键能力说明

应用持续部署

平台实现快速、可视化自动部署功能。支持对应用的快速、可视化部署。用户仅需在界面中选择相应的镜像和组件，并填写简单的配置信息，点击部署按钮，便可完成整个应用的安装或者升级。在测试环境可经过Jenkins，可实现应用的持续集成和全自动化升级，同时支持一键回滚和恢复发布功能。

应用弹性伸缩

构建具备需求预测和容器按需供给能力的弹性伸缩子系统，具备基于应用的负载和资源状况进行弹性伸缩能力，以应对互联网用户高并发的特色，应对流量冲击。其中，包括容器弹性伸缩、物理机弹性伸缩功能。

容器和组件的统一管理

从总体应用的角度出发，平台不只管理镜像和容器，而是将一个应用涉及的全部组件均作了统一管理，好比对前端的DNS、负载均衡（F5/Nginx），后端数据库等的管理。经过对系统相关组件和容器统一管理，平台将能够实现系统的全局统一部署、配置、升级/回滚、监控、故障处理等功能。

高可靠性

容器的故障恢复，当服务器宕机时，平台系统会自动在其它服务器上从新启动容器并为其分配资源，从而达到秒级启动，恢复业务。保障业务不掉线，高可靠运行；镜像仓库的可靠性，经过将单机版的镜像仓库扩展成镜像仓库集群，从而提高性能，实现Registry的无状态化，便于实现服务的高可用性。

应用docker化封装

系统支持以下几类常见应用：Tomcat、Jboss、Nginx、Redis、Zookeeper等。

PaaS平台功能组件

具体实施时，主要有几个基础组件须要开发：

〓 镜像管理

实际运行的应用镜像由 “基础中间件镜像”+“应用包”+“配置” 自动构建，无需开发人员理解镜像概念和手动制做镜像；

〓 DNS管理

定制化公司内部使用的DNS管理平台，对公司的DNS进行统一管理；

〓 服务管理

须要定制化一套Kubernetes的Deployment模板，从Ingress到Service再到RC都定义在这套模板里面，方便对容器进行扩容、缩容、删除操做；

〓 服务内pod管理

属于Kubernetes自有范畴，查看Service内的Pod运行状况、Pod日志输出等功能；

〓 日志管理

将日志输出到公司的日志平台（如ELK平台），对接研发人员排查问题、数据埋点使用。

〓 监控管理

参考方案cadvisor+influxdb+grafana/ heapster+influxdb+grafana/Prometheus/zabbix.

一个中小企业作成这样后，平常运维的工做量便可大量减小，两三我的就能完成平常的应用运维工做，有兴趣地话能够去挑战一下。固然作完这些后，还只是一个小型的PaaS平台。

若是是再复杂一点的PaaS平台，应该还有哪些要继续作的呢？

环境管理：即一套平台管理多套不一样的Kubernetes集群。安全管理、流程管理、计费管理等功能模块。

还有由于规模增长和更高的可靠性要求，对应的网络，IO等各类优化。

其实还有不少功能就不一一列举了，能够根据本身的实际状况添加功能模块，设计有本身公司特点的PaaS平台。