本文发布已超过一年。较旧的文章可能包含过时的内容。请检查页面中的信息自发布以来是否已变得不正确。

Rancher 中的 Kubernetes：进一步发展

作者：Alena Prokharchyk (Rancher Labs) |

Kubernetes 是 Rancher 支持的第一个外部编排平台，自发布以来，它已成为我们用户中最广泛使用的平台之一，并且采用率持续快速增长。随着 Kubernetes 的发展，Rancher 在适应 Kubernetes 新特性方面也随之发展。我们从支持 Kubernetes 1.1 版本开始，然后在 1.2 版本发布后立即切换到 1.2 版本，现在我们正在努力支持 1.3 版本中令人兴奋的新特性。我想向您介绍我们在每个阶段添加支持的特性。

Rancher 和 Kubernetes 1.2

Kubernetes 1.2 引入了增强的 Ingress 对象，以简化允许入站连接访问集群服务：这是一篇关于 Ingress 策略的优秀 博文。Ingress 资源允许用户以用户友好的方式为负载均衡器定义主机名路由规则和 TLS 配置。然后，它应该由 Ingress 控制器支持，该控制器将使用 Ingress 规则配置相应的云提供商的负载均衡器。由于 Rancher 已经包含基于 HAproxy 的软件定义负载均衡器，我们已经支持 Ingress 资源的所有配置要求，并且无需在 Rancher 端进行任何更改即可采用 Ingress。我们所要做的就是编写一个 Ingress 控制器，它会监听 Kubernetes Ingress 的特定事件，相应地配置 Rancher 负载均衡器，并将负载均衡器的公共入口点传播回 Kubernetes

Screen-Shot-2016-05-13-at-11.15.56-AM.png

现在，Ingress 控制器作为 Rancher Kubernetes 系统堆栈的一部分进行部署，并由 Rancher 管理。Rancher 监控 Ingress 控制器的运行状况，并在出现任何故障时重新创建它。除了标准的 Ingress 特性外，Rancher 还允许您通过 Ingress 注解指定扩展来水平扩展支持 Ingress 服务的负载均衡器。例如

apiVersion: extensions/v1beta1

kind: Ingress

metadata:

 name: scalelb

 annotations:

 scale: "2"

spec:

  rules:

  - host: foo.bar.com

    http:

      paths:

      - path: /foo

        backend:

          serviceName: nginx-service

          servicePort: 80

因此，Rancher 负载均衡器的 2 个实例将在单独的主机上启动，并且 Ingress 将使用 2 个公共 IP 地址进行更新

kubectl get ingress

NAME      RULE          BACKEND   ADDRESS

scalelb      -                    104.154.107.202, 104.154.107.203  // hosts ip addresses where Rancher LB instances are deployed

          foo.bar.com

          /foo           nginx-service:80

有关 Kubernetes 的 Rancher Ingress 控制器实现的更多详细信息，请参阅此处

Rancher 和 Kubernetes 1.3

我们对 Kubernetes 1.3 版本的发布以及其中包含的所有新特性感到非常兴奋。我们特别感兴趣的是两个：有状态应用和集群联邦。

Kubernetes 有状态应用

有状态应用是 Kubernetes 的一个新资源，用于表示有状态应用中的一组 Pod。这是一种替代使用复制控制器的方法，复制控制器最适合用于运行无状态应用。此特性对于依赖于领导者选举（例如 MongoDB、Zookeeper、etcd）和分散式仲裁（Cassandra）的仲裁的应用特别有用。有状态应用创建并维护一组 Pod，每个 Pod 都具有稳定的网络标识。为了提供网络标识，必须可以为 Pod 提供可解析的 DNS 名称，该名称根据 Kubernetes 设计文档 与 Pod 标识相关联

# service mongo pointing to pods created by PetSet mdb, with identities mdb-1, mdb-2, mdb-3


dig mongodb.namespace.svc.cluster.local +short A

172.130.16.50


dig mdb-1.mongodb.namespace.svc.cluster.local +short A

# IP of pod created for mdb-1


dig mdb-2.mongodb.namespace.svc.cluster.local +short A

# IP of pod created for mdb-2


dig mdb-3.mongodb.namespace.svc.cluster.local +short A

# IP of pod created for mdb-3

