Kubernetes CKA課程筆記 21
前一篇介紹了在Pod內的網路溝通問題
接著要來介紹Pod ← 與→Pod 之間如何溝通
Pod to Pod communication:
- 首先其實並無內置的solution
- 並且預期要有實作的solution引入
- 但是Kubernetes有提供必要Pod to Pod網路溝通的規則
- 並且solution pluggable都必要遵守那些定義與規則
- 這些規格就稱為Container Network Interface(CNI)
- 其腳色就類似Container Runtime Interface
CNI(Container Network Interface)要求3條規則:
- 在整個Cluster中的每一個Pod都擁有唯一的IP位置
- 在相同Node中的Pods之間溝通可以直接透過各自的IP位置
- 在不同Node中的Pods之間溝通可以直接透過各自的IP位置,並且不用NAT(Network Address Translation)
- 也就是Kubernetes預期引入的CNI solution可以實作整個Cluster所有Nodes的Pods網路
- 並且K8s不在乎取得的IP的範圍或說不在乎Pod拿到的IP位置,這些全權交由引入的CNI solution(Plugin)決定
而上述這些Pod的網路該長甚麼樣定義在The Kubernetes network model:
常見的實作CNI的solution Network Plugins:
上述這些Plugin如何實作CNI並滿足前面Kubernetes開出的三大條件?
這就要考量是同個Node或不同Node的Pods間的溝通
在相同Node中的Pods之間溝通可以直接透過各自的IP位置:
- 這個首先要從Node講起
- 接著考慮到Pod建立,Pod會分布長在各個Node上
- 在Node裡面又會建立一個獨立的私人網路,這個私人網路則是由CNI的Plugin提供,並且使用不同範圍的IP(不同於VPC提供給Node的IP範圍,也就是不重複)
- 所以Node上實作CNI的Plugin提供給Pod不同IP範圍(不同於VPC給Node的範圍)就是下圖的BRIDGE
如果實作CNI的Plugin的BRIDGE提供出來給NODE內部的Pods使用的IP範圍
與VPC提供給NODE的IP範圍有重複的話
那麼Pods間的溝通將無法正常作用
(想想道理很簡單,如果VPC內又有一台Linux機
卻跟某個NODE機台上的Pod IP位置一致
那也就是地址門牌有重複,一定會有問題)
- 而在不同Node間怎麼知道要發給Pod的IP不是隔壁Node已經用掉了?
- 仔細看是因為BRIDGE給的範圍是獨立不同的
- 所以IP範圍的發配全權由CNI Plugin決定,通常方式如下
在不同Node中的Pods之間溝通可以直接透過各自的IP位置,並且不用NAT:
- 考慮如下情況
- 跨Node的Pods間溝通其實是透過Gateways
- Gateways其上有定義Route table對應每個Node的IP位置
- 所以Gateways=各個Node的IP位置
Route rule比對知道哪一個Node:
最終:
- 換言之這些Network Plugin建立一個巨大的Pod網路
- 為何可以跨如圖整整3個Nodes做請求?
- 因為這三個Nodes根本就是同一個網路!
- Node跟Node之間本來就是同個網路(VPC內),所以可以溝通
- 並且Node本身(如172.31.1.10)可以進到裡面Pod裡面的網路(10.32.1.10)
更有擴展性的solution →Node上的Agents:
- 考量到如果有一天我們有上千個Node
- 亦即Route Rule也會有上千條要比對就會比較難
- 所以需要更自動更有擴展性的Solution
- 例如weave net的是直接佈署在每一個Node成為一個Pod
- 不同Node間的weave net的Pod會找到彼此形成group
- 並且直接互相溝通分享哪個Pod現在活在哪個Node等資訊
- 所以當有請求由某個Pod發動時
- 當地Node的weave net直接詢問其他Node上的weave net目標在誰那邊
- 然後直接拋過去
- 以上方式更加快速,之後會安裝如下的Weave Work的Weave Net
- Weave Net非常容易安裝
- 並且其Agents運作為DaemonSet
後面就要安裝Weave Net Plugin!
