從零開始入門 | Kubernetes 中的服務發現與負載均衡

做者 | 阿里巴巴技術專家  溪恆

1、需求來源

爲何須要服務發現

在 K8s 集羣裏面會經過 pod 去部署應用，與傳統的應用部署不一樣，傳統應用部署在給定的機器上面去部署，咱們知道怎麼去調用別的機器的 IP 地址。可是在 K8s 集羣裏面應用是經過 pod 去部署的， 而 pod 生命週期是短暫的。在 pod 的生命週期過程當中，好比它建立或銷燬，它的 IP 地址都會發生變化，這樣就不能使用傳統的部署方式，不能指定 IP 去訪問指定的應用。

另外在 K8s 的應用部署裏，以前雖然學習了 deployment 的應用部署模式，但仍是須要建立一個 pod 組，而後這些 pod 組須要提供一個統一的訪問入口，以及怎麼去控制流量負載均衡到這個組裏面。好比說測試環境、預發環境和線上環境，其實在部署的過程當中須要保持一樣的一個部署模板以及訪問方式。由於這樣就能夠用同一套應用的模板在不一樣的環境中直接發佈。

Service：Kubernetes 中的服務發現與負載均衡

最後應用服務須要暴露到外部去訪問，須要提供給外部的用戶去調用的。咱們上節瞭解到 pod 的網絡跟機器不是同一個段的網絡，那怎麼讓 pod 網絡暴露到去給外部訪問呢？這時就須要服務發現。

在 K8s 裏面，服務發現與負載均衡就是 K8s Service。上圖就是在 K8s 裏 Service 的架構，K8s Service 向上提供了外部網絡以及 pod 網絡的訪問，即外部網絡能夠經過 service 去訪問，pod 網絡也能夠經過 K8s Service 去訪問。

向下，K8s 對接了另一組 pod，便可以經過 K8s Service 的方式去負載均衡到一組 pod 上面去，這樣至關於解決了前面所說的複發性問題，或者提供了統一的訪問入口去作服務發現，而後又能夠給外部網絡訪問，解決不一樣的 pod 之間的訪問，提供統一的訪問地址。

2、用例解讀

下面進行實際的一個用例解讀，看 pod K8s 的 service 要怎麼去聲明、怎麼去使用？

Service 語法

首先來看 K8s Service 的一個語法，上圖實際就是 K8s 的一個聲明結構。這個結構裏有不少語法，跟以前所介紹的 K8s 的一些標準對象有不少類似之處。好比說標籤 label 去作一些選擇、selector 去作一些選擇、label 去聲明它的一些 label 標籤等。

這裏有一個新的知識點，就是定義了用於 K8s Service 服務發現的一個協議以及端口。繼續來看這個模板，聲明瞭一個名叫 my-service 的一個 K8s Service，它有一個 app:my-service 的 label，它選擇了 app:MyApp 這樣一個 label 的 pod 做爲它的後端。

最後是定義的服務發現的協議以及端口，這個示例中咱們定義的是 TCP 協議，端口是 80，目的端口是 9376，效果是訪問到這個 service 80 端口會被路由到後端的 targetPort，就是隻要訪問到這個 service 80 端口的都會負載均衡到後端 app：MyApp 這種 label 的 pod 的 9376 端口。

建立和查看 Service

如何去建立剛纔聲明的這個 service 對象，以及它建立以後是什麼樣的效果呢？經過簡單的命令：

• kubectl apply -f service.yaml

或者是

• kubectl created -f service.yaml

上面的命令能夠簡單地去建立這樣一個 service。建立好以後，能夠經過：

• kubectl discribe service

去查看 service 建立以後的一個結果。

service 建立好以後，你能夠看到它的名字是 my-service。Namespace、Label、Selector 這些都跟咱們以前聲明的同樣，這裏聲明完以後會生成一個 IP 地址，這個 IP 地址就是 service 的 IP 地址，這個 IP 地址在集羣裏面能夠被其它 pod 所訪問，至關於經過這個 IP 地址提供了統一的一個 pod 的訪問入口，以及服務發現。

這裏還有一個 Endpoints 的屬性，就是咱們經過 Endpoints 能夠看到：經過前面所聲明的 selector 去選擇了哪些 pod？以及這些 pod 都是什麼樣一個狀態？好比說經過 selector，咱們看到它選擇了這些 pod 的一個 IP，以及這些 pod 所聲明的 targetPort 的一個端口。

實際的架構如上圖所示。在 service 建立以後，它會在集羣裏面建立一個虛擬的 IP 地址以及端口，在集羣裏，全部的 pod 和 node 均可以經過這樣一個 IP 地址和端口去訪問到這個 service。這個 service 會把它選擇的 pod 及其 IP 地址都掛載到後端。這樣經過 service 的 IP 地址訪問時，就能夠負載均衡到後端這些 pod 上面去。

