CloudFoundry与Kubernetes在PaaS中的应用@MoPaaS原创

 

谷歌的容器管理系统从Borg、Omega到近日火爆的Kubernetes,尽管它是近期才受人知晓,但作为Linux容器被谷歌使用已经有十多年。所以今天就PaaS层面来讲讲CloudFoundry和Kubernetes的那些技术。
撰稿人介绍
 沈阅斌   MoPaaS研发总监   
目前在Anchora负责云计算平台产品研发和管理工作。先后在多家软件公司担任项目研发、项目管理及技术培训等工作。对企业应用开发、大型网站架构、云计算、大数据等领域有相关实践经验。对Cloudfoundry、Openstack、CloudStack、Hadoop等开源云技术进行研究和使用。目前担任Anchora产品研发总监,主要负责PaaS产品的研发。
CloudFoundry 介绍
CloudFoundry是一个工业级开源PaaS,它可以部署为一个云,并对外提供多语言多框架、应用运行环境及服务。个人认为,CF的社区相对还是比较活跃的,并且版本迭代比较快,一般1,2周就会发布一个小版本。而且CF在不断地改进和优化自身的架构,到目前为止已经经历了CFV1,CFV2以及 CFV3。每一次大版本的发布都对CF进行了性能和架构上的优化。
1
软件路由和软负载均衡
Haproxy、Gorouter:
Router将平台流量分发给特定的组件,通常为CloudController,或者运行在DEA节点上的应用。其中Haproxy可以替换为其他负载均衡设备,比如F5,Gorouter节点会对平台所有的访问请求进行记录,我们可以采集这些日志并进行分析,比如可以分析出像应用的访问量、流量、错误率、访问来源等信息。对于公有云来说,资源的充分利用是非常重要的,所以对于那些一段时间不被访问的应用,我们会对其进行休眠,一旦有新的请求过来时,则立刻唤醒这个应用。这个功能就需要对Gorouter进行相关定制。如果要实现应用的灰度发布,也可以利用Gorouter实现,通过对其路由表信息进行逐步更新,替换原来的路由信息来完成。
2
认证和授权
UAA、LoginServer:
UAA与LoginServer主要提供用户身份认证管理服务,支持OAuth2认证协议,也可以作为单点登录服务。当我们在多个数据中心中部署PaaS的时候,只需要部署一套用户系统,所有的PaaS平台实例可以接入到同一个Uaa系统中。
3
应用生命周期管理
CloudController、HealthManager:
当开发者将一个应用push到cloudfoundry后,CloudController会存储应用文件,在数据库中创建应用的元数据记录,并指派DEA节点来stage及运行应用。CloudController同时还维护了组织、空间、服务、服务实例、用户角色等记录信息。CC提供了标准的API接口,用来管理整个平台,所以我们可以基于这套API来实现对CF的管理,如果需要扩展CF的功能,可以对API进行修改或者增加来完成。并且我们可以修改CC来实现将应用分发到特定的DEA组去运行。
4
应用存储和运行
BlobStore、DEA:
DEA负责管理应用实例,跟踪已启动的应用实例,并广播其运行状态的消息。
Blobstore保存了应用代码、Buildpacks(应用依赖的runtime、webserver、framework等的集合)以及Droplets(已完成stage的可直接在DEA上运行的应用包)。Dea提供过了VAZ接口,我们可以定时采集DEA上的运行数据进行分析和处理。
5
服务
ServiceBroker:
应用往往依赖于数据库或第三方服务。
当开发者需要创建一个服务实例并将其与某个应用绑定,该服务的ServiceBroker负责提供这个服务实例。
6
消息
NATS:
CloudFoundry使用NATS进行组件间的内部通信。
NATS是一种轻量级的、基于发布-订阅机制的分布式队列消息系统。通过NATS我们可以很容易将一个新的组件注册到CF平台,通过订阅某个主题可以获取CF平台收集的信息。
7
日志和监控数据
MetricsCollector、AppLogAggregator:
计量数据收集器从各组件收集计量数据。运维人员可以使用这些信息对整个CloudFoundry平台进行监控。
应用日志汇集器(loggregator)可以将应用日志输出给开发者。
Kubernetes 介绍
Pod:Pod是Kubernetes的基本操作单元,包含一个或者多个紧密相关的容器。Pod包含的容器作为一个统一管理单元运行在同一个node上面,共享网络与存储,如上图Php-frontend、Redis-master、Redis-slave
Replication Controller:Replication Controller确保任何时候Kubernetes集群中有指定数量的pod副本(replicas)在运行, 如果少于指定数量的pod副本(replicas),Replication Controller会启动新的Container,反之会杀死多余的,总之通过RC的定义kubernetes总是保证集群中运行着用户期望的副本数量。如上图Php-fronted、Redis-master、Redis-slave都有对应的一个RC管理,并且维护对应的副本数量
Service:service是Kubernetes的基本操作单元,一个service可以看作一组提供相同服务的pod的对外访问接口。Service作用于哪些pod是通过label来定义的。如上图Php-frontend、Redis-master、Redis-slave都有对应的一个service,service是一个逻辑概念,真正实现负载均衡是通过kube-proxy完成的
Label:label是kubernetes系统的一个核心概念。Label以key/value键值对的形式附加到各种对象上如pod,service,rc。Label定义了这些对象的可识别性,用来对他们进行管理和选择。如上图Php-fronted、Redis-master、Redis-slave都定义了Label,RC和Service就是通过Label作用到对应的Pod上。
1
Master上运行的
Etcd:所有的持久性状态都保存在etcd中,这样是配置数据的存储变得可靠。Etcd同时支持watch,这样组件很容易得到系统状态的变化,从而快速响应和协调工作。
API Server:API Server为Kubernetes API提供服务,大多数的业务逻辑在不同的组件或插件实现。它主要处理REST操作、验证及更新etcd中相应的资源。
Scheduler:负责集群的资源调度,根据特定的调度算法将pod调度到指定的node上。
Controller Manager:所有其他群集级别的功能由控制器管理器执行。例如,Endpoints controller来控制Endpoints的创建和更新,节点控制器控制节点的发现、管理和监控,Replication controller来控制pod副本的数量。
2
Node上运行的
Kubelet:负责本node节点上面的pod创建、修改、删除等生命周期管理,同事定时上报本node的状态信息到API Server中
Kube-proxy:负载均衡和服务的发现。它会从API Server上同步service及其endpoints,为每个service创建一个代理已完成具备负载均衡能力的服务转发能力。实现过程对于每一个service,它设定一个iptables rules,把到这个service集群ip和端口的流量重定向到这个service对应的后端的随机的一个Pod中。
3
认证和授权
Kubernetes使用客户端证书,或HTTP基本认证令牌,认证用户API调用。
  • 客户端证书认证:在apiserver设置–client-ca-file=SOMEFILE即可实现。引用的文件必须包含一个或多个证书颁发机构使用验证客户端证书提交对服务器的API
  • Token:在apiserver设置–token-auth-file=SOMEFILE即可实现。目前,令牌和令牌列表无限延续下去,需要重新启动apiserver才会改变。
  • Token格式为 :  token,user,uid,”group1,group2,group3″      http basic auth:在apiserver设置–basic-auth-file=SOMEFILE即可实现。
  • 文件格式为 : password, user name, user id
