一 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可以互相訪問。
對於Kubernetes而言，采用了網絡增強開源軟件Flannel進行IP資源池的管理和分配。
同時采用相應的機制，實現Pod中的數據在發出時，能獲知對方Pod的IP地址位於某個具體的Node上。也就是說先要找到Node對應宿主機的IP地址，將數據發送到這個宿主機的網卡，然后在宿主機上將相應的數據轉發到具體的docker0上。一旦數據到達宿主機Node，則那個Node內部的docker0便知道如何將數據發送到Pod。
由上圖可知，IP1對應的是Pod1，IP2對應的是Pod2。Pod1在訪問Pod2時，首先要將數據從源Node的eth0發送出去，找到並到達Node2的eth0。即先是從IP3到IP4的遞送，之后才是從IP4到IP2的遞送。