k8s自身原理service及實現(xiàn)圖文示例解析
引言
終于來到 k8s 自身的原理之 關(guān)于 Service 的一部分了
前面我們用 2 個簡圖展示了 pod 之間和 pod 與 node 之間是如何通信息的,且通信的數(shù)據(jù)包是不會經(jīng)過 NAT 網(wǎng)絡(luò)地址轉(zhuǎn)換的
那么 Service 又是如何實現(xiàn)呢?
Service 我們知道是用來對外暴露服務(wù)的 ip 和 端口的,好讓外部的客戶端可以訪問到我們內(nèi)部 pod 提供的服務(wù)
另外 Service 管理的 pod ,實際的 ip 和 端口 列表,都是存放在對應(yīng)的 endpoints 里面的
目前為止,我們也僅僅是停留在會使用 Service 了,那么 Service 自身的原理又是如何呢?我們一起來瞅瞅看
對于 Service 的服務(wù) ip 地址,也是一個虛擬的,同時也是對外暴露了 1 個或者多個端口,既然是虛擬的,咱們肯定是 ping 不通的,例如我的 minikube 環(huán)境

當然,我們看了之前的分享之后,發(fā)現(xiàn) k8s 中對于資源的變動,基本上都是使用的監(jiān)聽機制,那么對于 Service 的行為 和 endpoints 的行為,是不是同樣是被不同的關(guān)鍵組件所監(jiān)聽呢?
我們可以用一個簡圖來了解一下:

圖中,我們可以看到
- 一個 Service 管控的是 2 個 pod,具體的 ip 和 端口 列表 都是存放在 endpoints 中
- kube-proxy 會監(jiān)控 ApiServer 中 Endpoints 對象的變化,若 endpoints 這中 list 有變化,kube-proxy 監(jiān)聽到之后,就會通知 iptables 去配置新的規(guī)則
- 例如環(huán)境中的 一個 pod 3 發(fā)請求給到咱們這個 Service,發(fā)出來的 目的地址是 Service 的地址和端口
- 但是通過 iptables 設(shè)定的規(guī)則進行轉(zhuǎn)換,目的地址和端口就變成了 Service 管控的 pod 自己的 ip 和端口了
就看這個流程,好像也不復(fù)雜嘛,那么實際生產(chǎn)環(huán)境中也會是這樣的嗎?我們可以思考一下,更多關(guān)于k8s service實現(xiàn)原理的資料請關(guān)注腳本之家其它相關(guān)文章!
相關(guān)文章
Kubernetes中根據(jù)Pod IP查找Pod及關(guān)聯(lián)服務(wù)的實現(xiàn)方式
文章介紹Kubernetes中通過Endpoints、Service選擇器、網(wǎng)絡(luò)策略及節(jié)點IPVS/iptables等方法快速定位Pod與關(guān)聯(lián)Service的技巧,推薦優(yōu)先使用Endpoints并結(jié)合標簽匹配,適用于調(diào)試和運維場景2025-10-10
K8S?實用工具之合并多個kubeconfig實現(xiàn)詳解
這篇文章主要為大家介紹了K8S?實用工具之合并多個kubeconfig實現(xiàn)詳解,有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進步,早日升職加薪2023-03-03
Kubernetes(k8s?1.23))安裝與卸載詳細教程
這篇文章主要介紹了Kubernetes(k8s?1.23))安裝與卸載,本文給大家介紹的非常詳細,對大家的學習或工作具有一定的參考借鑒價值,需要的朋友可以參考下2022-07-07

