云萌主-BIGSAAS旗下 - Powered by Discuz!

云萌主云应用官方论坛 › 首页 › 资讯 ›

分享到

【转载】乐视云基于Kubernetes的PaaS平台建设（下）

资讯 2017-2-16 11:03 717人浏览 0人回复

来自: CSDN 收藏分享邀请

摘要

2014年乐视云开始尝试Docker的推广和使用，我们的团队开始开发第一代容器云平台Harbor （分享网址：http://dockone.io/article/1091 ）。（在这里提醒一下，这与VMware公司中国团队为企业用户设计的Docker Registry ...

每一台Nginx主机上都会安装一个Agent，每个Agent监控他所属的groupid 的key，比如/slb/2/，这样可监控本Nginx 集群下所有Domain的配置变化，Agent 将变化过的Domain 配置更新到Nginx下的目录下，并判断配置变化是否是更改的upstream下的Server IP还是其他配置，如果发现是其他配置更改，比如location或者增加header，则会reload nginx，如果发现单纯更改upstream 下Server IP，则直接调用Nginx动态更改upstream ip的接口。

上层的slb-core 则会提供domain动态更改后台upstream ip的接口，供服务发现调用。

如果多个互相关联，互相调用的业务域名都同时被一个Nginx集群所代理，若其中一个domain需要更改配置，导致需要reload nginx，很可能会出现reload 时间过长的问题。

基于这套架构，后端Nginx主机可以快速扩展，迅速增加到对应集群中。由于增加了nginx test机制，当用户更改domain的配置有语法问题，也不会影响负载均衡，还会保持上一个正确的配置。现在这套架构已经是乐视负载集群的通用架构，承载了乐视上千个域名的负载均衡。

用户在创建一个应用时候，如果需要负载均衡则需要填写负载均衡域名，Nginx集群等信息，如下图：

创建成功后，通过查看应用的负载均衡导航栏可以知道这个应用负载均衡的CNAME和VIP信息，等业务测试成功后，DNS系统上配置使域名生效。

如下图：

下图可以让用户查看负载均衡Nginx配置信息：

现阶段Nginx负载均衡集群并没有按照一个应用来进行划分，大多数情况是一个Nginx负载均衡集群代理了多组domain。因此对于用户端，为了防止业务线用户恶意或者无意的随便更改，而导致整个Nginx集群出现问题，现阶段用户端无权更改Nginx配置，如果需要更改特殊配置，需要联系管理员，由管理员进行配置。后续我们会考虑给一个应用分配一组Nginx容器进行负载均衡代理，这样用户就会拥有Nginx配置更改的最高权限。

LeEngine registry

LeEngine Registry是我们内部提供的镜像仓库，根据Docker Registry 2.0 版本：docker distribution做了修改，支持乐视Ceph后端存储，同时使用auth-server 以及LeEngine 的权限机制，定义用户和权限划分。允许镜像私有和公开。公开的镜像任何用户可以执行Pull 操作。私有的镜像可以添加团队成员，不同角色的成员具有不同的Push，Pull，删除权限。基于以上的设计LeEngine Registry 可以完全独立于LeEngine对外提供镜像仓库服务，业务线如果不想使用LeEngine的代码构建功能，可以完全使用自己的构建方法，构建出镜像来，之后Push 到LeEngine registry中。

如下图是关于镜像tag的相关操作：

成员：

动态：

LeEngine下4大资源：应用、镜像、镜像组织、代码构建，在每个资源页里都是有动态一栏，用来记录操作记录,方便以后的问题追踪。

代码构建

为了快速将代码构建成Image，并Push到镜像仓库中，LeEngine后面会设置一组专门构建用的Docker物理机集群，用来执行构建任务，每个构建物理机都会安装一个Agent。

LeEngine的代码构建框架如下：

每个构建物理机上的agent 启动后，都会将自己的信息定期自动注册到etcd中，表示新增一台构建机，当Agent意外停止或者主机挂掉，etcd中的注册信息会失效，表示已经下线一台构建机。另外Agent会监控自己的任务key，用来接收LeEngine-core下发的构建任务。

当有一个构建请求时会调用LeEngine-core的API，LeEngine-core会从etcd中选出一个合适的构建机（一般按照hash方式，尽量保证一个代码构建在同一台物理机上构建，加快构建速度），然后将构建任务放到这个构建机的任务key中，对应的Agent监控到key变化后，会执行代码Clone，编译，Build和Push操作。

Etcd在LeEngine中扮演这非常重要的角色，是各个模块通信的消息总线。

鉴于Maven项目，需要编译，在第一代Harbor系统中，编译步骤放在了Docker Build 过程中，由于Maven编译需要大量的mvn依赖，每次编译都需要重新下载依赖，导致编译时间长，编译的镜像多大，因此我们在Build之前，会起一个Container，在Container中对代码进行编译，并将mvn依赖的目录映射到主机上，这样同一个代码构建，在每次构建时候，都会共享同一个mvn依赖，不需要重新下载，加快编译速度，同时还能保证不同的代码构建使用不同的mvn依赖目录，保证编译环境绝对纯净，最后只将编译好的二进制打到镜像中，在一定程度上保证代码不外泄。

代码构建仅限于放在Git上的代码，现阶段并不支持SVN，因此有的业务如果代码在SVN上，可以使用其他工具自己将代码制作成镜像，然后Push到LeEngine Registry上。由于LeEngine Registry上对镜像和镜像仓库做了权限认证，保证了镜像的安全。

代码构建支持手动构建和自动构建，在GitLab上设置相应的Web hook，这样用户只要提交代码，就会自动触发LeEngine的代码构建功能。

下图为创建代码构建的Web页：

