背景

在做傳統(tǒng)業(yè)務(wù)開(kāi)發(fā)的時(shí)候，當(dāng)我們的服務(wù)提供方有多個(gè)實(shí)例時(shí)，往往我們需要將對(duì)方的服務(wù)列表保存在本地，然后采用一定的算法進(jìn)行調(diào)用；當(dāng)服務(wù)提供方的列表變化時(shí)還得及時(shí)通知調(diào)用方。

student:     url:        - 192.168.1.1:8081        - 192.168.1.2:8081

這樣自然是對(duì)雙方都帶來(lái)不少的負(fù)擔(dān)，所以后續(xù)推出的服務(wù)調(diào)用框架都會(huì)想辦法解決這個(gè)問(wèn)題。

以spring cloud為例：

(相關(guān)資料圖)

圖片

服務(wù)提供方會(huì)向一個(gè)服務(wù)注冊(cè)中心注冊(cè)自己的服務(wù)（名稱(chēng)、IP等信息），客戶(hù)端每次調(diào)用的時(shí)候會(huì)向服務(wù)注冊(cè)中心獲取一個(gè)節(jié)點(diǎn)信息，然后發(fā)起調(diào)用。

但當(dāng)我們切換到k8s后，這些基礎(chǔ)設(shè)施都交給了k8s處理了，所以k8s自然得有一個(gè)組件來(lái)解決服務(wù)注冊(cè)和調(diào)用的問(wèn)題。

也就是我們今天重點(diǎn)介紹的service。

service

在介紹service之前我先調(diào)整了源碼：

func main() {     http.HandleFunc("/ping", func(w http.ResponseWriter, r *http.Request) {        name, _ := os.Hostname()        log.Printf("%s ping", name)        fmt.Fprint(w, "pong")     })     http.HandleFunc("/service", func(w http.ResponseWriter, r *http.Request) {        resp, err := http.Get("http://k8s-combat-service:8081/ping")        if err != nil {           log.Println(err)           fmt.Fprint(w, err)           return        }        fmt.Fprint(w, resp.Status)     })       http.ListenAndServe(":8081", nil)  }

新增了一個(gè)/service的接口，這個(gè)接口會(huì)通過(guò) service 的方式調(diào)用服務(wù)提供者的服務(wù)，然后重新打包。

make docker

同時(shí)也新增了一個(gè)deployment-service.yaml:

apiVersion: apps/v1  kind: Deployment  metadata:    labels:      app: k8s-combat-service # 通過(guò)標(biāo)簽選擇關(guān)聯(lián)    name: k8s-combat-service  spec:    replicas: 1    selector:      matchLabels:        app: k8s-combat-service    template:      metadata:        labels:          app: k8s-combat-service      spec:        containers:          - name: k8s-combat-service            image: crossoverjie/k8s-combat:v1            imagePullPolicy: Always            resources:              limits:                cpu: "1"                memory: 100Mi              requests:                cpu: "0.1"                memory: 10Mi  ---  apiVersion: v1  kind: Service  metadata:    name: k8s-combat-service  spec:    selector:      app: k8s-combat-service # 通過(guò)標(biāo)簽選擇關(guān)聯(lián)    type: ClusterIP    ports:      - port: 8081        # 本 Service 的端口        targetPort: 8081  # 容器端口        name: app

使用相同的鏡像部署一個(gè)新的 deployment，名稱(chēng)為k8s-combat-service，重點(diǎn)是新增了一個(gè)kind: Service的對(duì)象。

這個(gè)就是用于聲明service的組件，在這個(gè)組件中也是使用selector標(biāo)簽和deployment進(jìn)行了關(guān)聯(lián)。

也就是說(shuō)這個(gè)service用于服務(wù)于名稱(chēng)等于k8s-combat-service的deployment。

下面的兩個(gè)端口也很好理解，一個(gè)是代理的端口， 另一個(gè)是 service 自身提供出去的端口。

至于type: ClusterIP是用于聲明不同類(lèi)型的service，除此之外的類(lèi)型還有：

