前言

經過了前幾篇的 CNI 描述後，大家對於 CNI 的使用有了基本認知，一般常說的 CNI 可以包含 IPAM (IP位址管理)也可以不包含 IPAM。因為在某些情況下，CNI Plug-in 的使用和 IPAM Plug-in 的使用是分開為不同的 bin 檔，按照 kubernetes 的規範，我們在使用 CNI 的時候是要區分 CNI 和 IPAM，但是即使寫在⼀起也可以使⽤ CNI ，在 kubernets 啟動 POD 網路的配置流程是 kubelet->docker(pause)->cni->ipam，因此 kubernetes 的網路主要是 CNI 與 IPAM 組成。

整體來說，CNI + IPAM 的實現可以分為兩種：

• 第⼀種：與 Host 主機平行網路（L2 or L3）
  • 主要是：bridge、macvlan、ipvlan、calico bgp、flannel host-gw 等
• 第⼆種：利用 SDN 技術的虛擬網路
  • 主要有：flannel vxlan、calico ipip、weave 等

SDN 網路的優點與缺點

⼤部分使⽤ kubernetes 的公司，都是使用 kubernetes 經典 CNI，例如： kubernetes +Flannel（VXLAN）、 kubernetes +Calico（IPIP） 等。這種模式下的網路有⼀個共同特點，就是容器網路在 kubernetes cluster 內是隔離的，cluster 外的 Host 主機是無法直接訪問容器 IP 。
之所以會這樣，是因為容器網路是虛擬，這個 kubernets 的虛擬網路，⼤部分上都是借助 routing table + iptables + tunnel 模式來做。

這樣做的優點是網路隔離，部署方便，缺點是流量穿透的情況 kubernetes 內雖然是網路隔離。但其隔離的並不徹底。它的隔離性，一般是由 kube-proxy 元件產生的大量 iptables 規則和 routing table 來實現。這種模式下，iptables 的動態變化，其實依賴 kube-proxy 這個元件，⽽這個元件，其實是用於監聽 kubernetes cluster 的 service + endpoint 資源。我們部署在 cluster 內的 service，訪問某個內部服務，⽤的是基於 DNS 的服務發現機制。
這就帶來了下⾯⼀個問題：

• 如果服務 A 訪問服務 B，必先經過 DNS 解析拿到 service ip（⽐如 172.18.42.56） 這個虛擬 IP 位址。
  然⽽，如果 A 是拿著這個 IP 作為長連接服務，頻繁對 B 發封包。這個時候，B 服務掛掉了。掛掉後，kube-proxy 元件，將從 iptables 中刪除 B 服務的 iptables 規則，也就是說，172.18.42.56 這個虛擬 IP 從 iptables 中刪除了。
• 此時，A 如果還拿著這個 IP 發送封包，那麼因為 cluster 內已經缺少了這個虛擬 IP 的記錄，必然導致這部分流量，將穿越 iptables 規則，發到上層的 gateway。如果這個流量非常⼤的話，將對 gateway 和 路由器造成非常大的衝擊。
• 這個問題，只能去⼿動修改 iptables 規則來處理。因為 kube-proxy 也在修改 iptables 規則，所以，這個操作存在⼀定風險性，需要謹慎操作。

下篇待續...

Reference

https://github.com/containernetworking/cni