本文分三個部分：
- kubernetes 集群內部的服務註冊與發現
- kubernetes consul實現服務註冊與發現
- kubernetes 跨集群服務註冊與發現
一、kubernetes 集群內部的服務註冊發現
k8s平臺通過kube-dns或者coreDNS實現了服務註冊和發現功能。對於應用來講，這個功能是透明的！
服務註冊：
比如服務serviceA只要在yaml文件中定義servicename為serviceA即可。當這個yaml文件被k8s平臺調度執行的時候，就會自動把這個serviceA註冊到k8s平臺；
服務發現（基於DNS）：
其他服務，比如serviceB如果要使用這個服務（serviceA），直接使用http://serviceA 或者http://serivceA.${namespace_name}(不同namespace需要在url裡進一步制定namespace_name)作為url即可訪問。
但是有時候，我們基於某些考量，不想使用k8s本身的服務註冊和發現功能，那麼我們還有另外一種選擇，那就是consul。
二、kubernetes consul實現服務註冊發現
kubernetes集群使用consul有兩種方式：一種是侵入式的，一種是非侵入式的。
方案一、sidecar方式
在編寫pod的yaml的時候，需要附帶額外的consul-agent container。正常的工作container通過configmap把服務信息傳遞到consul-agent container。啟動時，由consul-agent container根據configmap完成服務註冊的過程。
sidecar方式實現服務註冊
方案二、consul-k8s project
開源項目，運行額外的webhook容器。此容器會通過k8s api server監控集群中的service，當有新的service添加進來，則自動將其註冊到consul server。
consul-k8s 方案
這兩種方案的差別在這裡：
方案優劣比較
綜上所述，關於k8s集群內部的服務註冊和發現功能，其實我們有三種選擇：k8s平臺本身提供的服務註冊與發現功能、k8s consul sidecar方式、consul-k8s方案。
然而，這三種方案都是k8s集群內部所用的方案，如果是k8s跨集群的服務註冊與發現呢，我們該如何實現？
三、kubernetes 跨集群服務註冊與發現
k8s本身的服務註冊與發現只能解決集群內部的服務註冊與發現。所以，要解決跨集群的問題，我們只能在consul上找方法。
方案一：Consul server under master cluster
consul server運行在一個獨立的k8s集群，名字為master，其他k8s集群裡的consul agent都連接到master集群的consul server。示例架構圖如下：
Consul server under master cluster
網絡要求：
- 每個consul server 至少要暴露8300和8301端口
- master集群consul server 的pod和所有slave1 集群裡的consul agent所在的pod網絡互通！
而第二個條件，實際上是不可達的。所以，此方案無效！
方案二：Consul more datacenter
此方案其實使用了consul多datacenter機制。每個k8s集群運行一套consul server並命名為不同的datacenter。datacenter之間通過wlan gossip交換服務信息。
Consul more datacenter
網絡要求：
- 每個consul server 至少要暴露8300和8302端口
- datacenter DC1裡的所有consul server pod和datacenter DC2的所有consul server pod 網絡互通
但是由於不同的k8s集群之間的pod其實是網絡隔離的。所以，本方案的要求也得不到滿足。
因而，此方案也是無效的。
所以，在k8s的網絡環境下，要通過consul實現跨集群的服務註冊與發現功能，是不可行的！
大家如有可行的方案，請私信與我！
下期預報：kubernetes服務安全之istio
作者簡介：研華科技軟件主管，聚焦linux內核技術和k8s雲平臺架構設計。我會在這裡分享kubernetes雲平臺的架構設計。也會分享我們針對某些開源組件的優劣評估和性能測試以及優化過程。歡迎大家一起探討雲原生技術。
閱讀更多 80後程序員的世界觀 的文章
