云原生(Cloud Native)可以認(rèn)為是一套技術(shù)體系或生態(tài)，它包含2大部分：云(Cloud)和原生(Native)。云(Cloud)表示應(yīng)用程序位于云中，而不是傳統(tǒng)的數(shù)據(jù)中心;原生(Native)表示應(yīng)用程序從設(shè)計(jì)之初即考慮到云的環(huán)境，原生為云而設(shè)計(jì)，在云上以最佳狀態(tài)運(yùn)行，充分利用和發(fā)揮云平臺(tái)的彈性和分布式優(yōu)勢(shì)。

[[435838]]

云原生的代表技術(shù)體系包括容器(Container)、服務(wù)網(wǎng)格(Service Mesh)、微服務(wù)(Microservice)、不可變基礎(chǔ)設(shè)施和聲明式API。本文主要基于容器技術(shù)，解析在容器編排生態(tài)K8S中的網(wǎng)絡(luò)流量模型，讓大家能夠更深刻了解容器技術(shù)在云原生生態(tài)中的應(yīng)用與落地。

Kubernetes基于扁平地址空間，非NAT的網(wǎng)絡(luò)結(jié)構(gòu)，無(wú)需在主機(jī)和容器之間映射端口。此網(wǎng)絡(luò)模型的主要特點(diǎn)是消除了在主機(jī)和容器之間映射端口的需求。我們先看下其總體架構(gòu)拓?fù)淠Ｐ停?/p>

在容器網(wǎng)絡(luò)中主要涉及以下幾個(gè)地址：

• Node Ip：即物理機(jī)地址。
• Pod Ip：Kubernetes的最小部署單元是Pod，一個(gè)Pod 可能包含一個(gè)或多個(gè)容器，簡(jiǎn)單來(lái)講容器沒(méi)有自己?jiǎn)为?dú)的地址，他們共享Pod 的地址和端口區(qū)間。
• ClusterIp：Service的Ip地址，外部網(wǎng)絡(luò)無(wú)法Ping通改地址，因?yàn)樗翘摂MIP地址，沒(méi)有網(wǎng)絡(luò)設(shè)備為這個(gè)地址負(fù)責(zé)，內(nèi)部實(shí)現(xiàn)是使用Iptables規(guī)則重新定向到其本地端口，再均衡到后端Pod;只有Kubernetes集群內(nèi)部訪問(wèn)使用。
• Public Ip ：Service對(duì)象在Cluster IP range池中分配到的IP只能在內(nèi)部訪問(wèn)，適合作為一個(gè)應(yīng)用程序內(nèi)部的層次。如果這個(gè)Service作為前端服務(wù)，準(zhǔn)備為集群外的客戶提供業(yè)務(wù)，我們就需要給這個(gè)服務(wù)提供公共IP。

容器網(wǎng)絡(luò)流量模型

1、POD內(nèi)容器間通信

Pod中的容器可以通過(guò)“localhost”來(lái)互相通信，他們使用同一個(gè)網(wǎng)絡(luò)命名空間，對(duì)容器自身來(lái)說(shuō)，hostname就是其Pod的名稱。Pod中的所有容器共享同一個(gè)IP地址和端口空間，你需要為每個(gè)需要接收連接的容器分配不同的端口。也就是說(shuō)，Pod中的應(yīng)用需要自己協(xié)調(diào)端口的使用。

內(nèi)部實(shí)現(xiàn)機(jī)制：同Pod內(nèi)的容器實(shí)際共享同一個(gè)Namespace，因此使用相同的Ip和Port空間，該Namespace 是由一個(gè)叫Pause的小容器來(lái)實(shí)現(xiàn)，每當(dāng)一個(gè)Pod被創(chuàng)建，那么首先創(chuàng)建一個(gè)pause容器，之后這個(gè)Pod里面的其他容器通過(guò)共享這個(gè)pause容器的網(wǎng)絡(luò)棧，實(shí)現(xiàn)外部Pod進(jìn)行通信,因此對(duì)于同Pod里面的所有容器來(lái)說(shuō)，他們看到的網(wǎng)絡(luò)視圖是一樣的，我們?cè)谌萜髦锌吹牡刂?，也就是Pod地址實(shí)際是Pause容器的IP地址?？傮w模型如下： 

