K8S 的網絡特征:

1. 每個POD 一個IP (IP peer POD)

2. 所有POD 通過IP 直接訪問其他POD 而不管POD 是否在同一臺物理機上

3. POD 內的所有容器共享一個LINUX NET NAMESPACE (網絡堆棧), POD 內的容器, 都可以使用localhost 來訪問pod 內的其他容器.

K8S 對集群網絡的要求:

1. 所有容器都可以在不用NAT 的方式下訪問其他容器
2. 所有節點都可以在不用NAT的方式下同所有容器通信,反之亦然
3. 容器的地址和別人看到的地址是同一個地址

kubernetes 網絡實現

POD 間通信網絡模型

image.png

NODE 間通信網絡模型

image.png

ip1 ip2 都存在 etcd中

K8S 不同node 中pod 相互通信需要滿足的條件如下

1. 整個K8S集群中的POD IP 分配不能有沖突
2. 找到一種辦法,將 POD 的 IP 和所在的 NDOE 的 IP 關聯起來, 通過這個關聯讓 POD 相互訪問

條件1 要求NODE 中的docker0 的網橋地址不能沖突

條件2 要求 POD 中的數據在出發時,需要有一個機制能夠知道對方 POD 的 IP 地址在哪個NODE上

滿足條件的扁平化網絡拓撲如下

image.png

默認docker0 的網絡為 172.17.0.0/16 的網段. 每個容器都在這個子網內獲得 IP 并且將 docker0 作為網關

docker 宿主機不需要知道任何關于docker 0 的信息, 因為docker 宿主機對任何容器發出的數據,在物理卡上都做了 IP 偽裝(masquerade 隱含nat),也就是說其他任何node看到的數據包來源都是宿主機的物理網卡IP

這個模型的缺點是, 需要使用nat技術

K8S 模型中,每個 NODE 上的 docker0 都是可以被路由到的, 也就是說, 在部署一個 POD 時, 在同一個集群內, 各個主機都可以訪問其他主機上的 POD IP, 并不需要在主機上做端口映射.

我們可以把NODE 看作交換機網絡模型看起來就是下面這個樣子

image.png

在node中,我們目前采用直接路由的方式來實現.在每個node上配置講臺路由

例如在192.168.1.10 上配置

route add -net 10.1.20.0 netmask 255.255.255.0 gw 192.168.1.20
route add -net 10.1.30.0 netmask 255.255.255.0 gw 192.168.1.30

當我們啟動一個POD ,要求POD 下的所有容器都使用同一個網絡命名空間,以及同一個IP,所以必須要使用容器網絡的 container 模式. 如果將所有 pod 中的容器做成一個鏈的結構, 中間任何一個容器出問題, 都會引起連鎖反映, 所以在每個 POD 中都引入一個 google_containers/pause 其他容器都鏈接到這個容器, 由 google_containers/pause 來負責端口規劃和映射

POD 內部的網絡模型為

image.png

pause 容器用于接管pod的endpoint.

通過docker inpsect <id> | grep NetworkMod 查看pause 容器的網絡模式,可以看到使用的是bridge 而 業務容器 docker inpsect < 業務容器id> | grep NetworkMod 使用的是 container:<長ID>

Service 的網絡信息

當在K8S中創建一個service(非 NODEPORT) 之后, K8S 會為每個 service 分配一個cluster IP

roger@microk8s:~$ kubectl get service
NAME                   TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)   AGE
default-http-backend   ClusterIP   10.152.183.69    <none>        80/TCP    11d
http-svc               ClusterIP   10.152.183.164   <none>        80/TCP    11d

IP 地址段為 apiserver 啟動時, --server-cluster-ip-range 所指定的 IP 段,這個 IP 段不能和 docker0 的 IP 段沖突, 這個網段不會在 物理網絡和 docker0 之間路由. 這個portal network 的意義是讓容器流量都指向默認的網關,也就docker0

查看iptables-save 數據

:KUBE-POSTROUTING - [0:0]
...
-A KUBE-PORTALS-CONTAINER -d 10.152.183.69/32 -p tcp -m comment --comment "default/default-http-backend:" -m tcp --dport 80 -j REDIRECT --to-ports 37853
-A KUBE-PORTALS-CONTAINER -d 10.152.183.164/32 -p tcp -m comment --comment "default/http-svc:http" -m tcp --dport 80 -j REDIRECT --to-ports 35667
-A KUBE-PORTALS-CONTAINER -d 10.152.183.1/32 -p tcp -m comment --comment "default/kubernetes:https" -m tcp --dport 443 -j REDIRECT --to-ports 40441
...
-A KUBE-PORTALS-HOST -d 10.152.183.69/32 -p tcp -m comment --comment "default/default-http-backend:" -m tcp --dport 80 -j DNAT --to-destination 192.168.10.5:37853
-A KUBE-PORTALS-HOST -d 10.152.183.164/32 -p tcp -m comment --comment "default/http-svc:http" -m tcp --dport 80 -j DNAT --to-destination 192.168.10.5:35667
-A KUBE-PORTALS-HOST -d 10.152.183.1/32 -p tcp -m comment --comment "default/kubernetes:https" -m tcp --dport 443 -j DNAT --to-destination 192.168.10.5:40441

可以發現, 到三個服務的流量都被重定向到一個隨機端口, 37853, 35667, 40441 . 這幾個端口都是由kube-proxy 創建的, kube-proxy 服務會為每個創建的service 都關聯一個隨機端口,并監聽那個特定的端口, 為服務創建相關聯的負載均衡.

image.png

注意, node3 的kubeproxy 并未參與此次交互. node1 的kube-proxy 起到了負載均衡的作用

如果文章對您有幫助,請點一下下面的 "喜歡"