![4.16頭條 頭圖.jpeg](https://ucc.alicdn.com/pic/developer-ecology/2d5e40aef6b945118f6032aa9e75bafe.jpeg)

作者 | 溪恆  阿里雲技術專家

直播完整影片回顧：[https://www.bilibili.com/video/BV1nC4y1x7mt/](https://www.bilibili.com/video/BV1nC4y1x7mt/)

**關注“阿里巴巴雲原生”公眾號，後臺回覆 “416” 即可下載 PPT。**

4 月 16 日，我們發起了第 2 期 SIG Cloud-Provider-Alibaba 網研會直播。本次直播主要介紹了阿里雲在雲原生環境中如何設計和構建高效能雲原生容器網路。本文彙集了此次直播完整影片回顧及資料下載，並整理了直播過程中收集的問題和解答，希望能夠對大家有所幫助~

**本文彙集了此次直播完整影片回顧及資料下載，並整理了直播過程中收集的問題和解答，希望能夠對大家有所幫助~**

![1.png](https://ucc.alicdn.com/pic/developer-ecology/be58c74f6b484b6ab10c8d4062dc6936.png)

# 前言

首先，給大家介紹一下 Cloud Provider SIG， Cloud Provider SIG 是 Kubernetes 的雲廠商興趣小組，致力於讓 Kubernetes 的生態系統往廠商中立的方向演進，他會負責協調不同廠商儘可能以統一的標準來滿足開發者的需求。阿里雲作為國內首個加入 Cloud Provider SIG 的雲廠商也在推動 Kubernetes 的進一步標準化，並進一步和橫向雲廠商如 AWS、Google、Azure 進行技術協同，最佳化雲和 Kubernetes 連線，並統一不同元件的模組化和標準化協議。非常期待你與我們一同共建。

第 1 期網研會回顧：[Kubernetes SIG-Cloud-Provider-Alibaba 首次網研會（含 PPT 下載）](http://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247489370&idx=1&sn=a0ada070f012549fbfb4719ca1e43f78&chksm=fae51c95cd929583398619213f4b969db193f3bc1cbbd3ff6981d8845af5a98d23c6f0c58274&scene=21#wechat_redirect)

隨著雲原生計算的普及，越來越多的應用負載都部署在 Kubernetes 之上，Kubernetes 已成為雲原生計算的基石，成為使用者和雲端計算新的互動介面。而網路作為應用的最基礎的依賴之一，在應用雲原生化中是必不可少的基礎元件，也是很多開發者在雲原生化時最擔心的地方，面臨很多問題，例如容器網路跟原有機器網路不在一個平面，容器的 Overlay 容器網路帶來了封包的效能損失，Kubernetes 的負載均衡和服務發現的可擴充套件性不足等等。那麼怎樣才能構建叢集容器網路呢？

本次分享將會介紹阿里雲在雲原生環境中如何設計和構建高效能雲原生容器網路。

今天的分享將從 3 個方面進行：

- Kubernetes 容器網路概述
- 構建高效能雲原生 CNI 網路
- 增強網路的擴充套件性和效能

# Kubernetes 容器網路概述
首先我們會介紹下 Kubernetes 容器網路的基礎概念，包括：

- Pod 網路連通性(CNI)
- Kubernetes 負載均衡(Service)
- Kubernetes 服務發現(Coredns)

## Pod 網路連通性（CNI）

如下所示是 Kubernetes Pod 網路示意圖：

![2.png](https://ucc.alicdn.com/pic/developer-ecology/8e666810a95b47b4aad2f5c81df33668.png)

首先我們會介紹 Pod 網路的連通性，這裡就是我們常說的 CNI 網路，主要包含了以下內容：

- Pod 有自己獨立的網路空間和 IP 地址。不同 Pod 的應用可以監聽同樣的埠而不衝突；
- Pod 可以透過各自的 IP 地址互相訪問。叢集中 Pod 可以透過它獨立的 IP 地址訪問其它網路：Pod 和 Pod 的聯通；Pod 與 Node 的聯通；Pod 與外部網路連通。

而實現這些網路的能力，需要地址分配和網路打通，通常是由網路外掛(CNI)來負責實現的。

### 什麼是 CNI

CNI 外掛即 Container Network Interface，是 K8s 配置容器網路的 API 介面。CNI 外掛就是實現了這個 API 的一系列網路外掛，例如我們常見的有 Terway,Flannel, Calico 等等。

![3.png](https://ucc.alicdn.com/pic/developer-ecology/ee27a7407b8241f3b74b2a252db287d6.png)

在我們建立 Pod 時：

1. Kubelet 會首先從 ApiServer 監聽到 Pod 的建立，會建立 Pod 的沙箱；
1. 然後透過 CNI 介面呼叫 CNI 的外掛去配置容器的網路；
1. CNI 會配置 Pod 的網路空間，以及打通不同 Pod 之間的網路訪問。

### 如何打通的網路？

通常 Pod 跟宿主機網路不在一個平面，要如何打通 Pod 之間通訊呢？一般實現 Pod 之間聯通的方案有兩種：

- 封包方式：容器之間的通訊報文封裝成宿主機之間通訊的報文；
- 路由方式：容器之間的通訊報文由路由錶轉發到對應的節點上。

![4.png](https://ucc.alicdn.com/pic/developer-ecology/7cb05add473645ffb6527be66c0e77a0.png)
![5.png](https://ucc.alicdn.com/pic/developer-ecology/066f17ef677d43ae9fc5beab3b1a8b9c.png)

## Kubernetes 網路負載均衡(Service)

為什麼需要 Kubernetes Service？原因如下：

- Pod 生命週期短暫，IP 地址隨時變化，需要固定的訪問方式；
- Deployment 等的一組 Pod 組需要統一訪問入口和做負載均衡。

### Kubernetes Service

![6.png](https://ucc.alicdn.com/pic/developer-ecology/55984b331dda475387c5a663f25c7cc1.png)

- Kubernetes Service 物件建立會分配一個相對固定的 Service IP 地址；
- 透過 labelSelector 選擇到一組 Pod，將這個 Service IP 地址和埠負載均衡到這一組 Pod IP 和埠上；
- 從而實現一組 Pod 固定的訪問入口，並對這一組 Pod 做負載均衡。

### Kubernetes LoadBalancer Service

![7.png](https://ucc.alicdn.com/pic/developer-ecology/e1484f86be7c492887e7f08cca7262c2.png)

### Kubernetes 服務發現(DNS)

- 雖然 Service 固定了 IP 訪問方式，但 Service 的 IP 在不同的 namespace 或者叢集中是不同的，如何統一？
- 叢集的 Coredns 會將 Service 名自動轉換成對應的 Service 的 IP 地址，來實現不同部署環境中同樣的訪問入口。

![8.png](https://ucc.alicdn.com/pic/developer-ecology/e5257d39f10c48a789995eee1db8f92d.png)

# 構建高效能雲原生的 CNI 網路

## 什麼是雲原生容器網路？

雲上 IaaS 層網路虛擬化，在容器中再做一層網路虛擬化帶來的效能損失比較大。

雲原生容器網路是直接使用雲上原生雲資源配置容器網路：

- 容器和節點同等網路平面，同等網路地位；
- Pod 網路可以和雲產品無縫整合；
- 不需要封包和路由，網路效能和虛機幾乎一致。

![9.png](https://ucc.alicdn.com/pic/developer-ecology/71728c98b96640499d66220079e31610.png)

在 CNI 呼叫中呼叫雲網路 OpenAPI 完成網路資源分配：

- 網路資源一般是彈性網路卡，彈性網路卡輔助 IP 等，繫結到 Pod 所在的節點上；
- 網路資源分配出來之後 CNI 外掛在宿主機中將資源配置到 Pod 的沙箱中。

![10.png](https://ucc.alicdn.com/pic/developer-ecology/88631abd3a304a8995a03ea45d482aac.png)

由於容器的網路直接成為了 VPC 中的一等公民，所以使用雲原生容器網路會有這些優勢：

- Pod 和虛擬機器同一層網路，便於業務雲原生化遷移；
- 不依賴封包或者路由表，分配給 Pod 的網路裝置本身可以用來通訊；
- 叢集節點規模不受路由表或者封包的 FDB 轉發表等 Quota 限制；
- 不需要額外為 Pod 規劃 Overlay 的網段，多個叢集Pod之間只要安全組放開就可以互相通訊；
- 可以直接把 Pod 掛到 LoadBalancer 後端，無需節點上埠再做一層轉發；
- NAT 閘道器可以對 Pod 做 SNAT，無需節點上對容器網段做 SNAT：Pod 訪問 VPC 內資源，所帶的源 IP 都是 PodIP，便於審計；Pod 訪問外部網路不依賴 conntrack SNAT，失敗率降低。

## 如何利用雲原生資源構建容器網路？

IaaS 層網路資源（以阿里云為例）：

- 彈性網路卡（ENI）。 IaaS 層虛擬化出來的虛擬網路卡，可動態分配和繫結到虛擬機器上；一般能繫結數量有限，受限於 PCI-E 的限制；
- 彈性網路卡輔助 IP。彈性網路卡上通常可以繫結多個 VPC 的 IP 地址，為輔助 IP；一個彈性網路卡可以繫結數十個輔助 IP 地址，限制較小。

利用彈性網路卡或者彈性網路卡輔助 IP 分配給 Pod 來實現雲原生容器網路：

![11.png](https://ucc.alicdn.com/pic/developer-ecology/ede81fefda61457ca252cccb60c66622.png)

### 容器網路資源管理

如何解決雲資源跟容器快速擴縮容的差距：

- 容器的啟動速度是秒級的， 而 IaaS 層操作和呼叫一般在 10s 的級別；
- 容器擴縮容操作頻繁，雲產品 OpenAPI 通常有嚴格的呼叫限流。

Terway 透過內建資源池來緩衝資源加速啟動：

- 資源池中記錄分配的正在使用和空閒的資源；
- Pod釋放後資源會保留在資源池中供下次快速啟動；
- 資源池有最低水位和最高水位。空閒資源低於最低水位呼叫 API 補充資源，預熱資源減緩峰值 Pod 建立對 API 的呼叫；空閒資源高於最高水位呼叫 API 釋放資源。

![12.png](https://ucc.alicdn.com/pic/developer-ecology/caf1d53e21f74426bf39d28fd8676a6b.png)

對並行的 Pod 網路配置呼叫批次申請資源：

![13.png](https://ucc.alicdn.com/pic/developer-ecology/e5d356da63e645d4ad8fbac5d656f61f.png)

除此之外還有很多資源管理策略，例如：如何選擇 Pod 要用的虛擬交換機，保證 IP 充裕？如何平衡每個節點上的網路卡的佇列和中斷數，保證爭搶最少？

可參考 Terway 文件或程式碼：[https://github.com/AliyunContainerService/terway](https://github.com/AliyunContainerService/terway)。

### 網路如何打通

**Pod 獨佔彈性網路卡模式：**

它的在CNI的實現方式是：

1. 透過 Terway 資源管理將彈性網路卡繫結 Pod 所在 Node；
1. Terway CNI 將網路卡直接移入到 Pod 網路空間；
1. Terway CNI 為其網路卡配置 IP 和路由等網路配置。

![14.png](https://ucc.alicdn.com/pic/developer-ecology/fb64e417eccc437490bd80ac71309631.png)

這種方式的特點和優勢是：

- Pod 網路完全不經過宿主機網路棧
- 效能和 ECS 機器一致，無損耗
- Pod 中為彈性網路卡，可以使用 DPDK 等加速應用

**Pod 共享彈性網路卡模式：**

它的在CNI的實現方式是：

1. Terway 資源管理器根據申請的 IP 數量和現有 ENI上IP 來判斷申請 ENI 還是輔助 IP 地址
1. Terway CNI 在 ENI 上建立 IPVLAN 子介面
1. 將 IPVLAN 子介面放入到 Pod 網路空間
1. 配置 Pod 網路空間的 IP 和路由資訊

![15.png](https://ucc.alicdn.com/pic/developer-ecology/4e8d3c0753294d6f933c8c01056fee26.png)

這種方式的特點和優勢是：

- IPVLAN 網路僅部分經過網路棧，不走 iptables、路由表，損耗極低
- 一個彈性網路卡一般支援 10~20 個輔助 IP，不擔心部署密度

### 效能對比

![16.png](https://ucc.alicdn.com/pic/developer-ecology/d3511253fa034bb08dc173c07dbaeac9.png)

- TCP_RR、UDP、PPS、頻寬和延時都優於通用的 Flannel Vxlan 的 Overlay 網路；
- 獨佔 ENI 模式可以跑滿機器的網路資源 PPS 和頻寬無損失，適合於高效能運算和遊戲場景。

# 增強 Kubernetes 網路擴充套件性和效能

## Kubernetes Service 效能和擴充套件性問題

預設的 Kubernetes 的 Service 實現 kube-proxy，它是使用了 iptables 去配置 Service IP 和負載均衡：

![17.png](https://ucc.alicdn.com/pic/developer-ecology/249401fed58a4b868c293c6c5ce0d12a.png)

如上圖所示：

- 負載均衡過程的 iptables 鏈路長，導致網路延時顯著增加，就算是 ipvs 模式也是繞不開 iptables 的呼叫；
- 擴充套件性差。iptables 規則同步是全量刷的，Service 和 Pod 數量多了，一次規則同步都得接近 1s；Service 和 Pod 數量多了之後，資料鏈路效能大幅降低。

![18.png](https://ucc.alicdn.com/pic/developer-ecology/94749e0cd1704bc0a78eda08f61a4ea8.png)

### NetworkPolicy 效能和擴充套件性問題

NetworkPolicy 是 Kubernetes 控制 Pod 和 Pod 間是否允許通訊的規則。目前主流的 NetworkPolicy 實現基於 iptables 實現，同樣有 iptables 的擴充套件性問題：

- iptables 線性匹配，效能不高, Scale 能力差
- iptables 線性更新，更新速度慢

### 使用 eBPF 加速 Service 和 NetworkPolicy 擴充套件性

關於 eBPF 的介紹如下:

- Linux 在最近版本提供的可程式設計介面
- 透過 tc-ebpf 將 ebpf 程式注入到網路卡中
- 用於大幅降低網路鏈路的長度和複雜度

![19.png](https://ucc.alicdn.com/pic/developer-ecology/e3491fa99942470cbdf4f82131955c2d.png)

如上圖所示，使用 tc 工具注入 eBPF 程式到 Pod 的網路卡上，可以直接將 Service 和 NetworkPolicy 在網路卡中解決，然後直接轉發到彈性網路卡，大幅降低網路複雜度：

- 每個節點上執行 eBPF Agent，監聽 Service 和 NetworkPolicy，配置容器網路卡的 Ingress 和 Egress 規則；
- 在 Egress 的 eBPF 程式中，判斷訪問 k8s Service IP 的請求直接負載均衡到後端 Endpoint；
- 在 Ingress 的 eBPF 程式中，根據 NetworkPolicy 規則計算源 IP 決定是否放行。

![20.png](https://ucc.alicdn.com/pic/developer-ecology/92e047f91cb54869927fc10f4f2b3706.png)

PS：我們使用 Cilium 作為節點上的 BPF-agent 去配置容器網路卡的 BPF 規則，已貢獻 Terway 相關適配：[https://github.com/cilium/cilium/pull/10251](https://github.com/cilium/cilium/pull/10251)

### 效能對比

- 透過 eBPF 對鏈路的簡化，效能有明顯提升，相對 iptables 提升 32%, 相對 ipvs 提升 62%；
- 透過程式設計的 eBPF 的形式，讓 Service 數量增加到 5000 時也幾乎沒有效能損耗，而 iptables 在 Service 增加到 5000 時效能損失了 61%。

![21.png](https://ucc.alicdn.com/pic/developer-ecology/b943d69a13a342babea7dabfe8d3acfc.png)

## Kubernetes Coredns 效能和擴充套件性問題

![22.png](https://ucc.alicdn.com/pic/developer-ecology/e6811950b6ba4e42a03638d4649b8f04.png)

Kubernetes Pod 解析 DNS 域名會 search 很多次，例如上圖 Pod 中 DNS 配置，當它請求 aliyun.com，會依次解析:

- aliyun.com.kube-system.svc.cluster.local  -> NXDOMAIN
- aliyun.com.svc.cluster.local -> NXDOMAIN
- aliyun.com.cluster.local -> NXDOMAIN
- aliyun.com -> 1.1.1.1

Coredns 是中心化部署在某一個節點上的，Pod 訪問 Coredns 解析經過鏈路過長，又是 UDP 協議，導致失敗率高。

### 使用 AutoPath 大幅降低 Pod DNS 的查詢量
由客戶端 Search 變成服務端 Search：

![23.png](https://ucc.alicdn.com/pic/developer-ecology/96bf7a533b6a4b389687d7260c2d6a57.png)

當 Pod 請求 Coredns 時解析域名：

- Coredns 會透過源 IP 地址查詢到 Pod 的資訊
- 然後根據 Pod 的 Namespace 資訊，匹配到它真正想訪問的是哪個服務直接返回
- 客戶端請求從 4 個直接減少到 1 個，降低了 75% 的 Coredns 請求，從而讓失敗率降低

### 在每個節點上使用 node-local-dns

![24.png](https://ucc.alicdn.com/pic/developer-ecology/720f88d80eea4bdc803e1830aa87db5e.png)

- 攔截 Pod 的 DNS 查詢的請求
- 將外部域名分流，外部域名請求不再請求中心 Coredns
- 中間鏈路使用更穩定的 TCP 解析
- 節點級別快取 DNS 解析結果，較少請求中信 Coredns

### ExternalDNS 直接使用阿里雲的域名解析服務

- 雲原生的 DNS 解析，Pod 直接請求雲服務 PrivateZone 中的自定義 DNS 能力
- 由 ExternalDNS 監聽到服務和 Pod 建立後配置 PrivateZone 中的域名解析
- 和原生的 ECS 解析同樣的 DNS 解析效能

![25.png](https://ucc.alicdn.com/pic/developer-ecology/e6b1940c8c044f04b0130486274343d4.png)

# 總結

以上就是阿里雲的高效能雲原生的容器網路設計和構建過程，隨著雲原生的不斷髮展，會有越來越多型別的應用負載執行在 K8s 上，同時也會有更多的雲服務會融入到容器場景之中。我們相信以後在高效能的雲原生容器網路中會孵化出更多的功能和應用場景。

歡迎有興趣的同學一起參與共建！

- 專案地址: [https://github.com/AliyunContainerService/terway](https://github.com/AliyunContainerService/terway)
- 釘釘掃碼加入交流群：

![26.jpeg](https://ucc.alicdn.com/pic/developer-ecology/23d22fabdf8a4f359de8ac03c8a52503.jpeg)

# Q & A

**Q1：**建立 pod netns 的時候, 是使用 veth pair 連線 pod netns 和 host 的嗎?
**A1：**詳見下方內容。

- 共享 ENI 模式：在 3.10 的核心中，為了相容性，我們使用 veth pair 打通的 namespace，而在 4.x 的核心中，比如阿里雲上我們使用的 aliyunlinux2，是 4.19 的核心，我們採用的是 IPVlan 打通的 namespace；

- 獨享 ENI 模式：直接把 ENI 挪到 Pod 的 namespace 中，不需要打通 host 和 pod 的空間。

**Q2：**Pod IP 不固定怎麼做安全審計？
**A2：**詳見下方內容。

- Pod 在其宣告週期中 IP 是不變的，可以在 K8s 的事件中找到這個 IP 地址在某個事件分配給了哪個 Pod 做對照；

- 在 Terway 的 NetworkPolicy 的實現中，是透過 label 的方式標識 Pod 的，當 Pod 重建後監控到會動態更新 label 對應 Pod 的 IP 地址；

- 另外 Terway 配置給 Pod 的 IP 是相對固定的，比如在某一個節點更新 Statefulset 應用時，Terway 會在之前的 IP 釋放時為其保留一段時間供其再次啟動時快速使用起來，更新過程中 IP 就不會變化了。

**Q3：**ipvlan 對核心要求比較高吧？
**A3：**是的，在阿里雲上，我們可以使用 aliyunlinux2 的 4.19 的核心。對於低核心，Terway 也是支援 veth pair+ 策略路由方式來共享 ENI 上的輔助 IP，只是效能會低一些。

**Q4：**在 pod 內啟動 ebpf, 會不會影響 pod 啟動的速度? pod 內的 ebpf 部署時間估計是多少?
**A4：**ebpf 的程式程式碼不會太大，目前看整個部署時間增加在百毫秒的級別。

**Q5：**是否支援 IPV6，實現上遇到了什麼問題嗎？核心或 kube-proxy 程式碼問題？
**A5：**目前支援透過 IPV6 的 LoadBalancer 暴露，但實現還是在 LoadBalancer 中做 6to4 轉換。目前 Pod 還未支援 IPV6，K8s 從 1.16 中 kube-proxy 等開始支援 IPV6，我們也在積極跟進，計劃今年會和阿里雲 IaaS 一起實現原生的 Pod IPv4/IPv6 雙棧。

**Q6：**每次請求 coredns 解析，都去根據源 ip 去獲取直接訪問的服務，是呼叫 K8s  api 獲取嗎？會不會增加 api 的壓力?
**A6：**不會的，那裡那樣畫是為了讓結構更易於理解，實際上 Coredns 的 AutoPath 會透過 watch&list 的機制去從 ApiServer 那裡監聽 Pod 和 Svc 的變化，然後更新本地的快取。

**Q7：**K8s 的 Service 請求到一組 pod，這個過程是輪詢的嗎？請求到每個 pod 的機率是一樣的嗎？
**A7：**對，機率是一樣的，可以理解為 LB 領域的 roundrobin 演算法。

**Q8：**ipvlan 和 ebpf 好像是高核心才支援的，是不是對宿主機核心有要求？
**A8：**是的，在阿里雲上，我們可以使用 aliyunlinux2 的 4.19 的核心。對於低核心，Terway 也是支援 veth pair + 策略路由方式來共享 ENI 上的輔助 IP，只是效能會低一些。

**Q9：**cilium 是如何管理 ip 的呢，或者說分配 ip？類似其他的 cni 外掛管理 ip pool 嗎？
**A9：**cilium 本身有兩種分配 IP 的辦法：host-local：就是每個節點分段，然後順序分配；另外一種是 CRD-backend，可以讓 IPAM 外掛自己實現分配。Terway 中的 cilium 只會做網路策略和 Service 的劫持和負載，不會做 IP 分配和配置。

**Q10：**cilium 應該不是注入 bpf 到容器的 veth，而是注入到 host 端的 veth？你們做了什麼修改嗎？
**A10：**是的，cilium 是修改的容器對側的 veth，我們經過測試發現 IPvlan 的效能優於 veth，Terway 中是使用 IPvlan 做的高效能網路，是不存在對側 veth 的。我們適配的修改請參考：[https://github.com/cilium/cilium/pull/10251](https://github.com/cilium/cilium/pull/10251)， 另外 Terway 使用 Cilium 只會做 NetworkPolicy 和 Service 的劫持和負載。

**Q11：**使用 terway 外掛後， pod 是如何訪問 service 的 clusterip 的？
**A11：**使用內建在 Pod 網路卡上的 ebpf 程式直接將 serviceIP 負載到後端的 pod。

**Q12：**能聊下阿里雲對 service mesh 這塊有什麼規劃嗎？
**A12：**阿里雲目前已經產品化了 ASM 的 Service Mesh 產品，後面的發展會在易用性、效能以及全球跨地域雲邊端一體化連線等方向。

**Q13：**和 node 的網路打通後，如果一個 pod 的 ip 被複用，之前的 arp 快取應該會有影響吧？同時出現節點級別的故障，是否會有 IP 衝突？
**A13：**首先雲上的網路不會存在 arp 的問題，一般 IaaS 層的轉發採用 3 層的轉發，如果雲下自己使用 IPvlan也不存在這個問題，使用 Macvlan 的話會有 arp 快取的影響，一般來說可以採用 macnat 的方式（ebtables,ebpf 都可以實現哈）。是否存在 IP 衝突是要看 IP 管理策略，在目前的 Terway 方案中 IPAM 直接呼叫 IaaS 的IPAM，是不存在這個問題的，自己線下搭建得考慮 DHCP 策略或靜態分配 IP 地址去規避。

**Q14：**“透過 eBPF 對鏈路的簡化，效能有明顯提升，相對 iptables 提升 32%, 相對 ipvs 提升 62%；”為什麼對 ipvs 效能的提升更明顯？如果主要是對 iptables 的線性匹配和更新最佳化的話？
**A14：**這裡的這個對比是針對只有一個 Service 的對比，是主要看鏈路簡化的影響。iptables 模式是 nat 表進行的 DNAT，是隻有 forward 流程，而 ipvs 是會經過 INPUT 和 OUTPUT 的，所以在單個服務的情況下 iptables 可能還會更好一些，但是 iptables 的線性匹配會讓服務數量很多時效能下降明顯。比如 5000 service 時就 ipvs 更好啦 XD：

![27.png](https://ucc.alicdn.com/pic/developer-ecology/04c6b58031494d30beafe60f42accf19.png)

**Q15：**如果沒有用這套網路方案，又覺得 service 大規模使用影響效能，有什麼好的方案嗎？
**A15：**kube-proxy ipvs 模式的效能在大規模中損失還好，但其實整體引入了過長的鏈路，所以延時會增加一些。

> “[阿里巴巴雲原生](https://mp.weixin.qq.com/s/e4Ph3scexAZKGHA8Yds3rQ)關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的公眾號。”

在生產環境中，阿里雲如何構建高效能雲原生容器網路？（含 PPT 下載）

相關文章