如何在Rancher 2.0中使用服務發現

對於全部基於容器的環境而言，服務發現都是不可或缺的核心功能之一。使用容器打包和啓動應用程序以後，下一步就是使其能夠被環境或外部世界中的其餘應用程序容器發現。

在本文中，咱們將詳解Rancher 2.0中服務發現功能，並向你展現如何將Rancher 1.6功能集映射到最新版本。

Rancher 1.6中的服務發現

Rancher 1.6在Cattle環境中提供服務發現。Rancher本身的DNS微服務提供了內部DNS功能。

Rancher的內部DNS提供如下主要功能：

• 堆棧內和跨堆棧的服務發現

  堆棧中的全部服務均可以經過<service_name> 和<service_name>.<stack_name>跨堆棧解析。

• 容器發現

  全部容器都經過他們的名字全局解析。

• 建立服務別名

  爲服務添加別名，並使用別名連接到其餘服務。

• 發現外部服務

  指向使用外部IP或域名部署在Rancher以外的服務。

Rancher 2.0中的服務發現

Rancher 2.0使用原生的Kubernetes DNS支持爲Kubernetes工做負載和pod提供等效的服務發現。Cattle用戶將可以在不丟失任何功能的狀況下複製Rancher 2.0中的全部服務發現功能。

與Rancher 1.6 DNS微服務相似，Kubernetes在集羣內調度DNS pod和服務，並配置kubelet以將全部DNS查找路由到此DNS服務。Rancher 2.0的Kubernetes集羣將skyDNS部署爲Kubernetes DNS服務，這是默認Kube-DNS實現的一種風格。

服務解析

Rancher 1.6服務映射到某種類型的Kubernetes工做負載，您能夠在此瞭解一個有關流行類型工做負載的簡短摘要：

https://rancher.com/docs/rancher/v2.x/en/k8s-in-rancher/workloads/#workloads

Kubernetes工做負載是指定爲工做負載啓動的pod的部署規則的對象。工做負載對象自己沒法經過DNS解析爲Kubernetes集羣中的其餘對象。要查找和訪問工做負載，須要爲工做負載建立Kubernetes服務。如下是Kubernetes服務的一些細節：

https://kubernetes.io/docs/concepts/services-networking/service/

在Kubernetes中建立的任何服務都會得到DNS名稱。爲服務建立的DNS A記錄的格式爲 <service_name>.<namespace_name>.svc.cluster.local。服務的DNS名稱解析爲服務的集羣IP。集羣IP是分配給服務的內部IP，可在集羣內解析。

在Kubernetes命名空間內，服務可使用<service_name> 直接解析，命名空間外部的服務則可使用<service_name>.<namespace_name>直接解析。這相似於Rancher 1.6中堆棧內以及跨堆棧的服務發現。

所以，要查找和訪問應用程序工做負載，須要建立一個獲取DNS記錄的服務。

Rancher經過使用您在UI中選擇的服務端口和服務類型自動建立服務以及工做負載，同時部署與工做負載名稱相同的工做負載和服務名稱，從而簡化了此過程。若是沒有暴露端口，則使用端口42。這種作法使得工做負載能夠經過名稱在命名空間內和跨命名空間發現。

例如，以下所示，我使用Rancher 2.0 UI在兩個名稱空間中部署了幾個類型爲Deployment的工做負載。

我能夠在Cluster> Project> Service Discovery選項卡下看到Rancher爲工做負載自動建立的相應DNS記錄。

以下所示，工做負載可供命名空間內和跨命名空間的任何其餘工做負載訪問。

Pod解析

在Kubernetes集羣中運行的各個pod也會分配一個DNS記錄，其格式爲 <pod_ip_address>.<namespace_name>.pod.cluster.local。例如，某pod的IP爲10.42.2.7，它在命名空間default 中，DNS名稱爲 cluster.local，則它的entry爲10-42-2-7.default.pod.cluster.local。

若是是在pod規範中設置，也可使用hostname和subdomain字段解析Pod。相關內容能夠參考Kubernetes文檔：

https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/

爲工做負載和外部服務建立別名

就像您能夠爲Rancher 1.6服務建立別名同樣，您也可使用Rancher 2.0對Kubernetes工做負載執行相同的操做。一樣，您也可使用Rancher 2.0中的主機名或IP地址建立指向外部運行服務的DNS記錄。這些DNS記錄是Kubernetes服務對象。

使用2.0 UI，導航到Cluster> Project視圖，而後選擇Service Discovery選項卡。此處，爲您的工做負載建立的全部現有DNS記錄都將列在每一個命名空間下。