當 pod 的生命週期有變化時，好比說其中一個 pod 銷燬，service 就會自動從後端摘除這個 pod。這樣實現了：就算 pod 的生命週期有變化，它訪問的端點是不會發生變化的。

集羣內訪問 Service

在集羣裏面，其餘 pod 要怎麼訪問到咱們所建立的這個 service 呢？有三種方式：

• 首先咱們能夠經過 service 的虛擬 IP 去訪問，好比說剛建立的 my-service 這個服務，經過 kubectl get svc 或者 kubectl discribe service 均可以看到它的虛擬 IP 地址是 172.29.3.27，端口是 80，而後就能夠經過這個虛擬 IP 及端口在 pod 裏面直接訪問到這個 service 的地址。

• 第二種方式直接訪問服務名，依靠 DNS 解析，就是同一個 namespace 裏 pod 能夠直接經過 service 的名字去訪問到剛纔所聲明的這個 service。不一樣的 namespace 裏面，咱們能夠經過 service 名字加「.」，而後加 service 所在的哪一個 namespace 去訪問這個 service，例如咱們直接用 curl 去訪問，就是 my-service:80 就能夠訪問到這個 service。

• 第三種是經過環境變量訪問，在同一個 namespace 裏的 pod 啓動時，K8s 會把 service 的一些 IP 地址、端口，以及一些簡單的配置，經過環境變量的方式放到 K8s 的 pod 裏面。在 K8s pod 的容器啓動以後，經過讀取系統的環境變量比讀取到 namespace 裏面其餘 service 配置的一個地址，或者是它的端口號等等。好比在集羣的某一個 pod 裏面，能夠直接經過 curl $ 取到一個環境變量的值，好比取到 MY_SERVICE_SERVICE_HOST 就是它的一個 IP 地址，MY_SERVICE 就是剛纔咱們聲明的 MY_SERVICE，SERVICE_PORT 就是它的端口號，這樣也能夠請求到集羣裏面的 MY_SERVICE 這個 service。

Headless Service

service 有一個特別的形態就是 Headless Service。service 建立的時候能夠指定 clusterIP:None，告訴 K8s 說我不須要 clusterIP（就是剛纔所說的集羣裏面的一個虛擬 IP），而後 K8s 就不會分配給這個 service 一個虛擬 IP 地址，它沒有虛擬 IP 地址怎麼作到負載均衡以及統一的訪問入口呢？

它是這樣來操做的：pod 能夠直接經過 service_name 用 DNS 的方式解析到全部後端 pod 的 IP 地址，經過 DNS 的 A 記錄的方式會解析到全部後端的 Pod 的地址，由客戶端選擇一個後端的 IP 地址，這個 A 記錄會隨着 pod 的生命週期變化，返回的 A 記錄列表也發生變化，這樣就要求客戶端應用要從 A 記錄把全部 DNS 返回到 A 記錄的列表裏面 IP 地址中，客戶端本身去選擇一個合適的地址去訪問 pod。

能夠從上圖看一下跟剛纔咱們聲明的模板的區別，就是在中間加了一個 clusterIP:None，即代表不須要虛擬 IP。實際效果就是集羣的 pod 訪問 my-service 時，會直接解析到全部的 service 對應 pod 的 IP 地址，返回給 pod，而後 pod 裏面本身去選擇一個 IP 地址去直接訪問。

向集羣外暴露 Service

前面介紹的都是在集羣裏面 node 或者 pod 去訪問 service，service 怎麼去向外暴露呢？怎麼把應用實際暴露給公網去訪問呢？這裏 service 也有兩種類型去解決這個問題，一個是 NodePort，一個是 LoadBalancer。

• NodePort 的方式就是在集羣的 node 上面（即集羣的節點的宿主機上面）去暴露節點上的一個端口，這樣至關於在節點的一個端口上面訪問到以後就會再去作一層轉發，轉發到虛擬的 IP 地址上面，就是剛剛宿主機上面 service 虛擬 IP 地址。

• LoadBalancer 類型就是在 NodePort 上面又作了一層轉換，剛纔所說的 NodePort 實際上是集羣裏面每一個節點上面一個端口，LoadBalancer 是在全部的節點前又掛一個負載均衡。好比在阿里雲上掛一個 SLB，這個負載均衡會提供一個統一的入口，並把全部它接觸到的流量負載均衡到每個集羣節點的 node pod 上面去。而後 node pod 再轉化成 ClusterIP，去訪問到實際的 pod 上面。

3、操做演示

