關(guān)于Kubernetes的網(wǎng)絡(luò)模型，需要具備一些二三層網(wǎng)絡(luò)交換的基本知識(shí)。比如mac地址，ip地址，arp表，路由表等。那kubernetes內(nèi)部容器間的網(wǎng)絡(luò)通信也離不開這些基本的原理，只不過這個(gè)時(shí)候的個(gè)體不再是物理機(jī)實(shí)體，而是一個(gè)個(gè)的容器(container)，在邏輯層可以說是pod間通信，本質(zhì)上是不通namespace間的網(wǎng)絡(luò)通信。
kubernetes在發(fā)展的過程中，網(wǎng)絡(luò)功能一直都是由coreOS參與，其中Flannel就是CoreOS的網(wǎng)絡(luò)解決方案，在15年的時(shí)候，社區(qū)才有Calico和Weave冒出來，可以說基本解決了網(wǎng)絡(luò)問題。所以Kubernetes官方就沒有自己親歷親為去做這個(gè)事情，畢竟kubernetes是google的開源項(xiàng)目，如果什么都靠自己去做，也會(huì)消耗自己更多的成本。這個(gè)時(shí)候kubernetes推出了CNI，來做網(wǎng)絡(luò)插件的標(biāo)準(zhǔn)化?？赡苓@樣也更符合開源產(chǎn)品的發(fā)展模式。
所以有了以上背景，我們學(xué)習(xí)k8s的網(wǎng)絡(luò)模式，有2個(gè)CNI組件是繞不過的，一個(gè)是Flannel，一個(gè)就是Calico。
namespace間網(wǎng)絡(luò)通信，需要解決幾個(gè)場(chǎng)景的通信問題：
- 同一個(gè)宿主機(jī)下的不同namespace通信；
- 跨宿主機(jī)的不通namespace通信問題。
首先來看Flannel的通信模式，按照時(shí)間線（timeline）來分，經(jīng)歷了如下過程：
1、Flannel UDP; 這種模式提供了一個(gè)三層的Overlay網(wǎng)絡(luò)，對(duì)發(fā)出端的IP包進(jìn)行UDP封裝（Encapsulation
），通過查找本地的路由表進(jìn)行轉(zhuǎn)發(fā)，然后接收端開始解包（Decapsulation）.
該模式的缺點(diǎn)：用戶態(tài)內(nèi)核態(tài)切換過于頻繁，導(dǎo)致性能低下。
2、VXLAN；
該模式下，所有出去的數(shù)據(jù)包都必須經(jīng)過flannel.1 這個(gè)VTEP設(shè)備，數(shù)據(jù)包的內(nèi)部封裝目的VTEP設(shè)備的mac 地址 和 目的容器的IP地址，依賴flannel.1 虛擬設(shè)備（每個(gè)node節(jié)點(diǎn)都有），經(jīng)歷container--->docker0--->flannel.1--->eth0
以上2種模式下，容器都是連接在docker0網(wǎng)橋上，而網(wǎng)絡(luò)插件（CNI）都是在宿主機(jī)上創(chuàng)建一個(gè)特殊的設(shè)備（UDP模式下創(chuàng)建的是TUN設(shè)備，VXLAN模式創(chuàng)建的是VTEP設(shè)備），docker0和這個(gè)設(shè)備之間，通過IP轉(zhuǎn)發(fā)進(jìn)行寫作。
3、host-gw; --->Pure Layer3
host-gw模式是一個(gè)純?nèi)龑拥木W(wǎng)絡(luò)解決方案，它的工作原理，就是講每個(gè)Flannel子網(wǎng)（Flannel Subnet）的下一條設(shè)置成該子網(wǎng)對(duì)應(yīng)的宿主機(jī)的IP地址，宿主機(jī)充當(dāng)一個(gè)“網(wǎng)關(guān)”的角色。
這個(gè)時(shí)候就有路由的概念了，屬于三層的內(nèi)容，不過Flannel子網(wǎng)和主機(jī)的信息都保存在etcd中，flanneld只需要watch 數(shù)據(jù)的變化，就可以完成實(shí)時(shí)更新路由表。下圖是host-gw模式下的數(shù)據(jù)流向，
以上內(nèi)容對(duì)kubernetes Flannel網(wǎng)絡(luò)模型做了個(gè)簡(jiǎn)要的介紹，就當(dāng)是對(duì)kubernetes的網(wǎng)絡(luò)有了個(gè)基本的認(rèn)識(shí)。
