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和後端也在不斷的更叠。有可能當你讀到這篇文章的時候，已經有了更酷的功能出現，那麽敬請期待咯！

使用Rancher 2.0管理Kubernetes工作負載