我們知道容器是通過 pod 來承載的，我們在 k8s 中，服務都是跑在 pod 里面的，pod 里面可以跑 1 個容器，或者跑多個容器，那么咱們 pod 里面跑 1 個服務容器，咱真的就以為里面就只有這樣個容器嗎？

pod 到底是個啥？

假如咱們 pod 里面只運行我們的一個服務的時候，也就是里面只運行一個容器，那么實際上里面是有幾個容器呢？

是有兩個的，默認會有一個基礎容器，提供 Linux 命名空間

• 一個我們自己的容器

• 一個附加容器

這個附加容器難道就只提供命名空間？

不不不，這個附加容器就干一件事，就是保存這個 pod 的所有容器的命名空間

畫一個簡圖來形象的說明一下：

最開始我們認為的是圖中的上半部分，那么實際上容器 A 共享的命名空間是保存在哪里的呢？就是保存在基礎容器里面的

哪怕我們現在再加一個容器 B，這個容器 B 也是共享這個基礎容器的 Linux 命名空間的

那么基礎容器的生命周期是多少呢？

上述有說到一個 pod 里面的所有容器都會共享這個基礎容器保存的命名空間

咱們自己加入的容器，做服務，可能會有掛的時候，也會有重啟的時候，放咱們的服務容器重啟啟動時，還是需要之前的 Linux 命名空間，這個時候，就可以找基礎容器獲取了

只要 pod 還活著，基礎容器就會一直陪著它， pod 不掛，基礎容器不消失

如果手動關閉了這個重要的基礎容器，那么節(jié)點里面的 關鍵角色之一 kubelet 就會監(jiān)控到異常信息，就會馬上重新建立一個基礎容器

pod 和 pod 之間通信會進行網絡地址轉換嗎？

首先說一下結論：

• pod 和 pod 之間通信，是沒有進行網絡地址轉換 NAT 的

• pod 和 node 之間通信，也沒有進行網絡地址轉換 NAT

就比如說在 節(jié)點 1 里面有一個 pod1，ip 是 1.1.1.1 ， 節(jié)點 2 里面有一個 pod 2， ip：1.1.1.2

當 pod 1 中的容器需要訪問 pod 2 的時候， 節(jié)點 1 出去的包，源 ip 是 pod 1 的 ip，目的 ip 是 pod 2 的 ip，同樣，到 pod ?2 收到包的時候也是這樣的，并沒有經過 NAT

pod 和 node 通信也是這樣的邏輯

我們知道 pod 容器實際上是運行在 worker 節(jié)點上的， 那么我們要訪問咱們運行在 worker 節(jié)點上的 pod ，但是咱們的主控節(jié)點是 master

這個時候，如果我們外面的網絡，需要訪問上面這個 pod 節(jié)點的容器，那么這個時候，外面的網絡需要訪問 master 的 ip 還是 worker 的 ip 呢？

需要訪問 worker 的 ip ，這是為什么呢？可以思考一下...

今天就到這里，學習所得，若有偏差，還請斧正

歡迎點贊，關注，收藏

朋友們，你的支持和鼓勵，是我堅持分享，提高質量的動力

好了，本次就到這里

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

我是小魔童哪吒，歡迎點贊關注收藏，下次見~