Kubernets的網絡模型假定了所有Pod都在一個可以直接連同的扁平網絡空間中（所有Pod都可通過對方IP直接到達）。

同一個Pod內部通訊

同一個Pod共享Pause基礎容器的Linux協議棧，他們直接互相訪問就是走的這個網絡棧的IO,通過localhost（回環網卡）的方式能直接訪問。

Pod1至Pod2-各Pod之間的通訊

Pod1與Pod2在同一臺機器

由Docker0網橋直接轉發請求至Pod2,(因為大家都是在同一個網橋下面不同的子網)不需要經過Flannel-【也就是在真實服務器的主機內核已經完成了數據包的轉換】

Pod1與Pod2不在同一臺機器（跨主機通過對方的IP到達）

Pod的地址與docker0實在同一個網段的，但是docker0網段與宿主機網卡是兩個完全不同的IP網段,并且不同Node之間的通信只能通過宿主機的物理網卡進行。將Pod的IP和所在Node的IP關聯起來，通過這個關聯讓Pod可以互相訪問。
（在真實的Node服務器上會安裝Flanneld的守護進程，這個進程會監聽一個端口，這個端口就是用于后期轉發數據包以及接入數據包的服務端口，Flanneld進程啟動后會開啟一個網橋叫Flannel0，Flannel0專門收集Docker0轉發出來的數據包，可以理解為鉤子函數強行獲取數據報文。Docker0會分配自己的IP到對應的Pod上。）

例子：假設Web app2想把數據包轉發到Backend,它的數據包先寫入10.1.15.2/24，因為目標的網段和自己不是同一個網段，所以它先發到自己的網關Docker0，Docker0上會有鉤子函數把數據包抓到Flanne0,Flanneld還會從etcd拿路由表記錄判斷路由到哪個機器，因為Flannel0是Flanneld的網橋，數據包會到Flanneld,它會對數據報文進行封裝【mac-到三層-到udp數據報文-到新的三層信息-到數據包實體Payload】，因為三層寫了到192.168.66.12所以數據包到達192.168.66.12Node節點，并且數據包到達目標Flanneld的端口被Flanneld截獲，截獲后Flanneld拆封，拆封完轉發Flannel0,Flannel0轉發到Dokcer0,Docker0看到新三層的目標地址信息10.1.20.3把10.1.15.2數據包。轉發到Backend端

Flannel和ETCD的關聯:1存儲管理Flannel可分配的IP地址段資源（Flannel啟動后會向ETCD插入可以被分配的網段，并且把哪個網段分配到哪個機器也記錄上，防止已分配的網段再被Flannel利用分配給其他Node節點）2Flannel監控ETCD中每個Pod的實際地址，并在內存中建立維護Pod節點路由表（因為封裝最上層的三層信息的時候需要對方主機的地址信息）

Pod至Service直接的通信

基于各節點的Iptables規則進行維護和轉發，最新版本加入了LVS機制進行維護和轉發（轉發的效率和上限會更高）

Pod到外網

Pod向外網發送請求，查找路由表，轉發數據包到宿主機網卡，宿主機網卡完成路由選擇后，iptables執行Masquerade（SNAT動態轉換去完成上網行為）,把源IP更改為宿主網卡的IP,然后向外網服務器發送請求

外網訪問Pod

Service的NodePort方式

谷歌沒有對Kubernetes做很強的定義，允許通過CNI接口來達到自己想要的網絡方案。Flannel是符合CNI接口的最常用的解決扁平化網絡的方案。Flannel是CoreOS團隊針對Kubernets設計的網絡規劃服務，它的功能是讓集群中的不同節點主機創建的Docker容器具有全集群唯一的虛擬IP地址。而且它還能在這些IP地址之間建立一個覆蓋網絡（Overlay Network），通過這個覆蓋網絡，將數據包原封不動地傳遞到目標容器內。
不同容器之間IP一定不能一樣（可以修改docker啟動的配置文件，把docker0網橋的分配網段修改掉，只要docker0分配的網段不一樣，容器的IP肯定能夠不一樣）。

Kubernetes的三層網絡：
節點網絡（真實的物理網絡）、Pod網絡（虛擬網絡）、Service網絡（虛擬網絡）