授权发生在认证完成后,而授权则判断该用户是否有执行该API请求的权限。授权适用于所有HTTP访问的主要(安全)对服务器的API接口。授权会依据访问策略去核查请求。授权模式有三种
  •  –authorization-mode=AlwaysDeny
  •  –authorization-mode=AlwaysAllow
  •  –authorization-mode=ABAC
下面主要说ABAC模式。
首先修改kube-apiserver的对应参数–authorization-mode=ABAC 并指定授权文件的位置 –authorization-policy-file=SOME_FILENAME
该文件是一个json格式的文件,且每一行是一个授权策略。每一行最多有五个部分组成(个数可随意)
  • user如果你指定user, 它必须匹配已验证用户的用户名。
  • group, 如果你指定 group, 它必须匹配已验证用户的某一个组.
  • readonly当为真时,只能进行 GET 操作.
  • resource, 如 pods.
  • namespace
示例如下:
  • {“user”:”admin”}
  • {“user”:”scheduler”, “readonly”: true, “resource”: “pods”}
  • {“user”:”scheduler”, “resource”: “bindings”}
4
Namespace 多租户
Namespace是一种机制,由用户创建的资源分配到一个逻辑命名的组。
5
资源管理
Kubernetes是一个多层次的资源管理,可以从namespace,pod及container三个层次去进行资源管理。
6
多租户配额管理
在不同的租户的namespace上加载对应的Resource Quota来规定了该用户所占资源的总量的大小。一个简单的Resource Quota示例文件如上图所示。
7
全局默认配额
通过创建一个LimitRange对象来定义一个全局(namespace)默认配额模板。这个默认配额会加载到该namespace中的每个pod及容器上,这样就不用我们自己手动为每一个pod配置了,示例如上。
8
指定容器配额
只需要在创建pod或者RC的时候在定义文件中设定resource属性即可为某个容器指定配额,示例如下:
  
9
K8s的特色功能:应用滚动升级和动态扩容
Kubernetes提供了rolling-update和autoscale两个指令来实现应用滚动升级和动态扩容。
滚动升级使用rolling-update,使用该命令后系统会一次停掉一个旧的RC中的pod副本,然后创建一个新的RC中的pod副本,直至旧的RC中的pod副本数量减少到0,而新的旧的RC中的pod副本达到目标值。在rolling-update过程中会自动报告进程,如果在中间过程出错,可以去回滚到以前的版本。
动态扩容使用指令autoscale。使用该命令指定RC所能创建pod最大值和最小值,当负载压力大时该RC会自动增加pod副本的数量直至最大值,当负载压力小时该RC会自动减少pod副本的数量直至最小值。
以上就是本期“CloudFoundry与Kubernetes的那些技术”。如果您有想要知晓的技术信息,请在我们微信号中留言,下期我们讲主题是:CloudFoundry与K8S在PaaS中的应用!

今天就到这里,我们下期见!
MoPaaS作为企业持续创新的平台,在国内外有众多的PaaS云平台技术项目落地实例,可更有效的满足中国企业级用户对不同需求的计算资源优化调配,实现应用敏捷交付的智能化管理,包括应用软件开发管理,连续集成,部署运维,监控管理,弹性扩容等需求;MoPaaS提供企业私有云解决方案、软硬件融合一体机系统以及企业级公有云 PaaS 服务等。
MoPaaS 获得多项行业奖项和认可,2015年被全球三大市场调研公司之一的 Forrester 关于中国企业级云平台市场获得“强劲表现者 (Strong Performer)“的评估。

 

发表评论

电子邮件地址不会被公开。 必填项已用*标注

您可以使用这些HTML标签和属性: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>