k8s 自身原理 5
我們知道容器是通過(guò) pod 來(lái)承載的,我們?cè)?k8s 中,服務(wù)都是跑在 pod 里面的,pod 里面可以跑 1 個(gè)容器,或者跑多個(gè)容器,那么咱們 pod 里面跑 1 個(gè)服務(wù)容器,咱真的就以為里面就只有這樣個(gè)容器嗎?
pod 到底是個(gè)啥?
假如咱們 pod 里面只運(yùn)行我們的一個(gè)服務(wù)的時(shí)候,也就是里面只運(yùn)行一個(gè)容器,那么實(shí)際上里面是有幾個(gè)容器呢?
是有兩個(gè)的,默認(rèn)會(huì)有一個(gè)基礎(chǔ)容器,提供 Linux 命名空間
一個(gè)我們自己的容器
一個(gè)附加容器
這個(gè)附加容器難道就只提供命名空間?
不不不,這個(gè)附加容器就干一件事,就是保存這個(gè) pod 的所有容器的命名空間
畫(huà)一個(gè)簡(jiǎn)圖來(lái)形象的說(shuō)明一下:
最開(kāi)始我們認(rèn)為的是圖中的上半部分,那么實(shí)際上容器 A 共享的命名空間是保存在哪里的呢?就是保存在基礎(chǔ)容器里面的
哪怕我們現(xiàn)在再加一個(gè)容器 B,這個(gè)容器 B 也是共享這個(gè)基礎(chǔ)容器的 Linux 命名空間的
那么基礎(chǔ)容器的生命周期是多少呢?
上述有說(shuō)到一個(gè) pod 里面的所有容器都會(huì)共享這個(gè)基礎(chǔ)容器保存的命名空間
咱們自己加入的容器,做服務(wù),可能會(huì)有掛的時(shí)候,也會(huì)有重啟的時(shí)候,放咱們的服務(wù)容器重啟啟動(dòng)時(shí),還是需要之前的 Linux 命名空間,這個(gè)時(shí)候,就可以找基礎(chǔ)容器獲取了
只要 pod 還活著,基礎(chǔ)容器就會(huì)一直陪著它, pod 不掛,基礎(chǔ)容器不消失
如果手動(dòng)關(guān)閉了這個(gè)重要的基礎(chǔ)容器,那么節(jié)點(diǎn)里面的 關(guān)鍵角色之一 kubelet 就會(huì)監(jiān)控到異常信息,就會(huì)馬上重新建立一個(gè)基礎(chǔ)容器
pod 和 pod 之間通信會(huì)進(jìn)行網(wǎng)絡(luò)地址轉(zhuǎn)換嗎?
首先說(shuō)一下結(jié)論:
pod 和 pod 之間通信,是沒(méi)有進(jìn)行網(wǎng)絡(luò)地址轉(zhuǎn)換 NAT 的
pod 和 node 之間通信,也沒(méi)有進(jìn)行網(wǎng)絡(luò)地址轉(zhuǎn)換 NAT
就比如說(shuō)在 節(jié)點(diǎn) 1 里面有一個(gè) pod1,ip 是 1.1.1.1 , 節(jié)點(diǎn) 2 里面有一個(gè) pod 2, ip:1.1.1.2
當(dāng) pod 1 中的容器需要訪(fǎng)問(wèn) pod 2 的時(shí)候, 節(jié)點(diǎn) 1 出去的包,源 ip 是 pod 1 的 ip,目的 ip 是 pod 2 的 ip,同樣,到 pod ?2 收到包的時(shí)候也是這樣的,并沒(méi)有經(jīng)過(guò) NAT
pod 和 node 通信也是這樣的邏輯
我們知道 pod 容器實(shí)際上是運(yùn)行在 worker 節(jié)點(diǎn)上的, 那么我們要訪(fǎng)問(wèn)咱們運(yùn)行在 worker 節(jié)點(diǎn)上的 pod ,但是咱們的主控節(jié)點(diǎn)是 master
這個(gè)時(shí)候,如果我們外面的網(wǎng)絡(luò),需要訪(fǎng)問(wèn)上面這個(gè) pod 節(jié)點(diǎn)的容器,那么這個(gè)時(shí)候,外面的網(wǎng)絡(luò)需要訪(fǎng)問(wèn) master 的 ip 還是 worker 的 ip 呢?
需要訪(fǎng)問(wèn) worker 的 ip ,這是為什么呢?可以思考一下...
今天就到這里,學(xué)習(xí)所得,若有偏差,還請(qǐng)斧正
歡迎點(diǎn)贊,關(guān)注,收藏
朋友們,你的支持和鼓勵(lì),是我堅(jiān)持分享,提高質(zhì)量的動(dòng)力

好了,本次就到這里
技術(shù)是開(kāi)放的,我們的心態(tài),更應(yīng)是開(kāi)放的。擁抱變化,向陽(yáng)而生,努力向前行。
我是小魔童哪吒,歡迎點(diǎn)贊關(guān)注收藏,下次見(jiàn)~