一、Docker網絡模式
在討論Kubernetes網絡之前，讓我們先來看一下Docker網絡。Docker採用插件化的網絡模式，默認提供bridge、host、none、overlay、maclan和Network plugins這幾種網絡模式，運行容器時可以通過–network參數設置具體使用那一種模式。
- bridge：這是Docker默認的網絡驅動，此模式會爲每一個容器分配Network Namespace和設置IP等，並將容器連接到一個虛擬網橋上。如果未指定網絡驅動，這默認使用此驅動。
- host：此網絡驅動直接使用宿主機的網絡。
- none：此驅動不構造網絡環境。採用了none 網絡驅動，那麼就只能使用loopback網絡設備，容器只能使用127.0.0.1的本機網絡。
- overlay：此網絡驅動可以使多個Docker daemons連接在一起，並能夠使用swarm服務之間進行通訊。也可以使用overlay網絡進行swarm服務和容器之間、容器之間進行通訊，
- macvlan：此網絡允許爲容器指定一個MAC地址，允許容器作爲網絡中的物理設備，這樣Docker daemon就可以通過MAC地址進行訪問的路由。對於希望直接連接網絡網絡的遺留應用，這種網絡驅動有時可能是最好的選擇。
- Network plugins：可以安裝和使用第三方的網絡插件。可以在Docker Store或第三方供應商處獲取這些插件:flannel等。
在默認情況，Docker使用bridge網絡模式，bridge網絡驅動的示意圖如下，我們先以bridge模式對Docker的網絡進行說明。
1.1 bridge網絡的構建過程如下：
1）安裝Docker時，創建一個名爲docke0的虛擬網橋，虛擬網橋使用“10.0.0.0 -10.255.255.255 “、”172.16.0.0-172.31.255.255″和“192.168.0.0——192.168.255.255”這三個私有網絡的地址範圍。
通過 ifconfig 命令可以查看docker0網橋的信息：
通過 docker network inspect bridge 可以查看網橋的子網網絡範圍和網關：
2）運行容器時，在宿主機上創建虛擬網卡veth pair設備，veth pair設備是成對出現的，從而組成一個數據通道，數據從一個設備進入，就會從另一個設備出來。將veth pair設備的一端放在新創建的容器中，命名爲eth0；另一端放在宿主機的docker0中，以veth爲前綴的名字命名。通過 brctl show 命令查看放在docker0中的veth pair設備
1.2 外部訪問
bridge的docker0是虛擬出來的網橋，因此無法被外部的網絡訪問。因此需要在運行容器時通過-p和-P參數對將容器的端口映射到宿主機的端口。實際上Docker是採用 NAT的 方式，將容器內部的服務監聽端口與宿主機的某一個端口port 進行綁定，使得宿主機外部可以將網絡報文發送至容器。
1）通過-P參數，將容器的端口映射到宿主機的隨機端口：
$ docker run -P {images}
2）通過-p參數，將容器的端口映射到宿主機的制定端口：
$ docker run -p {hostPort}:{containerPort} {images}
可以修改docker的默認網段：
第一步 刪除原有配置
sudo service docker stop
sudo ip link set dev docker0 down
sudo brctl delbr docker0
sudo iptables -t nat -F POSTROUTING
第二步 創建新的網橋
sudo brctl addbr docker0
sudo ip addr add 172.17.10.1/24 dev docker0
sudo ip link set dev docker0 up
第三步 配置Docker的文件
注意： 這裏是 增加下面的配置
vi /etc/docker/daemon.json
##追加的即可
cat /etc/docker/daemon.json
{"registry-mirrors": ["http://224ac393.m.daocloud.io"],
"bip": "172.17.10.1/24"
}
$ systemctl restart docker
二、Kubernetes網絡模式
Kubernetes與Docker網絡有些不同。Kubernetes網絡需要解決下面的4個問題：
- 集羣內：
- 容器與容器之間的通信
- Pod和Pod之間的通信
- Pod和服務之間的通信
- 集羣外：
- 外部應用與服務之間的通信
因此，Kubernetes假設Pod之間能夠進行通訊，這些Pod可能部署在不同的宿主機上。每一個Pod都擁有自己的IP地址，因此能夠將Pod看作爲物理主機或者虛擬機，從而能實現端口設置、命名、服務發現、負載均衡、應用配置和遷移。爲了滿足上述需求，則需要通過集羣網絡來實現。
下文主要分析容器與容器之間，以及Pod和Pod之間的通信；
2.1 同一個Pod中容器之間的通信
這種場景對於Kubernetes來說沒有任何問題，根據Kubernetes的架構設計。Kubernetes創建Pod時，首先會創建一個pause容器，爲Pod指派一個唯一的IP地址。然後，以pause的網絡命名空間爲基礎，創建同一個Pod內的其它容器（–net=container:xxx）。因此，同一個Pod內的所有容器就會共享同一個網絡命名空間，在同一個Pod之間的容器可以直接使用localhost進行通信。
2.2 不同Pod中容器之間的通信
對於此場景，情況現對比較複雜一些，這就需要解決Pod間的通信問題。在Kubernetes通過flannel、calic等網絡插件解決Pod間的通信問題。
Flannel是CoreOS開源的CNI網絡插件，下圖flannel官網提供的一個數據包經過封包、傳輸以及拆包的示意圖：
從這個圖片裏面裏面可以看出兩臺機器的docker0分別處於不同的段：10.1.20.1/24 和 10.1.15.1/24 ，如果從Web App Frontend1 pod（10.1.15.2）去連接另一臺主機上的Backend Service2 pod（10.1.20.3），網絡包從宿主機192.168.0.100發往192.168.0.200，內層容器的數據包被封裝到宿主機的UDP裏面，並且在外層包裝了宿主機的IP和mac地址。這就是一個經典的overlay網絡，因爲容器的IP是一個內部IP，無法從跨宿主機通信，所以容器的網絡互通，需要承載到宿主機的網絡之上。
flannel的支持多種網絡模式，常用用都是vxlan、UDP、hostgw、ipip以及gce和阿里雲等。
vxlan和UDP的區別是vxlan是內核封包，而UDP是flanneld用戶態程序封包，所以UDP的方式性能會稍差；
hostgw模式是一種主機網關模式，容器到另外一個主機上容器的網關設置成所在主機的網卡地址，這個和calico非常相似，只不過calico是通過BGP聲明，而hostgw是通過中心的etcd分發，所以hostgw是直連模式，不需要通過overlay封包和拆包，性能比較高，但hostgw模式最大的缺點是必須是在一個二層網絡中，畢竟下一跳的路由需要在鄰居表中，否則無法通行。
Pod和服務之間，以及外部應用與服務之間的通信請參考《Kubernetes-核心資源之Service》和《Kubernetes-核心資源之Ingress》。
三、flannel安裝部署和在Kubernetes中運行的整體過程
flannel運行的基本流程：
1）設置網段（地址空間）：flannel利用Kubernetes API或者etcd用於存儲整個集羣的網絡配置，其中最主要的內容爲設置集羣的網絡地址空間。例如，設定整個集羣內所有容器的IP都取自網段“10.1.0.0/16”。
2）flannel服務：flannel在每個主機中運行flanneld作爲agent，它會爲所在主機從集羣的網絡地址空間中，獲取一個小的網段subnet，本主機內所有容器的IP地址都將從中分配。
然後，flanneld再將本主機獲取的subnet以及用於主機間通信的Public IP，同樣通過kubernetes API或者etcd存儲起來。
3）跨主機通信：最後，flannel利用各種backend mechanism，例如udp，vxlan等等，跨主機轉發容器間的網絡流量，完成容器間的跨主機通信。
1、下載安裝
flannel和etcd一樣，直接從官方下載二進制執行文件就可以用了。當然，你也可以自己編譯。
下載地址：https://github.com/coreos/flannel/releases/
解壓後主要有flanneld、mk-docker-opts.sh這兩個文件，其中flanneld爲主要的執行文件，sh腳本用於生成Docker啓動參數。
2、 etcd註冊網段
由於flannel需要依賴etcd來保證集羣IP分配不衝突的問題，所以首先要在etcd中設置 flannel節點所使用的IP段。
所有Node上的flanneld都依賴etcd cluster來做集中配置服務，etcd保證了所有node上flanned所看到的配置是一致的。
etcdctl --endpoints="http://node1.etcd.tulingapi.com:2379,http://node2.etcd.tulingapi.com:2379,http://node2.etcd.tulingapi.com:2379" set /k8s/network/config '{ "Network": "10.0.0.0/16", "Backend": {"Type": "vxlan"}}'
{ "Network": "10.0.0.0/16", "Backend": {"Type": "vxlan"}}
寫入的 Pod 網段 ${CLUSTER_CIDR} 必須是 /16 段地址，必須與 kube-controller-manager 的 --cluster-cidr 參數值一致；
flannel默認的backend type是udp，如果想要使用vxlan作爲backend，可以加上backend參數： {"Type": "vxlan"}}
flannel backend爲vxlan比起預設的udp性能相對好一些。
通過如下的命令能夠查詢網絡配置信息：
$ etcdctl --endpoints "http://node1.etcd.tulingapi.com:2379" ls /k8s/network/config
/coreos.com/network/subnets/10.0.2.0-24
獲取子網列表
$ etcdctl ls /k8s/network/subnets
/k8s/network/subnets/10.0.86.0-24
/k8s/network/subnets/10.0.35.0-24
/k8s/network/subnets/10.0.24.0-24
3、啓動flannel
flanneld 運行時需要 root 權限；命令行方式運行:
ln -s /mnt/app/flannel-v0.11.0/flanneld /usr/bin/flanneld
$ flanneld --etcd-endpoints="http://node1.etcd.tulingapi.com:2379" --ip-masq=true #命令行
$ cd /mnt/logs/flannel && nohup flanneld --etcd-endpoints="http://node1.etcd.tulingapi.com:2379" -etcd-prefix=/k8s
/network--ip-masq=true & #命令行後臺
也可以創建一個flannel systemd服務，方便以後管理。
啓動參數：
--logtostderr=false
--log_dir= /mnt/logs/flannel
--etcd-endpoints="http://node1.etcd.tulingapi.com:2379"
-etcd-prefix=/k8s/network #etcd路徑前綴
--iface=192.168.10.50 #要綁定的網卡的IP地址，請根據實際情況修改。
啓動時如果出現以下錯誤：
Couldn't fetch network config: 100: Key not found (/coreos.com)
通過-etcd-prefix指定/k8s/network。
flannel啓動過程解析：
flannel服務需要先於Docker啓動。flannel服務啓動時主要做了以下幾步的工作：
1）啓動參數設置網卡及對外IP選擇
2）從etcd中獲取network的配置信息。
3）劃分子網subnet，並在etcd中進行註冊。
4）將子網信息記錄到/run/flannel/subnet.env中。
5）在Node節點上，會創建一個名爲flannel.1的虛擬網卡。
可以看到每個node上/run/flannel/subnet.env 子網掩碼不一樣。
啓動參數設置網卡及對外IP選擇
flanneld的啓動參數中通過”–iface”或者”–iface-regex”進行指定。其中”–iface”的內容可以是完整的網卡名或IP地址，而”–iface-regex”則是用正則表達式表示的網卡名或IP地址，並且兩個參數都能指定多個實例。flannel將以如下的優先級順序來選取：
1) 如果”–iface”和”—-iface-regex”都未指定時，則直接選取默認路由所使用的輸出網卡
2) 如果”–iface”參數不爲空，則依次遍歷其中的各個實例，直到找到和該網卡名或IP匹配的實例爲止
3) 如果”–iface-regex”參數不爲空，操作方式和2)相同，唯一不同的是使用正則表達式去匹配
最後，對於集羣間交互的Public IP，我們同樣可以通過啓動參數”–public-ip”進行指定。否則，將使用–iface獲取網卡的IP作爲Public IP。
驗證flannel網絡：
在node1節點上看etcd中的內容：
$ etcdctl --endpoints "http://node1.etcd.tulingapi.com:2379" ls /k8s/network/subnets
/k8s/network/subnets/10.0.24.0-24
[root@k8s-master flannel]# cat /run/flannel/subnet.env
FLANNEL_NETWORK=10.0.0.0/16
FLANNEL_SUBNET=10.0.24.1/24
FLANNEL_MTU=1450
FLANNEL_IPMASQ=true
通過文件/run/flannel/subnet.env設定docker的網絡。我們發現這裏的MTU並不是以太網規定的1500，這是因爲外層的vxlan封包還要佔據50 Byte。
查看flannel1.1的網絡情況,注意查看docker0和flannel是不是屬於同一網段
可以看到flannel1.1網卡的地址和etcd中存儲的地址一樣，這樣flannel網絡配置完成。
4、創建docker網橋
容器配置名爲docker0的網橋，實際是通過修改Docker的啓動參數–bip來實現的。通過這種方式，爲每個節點的Docker0網橋設置在整個集羣範圍內唯一的網段，從保證創建出來的Pod的IP地址是唯一。
在etcd1節點上看etcd中的內容：
etcdctl --endpoints "http://node1.etcd.tulingapi.com:2379" ls /k8s/network/subnets
/k8s/network/subnets/10.0.24.0-24
在各個節點安裝好以後最後要更改Docker的啓動參數，使其能夠使用flannel進行IP分配，以及網絡通訊。
flannel運行後會生成一個環境變量文件，包含了當前主機要使用flannel通訊的相關參數。
1）查看flannel分配的網絡參數：
cat /run/flannel/subnet.env
FLANNEL_NETWORK=10.0.0.0/16
FLANNEL_SUBNET=10.0.24.1/24
FLANNEL_MTU=1450
FLANNEL_IPMASQ=true
2）創建Docker運行參數
使用flannel提供的腳本mk-docker-opts.sh將subnet.env轉寫成Docker啓動參數，創建好的啓動參數位於/run/docker_opts.env文件中。
/mnt/app/flannel/mk-docker-opts.sh -d /run/docker_opts.env -c
$ cat /run/docker_opts.env
DOCKER_OPTS=" --bip=10.0.24.1/24 --ip-masq=false --mtu=1450"
3) 修改Docker啓動參數
修改docker的啓動參數，並使其啓動後使用由flannel生成的配置參數，修改如下:
編輯 systemd service 配置文件
$ vim /lib/systemd/system/docker.service
(1)、指定這些啓動參數所在的文件位置:(這個配置是新增的，同樣放在Service標籤下)
EnvironmentFile=/run/docker_opts.env
(2)、在啓動時增加flannel提供的啓動參數:
ExecStart=/usr/bin/dockerd $DOCKER_OPTS
然後重新加載systemd配置，並重啓Docker即可
systemctl daemon-reload
systemctl restart docker
此時可以看到docker0的網卡ip地址已經處於flannel網卡網段之內。
到此節點etcd1的flannel安裝配置完成了，其它兩節點按以上方法配置完成就行了。
測試flannel
5、修改路由表
flannel會對路由表進行修改，從而能夠實現容器跨主機的通信。
四、backend原理解析
集羣範圍內的網絡地址空間爲10.1.0.0/16:
Machine A獲取的subnet爲10.1.15.0/24，且其中的兩個容器IP分別爲10.1.15.2/24和10.1.15.3/24，兩者都在10.1.15.0/24這一子網範圍內。Machine B同理。
Machine A中的容器要與Machine B中的容器進行通信，封包是如何進行轉發的？
從上文可知，每個主機的flanneld會將自己與所獲取subnet的關聯信息存入etcd中，例如，subnet 10.1.15.0/24所在主機可通過IP 192.168.0.100訪問，subnet 10.1.16.0/24可通過IP 192.168.0.200訪問。反之，每臺主機上的flanneld通過監聽etcd，也能夠知道其他的subnet與哪些主機相關聯。如上圖，Machine A上的flanneld通過監聽etcd已經知道subnet 10.1.16.0/24所在的主機可以通過Public 192.168.0.200訪問，而且熟悉docker橋接模式的同學肯定知道，目的地址爲10.1.20.3/24的封包一旦到達Machine B，就能通過veth0網橋轉發到相應的pod，從而達到跨宿主機通信的目的。
因此，flanneld只要想辦法將封包從Machine A轉發到Machine B就OK了，其中backend就是用於完成這一任務。不過，達到這個目的的方法是多種多樣的，所以我們也就有了很多種backend. 即網絡模式：
flannel的支持多種網絡模式，常用用都是vxlan、UDP、hostgw、ipip以及gce和阿里雲等。即我們啓動Backend參數：
etcdctl --endpoints="http://node1.etcd.tulingapi.com:2379,http://node2.etcd.tulingapi.com:2379,http://node2.etcd.tulingapi.com:2379" set /k8s/network/config '{ "Network": "10.0.0.0/16", "Backend": {"Type": "vxlan"}}'
我們將對hostgw，udp和vxlan三種backend進行解析。
1、 hostgw
hostgw是最簡單的backend，它的原理非常簡單，直接添加路由，將目的主機當做網關，直接路由原始封包。
因爲Machine A和Machine B處於同一個子網內，它們原本就能直接互相訪問。因此最簡單的方法是：在Machine A中的容器要訪問Machine B的容器時，我們可以將Machine B看成是網關，當有封包的目的地址在subnet 10.1.16.0/24範圍內時，就將其直接轉發至B即可。
圖中那條紅色標記的路由就能完成：我們從etcd中監聽到一個EventAdded事件subnet爲10.1.15.0/24被分配給主機Machine A Public IP 192.168.0.100，hostgw要做的工作就是在本主機上添加一條目的地址爲10.1.15.0/24，網關地址爲192.168.0.100，輸出設備爲上文中選擇的集羣間交互的網卡即可。對於EventRemoved事件，只需刪除對應的路由。
2、 udp
我們知道當backend爲hostgw時，主機之間傳輸的就是原始的容器網絡封包，封包中的源IP地址和目的IP地址都爲容器所有。這種方法有一定的限制，就是要求所有的主機都在一個子網內，即二層可達，否則就無法將目的主機當做網關，直接路由。
而udp類型backend的基本思想是：既然主機之間是可以相互通信的（並不要求主機在一個子網中），那麼我們爲什麼不能將容器的網絡封包作爲負載數據在集羣的主機之間進行傳輸呢？這就是所謂的overlay。具體過程如圖所示：
當容器10.1.15.2/24要和容器10.1.20.3/24通信時：
1）因爲該封包的目的地不在本主機subnet內，因此封包會首先通過網橋轉發到主機中。最終在主機上經過路由匹配，進入如圖的網卡flannel0。需要注意的是flannel0是一個tun設備，它是一種工作在三層的虛擬網絡設備，而flanneld是一個proxy，它會監聽flannel0並轉發流量。當封包進入flannel0時，flanneld就可以從flannel0中將封包讀出，由於flannel0是三層設備，所以讀出的封包僅僅包含IP層的報頭及其負載。最後flanneld會將獲取的封包作爲負載數據，通過udp socket發往目的主機。同時，在目的主機的flanneld會監聽Public IP所在的設備，從中讀取udp封包的負載，並將其放入flannel0設備內。由此，容器網絡封包到達目的主機，之後就可以通過網橋轉發到目的容器了。
最後和hostgw不同的是，udp backend並不會將從etcd中監聽到的事件裏所包含的lease信息作爲路由寫入主機中。每當收到一個EventAdded事件，flanneld都會將其中的subnet和Public IP保存在一個數組中，用於轉發封包時進行查詢，找到目的主機的Public IP作爲udp封包的目的地址。
3、 vxlan
首先，我們對vxlan的基本原理進行簡單的敘述。從下圖所示的封包結構來看，vxlan和上文提到的udp backend的封包結構是非常類似的，不同之處是多了一個vxlan header，以及原始報文中多了個二層的報頭。
下面讓我們來看看，當有一個EventAdded到來時，flanneld如何進行配置，以及封包是如何在flannel網絡中流動的。
如上圖所示，當主機B加入flannel網絡時，和其他所有backend一樣，它會將自己的subnet 10.1.16.0/24和Public IP 192.168.0.101寫入etcd中，和其他backend不一樣的是，它還會將vtep設備flannel.1的mac地址也寫入etcd中。
之後，主機A會得到EventAdded事件，並從中獲取上文中B添加至etcd的各種信息。這個時候，它會在本機上添加三條信息：
1) 路由信息：所有通往目的地址10.1.16.0/24的封包都通過vtep設備flannel.1設備發出，發往的網關地址爲10.1.16.0，即主機B中的flannel.1設備。
2) fdb信息：MAC地址爲MAC B的封包，都將通過vxlan首先發往目的地址192.168.0.101，即主機B
3）arp信息：網關地址10.1.16.0的地址爲MAC B
現在有一個容器網絡封包要從A發往容器B，和其他backend中的場景一樣，封包首先通過網橋轉發到主機A中。此時通過，查找路由表，該封包應當通過設備flannel.1發往網關10.1.16.0。通過進一步查找arp表，我們知道目的地址10.1.16.0的mac地址爲MAC B。到現在爲止，vxlan負載部分的數據已經封裝完成。由於flannel.1是vtep設備，會對通過它發出的數據進行vxlan封裝（這一步是由內核完成的，相當於udp backend中的proxy），那麼該vxlan封包外層的目的地址IP地址該如何獲取呢？事實上，對於目的mac地址爲MAC B的封包，通過查詢fdb，我們就能知道目的主機的IP地址爲192.168.0.101。
最後，封包到達主機B的eth0，通過內核的vxlan模塊解包，容器數據封包將到達vxlan設備flannel.1，封包的目的以太網地址和flannel.1的以太網地址相等，三層封包最終將進入主機B並通過路由轉發達到目的容器。
事實上，flannel只使用了vxlan的部分功能，由於VNI被固定爲1，本質上工作方式和udp backend是類似的，區別無非是將udp的proxy換成了內核中的vxlan處理模塊。而原始負載由三層擴展到了二層，但是這對三層網絡方案flannel是沒有意義的，這麼做也僅僅只是爲了適配vxlan的模型。vxlan詳細的原理參見文後的參考文獻，其中的分析更爲具體，也更易理解。
4、數據傳遞過程
在源容器宿主機中的數據傳遞過程：
1）源容器向目標容器發送數據，數據首先發送給docker0網橋
在源容器內容查看路由信息：
$ kubectl exec -it -p {Podid} -c {ContainerId} -- ip route
2）docker0網橋接受到數據後，將其轉交給flannel.1虛擬網卡處理
docker0收到數據包後，docker0的內核棧處理程序會讀取這個數據包的目標地址，根據目標地址將數據包發送給下一個路由節點：
查看源容器所在Node的路由信息：
$ ip route
3）flannel.1接受到數據後，對數據進行封裝，併發給宿主機的eth0
flannel.1收到數據後，flannelid會將數據包封裝成二層以太包。
Ethernet Header的信息：
- From:{源容器flannel.1虛擬網卡的MAC地址}
- To:{目錄容器flannel.1虛擬網卡的MAC地址}
4）對在flannel路由節點封裝後的數據，進行再封裝後，轉發給目標容器Node的eth0
由於目前的數據包只是vxlan tunnel上的數據包，因此還不能在物理網絡上進行傳輸。因此，需要將上述數據包再次進行封裝，才能源容器節點傳輸到目標容器節點，這項工作在由linux內核來完成。
Ethernet Header的信息：
- From:{源容器Node節點網卡的MAC地址}
- To:{目錄容器Node節點網卡的MAC地址}
IP Header的信息：
- From:{源容器Node節點網卡的IP地址}
- To:{目錄容器Node節點網卡的IP地址}
通過此次封裝，就可以通過物理網絡發送數據包。
在目標容器宿主機中的數據傳遞過程：
5）目標容器宿主機的eth0接收到數據後，對數據包進行拆封，並轉發給flannel.1虛擬網卡；
6）flannel.1 虛擬網卡接受到數據，將數據發送給docker0網橋；
7）最後，數據到達目標容器，完成容器之間的數據通信。
五、Kubernetes Cluster中的幾個“網絡”
node network：承載kubernetes集羣中各個“物理”Node(master和minion)通信的網絡；
service network：由kubernetes集羣中的Services所組成的“網絡”；
flannel network： 即Pod網絡，集羣中承載各個Pod相互通信的網絡。
1、node network (Node IP)
自不必多說，node間通過你的本地局域網（無論是物理的還是虛擬的）通信。
2、service network (clusterI)：比較特殊，每個新創建的service會被分配一個service IP 即spec.clusterIP，在集羣中，這個IP的分配範圍並不“真實”，更像一個“佔位符”並且只有入口流量，所謂的“network”也是“名不符實”的，後續我們會詳盡說明。
Service network(看cluster-ip一列)：
# kubectl get services
3、flannel network (Pod IP)：是我們要理解的重點，cluster中各個Pod要實現相互通信，必須走這個網絡，無論是在同一node上的Pod還是跨node的Pod。
Flannel network（看IP那列）:
# kubectl get pod -o wide
