kubernetes網(wǎng)絡通訊模式
Kubernetes的網(wǎng)絡模型假定了所有Pod都在一個可以直接連通的扁平的網(wǎng)絡空間中，這在GCE(Google Compute Engine)里面是現(xiàn)成的網(wǎng)絡模型，Kubernetes假定這個網(wǎng)絡已經(jīng)存在。而在私有云里搭建Kubernetes集群，就不能假定這個網(wǎng)絡已經(jīng)存在了。我們需要自己實現(xiàn)這個網(wǎng)絡假設，將不同節(jié)點上的Docker容器之間的互相訪問先打通，然后運行Kubernetes。
同一個Pod內(nèi)的多個容器之間網(wǎng)絡互訪：基于Pause容器的網(wǎng)絡棧Lo(共享網(wǎng)卡)
各個Pod之間的網(wǎng)絡通信：Overlay Network
Pod與Service之間的通訊：各節(jié)點的IpTables規(guī)則（新版本中已經(jīng)加入了LVS機制，轉(zhuǎn)發(fā)效率將會更高，上限也更高）
網(wǎng)絡解決方案Flannel
Flannel是CoreOS團隊針對Kubernetes設計的一個網(wǎng)絡規(guī)劃服務，簡單來說，它的功能是讓集群中的不同節(jié)點主機創(chuàng)建的Docker容器都具有全集群唯一的虛擬IP地址。而且它還能在這些IP地址之間建立一個覆蓋網(wǎng)絡(Overlay Network)，通過這個覆蓋網(wǎng)絡，將數(shù)據(jù)包原封不動地傳遞到目標容器內(nèi)。
Flavnel和ETCD之間的關聯(lián)
- 存儲管理Flannel可分配的IP地址段資源
Flannel啟動以后會向ETCD里插入可以被分配的網(wǎng)段，并且把那些網(wǎng)段分配給那些機器了都記錄上，防止已經(jīng)分配的網(wǎng)段再次被Flannel利用分配給其他的Node節(jié)點 - 監(jiān)控ETCD中每個Pod的實際地址，并在內(nèi)存中建立維護Pod節(jié)點路由表
不同情況下網(wǎng)絡通信方式
同一個Pod內(nèi)部通訊：同一個Pod共享同一個網(wǎng)絡命名空間，共享同一個Linux協(xié)議棧
Pod1至Pod2
- Pod1與Pod2不在同一臺主機，Pod的地址是與docker0在同一個網(wǎng)段的，但docker0網(wǎng)段與宿主機網(wǎng)卡是兩個完全不同的IP網(wǎng)段，并且不同Node之間的通信只能通過宿主機的物理網(wǎng)卡進行。將Pod的IP和所在Node的IP關聯(lián)起來，通過這個關聯(lián)讓Pod可以互相訪問。
- Pod1與Pod2在同一臺機器，由docker0網(wǎng)橋直接轉(zhuǎn)發(fā)請求至Pod2，不需要經(jīng)過Flannel
Pod至Service的網(wǎng)絡：目前基于性能考慮，全部為iptables維護和轉(zhuǎn)發(fā)。最新版已經(jīng)完全可以由LVS進行轉(zhuǎn)發(fā)和維護。
Pod到外網(wǎng)：Pod向外網(wǎng)發(fā)送請求，查找路由表，轉(zhuǎn)發(fā)數(shù)據(jù)包到宿主機的網(wǎng)卡，宿主網(wǎng)卡完成路由選擇后，iptables執(zhí)行Masquerade，把源IP更改為宿主網(wǎng)卡的IP，然后向外網(wǎng)服務器發(fā)送請求。
外網(wǎng)訪問Pod：Service
在Kuberbetes中，只有Node網(wǎng)絡是真實存在的，Pod以及Service網(wǎng)絡都是虛擬網(wǎng)絡
