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