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和后端也在不断的更迭。有可能当你读到这篇文章的时候，已经有了更酷的功能出现，那么敬请期待咯！
原文地址：http://blog.51cto.com/12462495/2105936
