不同k8s集群間服務(wù)如何相互訪問實(shí)現(xiàn)詳解
1 | 春天來了一個(gè)需求
1.1 | 現(xiàn)狀
- 不同工程團(tuán)隊(duì)有各自的 k8s 開發(fā)集群, 負(fù)責(zé)的服務(wù)部署在各自的集群上
- 但是這些服務(wù)之間存在調(diào)用關(guān)系(單項(xiàng)或者雙向的)
- 不同 k8s 集群之間內(nèi)網(wǎng)是聯(lián)通的
- 其中一個(gè)集群要作為流量入口,面向用戶
1.2 | 需求
- 實(shí)現(xiàn)服務(wù)跨集群訪問
- 服務(wù)之間只能通過內(nèi)網(wǎng)調(diào)用
- 統(tǒng)一的外部流量接入控制
2 | 方案有挺多的
跨集群訪問,應(yīng)該是一個(gè)比較普遍的需求,市面上有很多各種各樣的方案。比如:
- 跨集群的注冊(cè)發(fā)現(xiàn)服務(wù) 比如使用 nacos 作為跨集群的注冊(cè)發(fā)現(xiàn)中間件,所有在不同集群里的服務(wù)都注冊(cè)到 nacos 上,由 nacos 來進(jìn)行服務(wù)的注冊(cè)發(fā)現(xiàn)以及負(fù)載均衡。
- 配置集群內(nèi)網(wǎng)SLB 每一個(gè)集群各自配置一個(gè)自己的內(nèi)網(wǎng) SLB 地址,通過 ingress 的 path 配置不同的路由轉(zhuǎn)發(fā)。
- 使用ExternalName Service 在 請(qǐng)求發(fā)起方集群 配置 跨集群服務(wù) 在 本集群的 service,type 為 ExternalName 的headless service。
方案 | 優(yōu)點(diǎn) | 缺點(diǎn) |
---|---|---|
跨集群的注冊(cè)發(fā)現(xiàn)服務(wù) | 無需額外運(yùn)維要求 | 要求所有服務(wù)使用同一套注冊(cè)發(fā)現(xiàn)服務(wù),限制比較強(qiáng),且注冊(cè)發(fā)現(xiàn)服務(wù)不一定滿足不同技術(shù)棧的團(tuán)隊(duì),比如 nacos 就沒有官方支持的 go sdk |
配置集群內(nèi)網(wǎng)SLB | 對(duì)調(diào)用方友好,無需在調(diào)用方做額外運(yùn)維配置,只需要正常業(yè)務(wù)代碼內(nèi)調(diào)用即可 | 對(duì)集群運(yùn)維要求較高,需要有一定的運(yùn)維知識(shí),且如果沒有現(xiàn)成的 SLB 組件,還需要自建,成本較高 |
使用ExternalName Service | 適用范圍最廣,使用最靈活,可以在任何階段進(jìn)行配置改造,對(duì)跨集群服務(wù)支持的調(diào)用方式兼容性好(支持 ClusterIP, NodePort 以及域名調(diào)用) | 對(duì)本方集群運(yùn)維能力要求高 |
以上三種方案,都可以實(shí)現(xiàn)跨集群的服務(wù)調(diào)用。然而,方案三卻是目前最符合現(xiàn)狀且能推進(jìn)下去的。所以,下面就方案三展開來說。
3 | 展開來講講
方案三用到了 k8s 的 ExternalName Service(這里不展開講這是什么,感興趣可以點(diǎn)擊查看)。主要講怎么用。下面分幾個(gè)場(chǎng)景來講解:
3.1 | 場(chǎng)景 1
假設(shè):k8s2 集群有個(gè)服務(wù) s2, 對(duì)外以 Ingress 方式提供服務(wù),訪問地址是: abc.com 調(diào)用方集群創(chuàng)建一個(gè) service :
apiVersion: v1 kind: Service metadata: name: k8s2-s2 namespace: prod spec: type: ExternalName externalName: abc.com ports: - name: http port: 80 protocol: TCP targetPort: 80
那么, 在調(diào)用方集群內(nèi)的服務(wù),就可以通過本集群的服務(wù)名(k8s2-s2.prod.svc.cluster.local
)去訪問跨集群的服務(wù)。
3.2 | 場(chǎng)景 2
假設(shè):k8s3 集群有個(gè)服務(wù) s3, 對(duì)外以 NodePort 方式提供服務(wù),訪問地址是:192.168.0.199:30099 按照?qǐng)鼍?1 的配置生成一個(gè) service,可以用么?
apiVersion: v1 kind: Service metadata: name: k8s3-s3 namespace: prod spec: type: ExternalName externalName: 192.168.0.199 ports: - name: http port: 80 protocol: TCP targetPort: 30099
可以用,但是有問題。在 nginx 的日志里會(huì)瘋狂打印一個(gè)錯(cuò)誤:找不到 192.168.0.199 這個(gè)域名對(duì)應(yīng)的 ip。原因是,在集群看來, externalName 字段是一個(gè)域名,是需要做 dns 解析成 ip 的。如果我們直接填一個(gè) ip 的字段,雖然能用,但是會(huì)瘋狂輸出日志,沖掉正常 nginx 請(qǐng)求的日志。
那既然這樣,改成域名調(diào)用唄。那么問題來了,對(duì)方給我一個(gè) ip,我上哪去變一個(gè)域名呢?修改 hosts,準(zhǔn)確的說,修改 k8s coredns 服務(wù)的 hosts:
# kubectl -n kube-system edit cm coredns apiVersion: v1 data: Corefile: | .:53 { ... hosts { 192.168.0.199 s3.k8s3 fallthrough } ... } kind: ConfigMap metadata: name: coredns namespace: kube-system
然后修改 service
apiVersion: v1 kind: Service metadata: name: k8s3-s3 namespace: prod spec: type: ExternalName externalName: s3.k8s3 ports: - name: http port: 80 protocol: TCP targetPort: 30099
此時(shí),在調(diào)用方集群內(nèi)的服務(wù),就可以通過本集群的服務(wù)名(k8s3-s3.prod.svc.cluster.local
)去訪問跨集群的服務(wù)。
4 | 說點(diǎn)非技術(shù)的
- 技術(shù)上的最優(yōu)解,不一定是方案上的最優(yōu)解,要考慮人的因素
- 一個(gè)和尚挑水吃,兩個(gè)和尚抬水吃,三個(gè)和尚沒水吃
- 如果改變不了周圍,就勇敢改變自己
以上就是不同k8s集群間服務(wù)如何相互訪問實(shí)現(xiàn)詳解的詳細(xì)內(nèi)容,更多關(guān)于k8s 集群間服務(wù)相互訪問的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章!
相關(guān)文章
某集團(tuán)任意文件下載到虛擬主機(jī)getshell的方法
這篇文章主要介紹了某集團(tuán)任意文件下載到虛擬主機(jī)getshell的方法,非常不錯(cuò),具有參考借鑒價(jià)值,需要的朋友可以參考下2017-01-01k8s編排之DaemonSet知識(shí)點(diǎn)詳解
這篇文章主要為大家介紹了k8s編排之DaemonSet知識(shí)點(diǎn)詳解,有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進(jìn)步,早日升職加薪2023-01-01Podman開機(jī)自啟容器實(shí)現(xiàn)過程及與Docker對(duì)比
這篇文章主要為大家介紹了Podman開機(jī)自啟容器實(shí)現(xiàn)過程,通過示例代碼的形式進(jìn)行演繹過程,有需要的朋友可以參考下,希望可以有所幫助2021-09-09阿里云kubernetes查找鏡像中jar包的方法(docker查看鏡像中的jar)
這篇文章主要給大家介紹了關(guān)于阿里云kubernetes查找鏡像中jar包的方法,也就是在docker查看鏡像中的jar,文中通過圖文介紹的非常詳細(xì),需要的朋友可以參考下2022-09-09K8s實(shí)戰(zhàn)教程之容器和?Pods資源分配問題
這篇文章主要介紹了K8s實(shí)戰(zhàn)教程之容器和?Pods資源分配,本篇文章通過配置集群中運(yùn)行的容器的?CPU?請(qǐng)求和限制,你可以有效利用集群上可用的?CPU?資源,通過將?Pod?CPU?請(qǐng)求保持在較低水平,可以使?Pod?更有機(jī)會(huì)被調(diào)度,需要的朋友可以參考下2022-07-07