好不容易，終于來到 k8s 自身的原理之 關(guān)于 Service 的一部分了

前面我們用 2 個(gè)簡(jiǎn)圖展示了 pod 之間和 pod 與 node 之間是如何通信息的，且通信的數(shù)據(jù)包是不會(huì)經(jīng)過 NAT 網(wǎng)絡(luò)地址轉(zhuǎn)換的

那么 Service 又是如何實(shí)現(xiàn)呢？

Service 我們知道是用來對(duì)外暴露服務(wù)的 ip 和 端口的，好讓外部的客戶端可以訪問到我們內(nèi)部 pod 提供的服務(wù)

另外 Service 管理的 pod ，實(shí)際的 ip 和 端口 列表，都是存放在對(duì)應(yīng)的 endpoints 里面的

目前為止，我們也僅僅是停留在會(huì)使用 Service 了，那么 Service 自身的原理又是如何呢？我們一起來瞅瞅看

對(duì)于 Service 的服務(wù) ip 地址，也是一個(gè)虛擬的，同時(shí)也是對(duì)外暴露了 1 個(gè)或者多個(gè)端口，既然是虛擬的，咱們肯定是 ping 不通的，例如我的 minikube 環(huán)境

當(dāng)然，我們看了之前的分享之后，發(fā)現(xiàn) k8s 中對(duì)于資源的變動(dòng)，基本上都是使用的監(jiān)聽機(jī)制，那么對(duì)于 Service 的行為 和 endpoints 的行為，是不是同樣是被不同的關(guān)鍵組件所監(jiān)聽呢？

我們可以用一個(gè)簡(jiǎn)圖來了解一下：

圖中，我們可以看到

• 一個(gè) Service 管控的是 2 個(gè) pod，具體的 ip 和 端口 列表 都是存放在 endpoints 中

• kube-proxy 會(huì)監(jiān)控 ApiServer 中 Endpoints 對(duì)象的變化，若 endpoints 這中 list 有變化，kube-proxy 監(jiān)聽到之后，就會(huì)通知 iptables 去配置新的規(guī)則

• 例如環(huán)境中的 一個(gè) pod 3 發(fā)請(qǐng)求給到咱們這個(gè) Service，發(fā)出來的 目的地址是 Service 的地址和端口

• 但是通過 iptables 設(shè)定的規(guī)則進(jìn)行轉(zhuǎn)換，目的地址和端口就變成了 Service 管控的 pod 自己的 ip 和端口了

就看這個(gè)流程，好像也不復(fù)雜嘛，那么實(shí)際生產(chǎn)環(huán)境中也會(huì)是這樣的嗎？我們可以思考一下

今天就到這里，學(xué)習(xí)所得，若有偏差，還請(qǐng)斧正

歡迎點(diǎn)贊，關(guān)注，收藏

朋友們，你的支持和鼓勵(lì)，是我堅(jiān)持分享，提高質(zhì)量的動(dòng)力

好了，本次就到這里

技術(shù)是開放的，我們的心態(tài)，更應(yīng)是開放的。擁抱變化，向陽而生，努力向前行。

我是阿兵云原生，歡迎點(diǎn)贊關(guān)注收藏，下次見~