【云駐共創】華為云云原生之Kubernetes網絡架構原理深度剖析（上）

前言

kubernetes網絡和服務的概念與使用場景主要有以下兩點：

Service概念及使用場景

Ingress概念及使用場景

本文主要介紹

Kubernetes工作負載POD之間的互通、負載均衡等網絡功能是如何實現的

kubernetes容器網絡模型，Service負載均衡機制、CNI接口的實現原理以及若干實踐案例

一、Kubernetes誕生背景

1.云原生的概念

云原生是基于分布式部署和統一運維管理的分布式云，以容器、微服務、DevOps等技術為基礎建立的一套云技術產品體系。是一種新型技術體系，是云計算未來的發展方向。

云原生應用也就是面向“云”而設計的應用，在使用云原生技術后，開發者無需考慮底層的技術實現，可以充分發揮云平臺的彈性和分布式優勢，實現快速部署、按需伸縮、不停機交付等。

云原生（CloudNative）是一個組合詞，Cloud+Native。Cloud表示應用程序位于云中，而不是傳統的數據中心；Native表示應用程序從設計之初即考慮到云的環境，原生既為云而設計，在云上以最佳姿勢運行，充分利用和發揮云平臺的彈性+分布式優勢。

2.云原生架構

云原生架構歸納為模塊化、可觀察、可部署、可測試、可替換、可處理6特質；而Pivotal最新官網對云原生概括為4個要點：DevOps+持續交付+微服務+容器。

微服務： 幾乎每個云原生的定義都包含微服務，跟微服務相對的是單體應用，微服務有理論基礎，那就是康威定律，指導服務怎么切分，很玄乎，凡是能稱為理論定律的都簡單，但明白不了，不然就太沒逼格，大概意思是組織架構決定產品形態。

微服務架構的好處就是按功能劃分之后，形成服務，服務之間解耦，內聚更強，變更更易；另一個劃分服務的技巧是依據DDD來劃分。

容器化： Docker是應用最為廣泛的容器引擎，在思科谷歌等公司的基礎設施中大量使用，是基于LXC技術搞的，容器化為微服務提供實施保障，起到應用隔離作用，K8S是容器編排系統，用于容器管理，容器間的負載均衡，谷歌搞的，Docker和K8S都采用Go編寫，都是不錯的技術。

DevOps： 這是個組合詞，Dev+Ops，就是開發和運維合體，不像開發和產品，經常刀刃相見，實際上DevOps應該還包括測試，DevOps是一個敏捷思維，是一個溝通文化，也是組織形式，為云原生提供持續交付能力。

持續交付： 持續交付是不誤時開發，不停機更新，小步快跑，反傳統瀑布式開發模型，這要求開發版本和穩定版本并存，其實需要很多流程和工具支撐。

3.Kubernetes(k8s)

Kubernetes(k8s)是云原生架構體系中不可缺少的一環，是一個全新的基于容器技術的分布式架構領先方案。

Kubernetes(k8s)是Google開源的容器集群管理系統。在Docker技術的基礎上，為容器化的應用提供部署運行、資源調度、服務發現和動態伸縮等一系列完整功能，提高了大規模容器集群管理的便捷性。

Kubernetes(k8s)是一個完備的分布式系統支撐平臺，具有完備的集群管理能力，多擴展多層次的安全防護和準入機制、多租戶應用支撐能力、透明的服務注冊和發現機制、內建智能負載均衡器、強大的故障發現和自我修復能力、服務滾動升級和在線擴容能力、可擴展的資源自動調度機制以及多粒度的資源配額管理能力。同時Kubernetes(k8s)提供完善的管理工具，涵蓋了包括開發、部署測試、運維監控在內的各個環節。

二、Kubernetes基本網絡模型剖析

1.概念理清

1.1 二層橋接 VS 三層路由

1.2 Underlay VS Overlay

1.3 物理網絡 VS 虛擬網絡

1.4 傳統網絡 VS SDN網絡

1.5 Docker網絡 VS K8S網絡

