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

[[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)，無需在主機(jī)和容器之間映射端口。此網(wǎng)絡(luò)模型的主要特點(diǎn)是消除了在主機(jī)和容器之間映射端口的需求。我們先看下其總體架構(gòu)拓?fù)淠Ｐ停?/p>

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

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

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

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

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

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

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

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

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

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

Flannel插件

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

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

基本流程為：

1、地址分配

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

2、路由下發(fā)

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

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

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

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

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

Calico插件

Calico支持3種路由模式：

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

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

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

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

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

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

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

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

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