Kubernetes in Rancher架构分析

该主题是本人于Rancher kubernetes 北京meetup进行的一次线下分享，应Rancher China官方之邀，重新梳理成文字版本，便于大家阅读传播，如有问题纰漏或任何不妥之处随时联系牛小腩（niusmallnan），我会以最快速度更正。

正 文

在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这些基础设施服务。

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

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

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

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

无论是kubernetes还是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。

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

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