首页 > 其他 > 详细

k8s in Rancher架构分析

时间:2017-01-12 16:34:39      阅读:40      评论:0      收藏:0      [点我收藏+]

标签:docker   kubernetes   rancher   架构分析   k8s   

在Rancher 1.0版本开始,Rancher逐步增加了Kubernetes、Swarm、Mesos等多编排引擎的支持,很多朋友就此产生了疑惑,诸如Cattle引擎和这几个之间到底什么关系?每种引擎是如何支持的?自家的业务环境如何选型?我们将逐步揭开这些神秘面纱,了解基础架构才能在遇到问题时进行有效的分析,进而准确的定位问题并解决问题,因为没有一种生产环境是完全可靠的。基于这个背景下,这次我们首先向大家介绍kubernetes in Rancher的架构。

 

从现在Rancher的发展节奏来看,Cattle引擎已经被定义成Rancher的基础设施引擎,而Rancher的基础设施服务都包括哪些呢?如下:

  • Networking,Rancher的统一网络服务,由rancher-net组件提供

  • Load Balancer,Rancher的负载均衡服务,目前来看套路基本上是基于Haproxy来构建

  • DNS Service,Rancher的DNS服务,主要是为了提供服务发现能力,由Rancher-DNS组件来提供

  • Metadata Service,Rancher的元数据服务,Metadata是我们通过compose编排应用时的利器,可以很灵活的像service中注入特定信息

  • Persistent Storage Service,持久化存储服务目前是由convoy来提供,而对于真正的后端存储的实现Rancher还有longhorn没有完全放出

  • Audit Logging,审计日志服务是企业场景中比较重要的一个属性,目前是集成在Cattle内部没有被完全分离出来


所以Rancher在接入任何一种编排引擎,最终都会把基础设施服务整合到该引擎中,Kubernetes in Rancher的做法正是如此。

 

Kubernetes各个组件的角色可以归为三类即Master、Minion、Etcd,Master主要是kube-apiserver、kube-scheduler、kube-controller-manager,Minion主要是kubelet和kube-proxy。Rancher为了融合k8s的管控功能,又在Master中添加了kuberctrld、ingress-controller、kubernetes-agent三个服务来打通Rancher和K8s,同时每个node上都会依赖Rancher提供的Rancher-DNS、Rancher-metadata、Rancher-net这些基础设施服务。


技术分享


由于K8s是基于Cattle引擎来部署,所以在K8s在部署完成之后,我们可以通过Link Graph来很清晰的看到整体的部署情况。


技术分享


整个服务基于Cattle引擎的Rancher-compose构建,新增节点后自动添加kubelet和kube-proxy服务(此处利用了Global Label的特性),各个组件都添加了health-check机制,保证一定程度的高可用。考虑到etcd最低1个最多3个节点,单台agent host就可以部署K8s,三节点agent host则更合理些。

 

K8s集群完成部署后,我们就可以在其中添加各种应用服务,目前Rancher支持管理K8s的service、pod、replication-controller等,我们可以用一张图来形象得描述一下应用视图结构。


技术分享


rancher-net组件会给每个pod分配一个IP,Rancher-DNS则替代了K8s的Skydns来实现服务发现,在pod的容器内部依然可以访问Rancher-metadata服务来获取元数据信息。除了这三个基础服务外,我们之前提到的kuberctrld、ingress-controller、kubernetes-agent也在其中扮演者重要角色。

 

无论是K8s还是Rancher,其中一些抽象对象(如Rancher的stack/service,或者K8s的serivice/pod)在属性更新时都会有events产生,在任何服务入口来更改这些抽象对象都会有events产生,所以要保证Rancher和k8s能够互相感知各自对象的更新,那么kubernetes-agent就应运而生了。


技术分享


诸如K8s的namespaces、services、replicationcontrollers、pods等对象的信息变更会及时通知给Rancher,而Cattle管理的Host资源出现信息变更(诸如host label的变动)也会通知给K8s。

 

简单得说kubernetes-agent是为了维护Rancher和K8s之间的对象一致性,而真正要通过Rancher来创建K8s中的service或者pod之类的对象,还需要另外一个服务来实现,它就是kubectrld,直观的讲它就是包装了kubectrl,实现了其中kubectl create/apply/get 等功能。


技术分享


所有的K8s对象创建请求都会走cattle引擎,cattle会把请求代理到kubectrld启动的一个api服务。除此之外,还会监听Rancher events来辅助实现相关对象的CRUD。

 

K8s上创建的service如需对外暴露访问,那么必然会用到LoadBalancer Type和Ingress kind,注意K8s概念下的LoadBalancer和Ingress略有不同,LoadBalancer的功能主要关注在L4支持http/tcp,而Ingrees则是要实现L7的负载均衡且只能支持http。K8s 的LoadBalancer需要在K8s中实现一个Cloud Provider,目前只有GCE,而Rancher则维护了自己的K8s版本在其中提供了Rancher Cloud Provider。对于Ingress则是提供了Ingress-controller组件,它实现了K8s的ingress框架,可以获取ingress的创建信息并执行相应的接口。当然最终这两者都会调用Cattle api来创建Rancher的负载均衡,且都是通过Haproxy完成负责均衡功能。


技术分享


以目前K8s社区的火热势头,Rancher应该会持续跟进并不断更新功能优化架构,待到Rancher1.2发布之后,CNI的支持会是一个里程碑,到那时Kubernetes in Rancher也会更加成熟,一起向着最好用Kubernetes发行版大踏步的前进。


原文来源:Rancher Labs

本文出自 “12452495” 博客,请务必保留此出处http://12462495.blog.51cto.com/12452495/1891265

k8s in Rancher架构分析

标签:docker   kubernetes   rancher   架构分析   k8s   

原文:http://12462495.blog.51cto.com/12452495/1891265

(0)
(0)
   
举报
评论 一句话评论(0
0条  
登录后才能评论!
© 2014 bubuko.com 版权所有 鲁ICP备09046678号-4
打开技术之扣,分享程序人生!
             

鲁公网安备 37021202000002号