背景
在做傳統業務開發的時候,當我們的服務提供方有多個實例時,往往我們需要將對方的服務列表保存在本地,然後採用一定的算法進行調用;當服務提供方的列表變化時還得及時通知調用方。
student:
url:
- 192.168.1.1:8081
- 192.168.1.2:8081
這樣自然是對雙方都帶來不少的負擔,所以後續推出的服務調用框架都會想辦法解決這個問題。
以 spring cloud
爲例:
服務提供方會向一個服務註冊中心註冊自己的服務(名稱、IP等信息),客戶端每次調用的時候會向服務註冊中心獲取一個節點信息,然後發起調用。
但當我們切換到 k8s
後,這些基礎設施都交給了 k8s
處理了,所以 k8s
自然得有一個組件來解決服務註冊和調用的問題。
也就是我們今天重點介紹的 service
。
service
在介紹 service
之前我先調整了源碼:
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)
}
新增了一個 /service
的接口,這個接口會通過 service 的方式調用服務提供者的服務,然後重新打包。
make docker
同時也新增了一個 deployment-service.yaml
:
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app: k8s-combat-service # 通過標籤選擇關聯
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 # 通過標籤選擇關聯
type: ClusterIP
ports:
- port: 8081 # 本 Service 的端口
targetPort: 8081 # 容器端口
name: app
使用相同的鏡像部署一個新的 deployment,名稱爲 k8s-combat-service
,重點是新增了一個kind: Service
的對象。
這個就是用於聲明 service
的組件,在這個組件中也是使用 selector
標籤和 deployment
進行了關聯。
也就是說這個 service
用於服務於名稱等於 k8s-combat-service
的 deployment
。
下面的兩個端口也很好理解,一個是代理的端口, 另一個是 service 自身提供出去的端口。
至於 type: ClusterIP
是用於聲明不同類型的 service
,除此之外的類型還有:
NodePort
LoadBalancer
ExternalName
等類型,默認是ClusterIP
,現在不用糾結這幾種類型的作用,後續我們在講到Ingress
的時候會具體介紹。
負載測試
我們先分別將這兩個 deployment
部署好:
k apply -f deployment/deployment.yaml
k apply -f deployment/deployment-service.yaml
❯ k get pod
NAME READY STATUS RESTARTS AGE
k8s-combat-7867bfb596-67p5m 1/1 Running 0 3h22m
k8s-combat-service-5b77f59bf7-zpqwt 1/1 Running 0 3h22m
由於我新增了一個 /service
的接口,用於在 k8s-combat
中通過 service
調用 k8s-combat-service
的接口。
resp, err := http.Get("http://k8s-combat-service:8081/ping")
其中 k8s-combat-service
服務的域名就是他的服務名稱。
如果是跨 namespace 調用時,需要指定一個完整名稱,在後續的章節會演示。
我們整個的調用流程如下:
相信大家也看得出來相對於 spring cloud
這類微服務框架提供的客戶端負載方式,service
是一種服務端負載,有點類似於 Nginx
的反向代理。
爲了更直觀的驗證這個流程,此時我將 k8s-combat-service
的副本數增加到 2:
spec:
replicas: 2
只需要再次執行:
❯ k apply -f deployment/deployment-service.yaml
deployment.apps/k8s-combat-service configured
service/k8s-combat-service unchanged
不管我們對
deployment
的做了什麼變更,都只需要apply
這個yaml
文件即可, k8s 會自動將當前的deployment
調整爲我們預期的狀態(比如這裏的副本數量增加爲 2);這也就是k8s
中常說的聲明式 API。
可以看到此時 k8s-combat-service
的副本數已經變爲兩個了。
如果我們此時查看這個 service
的描述時:
❯ k describe svc k8s-combat-service |grep Endpoints
Endpoints: 192.168.130.133:8081,192.168.130.29:8081
會發現它已經代理了這兩個 Pod
的 IP。
此時我進入了 k8s-combat-7867bfb596-67p5m
的容器:
k exec -it k8s-combat-7867bfb596-67p5m bash
curl http://127.0.0.1:8081/service
並執行兩次 /service
接口,發現請求會輪訓進入 k8s-combat-service
的代理的 IP 中。
由於 k8s service
是基於 TCP/UDP
的四層負載,所以在 http1.1
中是可以做到請求級的負載均衡,但如果是類似於 gRPC
這類長鏈接就無法做到請求級的負載均衡。
換句話說 service
只支持連接級別的負載。
如果要支持 gRPC
,就得使用 Istio 這類服務網格,相關內容會在後續章節詳解。
總結
總的來說 k8s service
提供了簡易的服務註冊發現和負載均衡功能,當我們只提供 http 服務時是完全夠用的。
相關的源碼和 yaml 資源文件都存在這裏:
https://github.com/crossoverJie/k8s-combat