2、同主機(jī)POD間通信

每個(gè)節(jié)點(diǎn)上的每個(gè)Pod都有自己的Namespace，同主機(jī)上的Pod之間怎么通信呢?我們可以在兩個(gè)Pod之間建立Vet Pair進(jìn)行通信，但如果有多個(gè)容器，兩兩建立Veth 就會(huì)非常麻煩，假如有N 個(gè)Pod ，那么我們需要?jiǎng)?chuàng)建n(n-1)/2個(gè)Veth Pair，擴(kuò)展性非常差，如果我們可以將這些Veth Pair 連接到一個(gè)集中的轉(zhuǎn)發(fā)點(diǎn)，由它來(lái)統(tǒng)一轉(zhuǎn)發(fā)就就會(huì)非常便捷，這個(gè)集中轉(zhuǎn)發(fā)點(diǎn)就是我們常說(shuō)的Bridge，如下所示

3、跨主機(jī)POD間通信

對(duì)于網(wǎng)絡(luò)上兩個(gè)端點(diǎn)之間的互通目前主要有兩種方案：一種是基于Underlay 直接互通，此模式需要雙方有彼此的路由信息并且該路由信息在underlay的路徑上存在。一種是基于Overlay 方案，通過(guò)隧道實(shí)現(xiàn)互通。Underlay 層面保證主機(jī)可達(dá)即可，代表網(wǎng)絡(luò)方案有 Calico(Direct模式)和Macvlan，后者有Overlay，OVS，F(xiàn)lannel和Weave。本篇僅針對(duì)Flannel 和Calico 插件進(jìn)行簡(jiǎn)要介紹。

Flannel插件

Flannel是由CoreOS開(kāi)發(fā)的項(xiàng)目，是容器編排系統(tǒng)中最成熟的網(wǎng)絡(luò)結(jié)構(gòu)示例之一，旨在實(shí)現(xiàn)更好的容器間和主機(jī)間網(wǎng)絡(luò)。

與其他方案相比，F(xiàn)lannel相對(duì)容易安裝和配置。它被打包為單個(gè)二進(jìn)制文件Flanneld，許多常見(jiàn)的Kubernetes集群部署工具和許多Kubernetes發(fā)行版都可以默認(rèn)安裝Flannel。Flannel可以使用Kubernetes集群的現(xiàn)有Etcd集群來(lái)使用API存儲(chǔ)其狀態(tài)信息，因此不需要專用的數(shù)據(jù)存儲(chǔ)。其工作流程圖如下：

基本流程為：

1、地址分配

Flanneld 第一次啟動(dòng)時(shí)，從 etcd 獲取配置的 Pod 網(wǎng)段信息，為本節(jié)點(diǎn)分配一個(gè)未使用的地址段，然后創(chuàng)建 flannedl.1 網(wǎng)絡(luò)接口(也可能是其它名稱，如 flannel1 等)，flannel 將分配給自己的 Pod 網(wǎng)段信息寫(xiě)入 /run/flannel/docker 文件(不同k8s版本文件名存在差異)，docker 后續(xù)使用這個(gè)文件中的環(huán)境變量設(shè)置 docker0 網(wǎng)橋，從而使這個(gè)地址段為本節(jié)點(diǎn)的所有。

2、路由下發(fā)

每臺(tái)主機(jī)上，F(xiàn)lannel 運(yùn)行一個(gè)Daemon 進(jìn)程叫flanneld，它可以在內(nèi)核中創(chuàng)建路由表。

3、數(shù)據(jù)面封裝

Flannel 知道外層封裝地址后，對(duì)報(bào)文進(jìn)行封裝，源采用自己的物理Ip 地址，目的采用對(duì)端的，Vxlan 外層的Udp Port 8472(如果是UDP封裝使用8285作為默認(rèn)目的端口，下文會(huì)提到)，對(duì)端只需監(jiān)控Port 即可，當(dāng)改端口收到報(bào)文后將報(bào)文送到Flannedld 進(jìn)程，進(jìn)程將報(bào)文送到Flanned 接口接封裝，然后查詢本地路由表獲取目的地址。