上述操作是通过 Pod 上的注解实现的，该注解会显示到端点，并最终作为服务上的 DNS 显示，该服务公开这些 Pod。目前，Rancher 通过利用 Rancher DNS 作为 SkyDNS 的即插即用替代品来简化 DNS 配置。Rancher DNS 快速、稳定且可扩展 - 集群中的每个主机都运行 DNS 服务器。Kubernetes 服务被编程到 Rancher DNS，并被解析为来自 10.43.x.x 地址空间的服务的集群 IP，或解析为无头服务的 Pod IP 地址集。为了使 PetSet 通过 Rancher 与 Kubernetes 一起使用，我们必须向 Rancher DNS 配置添加对 Pod 标识的支持。我们现在正在努力解决这个问题，并且应该在即将发布的 Rancher 版本之一中支持它。

集群联邦

集群联邦是 Kubernetes 中集群联邦的控制平面。它通过在多个集群中传播应用程序来提高应用程序的可用性（下图是 Kubernetes 提供的）

Screen Shot 2016-07-07 at 1.46.55 PM.png

每个 Kubernetes 集群都公开一个 API 端点，并作为联邦对象的一部分注册到集群联邦。然后，使用集群联邦 API，您可以创建联邦服务。这些对象由多个等效的底层 Kubernetes 资源组成。假设上图中的 3 个集群属于同一个联邦对象，则通过集群联邦创建的每个服务，都将在每个集群中创建等效的服务。除此之外，集群联邦服务还将获得可公开解析的 DNS 名称，该名称可解析为 Kubernetes 服务的公共 IP 地址（DNS 记录被编程到以下公共 DNS 提供商之一）

Screen Shot 2016-07-07 at 1.24.18 PM.png

为了通过 Rancher 支持 Kubernetes 中的集群联邦，需要进行某些更改。今天，每个 Kubernetes 集群都表示为 Rancher 环境。在每个 Kubernetes 环境中，我们都会创建一个完整的 Kubernetes 系统堆栈，该堆栈由多个服务组成：Kubernetes API 服务器、调度器、Ingress 控制器、持久性 etcd、控制器管理器、Kubelet 和 Proxy（最后 2 个在每台主机上运行）。要设置集群联邦，我们将创建一个额外的环境，在其中运行集群联邦堆栈

Screen Shot 2016-07-07 at 1.23.14 PM.png

然后，由 Rancher 环境表示的每个底层 Kubernetes 集群都应注册到特定的集群联邦。每个集群都有可能通过 Rancher 集群联邦环境自动发现，方法是使用 Kubernetes 集群上代表联邦名称的标签。我们仍在努力完成我们的设计，但我们对此特性感到非常兴奋，并且看到了它可以解决的许多用例。集群联邦文档参考

Kubernetes 1.4 的计划

当我们在 Rancher 中启动 Kubernetes 支持时，我们决定维护我们自己的 Kubernetes 发行版，以支持 Rancher 的原生网络。我们知道，拥有我们自己的发行版，我们需要在每次 Kubernetes 发生更改时都对其进行更新，但我们认为这对于支持我们正在为用户开发的用例是必要的。作为我们 1.4 版工作的一部分，我们再次研究了我们的网络方法，并重新分析了我们自己最初分叉 Kubernetes 的需求。除了网络集成外，我们对 Kubernetes 所做的所有工作都是作为 Kubernetes 插件开发的

  • Rancher 作为 CloudProvider（支持负载均衡器）。
  • Rancher 作为 CredentialProvider（支持 Rancher 私有注册表）。
  • Rancher Ingress 控制器支持 Kubernetes Ingress 资源。

因此，我们已决定消除对 Rancher Kubernetes 发行版的需要，并尝试将我们所有的更改上游到 Kubernetes 仓库。为此，我们将重新设计我们的网络集成，并支持 Rancher 网络作为 Kubernetes 的 CNI 插件。有关这方面的更多详细信息将在特性设计完成后立即分享，但预计将在未来 2-3 个月内推出。我们还将继续投资于与 Kubernetes 集成的 Rancher 核心功能，包括但不限于

  • 通过代表 Kubernetes 集群的 Rancher 环境进行访问权限管理
  • 凭证管理和通过 Web 进行标准 kubectl cli 的便捷访问
  • 负载均衡支持
  • Rancher 内部 DNS 支持
  • Kubernetes 模板的目录支持
  • 增强的 UI，以表示更多 Kubernetes 对象，例如：Deployment、Ingress、Daemonset。

所有这些都是为了使 Kubernetes 体验更加强大且用户直观。我们对 Kubernetes 社区的所有进展感到非常兴奋，并且很高兴能够参与其中。Kubernetes 1.3 是一个非常重要的版本，您很快就可以在 Rancher 中升级到它。

Rancher-and-Kubernetes.png