前言
上一篇內容,我們詳細討論了怎麼使用envoy做負載均衡,並且記錄詳細的地址,其中還解決了一個問題,那就是怎麼讓envoy獲取真實後端pod ip地址,後面使用headless service,既使用了service的服務發現能力,又不使用service的負載均衡能力
如果在某些特殊的場景下完全放棄的k8s service(比如混合雲部署機房,兩邊雲都需要有相同的服務,但是服務之間不能跨雲訪問),怎麼賦予envoy服務發現的能力
靜態配置服務發現
顧名思義,直接寫在配置裏面
...
static_resources:
...
clusters:
- name: backend_cluster
connect_timeout: 0.25s
type: STATIC
load_assignment:
cluster_name: backend_cluster
endpoints:
- lb_endpoints:
- endpoint:
address:
socket_address:
address: 192.168.1.100
port_value: 8080
- endpoint:
address:
socket_address:
address: 192.168.1.101
port_value: 8080
...
type: STATIC是關鍵配置
基於dns的服務發現
之前的k8s服務發現,就是利用k8s dns做的服務發現,這裏再舉一個例子,也是經常使用的三方註冊中心,consul
安裝consul
docker run -d --name consul \
-p 8300-8302:8300-8302 \
-p 8500:8500 \
-p 8301-8302 \
-p 8600:8600/udp \
hashicorp/consul:1.22
這裏的關鍵是-p 8600:8600/udp
修改coredns配置
kubectl -n kube-system edit cm coredns
...
forward consul 10.22.12.178:8600 {
prefer_udp
}
...
只要訪問*.consul的域名,都去訪問10.22.12.178:8600,而8600端口,就是consul提供的dns udp端口
至於為什麼是*.consul呢?.service.consul 是 Consul 官方規定的服務發現域名
| 域名 | 含義 |
|---|---|
service.consul |
服務發現(最常用) |
node.consul |
查詢節點 IP |
query.consul |
Prepared Query |
dc.consul |
跨數據中心 |
所以直接轉發*.consul,粗暴有效
往consul註冊數據
curl -X PUT http://10.22.12.178:8500/v1/agent/service/register \
-H "Content-Type: application/json" \
-d '{
"Name": "backend-service-consul",
"ID": "service-1",
"Address": "10.244.0.82",
"Port": 10000
}'
修改envoy配置
...
clusters:
- name: app_service
connect_timeout: 1s
type: STRICT_DNS
lb_policy: ROUND_ROBIN
load_assignment:
cluster_name: app_service
endpoints:
- lb_endpoints:
- endpoint:
address:
socket_address:
address: "backend-service-consul.service.consul"
port_value: 10000
...
修改完之後重啓服務
這裏需要注意的是address: "backend-service-consul.service.consul"
backend-service-consul是註冊到consul的名字.service.consul上面已經説過,這是consul的固定格式
驗證
curl 10.22.12.178:30785/test
[2025-12-18T09:42:47.296Z] "GET /test HTTP/1.0" 200 40 1 fd326a0e-ec4f-4cf3-a244-b29f4c0c0173 "curl/7.81.0" "-" 10.244.0.82:10000 app_service -
[2025-12-18T09:42:47.584Z] "GET /test HTTP/1.0" 200 40 0 b44ce502-a8ed-489a-b95b-d3c21af9d24d "curl/7.81.0" "-" 10.244.0.82:10000 app_service -
[2025-12-18T09:42:47.816Z] "GET /test HTTP/1.0" 200 40 1 f6ac4149-1e58-4b0e-a263-85fc89cef968 "curl/7.81.0" "-" 10.244.0.82:10000 app_service -
[2025-12-18T09:42:48.039Z] "GET /test HTTP/1.0" 200 40 1 c64c7f05-bcbb-42a7-9e68-a376217a4ca2 "curl/7.81.0" "-" 10.244.0.82:10000 app_service -
[2025-12-18T09:42:48.240Z] "GET /test HTTP/1.0" 200 40 1 96097880-bc28-4686-98d3-ab09848cf28a "curl/7.81.0" "-" 10.244.0.82:10000 app_service -
[2025-12-18T09:42:48.464Z] "GET /test HTTP/1.0" 200 40 0 799f7f10-1cb1-447a-828a-45ccc50273f5 "curl/7.81.0" "-" 10.244.0.82:10000 app_service -
確實已經生效了
consul小結
這裏展示了怎麼使用consul作為服務發現,不管是用headless還是consul,都是dns的服務發現,在consul的例子中,將固定域名(.service.consul)引導至consul提供的dns服務,從而實現
小結
本文介紹瞭如何使用靜態的服務發現以及基於dns的服務發現,但是他們都存在一個問題,一旦envoy的配置有所改變,比如"backend-service-consul.service.consul"域名發生變化,或者port_value: 10000 端口發生變化, 那就勢必要重啓envoy來重新加載配置,這就帶來了系統的複雜性與不穩定性了
那有沒有什麼方法是可以自動加載配置呢?肯定是有的,那又是下一文的內容
聯繫我
- 聯繫我,做深入的交流
至此,本文結束
在下才疏學淺,有撒湯漏水的,請各位不吝賜教...