使用 Rancer 2.0 管理 Kubernetes 工作负载

Rancher 2.0 是一个开源的企业级 Kubernetes 平台，现已发布 Beta 版。Rancher 2.0 简洁直观的界面风格及操作体验，将解决业界遗留已久的 Kubernetes 原生 UI 易用性不佳以及学习曲线陡峭的问题。而 Rancher 2.0 创造性的多 Kubernetes 集群管理功能，更是将完美解决生产环境中企业用户可能面临的基础设施不同的困境。加之 Rancher 2.0 带来的监控、日志、CI/CD 等一系列拓展功能，可以说，Rancher 2.0 为企业在生产环境中落地 Kubernetes 提供了更加便捷的途径。

Rancher 2.0 在设计过程中考虑了很多因素。你可以配置和管理 Kubernetes 集群，将用户服务部署到上面，并且可通过身份验证和 RBAC 轻松控制访问。而 Rancher 2.0 最出色的一个地方就是它直观的用户界面，我们希望借此揭开 Kubernetes 神秘的面纱，降低 Kubernetes 原本陡峭的学习曲线。在本文中，Rancher Labs 首席软件工程师 Alena 将引导你理解 Rancher 2.0 新的用户界面，并会解释如何在 Rancher 2.0 中部署简单的 NGINX 服务。

设计你的工作负载

在为应用程序部署工作负载之前，建议你先清楚以下这几件事：

• 这个应用程序是有状态还是无状态的？

• 需要运行多少个应用程序实例？

• 放置规则是怎样的——应用程序是否需要在特定主机上运行？

• 你的应用程序是否要发布成专用网络上的一个服务，这样其他应用程序可以和它通信？

• 该应用程序是否需要公共访问入口？

当然还有更多的问题需要回答，以上只是一些最基本的问题，也是一个好的起点。Rancher UI 将提供更多有关工作负载上配置的详细信息，你可以在稍后对其进行调优和升级。

用 Rancher 2.0 部署属于你的第一个工作负载

我们先做一些有趣的事儿——部署一些非常简单的工作负载，使用 Rancher 将它们和外界对接。假设你已经安装好了 Rancher（Rancher 的安装极其简单，可以一键完成），并且至少配置了一个 Kubernetes 集群（这可能没有“一键部署”那么简单，不过也非常快）。那么现在你要做的是切换到 Project View，点击 Workloads 页面上的“Deploy”：

除了镜像和端口映射（我们将在后文介绍更多细节），所有的选项都是默认的。我希望我的服务能够在集群中的每个主机上的随机一个端口发布，当端口命中时，流量会重定向到 nginx 内部 80 端口。在部署了工作负载之后，将会在 UI 中设置公共端口以方便访问。

通过点击 31217 公共端口链接，你可以直接跳转到你的服务中：

如你所看到的那样，只需要一个步骤就能够部署工作负载并将其发布到外部，这和 Rancher 1.6 非常相似。如果你是 Kubernetes 的用户，那么你肯定知道这需要几个 Kubernetes 对象来备份上述的部署和服务。部署将负责启动容器应用程序；它还会监控容器的运行状况，如果基于重启策略产生崩溃，则重新启动。但是为了将应用程序发布到外部，Kubernetes 需要一个明确创建的服务对象。Rancher 通过用户友好的交互方式获取工作负载声明，并在后台创建所有需要的 Kubernetes 结构，这将大大简化终端用户的工作。关于这些结构的内容会在下一部分介绍。

更多的工作负载选项

默认情况下，Rancher UI 向用户提供是工作负载部署的最基本选项。你可以自行更改这些选项，比如说从更改工作负载类型开始：

根据所选的类型，会创建相应的 Kubernetes 资源。

• (n)Pods 的可扩展部署——Kubernetes 部署

• 在每个节点上运行一个 pod——Kubernetes DaemonSet

• 状态集——Kubernetes StatefulSet

