用Kubernetes记录Rancher进化史

本文由Rancher首席软件工程师Alena Prokharchyk所写，他分享的是如何将Kubernetes新特性集成到 Rancher平台。这篇文章是关于Kubernetes 1.3新功能的一系列深入的文章的一部分。本文是第四篇。Kubernetes是Rancher支持的第一个外部编排平台。自发布以来，它已经成为Rancher用户使用最广泛的平台之一，并且这个数字还在继续攀升。

随着Kubernetes的演进，从支持kubernetes新特性的角度来看，Rancher也在不断演进。

Rancher最早支持的Kubernetes版本是1.1， 1.2发布不久我们就切换到1.2，现在我们正努力支持Kubernetes1.3新增的特性。

接下来带你浏览一下每个阶段我们支持的Kubernetes特性。

Kubernetes 1.2 引入了增强Ingress对象 ，大大简化了对集群service入网连接的控制。关于Ingress Policy，参考这篇博客（“相关链接”）。

Ingress 允许用户便捷地定义域名的路由规则和负载均衡器的TLS配置。这样就能使用 Ingress controller对Ingress规则进行备份，Ingress Controller使用这些规则配置云服务商的负载均衡器。

由于Rancher已经包含了基于HAproxy的均衡器，支持所有Ingress资源的配置要求，因此支持 Ingress时Rancher不需要做出任何修改。

我们要做的只是：写一个能够监听Kubernetes ingress 特定事件的Ingress controller， 配置Rancher负载均衡器，将负载均衡器的公共入口传播给Kubernetes：

现在Ingress controller被部署为Rancher Kubernetes系统技术栈的一部分，并由Rancher管理。

Rancher监测Ingress controller的健康，在Ingress controller出现故障都会被自动重建。

除了标准的导入功能， Rancher也支持横向扩展Ingress 服务的负载均衡器，你可以通过修改Ingress 的annotations（scale字段）来实现。例如:

修改以后，Rancher 负载均衡器的2个实例将在独立的主机上启动，Ingress将使用2个公网IP地址进行更新：

Rancher Ingress Controller for Kubernetes的实现可以查看这些资料：

●   博客文章（http://rancher.com/rancher-controller-for-the-kubernetes-ingress-feature/）

●   Ingress上的 Rancher文档（http://docs.rancher.com/rancher/latest/en/kubernetes/ingress/）

●   Rancher ingress controller报告（https://github.com/rancher/lb-controller）

Kubernetes 1.3带来了很多激动人心的特性，有两个我们特别感兴趣：Stateful Apps和Cluster Federation。

Stateful Apps是Kubernetes中新的资源格式，它代表有状态应用内的一组pods。

它是Replication Controllers能够很好地运行无状态的应用，与此对应，Stateful Apps能够很好地运行有状态的应用。

这个特性对于严重依赖仲裁（leader election）和去中心化的应用非常实用，比如MongoDB、Zookeeper、etcd、Cassandra。

Stateful Apps 创建并维护一组pods，其中每一个都有稳定的网络身份。为了提供网络身份，按照Kubernetes设计文档，对于绑定到每个网络身份的Pod，都必须有一个可解析的DNS ：

以上功能是通过pod 的 annotation 实现的，对上层暴露为endpoints，最终作为Pods对应的service的DNS。

目前，Rancher利用Rancher DNS而不是SkyDNS，从而简化了DNS配置。

Rancher DNS 具有快速、稳定并可伸缩的特性——集群中的每个主机都运行一个DNS服务。

Kubernetes services编码到Rancher DNS中，能够被解析到service的ClusterIP （10,43.x.x）。

如果service是headless，那么会被解析到 pod IP。

通过 Rancher 让PetSet与 Kubernetes工作，我们将为Pod认证信息添加到Rancher DNS配置中。目前我们正在实现这个特性，该特性包含在未来的Rancher发型版中。

“集群联邦” 是 Kubernetes中一个控制平面。它通过将应用分布在多个集群中，提供了增强应用可用性。

由集群联邦创建的跨集群应用，我们称之为“联邦应用（服务）”。集群联邦的结构看下图：

每个Kubernetes集群暴露API，并作为联邦对象的一部分注册到Cluster Federation。

使用Cluster Federation API，你可以创建联邦服务。

这些联邦对象由多个等价的底层Kubernetes资源组成。

假设上图中的3个集群属于同一个联邦对象，每个服务通过Cluster Federation创建，每个集群中将会创建等价的服务。

除此之外，一个联邦服务会获取一个可被公开解析的DNS名，解析的目标是Kubernetes services的public IP（DNS记录被编码到一个公共的DNS服务上），具体结构看下图：

为了Rancher上的Kubernetes支持Cluster Federation，需要做出一些改变。这里每个Kubernetes集群代表一个Rancher环境。每个Kubernetes环境都包含了整个Kubernetes系统技术栈：Kubernetes API Server、Scheduler、Ingress Controller、持久化的etcd、Controller Manager、Kubelet和Proxy（每个主机上最后运行的两个服务）。

为了创建Cluster Federation，我们需要额外创建一个让Cluster Federation 技术栈运行的环境：

每个Rancher环境下的Kubernetes集群，都应当注册到一个特定的Cluster Federation。

通过设置Kubernetes 集群上代表联邦对象名称的label，每个集群都是可以被自动发现的。

我们还在讨论敲定该功能的原型，这一功能让我们很激动，因为它适用于很多场景。Cluster Federation文档参考：

 ●  Kubernetes集群 federation设计文档

●  多区集群的Kubernetes博客文章

●   Kubernetes federated服务设计文档

当初启动支持Kubernetes项目以后，为了支持Rancher原生网络，我们决定维护自己的Kubernetes发行版。

我们发现，维护自己的发行版以后，每次Kubernetes发生变化时，我们都需要更新我们自己fork的版本。为了支持用户的使用场景，我们认为这是必要的。

作为kubernetes 1.4工作的一部分，我们需要重新审视Rancher的网络方案，也需要重新分析fork版本的最初需求。除了网络集成，所有Kubernetes相关的项目都作为插件的形式发布：

●   Rancher 作为云提供商（支持负载均衡器）。

●   Rancher作为CredentialProvider（支持Rancher私人注册）。

●   Rancher Ingress controller（备份Kubernetes ingress资源）。

所以我们最终决定消除Rancher Kubernetes发行版存在的价值，努力将所有的变更都merge到Kubernetes代码库。

为了实现这一目标，我们重写了网络集成特性，现在Rancher 网络可以作为Kubernetes CNI插件运行。更多的细节会在该特性设计定稿之后发布，时间上大概在2-3个月之后。

我们也会继续在Rancher 核心功能与Kubernetes集成上持续投入，包括但不限于下面几个方面：

 ●    通过Rancher环境中的Kubernetes集群 进行访问权限管理

●    证书管理，基于http对标准kubectl cli的访问

●    支持负载均衡

●    支持Rancher 内部DNS

●    支持对Kubernetes模板的分类和目录

增强UI，用来展现更多的 Kubernetes 对象类型，如 Deployment, Ingress, Daemonset)。

所有这些工作都是为了让Kubernetes的用户体验更强大，更符合用户直觉。

对于Kubernetes社区的进步我们很激动，并很高兴能参与其中。Kubernetes 1.3版本是一个极为重要的发布，你将能很快通过Rancher来升级。