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