下面進行實際操做演示，在阿里雲的容器服務上面進去體驗一下如何使用 K8s Service。

建立 Service

咱們已經建立好了一個阿里雲的容器集羣，而後而且配置好本地終端到阿里雲容器集羣的一個鏈接。

首先能夠經過 kubectl get cs ，能夠看到咱們已經正常鏈接到了阿里雲容器服務的集羣上面去。

今天將經過這些模板實際去體驗阿里雲服務上面去使用 K8s Service。有三個模板，首先是 client，就是用來模擬經過 service 去訪問 K8s 的 service，而後負載均衡到咱們的 service 裏面去聲明的一組 pod 上。

K8s Service 的上面，跟剛纔介紹同樣，咱們建立了一個 K8s Service 模板，裏面 pod，K8s Service 會經過前端指定的 80 端口負載均衡到後端 pod 的 80 端口上面，而後 selector 選擇到 run:nginx 這樣標籤的一些 pod 去做爲它的後端。

而後去建立帶有這樣標籤的一組 pod，經過什麼去建立 pod 呢？就是以前所介紹的 K8s deployment，經過 deployment 咱們能夠輕鬆建立出一組 pod，而後上面聲明 run:nginx 這樣一個label，而且它有兩個副本，會同時跑出來兩個 pod。

先建立一組 pod，就是建立這個 K8s deployment，經過 kubectl create -f service.yaml。這個 deployment 也建立好了，再看一下 pod 有沒有建立出來。以下圖看到這個 deployment 所建立的兩個 pod 都已經在 running 了。經過 kubectl get pod -o wide 能夠看到 IP 地址。經過 -l，即 label 去作篩選，run=nginx。以下圖所示能夠看到，這兩個 pod 分別是 10.0.0.135 和 10.0.0.12 這樣一個 IP 地址，而且都是帶 run=nginx 這個 label 的。

下面咱們去建立 K8s service，就是剛纔介紹的經過 service 去選擇這兩個 pod。這個 service 已經建立好了。

根據剛纔介紹，經過 kubectl describe svc 能夠看到這個 service 實際的一個狀態。以下圖所示，剛纔建立的 nginx service，它的選擇器是 run=nginx，經過 run=nginx 這個選擇器選擇到後端的 pod 地址，就是剛纔所看到那兩個 pod 的地址：10.0.0.12 和 10.0.0.135。這裏能夠看到 K8s 爲它生成了集羣裏面一個虛擬 IP 地址，經過這個虛擬 IP 地址，它就能夠負載均衡到後面的兩個 pod 上面去。

如今去建立一個客戶端的 pod 實際去感覺一下如何去訪問這個 K8s Service，咱們經過 client.yaml 去建立客戶端的 pod，kubectl get pod 能夠看到客戶端 pod 已經建立好而且已經在運行中了。

經過 kubectl exec 到這個 pod 裏面，進入這個 pod 去感覺一下剛纔所說的三種訪問方式，首先能夠直接去訪問這個 K8s 爲它生成的這個 ClusterIP，就是虛擬 IP 地址，經過 curl 訪問這個 IP 地址，這個 pod 裏面沒有裝 curl。經過 wget 這個 IP 地址，輸入進去測試一下。能夠看到經過這個去訪問到實際的 IP 地址是能夠訪問到後端的 nginx 上面的，這個虛擬是一個統一的入口。

第二種方式，能夠經過直接 service 名字的方式去訪問到這個 service。一樣經過 wget，訪問咱們剛纔所建立的 service 名 nginx，能夠發現跟剛纔看到的結果是同樣的。

在不一樣的 namespace 時，也能夠經過加上 namespace 的一個名字去訪問到 service，好比這裏的 namespace 爲 default。

最後咱們介紹的訪問方式裏面還能夠經過環境變量去訪問，在這個 pod 裏面直接經過執行 env 命令看一下它實際注入的環境變量的狀況。看一下 nginx 的 service 的各類配置已經註冊進來了。

能夠經過 wget 一樣去訪問這樣一個環境變量，而後能夠訪問到咱們的一個 service。

介紹完這三種訪問方式，再看一下如何經過 service 外部的網絡去訪問。咱們 vim 直接修改一些剛纔所建立的 service。

最後咱們添加一個 type，就是 LoadBalancer，就是咱們前面所介紹的外部訪問的方式。

而後經過 kubectl apply，這樣就把剛剛修改的內容直接生效在所建立的 service 裏面。

如今看一下 service 會有哪些變化呢？經過 kubectl get svc -o wide，咱們發現剛剛建立的 nginx service 多了一個 EXTERNAL-IP，就是外部訪問的一個 IP 地址，剛纔咱們所訪問的都是 CLUSTER-IP，就是在集羣裏面的一個虛擬 IP 地址。