NodePortLoadBalancerExternalName等類(lèi)型，默認(rèn)是ClusterIP，現(xiàn)在不用糾結(jié)這幾種類(lèi)型的作用，后續(xù)我們?cè)谥v到Ingress的時(shí)候會(huì)具體介紹。負(fù)載測(cè)試

我們先分別將這兩個(gè)deployment部署好：

k apply -f deployment/deployment.yamlk apply -f deployment/deployment-service.yaml? k get podNAME                                  READY   STATUS    RESTARTS   AGEk8s-combat-7867bfb596-67p5m           1/1     Running   0          3h22mk8s-combat-service-5b77f59bf7-zpqwt   1/1     Running   0          3h22m

由于我新增了一個(gè)/service的接口，用于在k8s-combat中通過(guò)service調(diào)用k8s-combat-service的接口。

resp, err := http.Get("http://k8s-combat-service:8081/ping")

其中k8s-combat-service服務(wù)的域名就是他的服務(wù)名稱(chēng)。

如果是跨 namespace 調(diào)用時(shí)，需要指定一個(gè)完整名稱(chēng)，在后續(xù)的章節(jié)會(huì)演示。

我們整個(gè)的調(diào)用流程如下：

圖片

相信大家也看得出來(lái)相對(duì)于spring cloud這類(lèi)微服務(wù)框架提供的客戶(hù)端負(fù)載方式，service是一種服務(wù)端負(fù)載，有點(diǎn)類(lèi)似于Nginx的反向代理。

為了更直觀的驗(yàn)證這個(gè)流程，此時(shí)我將k8s-combat-service的副本數(shù)增加到 2：

spec:    replicas: 2

只需要再次執(zhí)行：

? k apply -f deployment/deployment-service.yamldeployment.apps/k8s-combat-service configuredservice/k8s-combat-service unchanged

圖片

image.png

不管我們對(duì)deployment的做了什么變更，都只需要apply這個(gè)yaml文件即可， k8s 會(huì)自動(dòng)將當(dāng)前的deployment調(diào)整為我們預(yù)期的狀態(tài)（比如這里的副本數(shù)量增加為 2）；這也就是k8s中常說(shuō)的聲明式 API。

可以看到此時(shí)k8s-combat-service的副本數(shù)已經(jīng)變?yōu)閮蓚€(gè)了。如果我們此時(shí)查看這個(gè)service的描述時(shí)：

? k describe svc k8s-combat-service |grep EndpointsEndpoints:         192.168.130.133:8081,192.168.130.29:8081

會(huì)發(fā)現(xiàn)它已經(jīng)代理了這兩個(gè)Pod的 IP。

圖片

此時(shí)我進(jìn)入了k8s-combat-7867bfb596-67p5m的容器：

k exec -it k8s-combat-7867bfb596-67p5m bashcurl http://127.0.0.1:8081/service

并執(zhí)行兩次/service接口，發(fā)現(xiàn)請(qǐng)求會(huì)輪訓(xùn)進(jìn)入k8s-combat-service的代理的 IP 中。

由于k8s service是基于TCP/UDP的四層負(fù)載，所以在http1.1中是可以做到請(qǐng)求級(jí)的負(fù)載均衡，但如果是類(lèi)似于gRPC這類(lèi)長(zhǎng)鏈接就無(wú)法做到請(qǐng)求級(jí)的負(fù)載均衡。

換句話說(shuō)service只支持連接級(jí)別的負(fù)載。

如果要支持gRPC，就得使用 Istio 這類(lèi)服務(wù)網(wǎng)格，相關(guān)內(nèi)容會(huì)在后續(xù)章節(jié)詳解。

總結(jié)

總的來(lái)說(shuō)k8s service提供了簡(jiǎn)易的服務(wù)注冊(cè)發(fā)現(xiàn)和負(fù)載均衡功能，當(dāng)我們只提供 http 服務(wù)時(shí)是完全夠用的。

關(guān)鍵詞：