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

作者 | 鄭超

> **導讀**：OpenYurt 是阿里巴巴開源的雲邊協同一體化架構，與同類開源方案相比，OpenYurt 擁有可實現邊緣計算全場景覆蓋的能力。在[之前的一篇文章](https://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247491404&idx=1&sn=87cfc565c8999b87c4df72dc67f79323&scene=21#wechat_redirect)中，我們介紹了 OpenYurt 是如何在弱網和斷網場景下實現邊緣自治的。本文作為 OpenYurt 系列文章的第四篇，我們將著重介紹 OpenYurt 的另一個核心能力——雲邊通訊，以及相關元件 Yurttunnel。

# 使用場景

在應用的部署和運維過程中，使用者常常需要獲取應用的日誌，或直接登入到應用的執行環境中進行除錯。在 Kubernetes 環境中，我們通常使用 kubectl log，kubectl exec 等指令來實現這些需求。如下圖所示，在 kubectl 請求鏈路上， kubelet 將扮演伺服器端，負責處理由 kube-apiserver(KAS) 轉發來的請求，這就要求 **KAS 和 kubelet 之間需要存在一條網路通路，允許 KAS 主動訪問 kubelet**。

![1.png](https://ucc.alicdn.com/pic/developer-ecology/c3edece3959f474082d6e56015982db9.png)
圖一：kubectl 執行流程

然而，在邊緣計算場景中，邊緣節點常位於本地專有網路中，這雖然保證了邊緣節點的安全，但也造成位於雲端管控節點的 KAS 無法直接訪問位於邊緣節點的 kubelet。因此，為了支援透過雲端節點對邊緣端應用進行運維操作，我們必須在雲、邊之間建立反向運維通道。

# 反向通道

Yurttunnel 是 OpenYurt 近期開源的一個重要元件，用來解決雲邊通訊問題。反向通道是解決跨網路通訊的一種常見方式，而 Yurttunnel 的本質就是一個反向通道。一個邊緣叢集下屬的節點常位於不同的 network region 中，而位於同一個 region 內的節點之間是可以相互通訊的，因此在設定反向通道時，我們只需保證在每個 region 內設定一個與 proxy server 相連的 agent 即可（如下圖所示）。具體包括以下幾個步驟：

- 在管控元件所在網路內，部署 proxy server。
- proxy server 對外開放一個公網可以訪問的 IP。
- 在每個 region 部署個 agent，並透過 server 的公網 IP 與 server 建立長連線。
- 管控元件對邊緣節點的訪問請求都將轉發致 proxy server。
- proxy server 再將請求透過對應的長連線發往目標節點。

![2.png](https://ucc.alicdn.com/pic/developer-ecology/3267ad250db14bd499c89148a141151f.png)
圖二

在 Yurttunnel 中，我們選擇使用上游專案 [apiserver-network-proxy(ANP)](https://github.com/kubernetes-sigs/apiserver-network-proxy) 來實現 server 和 agent 間的通訊。ANP 是基於 kubernetes 1.16 Alpha 新功能 [EgressSelector](https://github.com/kubernetes/kubernetes/blob/master/staging/src/k8s.io/apiserver/pkg/server/egressselector/egress_selector.go) 開發，意在實現 Kubernetes 叢集元件的跨 intranet 通訊（例如，master 位於管控 VPC，而 kubelet 等其他元件位於使用者 VPC）。

讀者可能會好奇，既然 OpenYurt 是基於 [ACK@Edge](mailto:ACK@EDGE) 開源的，而在生產環境中， [ACK@Edge](mailto:ACK@Edge) 的雲邊運維通道使用的是自研元件 tunnellib，那為什麼在開源版本里我們要選用一個新的元件呢？ 這裡不得不再次提到 **OpenYurt 的核心設計理念 “Extend upstream Kubernetes to Edge”**。

誠然，tunnellib 經過了複雜線上環境的考驗，元件效能穩定，但我們更希望能與上游保持最大的技術公約數，讓 OpenYurt 的使用者體驗更接近原生 Kubernetes ；同時，在 [ACK@Edge](mailto:ACK@Edge) 的開發和運維過程中，我們發現，邊緣叢集的許多需求也同樣存在於其他場景中（例如，大多數雲廠商也需要實現節點跨網路通訊），並且運維通道的傳輸效率也能進一步最佳化（4.5章將詳述最佳化過程）。因此，秉承開放分享、平等普惠的開源精神，我們希望能將開發和運維過程中積累的的寶貴經驗在上游社群與更多的開發者分享。

# ANP 並非開箱即用

然而 ANP 專案仍處於起步階段，功能尚未完善，許多問題仍有待解決。我們從實踐中發現的主要問題包括：

- **如何轉發雲端節點的請求** -- 反向通道正常工作的一個前提是，管控節點發往邊緣節點的請求必須先經過 proxy server。對於 Kubernetes 1.16 + 版本，KAS 能借由 EgressSelector 將發往節點的請求先發往指定的 proxy server。但對於 1.16 以前的版本，KAS 及其他管控元件（Prometheus 和 metrics server）只能直接訪問節點，而不能繞道 proxy server。可以預見的是，部分使用者在短期內，仍將使用 1.16 以前的版本，並且 Prometheus 和 metrics server 等管控元件在短期內也沒有支援 EgressSelector 的計劃。因此，我們要解決的第一個問題是，**如何將管控元件發往節點的請求轉發致 proxy server**。

- **如何確保 server 副本覆蓋所有的 region** -- 在生產環境中，一個邊緣叢集常常包含上萬個節點，並同時服務上百名使用者，如果一個叢集只有一個 proxy server， 那麼，一旦 proxy server 出現故障，所有使用者都將無法對位於邊緣節點上的 pod 進行操作。因此，我們必須同時部署多個 proxy server 副本以保證叢集高可用。同時，proxy server 的工作負荷將隨著訪問流量的增大而增大，使用者的訪問延時也勢必增加。因此在部署 proxy server 時，我們還需考慮如何對 proxy server 進行水平擴充，以應對高併發場景。一個應對單點故障和高併發場景的經典解決方案是，部署多個 proxy server 副本，並使用負載均衡進行流量分發。然而在 OpenYurt 場景下，對於 KAS 發來的任意請求，LoadBalancer (LB) 會轉發給哪個 server 副本是不可控的，因此，需要解決的第二個問題是，**如何保證每個 server 副本都能與所有的 agent 建立連線**。

- **如何將請求轉發給正確的 agent** -- 在執行過程中，proxy server 在收到請求後，需根據請求的 destination IP，將請求轉發至位於對應 network region 內的 agent。然而，ANP目前的實現，假設所有的節點都位於一個網路空間內， server 會隨機挑選一個 agent 轉發請求。因此，我們需要解決的第三個問題是，**如何將請求正確地轉發給指定的 agent**。

- **如何解除元件對節點證書的依賴** -- 在執行時，我們需要為 server 提供一套 TLS 證書，以實現 server 與 KAS，server 與 agent 間的安全通訊。同時，我們也需要為 agent 準備一套 TLS client 證書，用以建立 agent 和 server 間的 gRPC 通道。ANP 目前的實現，要求 server 必須和 KAS 部署在同一個節點上，並且在啟動時掛載節點 volume 共享 KAS tls 證書。同樣，agent 也需要在啟動時掛載 volume 共享 kubelet tls 證書。這無形中降低了部署的靈活性，造成了組建對節點證書的強依賴，在有些情況下，使用者可能希望將 server 部署在非 KAS 所在節點上。因此，另一個需要關注的問題是，**如何解除元件對節點證書的依賴**。

- **如何縮小 Tunnel 頻寬** -- ANP 的一個核心設計思想，是使用 gRPC 封裝 KAS 所有對外 HTTP 請求。這裡選擇 gRPC，主要是看重其對流（stream）的支援和清晰的介面規範，此外，強型別的客戶端和伺服器端可以有效減少執行時錯誤，提高系統穩定性。然而，我們也發現，相較於直接使用 TCP 協議，採用 ANP 也會帶來額外的開銷增加頻寬。從產品層面考慮，Tunnel 流量走的是公網，頻寬的增加也意味著使用者成本的增加。因此，一個非常重要的問題是，**在提高系統穩定性的同時，我們是否也能縮小頻寬**？

# Yurttunnel 設計解析

## 1. 制定 DNAT 規則轉發雲端節點的請求

如前文所述，ANP 是基於上游新功能 EgressSelector 開發的，該功能允許使用者在啟動 KAS 時透過傳入 egress configuration 來要求 KAS 將 egress 請求轉發到指定的 proxy server。但由於我們需要兼顧新老版本的 Kubernetes 叢集，並且考慮到，其他管控元件（Prometheus 和 metric server）並不支援 EgressSelector 特性，我們需要保證在無法使用 EgressSelector 的情況下也能將 KAS egress 請求轉發致 proxy server。為此，我們在每一個雲端管控節點上都部署一個 Yurttunnel Server 副本，並在 Server 中內嵌一個新元件 Iptabel Manager。Iptable Manager 會透過在宿主機的 Iptable 中的 OUTPUT 鏈中新增 DNAT 規則，將管控元件對節點的請求轉發致 Yurttunnel Server。

同時，當啟用 EgressSelector 後，KAS 對外請求都遵循一個統一的格式，因此我們新增一個元件， ANP interceptor。ANP interceptor 會負責擷取從 master 發來的 http 請求，並將其封裝成 EgressSelector 格式。Yurttunnel 請求轉發的具體流程見圖三。

![3.png](https://ucc.alicdn.com/pic/developer-ecology/c236d6507813439b9a2d00bdc8f8a92d.png)
圖三：Yurttunnel 請求轉發流程

## 2. 動態獲取 Server 副本數

在上一節中，我們提到，我們將採用負載均衡的方式來管理 yurttunnel server，所有的 ingress 請求都會透過 LB 分發給一個 server 副本。由於我們無法預測 LB 會挑選哪個 server 副本，我們必須保證每個 server 副本都要與所有的 agent 建立連線。這裡，我們將使用 ANP 自帶的功能實現這一需求，具體流程如下：

- 在啟動 yurttunnel server 時，我們會將副本數（serverCount）傳入每個 server 副本中，並且為每個副本指定一個 server ID；

- agent 連線 LB 後，LB會隨機選擇一個 server 副本並讓其與 agent 建立長連線；

- 與此同時，server 會透過該通道向 agent 返回一個 ACK package，這個 package 中將包含 serverCount 和 serverID；

- agent 透過解析 ACK package，可以獲悉 server 副本的個數，並在本地記錄已連線的 serverID；

- 如果 agent 發現，本地連線的 server 副本數小於 serverCount，則會再次向 LB 傳送連線請求，直至本地記錄的 serverID 數與 server Count 數一致為止。

該機制雖然幫助我們實現了 server 副本的全網段覆蓋。但同時，也存在不可忽視的缺點，由於 agent 無法選擇與哪個 server 副本建立連線，因此，為了連線所有的 server 副本，agent 必須反覆訪問 LB。在這個過程中，server 由於還沒有與所有的 agent 建立連線，KAS 發來的請求可能無法轉發至對應的節點。一個潛在的解決方案是，為每個 server 副本建立一個獨立的 LB，負責與 agent 之間的連線，同時在 agent 端記錄所有 server 副本對應 LB 的資訊，這一方案能幫助 agent 快速地與所有的 server 副本建立連線。該方案的具體實現細節，目前仍在與上游社群的開發者討論中。

## 3. 為 ANP 新增代理策略

在 OpenYurt 的網路模型下，邊緣節點分佈在不同的 network region 中，隨機選擇的 agent 可能無法將請求轉發至位於其他 region 內的節點上。因此我們不得不修改 ANP server 底層代理轉發的邏輯。然而，根據長期的經驗，我們相信，proxy server 支援不同的代理策略，例如，將請求轉發至指定資料中心，region，或者指定主機，是一個較為通用的需求。經過和 ANP 社群開發者[討論](https://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247495998&idx=1&sn=0fce8d2e736f911cecf1a35d83c5bd26&chksm=fae6faf1cd9173e787c8cb1e5f704083c24497ecd64451e0eb39855164d155f6f70b05089e88&token=1794504628&lang=zh_CN)，我們決定重構 ANP 管理 agent 連線的介面，允許使用者根據需求實現新的代理策略，並計劃將該 feature 最終合入上游程式碼庫。目前重構工作仍在進行中，在 Yurttunnel 第一個開源版本中，我們暫時採用以下配置：

- 在每個邊緣節點上部署一個 agent。

- agent 在 server 處登記時，使用 agent 所在節點的 IP 作為 agentID。

- server 在轉發請求時，透過匹配請求目標 IP 和 agentID，將請求轉發至對應的 agent。

我們計劃在 OpenYurt 後續釋出 Yurt Unit（邊緣節點分割槽管控）之後，配合新增的 ANP 代理轉發策略，實現 agent 的分割槽部署，和請求的分割槽轉發。

## 4. 動態申請安全證書

為了解除 yurttunnel 元件對節點證書的依賴，我們在 yurttunnel 中新增 cert manager 組建，cert manager 會在 server 和 agent 執行後，向 KAS 提交 certificate signning request(CSR)。server 將使用申請到的證書來確保其與 KAS 和 agent 間的安全通訊，agent 會使用申請到的證書確保其與 server 間 gRPC 通道的安全。由於 agent 和 kubelet 間是透過 tcp 協議連線，因此，我們無需為 agent 和 kubelet 間的連線準備證書。

## 5. 壓縮 Tunnel 頻寬，節約成本

在 3.5 中，我們提到，使用 gRPC 封裝 Tunnel 雖然可以提高傳輸穩定性，但同時也會增加公網流量。這是否意味著穩定性和效能，我們只能二選一？透過對不同使用者場景的分析，我們發現，在大多數情況下，使用者使用運維通道是為了獲取容器日誌（即 kubectl log），而傳統日誌檔案，存在許多相同的文字資訊，因此我們推斷使用 gzip 等壓縮演算法能有效縮小頻寬。為了驗證這一假設，我們在 ANP 底層的 gRPC 庫中新增了 gzip compressor，並且對比了與使用原生 TCP 連線場景下的資料傳輸量。

我們考慮的第一個實驗場景是，分別透過 TCP 連線和 ANP 獲取同一 kubeproxy 容器的日誌，我們擷取了這一過程中 Tunnel 上雙向 package 和 bytes 總量。

![4.png](https://ucc.alicdn.com/pic/developer-ecology/6c78168342e54ae7b7ed243e22e1a00a.png)
表 1: 原生 TCP V.S. ANP (kubectl logs kube-proxy)

如表 1 所示，透過使用 ANP， 總傳輸資料量下降了 **29.93%**。

經過長時間執行，容器的日誌文字常常可以達到十幾兆，為了模擬獲取大文字日誌的場景。我們建立了一包含 10.5M systemd log（即 journalctl）的 ubuntu 容器，同樣我們分別使用原生 TCP 連線和 ANP 傳輸該日誌檔案，並測量了 Tunnel 上的資料總量。

![5.png](https://ucc.alicdn.com/pic/developer-ecology/64097eb31c9340208a29b9dce69746e2.png)
表 2: 原生 TCP V.S. ANP (large log file)

如表 2 所示，在日誌文字較大的情況下，透過使用 ANP， 總傳輸資料量下降了 **40.85%**。

由此可見，相較於原生 TCP 連線，ANP 不僅能提供更高的傳輸穩定性，還可以大幅降低公網流量。考慮到邊緣叢集動輒上萬的節點規模，新的解決方案將幫助使用者在公網流量方面節約大量開銷。

# Yurttunnel 系統架構

![6.png](https://ucc.alicdn.com/pic/developer-ecology/f0dc98f539544663aabf9d152ce26945.png)
圖四：Yurttunnel 系統架構

綜上，Yurttunnel 主要包含以下元件：

- **Yurttunnel Server** - 負責將 apiserver，prometheus，metrics server 等管控元件發往節點的請求，轉發至對應的 agent。具體包括以下子元件：
   - ANP Proxy Server - 對 ANP gRPC server 的封裝，負責管理與 Yurttunnel Agent 之間的長連線，並轉發請求。
   - Iptable Manager - 修改管控節點的 DNAT 規則，以確保管控元件的請求能被轉發至 Yurttunnel Server。
   - Cert Manager - 為 Yurttunnel Server 生成 TLS 證書。
   - Request Interceptor - 將 KAS 對節點的 HTTP 請求封裝到符合 ANP 規則的 gRPC 包裡。

- **Yurttunnel Agent **- 與 Yurttunnel Server 主動建立連線，並將 Yurttunnel Server 發來的請求轉發給 Kubelet。具體包括兩個子元件：
   - ANP Proxy Agent - 對 ANP gRPC agent 的封裝，相較於上游，我們額外加入了 gzip compressor 以壓縮資料。
   - Cert Manager - 為 Yurttunnel Agent 生成 TLS 證書。

- **Yurttunnel Server Service** - 通常是一個 SLB，負責將管控元件發來的請求分發給合適的 Yurttunnel Server 副本，保證 Yurttunnel 的高可用和負載均衡。

# 總結與展望

Yurttunnel 作為 OpenYurt 近期開源的重要元件，打通了 OpenYurt 叢集的雲邊通道，為邊緣叢集上的容器運維提供了一個統一的入口。透過對上游解決方案進行改造，Yurttunnel 不僅提供了更高的傳輸穩定性，也大幅降低了資料傳輸量。

OpenYurt 於 2020 年 5 月 29 日正式對外開源，藉助社群和廣大開發者的力量快速成長，開源僅 3 個月後就正式成為 CNCF 沙箱級別邊緣計算雲原生專案。未來，OpenYurt 將延續 “Extending your upstream Kubernetes to edge” 的核心設計理念，在選擇與上游保持最大技術公約數的同時，發揚開源分享的精神，與廣大開發者一起推進 Kubernetes 社群的進步。

OpenYurt 已入圍 “2020 年度 10 大新銳開源專案”，歡迎大家點選連結：[https://www.infoq.cn/talk/sQ7eKfv1KW1A0kUafBgv](https://www.infoq.cn/talk/sQ7eKfv1KW1A0kUafBgv)，選擇“25 號”，為 OpenYurt 加油助力！

> “[阿里巴巴雲原生](http://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247495998&idx=1&sn=0fce8d2e736f911cecf1a35d83c5bd26&chksm=fae6faf1cd9173e787c8cb1e5f704083c24497ecd64451e0eb39855164d155f6f70b05089e88&token=1794504628&lang=zh_CN#rd)關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的公眾號。”

OpenYurt 深度解讀：如何構建 Kubernetes 原生雲邊高效協同網路？

相關文章