定制化K8S自动化资源交互平台

最近，我们和深圳谷歌开发者社区做了一场关于“TensorFlow Dev Summit Recap&kubernetes技术分享”活动。活动邀请到了具有丰富开发经验的Andrew老师，他就k8s进行开发定制过程中的设计与思考，与大家进行了交流分享。

本期整理出了活动当天的干货知识，供大家参考。主要内容如下：

●资源交互平台

●docker、mesos和k8s技术

●资源交互平台功能思考

●平台功能的设计与实现

文/翼动晴空

一、资源交互平台

1

为什么要实现资源交互平台？

实现这个平台主要考虑以下几点：

●项目团队日益增多

●业务复杂度日益增高

●业务资源请求量提升

●资源维护量直线上升

从上面的图表可以可以看到，随着公司的发展，团队、项目、资源请求、资源维护量都不断提升，而对应的资源的申请响应时间也变长了，从而导致资源响应率在下降。

2

我们需要什么样的平台？

之前的资源申请，可能是这样的流程：

首先，我们申请一个资源，用于项目开发和测试，以及上线。而这个资源可能是，中间件资源，或者一些开发所需的运行环境，也可能是一些裸机的部署机器。然后，我们提交申请之后，由系统工程师进行评估，再由上级领导进行审批。最后，审批完成后，由系统工程进行资源的分配。

这样的流程，在团队和项目增多之后，就会导致响应率的下降，申请时间的变长。

所以我们需要实现资源交互平台，人员可以自助申请，资源平台进行资源评估和资源分配。

3

平台功能规划

●自助交互:开发或者运维人员可以自己进行资源申请;

●简单及时:由于平台可能面向不同岗位的人员，所以必须做到操作简单，资源下达及时;

●可操作:可以对申请的资源进行修改，按需扩容；

●互不干扰:由于平台将会供多个项目组使用，必须保证资源隔离，互不干扰；

●状态查看:平台可以查看资源状态，资源更新后，状态及时反馈至平台）；

●资源自愈:资源异常时可以自动重建，保证资源持续集成。

4

底层资源选择

了解完功能之后，我们还需要考虑具体的底层资源，比如具体采用什么资源？是物理机、虚拟机、还是其他的？

大家都知道物理机太重了，虚拟机相比物理机，比较轻量，但是还是太重了，而且可分配的数量太少，那有没有比虚拟机还轻量级的资源呢？

答案就是容器，docker。

下面主要讲讲docker，以及docker的集群的2个比较火的编排工具， mesos和k8s。

二、Docker、Mesos和K8S

1

docker

1. Docker是什么？

Docker是一个开源的引擎，可以轻松的为任何应用创建一个轻量级的容器。编译测试通过的容器可以批量地在生产环境中部署，包括VMs（虚拟机）、OpenStack 集群和其他的基础应用平台。

2. Docker可以做什么？

在不同的环境，无差别地运行成容器。

●Docker容器轻量级，即用即销，方便扩缩容。

●Docker能把系统资源变成一个轻量级的容器资源。

●Docker能把应用的运行环境及依赖打包成镜像，进而运行成容器，变成容器资源。

比如，与虚拟机对比，可以发现容器启动更迅速，硬盘使用更小，性能更接近与原生，系统支持量更多。

虽然有了docker容器，但是为了更好的管理docker，我们需要一个docker的集群编排工具，就是现在社区比较火的2个编排工具， mesos和k8s。

2

mesos

Mesos，是一个资源调度框架，采用master-slave 架构，使用 zk 来做 HA。

master资源调度，健康检测。

slave由资源节点组成，汇报资源给master，执行各种任务。

Mesos采用两层调度算法：master提供资源offer给到Framework。

Framework：对offer可以接受也可以拒绝。如果接受，则可向master指定要的资源。

由master告知slave上的执行器，按照分配的资源策略执行任务。

3

k8s

1. k8s是什么？

