對k8s有點了解技術(shù)人員，應(yīng)該都只知道k8s是有服務(wù)注冊發(fā)現(xiàn)的，今天就分析下這個原理，看看怎么實現(xiàn)的。

什么是服務(wù)注冊與發(fā)現(xiàn)

服務(wù)注冊與發(fā)現(xiàn)是一種機制，用于在集群中動態(tài)地發(fā)現(xiàn)和連接不同的服務(wù)，比如我們在開發(fā)微服務(wù)時，經(jīng)常使用的Eureka、Nacos等

Service B 把自己注冊到 Service Registry 叫做 服務(wù)注冊

Service A 從 Service Registry 發(fā)現(xiàn) Service B 的節(jié)點信息叫做 服務(wù)發(fā)現(xiàn)

K8s 中為什么需要服務(wù)發(fā)現(xiàn)

動態(tài)性

在K8s集群中，Pod和服務(wù)的數(shù)量和位置都是動態(tài)變化的，Pod有可能伸縮、重新部署或遷移，在這樣的環(huán)境下，如果硬編碼的服務(wù)地址是不可行的，所以服務(wù)注冊與發(fā)現(xiàn)使得我們的系統(tǒng)能夠自動感知到這種變化。

透明性

服務(wù)注冊與發(fā)現(xiàn)使得我們的系統(tǒng)可以使用服務(wù)名稱來訪問其他服務(wù)，而不需要關(guān)心具體的IP地址和端口號。

負載均衡

通過服務(wù)注冊與發(fā)現(xiàn)可以實現(xiàn)負載均衡，將請求均勻地分發(fā)到多個后端服務(wù)實例。

容錯性

當(dāng)服務(wù)實例發(fā)生故障或不可用時，服務(wù)注冊與發(fā)現(xiàn)可以自動檢測并從服務(wù)發(fā)現(xiàn)機制中移除不可用的實例。這樣，請求將被自動路由到可用的實例上，提高應(yīng)用程序的容錯性和可用性。

k8s 服務(wù)注冊發(fā)現(xiàn)原理

基于上面的介紹，我們了解到K8s中的Pod的生命周期是短暫的，他們的IP地址會不斷變化，如果讓服務(wù)消費方去管理這些Pod IP在做負載均衡調(diào)用Pod，那么會很復(fù)雜，為了對外提供統(tǒng)一的入口來提供服務(wù)，所以k8s創(chuàng)建了Service，不管是內(nèi)部還是外部統(tǒng)一調(diào)用 Service，然后再由 Service 轉(zhuǎn)發(fā)到后端Pod

Endpoints

Pod 的地址管理則由Endpoints管理，根據(jù)Service名稱可以查詢Endpoints信息，當(dāng)通過API創(chuàng)建/修改service對象時，endpoints控制器的監(jiān)聽到Service對象，然后根據(jù)Service的配置的選擇器創(chuàng)建一個endpoints對象，此對象將pod的IP、容器端口信息存儲到etcd中。

他們之間關(guān)系如下：

同時Endpoints控制器會監(jiān)聽與Pod相關(guān)的事件，包括上下線事件，一旦Endpoints控制器接收到這些事件，它會相應(yīng)地更新Endpoints資源，將不可用的Pod從Endpoints列表中移除。

域名解析

由于Service的 IP有可能會變，如果在代碼里面寫死Service IP后期維護起來也是比較麻煩的事情，所以通過在創(chuàng)建一個Service時，CoreDNS會為該Service添加一個域名解析記錄，將Service的名稱解析為相應(yīng)的Cluster IP地址。這樣其他Pod或服務(wù)可以通過使用Service名稱來訪問該Service。

kube-proxy

kube-proxy 是集群中每個節(jié)點上運行的網(wǎng)絡(luò)代理，它負責(zé)將集群內(nèi)部的Service暴露給其他Pod或外部網(wǎng)絡(luò)。它通過在Node節(jié)點上設(shè)置網(wǎng)絡(luò)規(guī)則和轉(zhuǎn)發(fā)規(guī)則，將Service的請求轉(zhuǎn)發(fā)到正確的目標(biāo)Pod

同時kube-proxy實現(xiàn)負載均衡算法，將進入Service的請求均勻地分發(fā)到后端的Pod實例。這確保了在多個副本的情況下，Service能夠平衡地處理請求，提高可用性和性能。

kube-proxy 通過監(jiān)聽知道了Service、endpoints對象的創(chuàng)建，然后把Service的CLUSTER-IP 和端口信息拿出來，創(chuàng)建iptables NAT規(guī)則做轉(zhuǎn)發(fā)或通過ipvs模塊創(chuàng)建VS服務(wù)器，這樣經(jīng)過CLUSTER-IP的流量都被轉(zhuǎn)發(fā)到后端pod。

當(dāng)Service的目標(biāo)Pod位于同一節(jié)點上時，kube-proxy會將請求直接轉(zhuǎn)發(fā)到該節(jié)點上的Pod，而不會跨節(jié)點轉(zhuǎn)發(fā)。這種情況下，請求不會被發(fā)送到其他節(jié)點上。

然而，如果Service的目標(biāo)Pod分布在多個節(jié)點上，kube-proxy可以通過負載均衡算法將請求轉(zhuǎn)發(fā)到其他節(jié)點上的Pod。

示例演示

下面我們基于兩個配置文件，驗證下上面的結(jié)論

nginx-deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 4
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: mirrorgooglecontainers/serve_hostname
        ports:
        - containerPort: 80

serve_hostname是k8s官方提供的debug鏡像，返回hostname的web server，訪問pod時會返回hostname。

nginx-service.yaml

apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  ports:
    - name: service-port
      port: 80
      protocol: TCP
      targetPort: 9376
  selector:
    app: nginx
  type: ClusterIP

可以看到service 的selector屬性指定了app: nginx，這樣就能匹配 deplyment 中定義的 nginx pod

我們依次執(zhí)行以上兩個文件，最后獲取到信息如下

Service地址查看

kubectl get svc nginx-service

Pod信息查看

kubectl get pods -l app=nginx -o wide

Endpoints信息查看

根據(jù)service名稱查詢

kubectl get ep nginx-service

CoreDNS信息驗證

登錄任意Pod，執(zhí)行ping命令，可以看到根據(jù)Service 名稱解析到了Service cluster ip

負載均衡驗證

登錄任意 pod，執(zhí)行curl nginx-service，請求 service的 80 端口，會返回目標(biāo) pod名稱

以上我們講了什么是服務(wù)發(fā)現(xiàn)，以及 k8s 的服務(wù)發(fā)現(xiàn)是怎么實現(xiàn)的，希望對你有所幫助。