而後如今實際去訪問一下這個外部 IP 地址 39.98.21.187，感覺一下如何經過 service 去暴露咱們的應用服務，直接在終端裏面點一下，這裏能夠看到咱們直接經過這個應用的外部訪問端點，能夠訪問到這個 service，是否是很簡單？

咱們最後再看一下用 service 去實現了 K8s 的服務發現，就是 service 的訪問地址跟 pod 的生命週期沒有關係。咱們先看一下如今的 service 後面選擇的是這兩個 pod IP 地址。

咱們如今把其中的一個 pod 刪掉，經過 kubectl delete 的方式把前面一個 pod 刪掉。

咱們知道 deployment 會讓它自動生成一個新的 pod，如今看 IP 地址已經變成 137。

如今再去 describe 一下剛纔的 service，以下圖,看到前面訪問端點就是集羣的 IP 地址沒有發生變化，對外的 LoadBalancer 的 IP 地址也沒有發生變化。在全部不影響客戶端的訪問狀況下，後端的一個 pod IP 已經自動放到了 service 後端裏面。

這樣就至關於在應用的組件調用的時候能夠不用關心 pod 在生命週期的一個變化。

以上就是全部演示。

4、架構設計

最後是對 K8s 設計的一個簡單的分析以及實現的一些原理。

Kubernetes 服務發現架構

如上圖所示，K8s 服務發現以及 K8s Service 是這樣總體的一個架構。

K8s 分爲 master 節點和 worker 節點：

• master 裏面主要是 K8s 管控的內容；
• worker 節點裏面是實際跑用戶應用的一個地方。

在 K8s master 節點裏面有 APIServer，就是統一管理 K8s 全部對象的地方，全部的組件都會註冊到 APIServer 上面去監聽這個對象的變化，好比說咱們剛纔的組件 pod 生命週期發生變化，這些事件。

這裏面最關鍵的有三個組件：

• 一個是 Cloud Controller Manager，負責去配置 LoadBalancer 的一個負載均衡器給外部去訪問；
• 另一個就是 Coredns，就是經過 Coredns 去觀測 APIServer 裏面的 service 後端 pod 的一個變化，去配置 service 的 DNS 解析，實現能夠經過 service 的名字直接訪問到 service 的虛擬 IP，或者是 Headless 類型的 Service 中的 IP 列表的解析；
• 而後在每一個 node 裏面會有 kube-proxy 這個組件，它經過監聽 service 以及 pod 變化，而後實際去配置集羣裏面的 node pod 或者是虛擬 IP 地址的一個訪問。

實際訪問鏈路是什麼樣的呢？好比說從集羣內部的一個 Client Pod3 去訪問 Service，就相似於剛纔所演示的一個效果。Client Pod3 首先經過 Coredns 這裏去解析出 ServiceIP，Coredns 會返回給它 ServiceName 所對應的 service IP 是什麼，這個 Client Pod3 就會拿這個 Service IP 去作請求，它的請求到宿主機的網絡以後，就會被 kube-proxy 所配置的 iptables 或者 IPVS 去作一層攔截處理，以後去負載均衡到每個實際的後端 pod 上面去，這樣就實現了一個負載均衡以及服務發現。

對於外部的流量，好比說剛纔經過公網訪問的一個請求。它是經過外部的一個負載均衡器 Cloud Controller Manager 去監聽 service 的變化以後，去配置的一個負載均衡器，而後轉發到節點上的一個 NodePort 上面去，NodePort 也會通過 kube-proxy 的一個配置的一個 iptables，把 NodePort 的流量轉換成 ClusterIP，緊接着轉換成後端的一個 pod 的 IP 地址，去作負載均衡以及服務發現。這就是整個 K8s 服務發現以及 K8s Service 總體的結構。

後續進階

後續再進階部分咱們還會更加深刻地去講解 K8s Service 的實現原理，以及在 service 網絡出問題以後，如何去診斷以及去修復的技巧。

本文總結

本文的主要內容就到此爲止了，這裏爲你們簡單總結一下：

1. 爲何雲原生的場景須要服務發現和負載均衡，
2. 在 Kubernetes 中如何使用 Kubernetes 的 Service 作服務發現和負載均衡
3. Kubernetes 集羣中 Service 涉及到的組件和大概實現原理

相信通過本文的學習與把握，你們可以經過 Kubernetes Service 將複雜的企業級應用快速並標準地編排起來。

「阿里巴巴雲原生微信公衆號（ID：Alicloudnative）關注微服務、Serverless、容器、Service Mesh等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，作最懂雲原生開發者的技術公衆號。」