K8s是Google开源的容器集群管理系统，在Docker技术的基础上，为容器化的应用提供部署运行、资源调度、服务发现和动态伸缩等一系列完整功能

K8s具有完备的集群管理能力，强大的故障发现和自我修复能力、可扩展的资源自动调度机制，同时Kubernetes提供完善的管理工具，涵盖了开发、部署测试、运维监控在内的各个环节。

2. k8s的发展历程

●版本发展上，从最初1.0，1.4，再到去年推出具有里程碑意义的1.7，到目前发布的1.9版本，k8s发展很迅速。

●集群安装方式上，也从的二进制安装形式，到如今容器化，pod化的kubeadm，可以说集群部署目前是越来越简单。

●自身的特性和组件也在发展。在部署方式上，从rc，reset 到 deploment同时出现了针对任务型的job,可以自动扩容的HPA，而网络插件和存储插件也在不断的完善和增加。

3. k8s的特性

k8s特性很多，这里列举了几个和我们平台切合的特性。

●用户隔离。k8s有命名空间的概念，命名空间可以做的简单隔离

●服务发现和负载均衡。k8s有这自己的的虚拟网络，通过对服务进行注册、更新dns和ipatable规则，做到集群内部的服务器发现和服务访问的负载均衡

●弹性伸缩和滚动更新。我们可以手动或者自动的为pod资源进行扩容，可以通过滚动更新对服务进行滚动升级

●资源监控和日志。我们通过k8s的其他组件，对资源监控，对日志进行收集和分析，当然我们也可以使用自研的插件实现这些

●故障自愈。k8s有健康检查机制，可以保证pod资源的正常，保证pod数量在我们的预期设定，同时当业务节点出现宕机时，可以将资源在其他节点重建

●容器进行计算和调度。k8s可以对容器进行计算和调度，保证容器合理的分布，运行。

4

K8S 对比 Mesos

相同：

●K8s 和mesos 都可以对容器进行编排管理，都可以满足容器编排管理需求

●K8S也可以运行在Mesos上，K8S和Mesos结合， K8S作为Mesos作为计算框架

不同：

——K8s

—●K8s组件和功能完善，可以直接使用

—●K8s自带调度与计算框架

—●Kubernetes偏向于业务层的调度，微服务框架，容器服务编排，服务发现

——mesos

—●Meos需要自己组装实现自己的业务模型

—●Mesos定义为一个分布式内核，负责资源的管理，业务调度需要自己实现或者使用第三方框架，如：Marathon

—●Mesos偏向于底层资源的管理

经过调研后，最终我们决定使用k8s框架，使用其本身微服务的架构，同时参考mesos资源分配方式，建立比较通用和完善的资源交互系统的底层。

5

底层资源简单架构

用户通过平台申请—k8s集群，资源计算调度—生成对应的容器资源。

三、平台功能思考

这里主要从用户层、资源层、容器层、网络层等方面进行思考。

1

用户层功能

用户层直接和用户进行交互，也就是我们这个平台的直接展示层，对应这一层我们需要实现以下功能：

●资源状态统计和查看——我们可以通过该平台统计资源的使用情况和查看资源当前状态；

●资源操作——我们需要提供用户直接操作资源的功能（比如申请和修改，删除等）；

●资源操作日志——为了更好的管理和后续资源跟踪，我们需要记录对应的用户操作行为；

●用户权限划分—由于针对多种用户，为了保证项目之间互不干扰，也是为了平台安全考虑，我们需要对用户进行权限划分；

●项目组资源划分——在对用户进行权限划分之后，我们还需要对用户所能使用的资源进行分割和管理。

2

资源层功能

●物理资源分组，容器资源按需分配至不同的物理资源；

●项目组和物理资源相对应，对应项目组申请容器时被分配至物理资源；

●容器资源的统计和监控。

3

容器层功能

●通过api接口方式操作k8s集群，从而操作容器资源；

●容器的状态，容器的数量和分布情况，上报我们资源平台；

●容器数量和分布统计。

4

网络层功能