使用LeEngine的代码构建，我们要求用户的代码里需要自己写Dockerfile，Dockerfile 里FROM 的根镜像可以使用LeEngine Registry 里公开的镜像，也可以使用Docker Hub里公开的镜像。

如果业务代码需要编译，则可以指定编译环境，编译脚本也是需要放到代码中。

下图为手动构建页面：

tag名如果不写，LeEngine会根据当前分支下的commit号作为镜像tag名。如果选用mvncache，则本次构建就会使用上次构建所下载的mvn依赖，加快构建速度。

下图为构建结果：

构建过程：

构建日志中，每一关键环节都记录了耗时时间，以及具体的执行过程。

应用管理

应用支持垮机房部署，多版本灰度升级，弹性伸缩等功能。我们规定一个应用对应一个镜像。

部署版本（一个版本即一个RC）时候，需要指定镜像tag，容器数目，CPU，内存，环境变量，健康检查等等参数，现在的健康检查我们暂时只支持http接口方式：

由于大部分的升级，都是更改镜像tag，因此每次部署新版本时候，LeEngine会在新弹出框内，将上一版本的容器数目，CPU，内存，环境变量，健康检查等等参数自动填充到弹出框中，用户只需选择新的镜像tag就可以了。因此最后灰度上线，只需要创建新版本等新版本的容器完全启动，服务自动加入负载均衡后，再将旧版本删除即可。

下图为应用事件查看：

应用事件主要收集的是应用在Kubernetes集群中的事件信息。

监控、告警系统

监控报警我们分PaaS平台和业务应用两大类。

PaaS平台主要聚焦在基础设施和LeEngine的各个服务组件的监控报警（比如主机CPU，内存，IO，磁盘空间，LeEngine各个服务进程等等），这一类使用公司统一的监控报警机制。

业务应用类，也就是跑在LeEngine上的各个业务线的监控和报警，需要由LeEngine进行对其进行监控和报警，触发报警后，会通知给各个应用的负责人。我们采用了heapster 来收集容器的监控信息和Kubernetes的各种事件。每个Cell集群中都部署一个heapster，监控数据存放到influxdb中。设定了一个应用全局对应一个Kubernetes的Namespace，因此我们能很好的聚合出应用和单个容器的监控数据。

如下图针对应用的网络流量监控：

容器 IP，运行时间和状态：

下图是针对应用下单个容器的监控：

现在heapster 没法收集容器的磁盘IO数据，后期我们会增加对于磁盘IO的监控收集，同时我们会丰富其他的监控数据（比如请求量等等）。关于报警，我们后期准备使用kapacitor 进行用户自助化报警，让用户自定义设定针对于应用cpu，内存，网络，IO，容器重启，删除等的报警阀值。触发报警后，会调用公司统一的告警平台（电话，邮件，短信三种方式）对相关人员进行报警。默认报警人员为当前应用的Owner和Master角色的成员。此功能已经基本调研完成，计划3月底上线。

日志收集

根据公司具体状况，容器的日志收集暂时还没有纳入LeEngine范围内，全部由业务线自己收集，然后统一收入到公司的日志系统中或者由业务线自己搭建日志存储和检索系统。我们后期会考虑日志统一收集。

总结

一键式解决方案

LeEngine提供了代码构建，镜像仓库，应用管理，基本上实现了开发者一键式解决方案：

各个业务线开发人员只需要提交代码，剩下的就会根据打包和构建规则自动生成特定的镜像版本，测试和运维人员只需要拿着对应的镜像版本进行测试和线上升级即可，极大简化开发运维工作。

减少运维成本

我们建议程序在容器内前台启动，利用Kubernetes的功能，程序死掉后，由kubelet自动拉起，实时保证线上容器实例数。若需要调试，业务或者运维可以直接通过SSH连接到容器内排查问题。由于Kubernetes强大的容器自动迁移功能，即使后端物理主机出现宕机或者网络问题，也不会产生严重的问题，除非后端物理计算资源不够，这在很大程度上减少了运维人员大半夜被叫起处理问题的次数。

计算资源对业务完全透明

底层计算资源完全由我们提供，业务线不用担心资源的问题。

产品化

LeEngine在设计之初，保证尽量少的依赖其他外部资源和服务，整个LeEngine可以作为一个解决方案整体对外输出。

存在的问题

任何一款产品不管怎么设计，都有它的不足之处，LeEngine在上线之后，我们也收到了不少反馈和问题。

按照之前的运维习惯，运维人员在排查问题时候，经常会根据IP来进行区分，而LeEngine下的应用每次升级后，容器IP都会变化，这对传统的运维造成一定的冲击。我们现在的解决思路是，如果运维人员一定要通过IP去排查，我们会让运维人员登录LeEngine的Console，查看当前应用下的容器IP列表，之后再去逐个排查。同时有的业务会对IP进行访问限制，针对这种情况，我们只能让这些业务对一个IP段进行限制。
Kubernetes 1.2版本，对容器的swap并没有控制，若业务应用有bug，出现大量的内存泄露，往往会把容器所在物理机的swap吃满，而影响了物理机上其他的容器。我们现在的解决方案暂时只能通过报警方式，尽快让用户修复问题。
由于Dockerfile 和编译脚本都要求放在用户Git代码中。会存在用户Git使用不规范，不同分支代码互相merge，导致Dockerfile和编译脚本出现变化，导致构建出的镜像与预期的不一样，从而上线失败。这种问题，我们只能要求业务线规范Git使用规范，LeEngine代码构建本身已经无法控制到这种细粒度。
现阶段我们还没法做到自动弹性扩容（给应用设定一个最小容器数目和最大容器数目的阀值，根据CPU、内存、IO、请求量或者其他值，自动觉得容器是否需要扩容，缩容）。