Flannel功能內(nèi)部支持三種不同后端實(shí)現(xiàn)，分別是：

• Host-gw：需要兩臺(tái)host 在同一網(wǎng)段，不支持跨網(wǎng)，因此不適合大規(guī)模部署。
• UDP：不建議使用，除非內(nèi)核不支持Vxlan 或者Debugg時(shí)候使用，已廢棄。
• Vxlan : Vxlan 封裝，F(xiàn)lannel 使用Vxlan 技術(shù)為各節(jié)點(diǎn)創(chuàng)建一個(gè)可以互通的 Pod 網(wǎng)絡(luò)，使用的端口為 Udp 8472(需要開(kāi)放該端口，如公有云 AWS 等)。

Calico插件

Calico支持3種路由模式：

• Direct: 路由轉(zhuǎn)發(fā)，報(bào)文不做封裝。
• Ip-In-Ip:Calico 默認(rèn)的路由模式,數(shù)據(jù)面采用Ip封裝。
• Vxlan：vxlan 封裝。

本文主要介紹Direct模式，采用軟路由建立BGP 宣告容器網(wǎng)段,使得全網(wǎng)所有的Node和網(wǎng)絡(luò)設(shè)備都有到彼此的路由的信息，然后直接通過(guò)underlay 轉(zhuǎn)發(fā)。Calico實(shí)現(xiàn)的總體結(jié)構(gòu)如下：

數(shù)據(jù)通信的流程為：數(shù)據(jù)包先從veth設(shè)備對(duì)另一口發(fā)出，到達(dá)宿主機(jī)上的Cali開(kāi)頭的虛擬網(wǎng)卡上，到達(dá)這一頭也就到達(dá)了宿主機(jī)上的網(wǎng)絡(luò)協(xié)議棧，然后查詢路由表轉(zhuǎn)發(fā);因?yàn)楸緳C(jī)通過(guò)Bird 和RR 建立Bgp 鄰居關(guān)系，會(huì)將本地的容器地址發(fā)送到RR 從而反射到網(wǎng)絡(luò)其它節(jié)點(diǎn)，同樣，其它節(jié)點(diǎn)的網(wǎng)絡(luò)地址也會(huì)傳送到本地，然后由Felix 進(jìn)程進(jìn)行管理并下發(fā)到路由表中，報(bào)文匹配路由規(guī)則后正常進(jìn)行轉(zhuǎn)發(fā)即可。至于更為復(fù)雜的Iptables規(guī)則，因篇幅有限，本次暫不做解析。

4、集群內(nèi)Service Cluster IP和外部訪問(wèn)

Serice 和外部通信場(chǎng)景實(shí)現(xiàn)涉及較多iptables 轉(zhuǎn)發(fā)原理，簡(jiǎn)單介紹如下：

Pod與service通信：Pod間可以直接通過(guò)IP地址通信，前提是Pod知道對(duì)方的IP。在 Kubernetes集群中，Pod可能會(huì)頻繁地銷毀和創(chuàng)建，也就是說(shuō)Pod的IP 不是固定的。為了解決這個(gè)問(wèn)題，Service提供了訪問(wèn)Pod的抽象層。無(wú)論后端的Pod如何變化，Service都作為穩(wěn)定的前端對(duì)外提供服務(wù)。同時(shí)，Service還提供了高可用和負(fù)載均衡功能，Service負(fù)責(zé)將請(qǐng)求轉(zhuǎn) 給正確的Pod。

外部通信：無(wú)論是Pod的IP還是Service的Cluster IP，它們只能在Kubernetes集群中可見(jiàn)，對(duì)集群之外的世界，這些IP都是私有的Kubernetes提供了兩種方式讓外界能夠與Pod通信:

NodePort：Service通過(guò)Cluster節(jié)點(diǎn)的靜態(tài)端口對(duì)外提供服務(wù)，外部可以通過(guò):訪問(wèn)Service。

LoadBalancer：Service利用Cloud Provider提供的Load Balancer對(duì)外提供服務(wù)，Cloud Provider負(fù)責(zé)將Load Balancer 的流量導(dǎo)向Service。