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

Rancher 中的 Kubernetes：进一步演进

作者：Alena Prokharchyk (Rancher Labs) |

Rancher 支持的第一个外部编排平台是 Kubernetes。自发布以来，它已成为我们用户中使用最广泛的平台之一，并且采用率持续快速增长。随着 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 Annotation 指定规模来水平扩展支持 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

上述操作的结果是，将在不同的主机上启动 2 个 Rancher 负载均衡器实例，并且 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

可以在此处找到有关 Rancher Kubernetes Ingress 控制器实现的更多详细信息：

Rancher 和 Kubernetes 1.3

我们对 Kubernetes 1.3 的发布及其包含的所有新特性感到非常兴奋。我们尤其感兴趣的有两项：Stateful Apps 和集群 Federation。

Kubernetes Stateful Apps

Stateful Apps 是 Kubernetes 中一个新资源，用于表示有状态应用中的一组 Pod。它是使用 Replication Controller 的替代方案，后者最适合运行无状态应用。此特性对于依赖于带有领导者选举的法定人数（例如 MongoDB、Zookeeper、etcd）和去中心化法定人数（Cassandra）的应用特别有用。Stateful Apps 创建并维护一组 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 上的 Annotation 实现，Annotation 会暴露给 Endpoint，并最终通过暴露这些 Pod 的 Service 以 DNS 的形式暴露。目前 Rancher 通过利用 Rancher DNS 作为 SkyDNS 的直接替代方案来简化 DNS 配置。Rancher DNS 快速、稳定且可扩展 - 集群中的每个主机都运行 DNS 服务器。Kubernetes Service 会被编程到 Rancher DNS 中，并被解析为来自 10.43.x.x 地址空间的 Service 的 Cluster IP，或者对于 Headless Service，解析为一组 Pod IP 地址。为了通过 Rancher 使 PetSet 与 Kubernetes 一起工作，我们必须向 Rancher DNS 配置添加对 Pod Identities 的支持。我们正在为此努力，并应该在即将发布的 Rancher 版本中支持它。

集群 Federation

集群 Federation 是 Kubernetes 中集群 federation 的控制平面。它通过将应用分散到多个集群来提高应用可用性（下图由 Kubernetes 提供）。

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

每个 Kubernetes 集群都暴露一个 API 端点，并作为 Federation 对象的一部分注册到 Cluster Federation。然后，使用 Cluster Federation API，你可以创建 federated service。这些对象由多个等效的底层 Kubernetes 资源组成。假设上图中的 3 个集群属于同一个 Federation 对象，通过 Cluster Federation 创建的每个 Service 都将在每个集群中创建相应的 Service。此外，Cluster Federation service 将获得一个可公开解析的 DNS 名称，该名称可解析到 Kubernetes Service 的公共 IP 地址（DNS 记录会被编程到下面的某个公共 DNS 提供商）。

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

为了在 Rancher 中通过 Kubernetes 支持 Cluster Federation，需要进行一些更改。目前，每个 Kubernetes 集群都被表示为一个 Rancher 环境。在每个 Kubernetes 环境中，我们都会创建一个完整的 Kubernetes 系统栈，包括多个服务：Kubernetes API Server、Scheduler、Ingress Controller、持久化 etcd、Controller Manager、Kubelet 和 Proxy（最后两个服务在每个主机上运行）。为了设置 Cluster Federation，我们将创建一个额外的环境，用于运行 Cluster Federation 栈。

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

然后，由 Rancher 环境表示的每个底层 Kubernetes 集群都应注册到特定的 Cluster Federation。每个集群都可以通过代表 federation 名称的 Kubernetes 集群上的标签被 Rancher Cluster Federation 环境自动发现。我们仍在最终确定设计方案，但我们对这个特性感到非常兴奋，并看到了它能解决许多用例。Cluster Federation 文档参考：

Kubernetes 1.4 计划

当我们在 Rancher 中推出 Kubernetes 支持时，我们决定维护自己的 Kubernetes 发行版，以支持 Rancher 的原生网络。我们知道拥有自己的发行版意味着每次 Kubernetes 发生变化时都需要更新它，但我们认为这是支持我们正在为用户解决的用例所必需的。作为 1.4 工作的一部分，我们再次审视了我们的网络方法，并重新分析了最初需要我们自己的 Kubernetes 分支的原因。除了网络集成之外，我们在 Kubernetes 上所做的所有工作都是作为 Kubernetes 插件开发的：

  • Rancher 作为 Cloud Provider（支持负载均衡器）。
  • Rancher 作为 Credential Provider（支持 Rancher 私有仓库）。
  • Rancher Ingress 控制器，用于支持 Kubernetes Ingress 资源。

因此，我们决定取消对 Rancher Kubernetes 发行版的需求，并尝试将我们所有的更改 upstream 到 Kubernetes 仓库。为此，我们将重做我们的网络集成，并支持 Rancher 网络作为 Kubernetes 的 CNI 插件。有关更多详细信息，一旦特性设计最终确定，我们将尽快分享，预计将在接下来的 2-3 个月内推出。我们还将继续投资于与 Kubernetes 集成的 Rancher 核心功能，包括但不限于：

  • 通过代表 Kubernetes 集群的 Rancher 环境进行访问权限管理
  • 凭证管理和通过 Web 轻松访问标准 kubectl 命令行界面
  • 负载均衡支持
  • Rancher 内部 DNS 支持
  • Kubernetes 模板的 Catalog 支持
  • 增强的用户界面以表示更多 Kubernetes 对象，例如：Deployment、Ingress、Daemonset。

所有这一切都是为了让 Kubernetes 体验更加强大和用户友好。我们对 Kubernetes 社区取得的所有进展感到非常兴奋，并很高兴能参与其中。Kubernetes 1.3 是一个极其重要的版本，你很快就能在 Rancher 中升级到它。

Rancher-and-Kubernetes.png