愈發複雜的應用程序正在依靠微服務來保持可擴展性和提升效率。隨着北京都市體驗網（www.23tuzi.com）數據中心的架構分析，Kubernetes爲微服務提供了完美的環境，並能夠讓其與Kubernetes的工具組件和功能兼容。當應用程序的每個部分放置在一個容器中，整個系統就會更具可伸縮性。
微服務和容器的運作方式也適合當下的CI/CD工作流程，即無需關閉整個系統進行更新，因爲可以分別更新每個微服務（容器）。但是，這會使容器或pod的生命週期縮短，其IP地址會發生變化。
動態IP分配
在我們瞭解如何管理服務以及如何高效建立服務發現之前，我們必須瞭解服務發現所面臨的首要挑戰：IP分配問題。具體而言，Kubernetes將IP地址動態分配給Pod和服務的方式。
我們固然可以爲單個Pod和服務定義IP地址，但這樣做會限制Kubernetes環境的可伸縮性。在默認情況下，環境在每次重新啓動集羣、pod或服務時，任意資源都會獲得新的IP地址，因此我們只能對服務使用唯一的名稱。
爲了克服這一問題，你可以使用兩種方法。其一，查看服務的環境變量。與Docker允許容器相互通信的方式類似，Kubernetes允許你掃描注入到容器中的環境變量。
如果你有在多個端口上運行的服務，你可以運行kubectl exec memcached-rm58b en命令，然後對服務名稱進行快速grep操作，之後將會顯示分配給該服務的可用IP地址和端口。不過，這並不是管理服務發現的最有效方法。因爲，這種方法中依賴的服務必須在 pod 啓動之前就存在，不然是不會出現在環境變量中的。
Kube-DNS救場
長遠來看，以下闡述的第二種方法通常被認爲效率更高，這得益於Kubernetes的插件Kube-DNS。我們先來了解什麼是Kube-DNS。顧名思義，Kube-DNS是充當內部DNS解析器的附加組件。它是一個數據庫，其中包含用於查找的鍵值對。鍵是Kubernetes服務的名稱，值是服務所運行的IP地址。
Kube-DNS僅依賴命名空間，無需以其他方式配置Pod和服務，甚至無需修改集羣、Pod和服務的配置文件即可進行基於DNS的服務發現。
Kube-DNS同時也支持高級DNS查詢以及DNS策略。例如，你可以對每個Pod進行配置，將其配置爲遵循與其運行的節點不同的DNS屬性。這意味着你可以使用私有DNS空間來自定義pod之間如何進行通信。
這一方法還能更進一步，在每個pod的基礎上配置DNS策略。你需要做的就是將節點DNS策略設置爲“None”，然後手動配置每個Pod以滿足你的特定需求。
Label和Selectors
正如前文所述，你可以使用參數來進一步影響Pod之間和服務之間的通信方式。Kubernetes服務發現支持對高級控件使用label和selector，特別是在管理複雜集羣時，label尤爲方便。你可以將label分配給組件和容器，以便於識別。
Kubernetes處理label和selector的方式使得這些參數更易於使用。本質上，它們時添加到元數據中的簡單鍵值參數。也就是說，它們實際上並不會影響系統或環境中的其他部分，你可以在複雜的環境中跨pod和服務（甚至跨節點）自由使用label和selector。
接下來，我們要使用副本控制器。同樣，顧名思義，它是一個可以使Kubernetes的系統具有高可用性和可伸縮性的工具。你可以使用副本控制器來創建和管理pod副本並且維護高可用。同時，你也可以輕鬆地一次性刪除pod及其副本。
Service Mesh和高度彈性伸縮系統
要完成設置，我們需要使用與現有基礎架構和平臺相關的高級服務發現方法。AWS Cloud Map是一個十分有意思的例子。AWS環境中的應用程序資源可以擁有唯一的名稱，並且那些資源會被Cloud Map自動映射。它們註冊完成後，服務會自動變爲可發現的，並且在啓動Pod或服務後立即進行註冊過程。
現在有一個新的方法，通過使用服務網格讓管理微服務的複雜陣列變得容易。服務網格標準化了服務和Pod的通信方式。如果你要創建一個高可用的系統，那麼在環境中使用服務網格來維護Pod的可見性是一個完美的解決方案。
但是，如果你的環境在AWS上，則可以以AWS App Mesh的形式利用其服務網格功能。它會自動處理所有事情，包括流量路由、流量均衡、調用以及使用API調用的circuit breaking。所有微服務都能夠啓用API Mesh，以簡化管理。由於此工具是Amazon生態的一部分，因此它會自動和Amazon EKS、IAM等其他工具一起使用。
Kubernetes服務發現使得容器平臺具有強大功能以及靈活性，服務網格等方法無疑通過標準化使Kubernetes服務發現更加強大。只要服務在運行，就可以使正確的API調用在每個Pod之前來回傳遞數據而不會中斷。