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

[[435838]]

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

Kubernetes基于扁平地址空間，非NAT的網絡結構，無需在主機和容器之間映射端口。此網絡模型的主要特點是消除了在主機和容器之間映射端口的需求。我們先看下其總體架構拓撲模型：

在容器網絡中主要涉及以下幾個地址：

• Node Ip：即物理機地址。
• Pod Ip：Kubernetes的最小部署單元是Pod，一個Pod 可能包含一個或多個容器，簡單來講容器沒有自己單獨的地址，他們共享Pod 的地址和端口區間。
• ClusterIp：Service的Ip地址，外部網絡無法Ping通改地址，因為它是虛擬IP地址，沒有網絡設備為這個地址負責，內部實現是使用Iptables規則重新定向到其本地端口，再均衡到后端Pod;只有Kubernetes集群內部訪問使用。
• Public Ip ：Service對象在Cluster IP range池中分配到的IP只能在內部訪問，適合作為一個應用程序內部的層次。如果這個Service作為前端服務，準備為集群外的客戶提供業務，我們就需要給這個服務提供公共IP。

容器網絡流量模型

1、POD內容器間通信

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

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

2、同主機POD間通信

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

3、跨主機POD間通信

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

Flannel插件

Flannel是由CoreOS開發的項目，是容器編排系統中最成熟的網絡結構示例之一，旨在實現更好的容器間和主機間網絡。

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

基本流程為：

1、地址分配

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

2、路由下發

每臺主機上，Flannel 運行一個Daemon 進程叫flanneld，它可以在內核中創建路由表。

3、數據面封裝

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

Flannel功能內部支持三種不同后端實現，分別是：

• Host-gw：需要兩臺host 在同一網段，不支持跨網，因此不適合大規模部署。
• UDP：不建議使用，除非內核不支持Vxlan 或者Debugg時候使用，已廢棄。
• Vxlan : Vxlan 封裝，Flannel 使用Vxlan 技術為各節點創建一個可以互通的 Pod 網絡，使用的端口為 Udp 8472(需要開放該端口，如公有云 AWS 等)。

Calico插件

Calico支持3種路由模式：

• Direct: 路由轉發，報文不做封裝。
• Ip-In-Ip:Calico 默認的路由模式,數據面采用Ip封裝。
• Vxlan：vxlan 封裝。

本文主要介紹Direct模式，采用軟路由建立BGP 宣告容器網段,使得全網所有的Node和網絡設備都有到彼此的路由的信息，然后直接通過underlay 轉發。Calico實現的總體結構如下：

數據通信的流程為：數據包先從veth設備對另一口發出，到達宿主機上的Cali開頭的虛擬網卡上，到達這一頭也就到達了宿主機上的網絡協議棧，然后查詢路由表轉發;因為本機通過Bird 和RR 建立Bgp 鄰居關系，會將本地的容器地址發送到RR 從而反射到網絡其它節點，同樣，其它節點的網絡地址也會傳送到本地，然后由Felix 進程進行管理并下發到路由表中，報文匹配路由規則后正常進行轉發即可。至于更為復雜的Iptables規則，因篇幅有限，本次暫不做解析。

4、集群內Service Cluster IP和外部訪問

Serice 和外部通信場景實現涉及較多iptables 轉發原理，簡單介紹如下：

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

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

NodePort：Service通過Cluster節點的靜態端口對外提供服務，外部可以通過:訪問Service。

LoadBalancer：Service利用Cloud Provider提供的Load Balancer對外提供服務，Cloud Provider負責將Load Balancer 的流量導向Service。