转载

Kubernetes集成外部服务实践

亚信公司有一些多年来在大数据方面的积累,比如数据,计算工具,算法等。现在要把这些能力结合起来做一个PaaS平台。经过一些前期选型与评估,我们决定用kubernetes+外部服务形式的架构来建立PaaS平台。

首先我们简单回顾一下kubernetes。

关于kubetnetes的架构大家应该都有所了解,主要的组件比如apiserver、etcd、controlle rmanager、scheduler以及cluster node上的kubelet跟proxy。但是我们今晚的主题,关注点主要在apiserver和controller。

Api server是kubernetes集群管理的入口,我们在做集群部署,诸如起pod,rolling update,建rc之类都是通过kubectl这个CLI工具。

kubectl接收命令行的输入,再发请求给apiserver,apiserver在接收到请求后会做一些验证,比如请求体是否合法、格式是否规范等。校验后,格式化的请求数据便会被写入到etcd。

Controller manager则一直在监控etcd的数据变化,kubenetes里的各种资源对应到自己相应的controller,比如pod会有pod的controller,service有service的controller,等等。当这些资源在etcd的存储数据发生变化时,controller manager则会监控到这些变化。

当我们在master node上观察kubenetes的网络连接时,我们会看到有在apiserver与etcd服务端口之间有许多tcp长连接。这些长连接就是在通过etcd的watch接口监控etcd中的数据变化。我们甚至可以用curl来直接调用这些接口,便会发现这是一个不会断开的长连接,当etcd里的数据发生变化时,这个长连接会不断地收到全量数据。

Scheduler的任务则是调度具体的节点来拉取镜像,起pod等调度工作。并且把结果写入到etcd。当我们使用 kubectl get xx命令时,便会从etcd中取出相应资源的存储值并格式化输出到终端。

Kubenetes整体上采用了优美的异步机制设计,从kubectl发起一个命令后,apiserver本身不会执行命令要求的动作,只是把请求数据写入到etcd中,然后由conrtoller manager从etcd观察到数据发生变化,再调用controller去执行具体的动作。如果是一个get操作,则是简单的从etcd返回相应资源数据。这里要注意的是,controller或者scheduler在完成任务,要写回数据至etcd时,也是通过api server来操作etcd。

关于kubernetes的内容我们简单回顾到这。下面我们来看看Backing Service,即后端服务。

Backing Service指需要通过网络调用来完成的服务。比方数据库啊,消息队列啊,以及api访问的服务比如Twitter api等等。目前大家开发应用都比较讲究应用与服务分离,开发者只需要关注应用业务本身的开发,对依赖的服务只需通过外部接入,直接使用。

外部服务有诸如持久化、插件化,服务化等特性。拿mysql来做比方,如果要把mysql跟应用打包在一起跑在集群容器里,需考虑把数据存储挂一个volume出来。而这一点在集群中会表现的更加复杂,因为涉及到跨主机数据同步的问题,开发者也许并不熟悉这些细节原理,如果总是纠结于应用之外的问题,那毫无疑问,开发效率会明显降低。目前主流的方式是把mysql的连接信息注入到应用的环境变量中,如果应用不再使用这个数据库,那么可以随时卸载这个数据库,或者接入另一个数据库,只要简单地清除或修改环境变量就可以,而不用再关心怎样优雅地去停掉那个不再被使用的数据库。

在PaaS上,应用开发者依赖的服务都会产生交集,这也是我们为什么以后端服务的形式来提供这些服务的原因之一,我们把这些后端服务作为一个支撑服务体系,给开发者提供服务。还以mysql来比方,如果没有后端服务,那每一个依赖mysql的应用都要起一个mysql的容器。对于集群管理者,意味着集群里会跑许多mysql容器。

另一个原因是,有很多后端服务比如大数据算法和分析工具,只以api或者独立服务的形式提供出来,如此一来,开发者也没有能力在自己的应用里打包一个这样的容器/镜像。

