一 Kubernetes網路實現 1.1 Kubernetes網路優勢 在實際的業務場景中，業務組件之間的關係十分複雜，微服務的理念更是讓應用部署的粒度更加細小和靈活。為了支持業務應用組件的通信，Kubernetes網路的設計主要致力於解決以下問題。 容器到容器之間的直接通信。 抽象的Pod到Pod ...
一 Kubernetes網路實現
1.1 Kubernetes網路優勢
在實際的業務場景中，業務組件之間的關係十分複雜，微服務的理念更是讓應用部署的粒度更加細小和靈活。為了支持業務應用組件的通信，Kubernetes網路的設計主要致力於解決以下問題。- 容器到容器之間的直接通信。
- 抽象的Pod到Pod之間的通信。
- Pod到Service之間的通信。
- 集群外部與內部組件之間的通信。
二 Kubernetes網路通信
2.1 容器之間通信
同一個Pod內的容器（Pod內的容器是不會跨宿主機的）共用同一個網路命名空間，共用同一個Linux協議棧。所以對於網路的各類操作，就和它們在同一臺機器上一樣，它們甚至可以用localhost地址訪問彼此的埠。這種方式簡單、安全和高效，也能減小將已經存在的程式從物理機或者虛擬機移植到容器下運行的難度。 在Kubernetes使用如下方式利用Docker的網路模型：
如上圖所示，在Node1上運行著一個Pod實例，且運行著容器1和容器2。容器1和容器2共用一個網路的命名空間，共用一個命名空間的結果就是它們好像在一臺機器上運行，它們打開的埠不會有衝突，可以直接使用Linux的本地IPC進行通信（例如消息隊列或者管道）。其實，這和傳統的一組普通程式運行的環境是完全一樣的，傳統程式不需要針對網路做特別的修改就可以移植了，它們之間的互相訪問只需要使用localhost就可以。例如，如果容器2運行的是MySQL，那麼容器1使用localhost:3306就能直接訪問這個運行在容器2上的MySQL了。
2.2 Pod之間的通信
每一個Pod都有一個真實的全局IP地址，同一個Node內的不同Pod之間可以直接採用對方Pod的IP地址通信，而且不需要採用其他發現機制，例如DNS、Consul或者etcd。Pod容器既有可能在同一個Node上運行，也有可能在不同的Node上運行，所以通信也分為兩類：同一個Node內Pod之間的通信和不同Node上Pod之間的通信。- 同一個Node內Pod之間的通信
由上圖可知，Pod1和Pod2都是通過Veth連接到同一個docker0網橋上的，它們的IP地址IP1、IP2都是從docker0的網段上動態獲取的，它們和網橋本身的IP3是同一個網段的。另外，在Pod1、Pod2的Linux協議棧上，預設路由都是docker0的地址，也就是說所有非本地地址的網路數據，都會被預設發送到docker0網橋上，由docker0網橋直接中轉。綜上所述，由於它們都關聯在同一個docker0網橋上，地址段相同，所以它們之間是能直接通信的。
- 不同Node上Pod之間的通信
Pod的地址是與docker0在同一個網段的，我們知道docker0網段與宿主機網卡是兩個完全不同的IP網段，並且不同Node之間的通信只能通過宿主機的物理網卡進行，因此要想實現不同Node上Pod容器之間的通信，就必須實現能通過主機的這個IP地址進行定址和通信。
同時，這些動態分配且位於docker0之後的容器(Pod)“私有”IP地址也需要進行定址。Kubernetes會記錄所有正在運行的Pod的IP分配信息，並將這些信息保存在etcd中（作為Service的Endpoint）。
這些私有IP信息對於Pod到Pod的通信也是十分重要的，Kubernetes的網路模型要求Pod到Pod使用私有IP進行通信。所以首先獲知這些IP是什麼。由於Kubernetes的網路對Pod的地址是平面的和直達的，所以這些Pod的IP規劃也很重要，若需要在整個集群中進行定址，必須保證IP不能有衝突。
綜上所述，要想支持不同Node上Pod之間的通信，就要滿足兩個條件：
- 在整個Kubernetes集群中對Pod的IP分配進行規劃，不能有衝突；
- 需要一種方案，將Pod的IP和所在Node的IP關聯起來，通過這個關聯讓Pod可以互相訪問。