• 在 cron 时间表上运行——Kubernetses CronJob

根据类型的不同，还可以设置镜像、环境变量和标签之类的选项，这些都将定义应用程序的部署规范。现在，可以通过端口映射（Port Mapping）部分完成应用程序到外部的公开：

通过这个端口声明，在部署工作负载之后，它将通过集群中每个节点上的同一个随机端口公开。如果你需要设定特定的值而不是随机产生，那么就在 Source Port 下修改端口。在 Publish on 下还有几个选项：

根据所选的内容，Rancher 将在 Kubernetes 侧创建相应的服务对象：

• 每个节点——Kubernetes NodePort 服务

• 内部集群 IP——Kubernetes ClusterIP 服务。只有在这种情况下，才能通过专用网络访问你的工作负载

• 负载均衡器——Kubernetes 负载均衡器服务。只有当你的 Kubernets 集群部署在公有云（如 AWS）中，并且有一个外部负载均衡器支持（如 AWS ELB）时，才需要选择此选项

• 运行 pod 的节点——不会创建服务；HostPort 选项在部署规范中设置

我们在这里强调了实现细节，不过你其实并不会真正使用到它们。Rancher UI/API 将提供所有必需的信息，只需要单击一下那个连到工作负载的链接，即可访问你的工作负载。

使用 Ingress 时工作负载间的流量分配

还有一种方法可以发布工作负载——通过 Ingress。它不仅在标准 http 的 80/443 端口上发布应用程序，还提供 L7 路由功能以及 SSL 终止。如果你部署一个 Web 应用程序，并且希望根据主机/路径路由规则路由到不同的端口，那么这样的功能是非常有用的：

与 Rancher 1.6 不同的是，负载均衡器不适合像 haproxy 这样的特定 LB 提供者。因集群类型不同，实现也不一样。对于谷歌容器引擎（GCE）集群，负载均衡器是 GLBC；对于 Amazon EKS，它是 AWS ELB/ALB；而对于 Digital Ocean/Amazon EC2；用的是 nginx 负载均衡器。我们将会在未来根据用户的需要推出更多的负载均衡器。

更强大的服务发现

如果你正在构建一个包含多个工作负载的应用程序，那么很可能会使用到 DNS 解析服务名称。当然你可以使用 API 地址连接到容器，但是容器可能会死亡，并且 IP 地址将会改变。因此使用 DNS 是最好的方法。对于那些使用 Rancher 创建的 Kubernetes 集群，Kubernetes 服务发现（Kubernetes Service Discovery）功能是已经内置好了的。从 Rancher UI 创建的每个工作负载都可以在同一个 Namespace（命名空间）中通过其名称解析。尽管为了发现工作负载，需要显式创建一个 Kubernetes 服务（ClusterIP 类型），但是 Rancher 为用户承担了这个负担，并且为每个工作负载自动创建服务。此外，Rancher 通过让用户创建以下内容来增强服务发现：

• DNS 值的别名

• 指向一个或多个现有工作负载的自定义记录

所有上述内容都可以在用户界面的工作负载服务发现（Workloads Service Discovery）页面中找到：

如你所见的那样，在 Rancher 2.0 中配置工作负载和在 1.6 中一样简单。尽管 Rancher 2.0 后端现在是通过 Kubernetes 实现所有功能，但是 Rancher UI 仍然像以前一样简化工作负载的创建。通过 Rancher 接口，你可以向外界公开你的工作负载，将其放置在负载均衡器后面，并配置内部服务发现——这一切都以一种直观且简单的方式完成。

这篇文章介绍了工作负载管理的基本知识。未来我们还会带来更多的有关其他 Rancher 2.0 特性和功能的文章，比如卷、应用程序目录等等。此外，Rancher 2.0 的 UI 和后端也在不断的更迭。有可能当你读到这篇文章的时候，已经有了更酷的功能出现，那么敬请期待咯！