最后一个主要原因是,这些后端服务对开发者是热插拔的。使用的时候只要通过命令/接口来创建一个服务实例,然后绑定实例到自己的应用上就可以了,非常便捷。

那么再具体地,开发者如何使用这些后端服务,与自己的应用对接呢?我们采用了Service Broker协议规范。

Service Broker是CloudFoundry中的概念,目标就是把应用与服务分离。Service Broker实现7个REST API,通过API,我们可以知道一个Broker会提供何种服务,并且轻松地实现对服务实例的创建、绑定、解绑,以及销毁。采用ServiceBroker规范还有一个好处就是,所有实现了ServiceBroker协议的服务,都可以以后端服务的方式无缝接入我们的PaaS平台。这样,一些第三方服务就可以轻松地为开发者提供诸多服务。

我们来看一看Service Broker API。

Kubernetes集成外部服务实践

(Service Broker API)

上面7个api便是server broker协议中需要实现的接口。获取服务,创建实例,绑定应用,这一系列操作都通过这几个api完成。关于service broker api的更多信息,我们从cloudfoundry网站可以看到更详细的介绍,想进一步了解的同学可以到这个链接查看: docs.cloudfoundry.org/services/api.html

下面分享如何扩展kubernetes。

Kubernetes的代码架构设计使得扩展其功能变得容易。正如前面所述,kubernetes里的概念诸如pod,service,在kubernetes里都被当作一种资源(Resource)来对待。所以我们的扩展首先是增加新的Resource类型。

针对Backing Service,我们增加了三个新的Resource,分别是:ServiceBroker,BackingService,BackingServiceInstance。相应地,我们增加了这三种Resource的controller,api,以及CLI。这样一来,我们就可以用命令行工具或者API,像操作其他资源一样去操作后端服务资源,来完成对应的功能。

下面我们以mongodb的Service Broker来举例说明,开发者如何在应用里同一个经由后端服务提供的mongodb实例交互。我们用oc命令来展示。oc是openshift客户端,也是由kubernetes扩展而来,完全兼容kubernetes。

首先是一个mongodb的Service Broker的yaml定义,内容如下:

Kubernetes集成外部服务实践

(mongo.yaml)

我们用oc create -f mongo.yaml 把这个Broker接入到平台。

Kubernetes集成外部服务实践

(接入mongoServicerBroker,并创建一个mongodb实例)

上面是几个命令执行的截图,分别解释一下。

用oc create命令创建一个broker后,我们用oc get servicebroker mongodbldp来查看刚刚创建的broker。

然后用oc get backingservice来查看刚刚接入的broker都提供什么服务。我们从图中看到,有mongodb_aws这个服务处于激活状态,也就是说,我们可以用它来创建mongodb实例。oc describe backingservice会列出mongodb这个后端服务更详细的信息,例如提供哪些套餐计划,套餐价格等等。其中,planid我们会在创建实例时用到。

oc new-backingserviceinstance mongo-demo --backingservice_name=mongodb_aws --planid xxxxxxxx 这个命令会创建一个mongodb实例。这个命令需要两个参数。一个是后端服务名,和planid。这两个参数将对应到所有后端服务中一个唯一的plan。

到这里,我们的实例就创建好了,通过oc get bsi可以看到刚刚创建的一个实例,处于未绑定状态。

下面把这个实例绑定到我们的应用中。我们继续看一张截图。

Kubernetes集成外部服务实践

(绑定mongo实例)

首先我们有一个应用叫docker-2048,用oc describe dc docker-2048来观察,可以看到输出的ENV项,是我们注入到pod/container的环境变量。只有一个值TEST=test。

我们绑定刚刚创建的实例到这个应用。用命令oc bind mongo-demo docker-2048。bind命令也需要两个参数,就是服务实例和要绑定的应用。这里是dc的名字。dc是deploymentconfig,是openshift里的概念。在kubernetes中,则用rc。