Docker 采用插件化的網絡模式，默認提供bridge、host、none、overlay、maclan和Network plugins這幾種網絡模式，運行容器時可以通過--net參數設置具體使用那一種模式。

bridge： 這是Docker默認的網絡驅動，此模式會為每一個容器分配Network Namespace和設置IP等，并將容器連接到一個虛擬網橋上。如果未指定網絡驅動，則默認使用此驅動。

host： 此網絡驅動直接使用宿主機的網絡。

none： 此驅動不構造網絡環境。采用了none網絡驅動，那么就只能使用loopback網絡設備，容器只能使用127.0.0.1的本機網絡。

overlay： 此網絡驅動可以使多個Docker daemons連接在一起，并能夠使用swarm服務之間進行通訊。也可以使用overlay網絡進行swarm服務和容器之間的通訊。

macvlan： 此網絡允許為容器指定一個MAC地址，允許容器作為網絡中的物理設備，這樣Docker daemon就可以通過MAC地址進行訪問的路由。對于希望直接連接網絡的應用，這種網絡驅動有時可能是最好的選擇。

Network plugins： 可以安裝和使用第三方的網絡插件?？梢栽贒ocker Store或第三方供應商處獲取這些插件。

在默認情況，Docker使用bridge網絡模式，bridge網絡驅動的示意圖如下，此文以bridge模式對Docker的網絡進行說明。

實際上Docker是采用NAT的方式，將容器內部的服務監聽端口與宿主機的某一個端口port進行綁定，使得宿主機外部可以將網絡報文發送至容器。

1）通過-p參數，將容器的端口映射到宿主機的隨機端口：

2）通過-d參數，以守護進程方式運行：

2）通過–net參數，指定網絡：

docker run -d -p {hostPort}:{containerPort} {images} --net={network}

K8S網絡與Docker網絡有些不同。K8S網絡需要解決下面的4個問題：

集群內：

容器與容器之間的通信

Pod和Pod之間的通信

Pod和服務之間的通信

集群外：

外部應用與服務之間的通信

2.K8S網絡模型對互通性的要求

節點node網絡互通性的要求：

節點上的容器POD可以與集群內任意節點上的容器POD進行通信，無需NAT，就能實現互相訪問

節點上的代理agent(比如:系統后臺進程、kubelet)可以與同節點上的容器POD互相訪問

對于支持容器POD的主機網絡模式運行的平臺(如:Linux)互通性的要求：

主機網絡模式的容器POD可以與集群內任意節點上的容器POD進行通信，無需NAT，就能實現互相訪問

3.K8S網絡模型

3.1 Overlay組網模型

同節點內POD二、三層直接互通

跨節點POD互通通過隧道(VXLAN/IPIP)

POD訪問宿主節點地址或集群外地址需SNAT

與底層網絡解耦，節點IP互通

隧道封裝解封裝開銷大，小包帶寬損耗可達30%+，互通性差，地址需SNAT

Flannel/VXLAN，Calico/IPIP，CCE隧道網絡

3.2 二層組網模型

容器和宿主節點屬于同一子網

宿主節點間要求二層互通(物理網絡)

扁平網絡，容器與節點具有同等互通能力

規模擴展受子網限制

要求節點網絡二層廣播域開放

橋接模式轉發性能較差

Azure CNI，Rancher扁平網絡，CCEUnderlay L2

3.3 三層組網模型

按節點掩碼長度，給每個節點分配容器子網

同節點內POD二、三層直接互通

跨節點POD互通通過本地路由表及節點網絡路由轉發

POD訪問宿主節點地址無需SNAT

無隧道開銷，互通性好

規模擴展性高

需要對接節點網絡，支持BGP協議或路由配置接口

Calico Native，CCE VPC路由

三、K8S Service負載均衡機制實現原理

1.IPTables

1.1 方案說明

利用linux內核原生Netfilter/IPTable的HOOK/Chain及Conntrack連接狀態機制，實現NAT和負載均衡

1.2 優勢

內核原生能力，經歷了長期的考驗，穩定性好(k8s1.2開始作為default方案)

易于與不同容器網絡模型集成

