5分鐘讓你理解K8S必備架構概念，以及網絡模型（下）

寫在前面

在這用XMind畫了一張導圖記錄Redis的學習筆記和一些面試解析（源文件對部分節點有詳細備註和參考資料，歡迎關注個人公衆號：阿風的架構筆記 後臺發送【導圖】拿下載連接， 已經完善更新）：

前言

前兩篇介紹了K8S的核心的概念，以及各自起到的做用，小夥伴們必定須要瞭解哦。今天來分享一下K8S核心的網絡模型，這一塊也是比較複雜的，但也是很是重要的。咱們從最基本的點慢慢梳理。

Node網絡

這個是最基礎的網絡，就是每一個機器Node節點之間網絡通訊，也會整個K8S的基礎網絡，這個運維工程師會保證每一個機器Node網絡的互通。

上面的WorkNode虛機節點，經過IP+Port便可以實現網絡互通，相似搭建了一個內部局域網環境。

Pod網絡

K8S最小單位是Pod，每一個WorkNode節點中會存在多個Pod，以及一個Pod會有多個容器，那他們的網絡通信模型是什麼呢？

咱們只須要保證各個Pod之間，都是可以互通的。以下圖

咱們先來看看在同一個Pod之間不一樣容器的互通原理。

同一個Pod不一樣容器之間的網絡互通

上圖中有eth0、docker0、veth0三種網絡設備：

• eth0：是表明node節點的網絡設備， 便是node之間的互通是經過此設備。
• docker0：虛擬網橋，能夠理解爲虛擬交換機。 此設備是用在同一個node中的不一樣pod之間互相通信的。
• veth0：是Pod內部的虛擬網卡。 它是Pod內不一樣容器之間互聯的網絡設備，它的IP地址是由docker0分配的。
• 在k8s中每一個Pod中管理着一組Docker容器， 這些Docker容器會共享同一個網絡命名空間
• Pod中的每一個Docker容器擁有與Pod相同的IP和port地址空間，而且因爲他們在同一個網絡命名空間，他們之間能夠經過localhost相互訪問。 什麼機制讓同一個Pod內的多個docker容器相互通訊那？實際上是使用Docker的一種網絡模型：–net=container

container模式指定新建立的Docker容器和已經存在的一個容器共享一個網絡命名空間，而不是和宿主機共享。新建立的Docker容器不會建立本身的網卡，配置本身的 IP，而是和一個指定的容器共享 IP、端口範圍等。

每一個Pod容器中有一個系統提供的pause容器有獨立的網絡命名空間，在Pod內啓動Docker容器時候使用 –net=container就可讓當前Docker容器加入到Pod容器擁有的網絡命名空間 （pause容器）。

因此咱們可以看到每一個Pod中的pause容器是很重要的哦。

同一個Node節點不一樣Pod之間網絡互通

上圖就是同一個node啓動多個Pod時，docker0又會給Pod2分配ip地址，由於Pod的IP都是由docker0分配的，docker0承擔着虛擬網橋的做用，則同一個node的不一樣Pod之間的通信便是經過docker0實現的。

比較細心的小夥伴們會發現，pod的ip地址空間是172.17.0.0/24；而node節點的ip地址空間是在10.100.0.0/24。

那麼不一樣node節點之間的pod是如何互通的呢？

不一樣node之間的pod網絡互通

上圖闡述了不一樣的Node節點之間的Pod是互通需求，Node節點IP地址空間爲10.100.0.0/24；Pod的IP地址是在172.17.0.0/16；pod的ip地址在整個K8S集羣是惟一的，這個是由K8S保證的。 Node節點網絡和Pod網絡不在同一個網絡空間，那2個Pod是如何互通的呢？

這個底層實現比較複雜，小夥伴們能夠理解爲是經過覆蓋網絡方式實現，即pod1給pod2時，先把數據包封裝爲所在node節點的網絡數據包，而後到目標Node以後再解數據包，再到目標Pod。整個流程須要知道哪一個Pod在哪一個Node映射關係。