绑定实例到应用后,我们用oc get bsi mongo-demo可以看到,这个实例上已经绑定了一个应用。我们再用oc describe bsi来观察,可以看到,连接mongodb数据库的必要信息已经以环境变量的方式注入到了应用docker-2048。在kubernetes中,当rc(openshift中是dc)发生改变时,会触发pod重启。

继续来看一张命令截图:

Kubernetes集成外部服务实践

(解绑实例前后环境变量变化)

从这张截图看到,刚刚与mongo-demo绑定的docker-2048,现在已经有了几个新的变量,BSI_开头的,就是我们新注入的环境变量,此时pod已经被重启了。这时候,我们的应用docker-2048就可以通过这几个环境变量来访问mongodb。至此,外部服务和应用已经完成了对接。

当我们的应用不再使用mongodb这个实例,我们只需简单的命令oc unbind把实例与应用解绑即可,也很方便。上面的截图显示了当实例与应用解绑后,应用的环境变量再次发生了变化。之前注入的环境变量被清除了。只剩注入变量之前的那个环境变量TEST。

从上面几张截图,我们可以依次看到一个mongodb的后端服务实例被创建的过程,并且演示了实例如何被绑定到我们的应用docker-2048。我们观察到,在绑定了实例后,docker-2048的容器里多了一些mongodb的环境变量。这些环境变量随着解绑操作,被从应用容器里清除。上面的绑定与解绑过程,dc的改变会自动触发应用pod被重启。

Q&A:

Q: 请问在举的mysql服务的例子中,讲到不是采用应用与mysql一起打包成容器运行的方式,而是只需要把应用链接mysql服务的环境变量注册到pass平台上面就可以使用mysql的服务了是吗?那么你们平台上面不是运行多个mysql镜像吗?

A: 后端服务与PaaS在逻辑上是分开的,可能独立运行在平台集群外部,也可能运行在集群里,以service的形式服务。所以是否运行多个mysql容器,取决于servicebroker的设计实现。每一种servicebroker的设计都不必相同。

Q: 如果我把mysql环境变量注册到pass平台后,我应用链接你们平台上面的mysql服务后,如果后期分库分表可以吗?还需要重新配置环境变量信息吗?

A: 这个取决于后端服务提供的套餐。不同套餐计划提供不同程度的服务。

Q: 1.k8s自定义扩展具体怎么做的?2.后端服务你弹性伸缩直接用k8s自带的,还是有什么改造?

A: 1.扩展k8s是我们参考k8s的api server、controller这种异步机制直接在k8s中增加代码,k8s在易扩展性上做的挺好。后端服务可以运行在k8s集群上,或独立运行,其弹性伸缩由后端服务自身的设计来决定。

Q: 请问容器里的环境变量是Kubernetes的backingservice自动生成的,还是openshift特有的?是不是可以说因为backingservice会自动在容器里注册环境变量,所以某些场景下使用起来比起直接使用mongo地址来得方便?

A:是实例在绑定的时候由我们的扩展生成,并更新到pod里,不是openshift特有的。第二个问题的话,确实是这样,多数情况下,用环境变量都会很方便。

Q: k8s的volume,你们是如何使用的,当pod发生迁移后,如何保证volume还挂在pod上?

A: k8s本身提供了persistent volume功能,并且支持多种存储机制。pod迁移时,k8s会维护其对应的volume,根据不同的存储,k8s有不同的调度实现。

Q: 现在生产上用什么监控,监控有报警吗,什么粒度的?还有就是日志收集怎么处理有什么成熟的方案吗?

A: 我们采用了多种监控机制。主机、容器、和k8s服务本身,我们都采取不同的监控策略/工具。至于粒度,也跟监控的对象有关。日志我们用ELK。

Q: k8s的部署可否做到跨数据中心吗?如何实现?谢谢。

A: k8s是分布式的异步系统,理论上是可以跨数据中心的。但考虑到网络环境的复杂性,我们当前还没有作这方面的尝试。

原文  http://dockone.io/article/1137
正文到此结束
Loading...