●用户申请资源后，通过IP或域名等访问容器资源。

●为了兼容之前的虚拟机部署的项目组，需要确定一个网络方案进行过度。

5

辅助功能

●更好操作和查看容器资源，例如进入容器。

●容器的日志收集、监控、报警。

四、平台的设计与实现

1

K8s系统控制中心

上面提到，我们需要可以更好从操作k8s集群，实际部署的时候，我们不能像平时到master主机之上执行kubeclt，好在k8s提供了api接口，也有对应的k8s api client。那么，我们可以选取go client lib库，里面实现了操作k8s的api，同时通过里面workqueue，实现资源状态变化的监听。

实现之后，控制中心可以接收平台的请求，然后操作k8s集群，同时监听k8s对应资源状态，讲状态反馈至资源平台。

2

资源池划分

为了更改的对资源进行管理和隔离，也为了满足不同项目组，机器性能要求不同的问题，因此这里引入了资源池的概念。

项目组可以自己申请机器，然后我们将对应机器分为一类资源池，该项目所申请的容器资源都调度在对应的资源池之上，如果没有申请，可以使用我们的公共的资源池机器。

下面，我们可以看下对应项目组和资源池的关系：

从上图可以看到，项目组和资源池是一对多的关系，一个项目组可以有多个资源池，然后项目申请容器资源时，可以选择其中一个资源池。

那么，考虑一个资源池之上可能有多个项目组，我们使用了k8s的namespace概念，为每个项目组分配了对应的namespace。

3

网络方案

1. flanel

使用flanel，将集群组成一个大网。

对于内部服务，直接使用k8s服务发现的机制，定义的service name 直接访问服务；

对于需要对外访问的服务，有2种：一种是nodeport，端口映射到实际物理机；一种使用ingress，同时更新网络的dns。

2. 固定ip

我们给对应的容器添加固定的IP，这个IP可以从同一网络内直接访问，这时候容器可以类似一个虚拟机。这个方案也是为了兼容传统虚拟机的业务，更好的业务平滑过渡。

4

WEB平台

我们的web平台，使用bootstrp和flask进行构建，对应需要远程操作的，使用了改造后的ansible。

接下来看下它的具体功能：

1.用户鉴权

鉴权是这样的，用户属于对应的一个应用组或者说项目组，应用组有对应的资源配约束，同时每个用户分了3个角色，只读，部署和管理。角色约束了用户的操作。

2.平台功能

前端：功能主要有 dashboard，状态统计， 资源操作，资源查看，日志统计，监控报警；

后端：数据统计，资源定时检测更新，资源操作，资源查询，状态回调，操作纪录，日志收集；

底层，k8s控制中心功能，mysql存储功能。

3.辅助功能

●webssh 支持用于从前端web页面之间ssh进去容器。

●日志收集平台和监控报警平台。

4.整体框架

以上是一张整体框图，用户通过web平台，可以操作和查看资源。然后，底层k8s控制中心接收web平台调用，操作k8s集群。K8s集群再分配调度容器资源到对应的资源池之上，同时底层资源宿主机之上。

另外，还有日志采集器和状态采集器等其他插件，对应资源日志进行收集，监控和上报资源状态至web平台。

5.平台展示

●DashBoard

这是Dashboard 状态信息统计，统计集群和资源池机器的状态，以及运行docker实例数。资源池当前cpu和内存使用率。

●应用管理

我们把容器资源的申请，以应用方式管理，申请容器资源，对应的就是一个容器应用的申请。

下面是具体容器的实例，可以对容器实例进行扩容和缩容，同时可以接收底层资源状态更新的websocket通知。

●应用组管理

应用组管理，也可以叫项目组管理。我们可以给应用组分配对应的资源池，同时管理其容器资源的配额。

●日志查看

我们可以对用户名、时间、具体容器应用进行搜索，搜索对应的的操作日志。

●webssh

通过webssh，我们可以从页面直接连接到我们的容器内部，如果xshell连接虚拟机就比较一般。