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

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

上述操作的结果是，将在单独的主机上启动 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 Ingress 控制器在 Kubernetes 中的实现详情，请参见此处：

Rancher 和 Kubernetes 1.3

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

Kubernetes 有状态应用程序

有状态应用程序是 Kubernetes 中的一个新资源，用于表示有状态应用程序中的一组 Pod。这是使用复制控制器的替代方案，复制控制器最适合用于运行无状态应用程序。此功能对于依赖于具有领导者选举的仲裁（例如 MongoDB、Zookeeper、etcd）和去中心化仲裁（Cassandra）的应用程序特别有用。有状态应用程序创建并维护一组 Pod，每个 Pod 都具有稳定的网络身份。为了提供网络身份，必须能够为 Pod 提供一个可解析的 DNS 名称，该名称与 Pod 身份相关联，如 Kubernetes 设计文档所述。

# 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 和代理（最后两个在每台主机上运行）。为了设置集群联邦，我们将创建一个额外的环境，在该环境中运行集群联邦堆栈。

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 个月内推出。我们还将继续投资 Rancher 与 Kubernetes 集成的核心功能，包括但不限于：

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

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

Rancher-and-Kubernetes.png