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

作者 | 阿裡巴巴技術專家  溪恒

一、需求來源

為什麼需要服務發現

在 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 之間的通路，提供統一的通路位址。

二、用例解讀

下面進行實際的一個用例解讀，看 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 上面。

三、操作示範

下面進行實際操作示範，在阿裡雲的容器服務上面進去體驗一下如何使用 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 在生命周期的一個變化。

以上就是所有示範。

四、架構設計

最後是對 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等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的技術公衆号。”