對於所有基於容器的環境而言，服務發現都是不可或缺的核心功能之一。使用容器打包和啓動應用程序之後，下一步就是使其可以被環境或外部世界中的其他應用程序容器發現。
在本文中，我們將詳解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客戶端部署工作負載，那麼您應該如何確保完成相同的服務發現行爲？ 讓我們從以下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服務。相同的解決方案也適用於工作負載的跨命名空間引用。 如果您是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相比存在的限制。