單擊「Add Record 」以建立新的DNS記錄，並查看連接到外部服務所支持的各類選項，或爲另外一個工做負載/ DNS記錄/pod組建立別名。

須要注意的一點是，在建立DNS記錄的這些選項中，Kubernetes自己支持如下選項：

• 指向外部主機名

• 指向一組與選擇器匹配的pod

其他功能由Rancher利用Kubernetes實現：

• 指向外部IP地址

• 爲另外一個DNS記錄建立別名

• 指向另外一個工做負載

  
  

從Docker Compose到Kubernetes YAML

如今讓咱們看看若是咱們想要使用Compose文件將應用程序從1.6遷移到2.0而不是經過2.0 UI部署它，咱們須要怎麼作。

上文中介紹過，當咱們使用Rancher 2.0 UI部署工做負載時，Rancher會在內部爲服務發現建立必要的Kubernetes ClusterIP服務。可是，若是您是經過Rancher CLI或Kubectl客戶端部署工做負載，那麼您應該如何確保完成相同的服務發現行爲？

經過Compose在命名空間內和跨命名空間進行服務發現

讓咱們從如下docker-compose.yml文件開始，該文件顯示了堆棧中的兩個服務（foo和bar）。在Cattle堆棧中，這兩個服務可使用其服務名稱相互訪問。

那麼，若是咱們將這兩個服務遷移到Rancher 2.0中的命名空間，會發生什麼？

咱們可使用Kompose工具將此docker-compose.yml文件從Rancher 1.6轉換爲Kubernetes YAML，而後使用Rancher CLI在Kubernetes集羣中部署該應用程序。

如今，此轉換會生成* -deployment.yaml文件，使用Rancher CLI部署它們會在命名空間內建立相應的工做負載。

這些工做負載能夠在命名空間內相互訪問嗎？咱們可使用Rancher 2.0 UI執行工做負載foo的shell，而後看看ping另外一個工做負載bar是否有效。

沒有！緣由是咱們只建立了Deployment類型的工做負載對象。爲了使這些工做負載可被發現，它們每一個都須要一個指向它們的ClusterIP類型的服務，該服務將被分配一個DNS記錄。用於此類服務的Kubernetes YAML應以下所示。

請注意，ports是必填字段。所以，咱們須要爲其提供一些端口號，如此處所示的42。

經過CLI部署此服務後，服務foo能夠成功ping到服務bar了！

所以，若是您使用Compose-to-Kubernetes-YAML路由將1.6服務遷移到Rancher 2.0，請確保您還爲工做負載部署了相應的ClusterIP服務。相同的解決方案也適用於工做負載的跨命名空間引用。

Compose的連接／外部連接

若是您是Cattle用戶，您必定知道在Rancher 1.6中，您能夠建立指向其餘服務的服務連接/別名，並在您的應用程序中使用該別名來發現該連接的目標服務。

例以下面的應用程序，其中Web服務使用別名mongo連接到數據庫服務。

使用Kompose，將此Compose文件轉換爲Kubernetes YAML生成相應的部署和服務YAML規範。若是您在docker-compose.yml中的服務公開端口，Kompose默認會生成Kubernetes ClusterIP服務YAML規範。

使用Rancher CLI部署這些工具會生成必要的工做負載。

可是此處缺乏了服務連接mongo，由於Kompose轉換不支持docker-compose.yml文件中的連接。如此一來，工做負載web出現了錯誤，其pod繼續從新啓動，沒法解析到數據庫服務的mongo連接。

咱們如何修復破壞的DNS連接？解決方案是建立另外一個ClusterIP服務規範，並將其名稱設置爲docker-compose中連接的別名。

部署此服務會建立必要的DNS記錄，並建立連接mongo，從而使web工做負載可用。

下圖顯示的就是web工做負載啓動的pod已進入Running狀態。

將來從SkyDNS過渡到CoreDNS

從Rancher v2.0.7開始，Rancher部署了由Kubernetes版本1.10.x支持的skyDNS。在Kubernetes 1.11及更高版本中，CoreDNS能夠做爲DNS提供程序安裝。咱們也正在評估CoreDNS，它將在Rancher的將來版本中做爲skyDNS的替代品。

結  語  

本文介紹瞭如何經過Kubernetes DNS功能在Rancher 2.0中支持等效的服務發現。在後續文章中，咱們將分享Rancher 2.0支持的負載均衡功能以及與Rancher 1.6相比存在的限制。