簡單一點理解：Pod1與Pod2不在同一臺主機，Pod的地址是與docker0在同一個網段的，但docker0網段與宿主機Node網卡是兩個徹底不一樣的ip網段，而且不一樣Node之間的通信只能經過宿主機的物理網卡進行。

將Pod的ip和所在Node的ip關聯起來，經過這個關聯可讓Pod互相訪問。

Service的ClusterIP網絡模型

在咱們以前文章介紹了一個服務是能夠存在多個pod的，那麼另外一個服務請求此服務時，究竟是請求到其中哪個pod的呢？看下圖

咱們看到User服務啓動了3個Pod，都有獨立的PodIP；那咱們黃色的pod怎麼發現User服務的Pod呢？若是重啓了User服務的Pod，ip會有變更怎麼辦？增長或減小Pod又怎麼辦？

K8S提供了ClusterIP網絡模型解決了服務發現，黃色Pod不須要知道User服務到底有多少Pod以及Pod的Ip變化；黃色Pod訪問User服務是經過User Service的ClusterIP進行的，ClusterIP會感知後端User服務的Pod變化。

ClusterIP也起到了負載均衡的做用，默認爲隨機算法。

註冊發現

那ClusterIP的服務發現原理是什麼呢？

看上圖的服務註冊以及發現，很是相似微服務的註冊中心的服務註冊/發現。在Pod實例化後會經過kubelet註冊到K8S Master節點上面。註冊的信息就是ServiceName和ClusterIP關係、ClusterIP和PodIP的關係。

kube-proxy和kube-dns會監聽K8S Master上面的信息。kube-dns目的就是解析ServiceName到哪一個ClusterIP。

消費者Pod訪問某個ServiceName時，則經過註冊信息找到對應的ClusterIP、而後再找到PodIP。

ClusterIP的訪問核心是系統的Iptables、ipvs進行截獲請求

外部流量接入

上面介紹了K8S內部，pod訪問不一樣pod的方式，是經過ClusterIP方式的Service。

那外部網絡如何鏈接K8S集羣內部的Pod呢？上一篇文章中已經介紹了一種NodePort方式的Service。

定義了NodePort的Service，會在全部的Node節點上面建立這個NodePort，提供給外部訪問。多個Node節點上面都有一個NodePort；那怎麼實現負載均衡訪問呢？

這個時候會要延伸出LoadBalancer這個組件了，通常作生產雲端部署的時候會用到；須要一些費用的哦。開發測試環境只須要NodePort訪問就好了

這個外部請求時，會經過Load Balancer選擇一個Node節點上的NodePort進行訪問。

Ingress

上面的NodePort和LoadBalancer針對的是某一個Service；可是咱們業務中會有不少個這樣的Service，若是每一個Service都要去申請一個LoadBalancer，那麼費用就過高了。

那能不能只要購買一個LoadBalancer就能夠支持不少個Service呢？這個就是用到Ingress組件了。

上圖中就能看出來，Ingress本質就是7層反向代理，作了個路由轉發，相似網關路由轉發；把不一樣的path轉發到不一樣的Service。

實現Ingress的方式有不少，如：Nginx/Kong/Envoy/Zuul/SpringCloudGateway等

總結

K8S中的網絡模型比較多，咱們來看個對比圖，方便小夥伴們記憶理解。

看完三件事❤️

​ 若是你以爲這篇內容對你還蠻有幫助，我想邀請你幫我三個小忙： ​

1. 點贊，轉發，有大家的 『點贊和評論』，纔是我創造的動力。
2. 關注公衆號 『 阿風的架構筆記 』，不按期分享原創知識。
3. 同時能夠期待後續文章ing🚀
4. 關注後回覆【666】掃碼便可獲取架構進階學習資料包