使用Rancher 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和后端也在不断的更迭。有可能当你读到这篇文章的时候，已经有了更酷的功能出现，那么敬请期待咯！