1.3 劣勢

線性遍歷查表機制，造成大規模規則場景下，新建連接開銷大

大規模規則刷新較慢

負載均衡算法相對少，均衡效果較差

2.IPVS

2.1 方案說明

基于內核負載均衡模塊IPVS，實現NAT和負載均衡。

2.2 優勢

專用負載均衡方案，基于IPSet/Hash查表機制，性能高(k8s1.11GA，由華為云原生容器團隊貢獻給K8S社區)

負載均衡算法豐富，均衡性好(round-robin，min connection etc)

規模擴展性好，規則數對匹配性能影響小和刷新規則快

2.3 劣勢

原始設計針對南北向邊界負載均衡，對于分布式東西向某些特殊訪問場景存在限制

仍然依賴IPTables+Conntrack實現MASQUADE(SNAT)

3.eBPF

3.1 方案說明

基于高內核版本eBPF機制

東西向采用Socket Layer LB機制實現，支持會話保持

南北向采用XDP/TCBPF實現負載均衡/NAT和狀態表

3.2 優勢

適合容器場景，轉發路徑短，最大開銷下降可達80%

3.3 劣勢

內核版本要求社區內核5.7+

缺乏大規模的商用檢驗，處于快速迭代過程，社區不斷有新patch合入

負載均衡算法待增強和豐富

3.4 典型方案

Cilium，Calico

四、華為云CCE Yangtse網絡模型

1.VPC 路由模式

1.1 方案說明

按照創建集群時設定的節點長度為節點分配容器子網

將每個節點的容器子網路由配置到VPC路由表

1.2 優勢

無隧道開銷，轉發性能與主機網絡持平

VPC內節點與容器互通無SNAT，支持源地址保持

1.3 劣勢

集群規模受限于VPC路由表規格，比如:200

互通性受限:

需要通過nodeport對接ELB后端，存在多跳損耗，負載均衡性差

訪問OBS或外網等服務需要SNAT為節點地址

2.ENI/TrunkPort

2.1 方案說明

容器網絡與VPC網絡一體化融合方案，充分利用VPC網絡的軟硬協同和分布式架構為容器提供云原生的規模擴展、極致彈性、負載均衡和安全隔離能力。

每個容器POD具有獨立的VPC子網地址，統一IPAM(節點容器、服務子網統一管理)

BMS節點支持128個VF直通網口到容器POD

虛機節點Trunkport模式ENI，最多支持創建256個VLAN子接口直通容器POD

每個POD具有獨立的安全組，支持容器粒度的網絡隔離

POD間互訪不經過節點root namespace，直通模式轉發0損耗

不再依賴節點內核，IPVS/IPTables實現Service負載均衡，不再需要kube-proxy組件，service負載均衡卸載到VPC分布式ELB

裸機容器支持POD級網絡QoS極簡組網，運維更簡單

總結

在微服務化情況下，容器數量會非常多，不利于管理和編排。kubernetes誕生得益于kubernetes網絡架構設計，使得管理容器，持續集成和容器編排問題都能很好解決。

本文介紹的內容主要有：云原生、K8S容器網絡模型原理、K8SService負載均衡實現原理、華為CCEYangtse容器網絡模型和原理。通過以上講解相信大家對Kubernetes網絡架構有所理解，對華為云CCE Yangtse網絡模型也有初步的認識，這是上半部部分，別忘了還有下半部分，還請大家多多支持。

華為云官網鏈接:

https://support.huaweicloud.com/usermanual-cce/cce_01_0249.html

https://support.huaweicloud.com/usermanual-cce/cce_01_0094.html

Kubernetes官方文檔:

https://kubernetes.io/docs/concepts/services-networking/servicel

https://kubernetes.io/docs/concepts/services-networking/ingress

本文整理自華為云社區【內容共創】活動第13期。

查看活動詳情：https://bbs.huaweicloud.com/blogs/330939

相關任務詳情：任務23.華為云云原生鉆石課程06：Kubernetes網絡架構原理深度剖析（上）

Kubernetes 云原生 容器 網絡

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。