作者 | 鄭超

導(dǎo)讀：OpenYurt 是阿里巴巴開源的云邊協(xié)同一體化架構(gòu)，與同類開源方案相比，OpenYurt 擁有可實現(xiàn)邊緣計算全場景覆蓋的能力。在之前的一篇文章中，我們介紹了 OpenYurt 是如何在弱網(wǎng)和斷網(wǎng)場景下實現(xiàn)邊緣自治的。本文作為 OpenYurt 系列文章的第四篇，我們將著重介紹 OpenYurt 的另一個核心能力——云邊通信，以及相關(guān)組件 Yurttunnel。

使用場景

在應(yīng)用的部署和運維過程中，用戶常常需要獲取應(yīng)用的日志，或直接登錄到應(yīng)用的運行環(huán)境中進行調(diào)試。在 Kubernetes 環(huán)境中，我們通常使用 kubectl log，kubectl exec 等指令來實現(xiàn)這些需求。如下圖所示，在 kubectl 請求鏈路上， kubelet 將扮演服務(wù)器端，負責(zé)處理由 kube-apiserver(KAS) 轉(zhuǎn)發(fā)來的請求，這就要求 KAS?和 kubelet 之間需要存在一條網(wǎng)絡(luò)通路，允許 KAS 主動訪問 kubelet。

圖一：kubectl 執(zhí)行流程

然而，在邊緣計算場景中，邊緣節(jié)點常位于本地專有網(wǎng)絡(luò)中，這雖然保證了邊緣節(jié)點的安全，但也造成位于云端管控節(jié)點的 KAS 無法直接訪問位于邊緣節(jié)點的 kubelet。因此，為了支持通過云端節(jié)點對邊緣端應(yīng)用進行運維操作，我們必須在云、邊之間建立反向運維通道。

反向通道

Yurttunnel 是 OpenYurt 近期開源的一個重要組件，用來解決云邊通信問題。反向通道是解決跨網(wǎng)絡(luò)通信的一種常見方式，而 Yurttunnel 的本質(zhì)就是一個反向通道。一個邊緣集群下屬的節(jié)點常位于不同的 network region 中，而位于同一個 region 內(nèi)的節(jié)點之間是可以相互通信的，因此在設(shè)置反向通道時，我們只需保證在每個 region 內(nèi)設(shè)置一個與 proxy server 相連的 agent 即可（如下圖所示）。具體包括以下幾個步驟：

• 在管控組件所在網(wǎng)絡(luò)內(nèi)，部署 proxy server。
• proxy server 對外開放一個公網(wǎng)可以訪問的 IP。
• 在每個 region 部署個 agent，并通過 server 的公網(wǎng) IP 與 server 建立長連接。
• 管控組件對邊緣節(jié)點的訪問請求都將轉(zhuǎn)發(fā)致 proxy server。
• proxy server 再將請求通過對應(yīng)的長連接發(fā)往目標節(jié)點。

圖二

在 Yurttunnel 中，我們選擇使用上游項目?apiserver-network-proxy(ANP)?來實現(xiàn) server 和 agent 間的通信。ANP 是基于 kubernetes 1.16 Alpha 新功能?EgressSelector?開發(fā)，意在實現(xiàn) Kubernetes 集群組件的跨 intranet 通信（例如，master 位于管控 VPC，而 kubelet 等其他組件位于用戶 VPC）。

讀者可能會好奇，既然 OpenYurt 是基于?ACK@Edge?開源的，而在生產(chǎn)環(huán)境中，?ACK@Edge?的云邊運維通道使用的是自研組件 tunnellib，那為什么在開源版本里我們要選用一個新的組件呢？ 這里不得不再次提到 OpenYurt 的核心設(shè)計理念 “Extend upstream Kubernetes to Edge”。

誠然，tunnellib 經(jīng)過了復(fù)雜線上環(huán)境的考驗，組件性能穩(wěn)定，但我們更希望能與上游保持最大的技術(shù)公約數(shù)，讓 OpenYurt 的用戶體驗更接近原生 Kubernetes ；同時，在?ACK@Edge?的開發(fā)和運維過程中，我們發(fā)現(xiàn)，邊緣集群的許多需求也同樣存在于其他場景中（例如，大多數(shù)云廠商也需要實現(xiàn)節(jié)點跨網(wǎng)絡(luò)通信），并且運維通道的傳輸效率也能進一步優(yōu)化（4.5章將詳述優(yōu)化過程）。因此，秉承開放分享、平等普惠的開源精神，我們希望能將開發(fā)和運維過程中積累的的寶貴經(jīng)驗在上游社區(qū)與更多的開發(fā)者分享。

ANP 并非開箱即用

然而 ANP 項目仍處于起步階段，功能尚未完善，許多問題仍有待解決。我們從實踐中發(fā)現(xiàn)的主要問題包括：

• 如何轉(zhuǎn)發(fā)云端節(jié)點的請求?–?反向通道正常工作的一個前提是，管控節(jié)點發(fā)往邊緣節(jié)點的請求必須先經(jīng)過 proxy server。對于 Kubernetes 1.16 + 版本，KAS 能借由 EgressSelector 將發(fā)往節(jié)點的請求先發(fā)往指定的 proxy server。但對于 1.16 以前的版本，KAS 及其他管控組件（Prometheus 和 metrics server）只能直接訪問節(jié)點，而不能繞道 proxy server。可以預(yù)見的是，部分用戶在短期內(nèi)，仍將使用 1.16 以前的版本，并且 Prometheus 和 metrics server 等管控組件在短期內(nèi)也沒有支持 EgressSelector 的計劃。因此，我們要解決的第一個問題是，如何將管控組件發(fā)往節(jié)點的請求轉(zhuǎn)發(fā)致 proxy server。

• 如何確保 server 副本覆蓋所有的 region?–?在生產(chǎn)環(huán)境中，一個邊緣集群常常包含上萬個節(jié)點，并同時服務(wù)上百名用戶，如果一個集群只有一個 proxy server， 那么，一旦 proxy server 出現(xiàn)故障，所有用戶都將無法對位于邊緣節(jié)點上的 pod 進行操作。因此，我們必須同時部署多個 proxy server 副本以保證集群高可用。同時，proxy server 的工作負荷將隨著訪問流量的增大而增大，用戶的訪問延時也勢必增加。因此在部署 proxy server 時，我們還需考慮如何對 proxy server 進行水平拓展，以應(yīng)對高并發(fā)場景。一個應(yīng)對單點故障和高并發(fā)場景的經(jīng)典解決方案是，部署多個 proxy server 副本，并使用負載均衡進行流量分發(fā)。然而在 OpenYurt 場景下，對于 KAS 發(fā)來的任意請求，LoadBalancer (LB) 會轉(zhuǎn)發(fā)給哪個 server 副本是不可控的，因此，需要解決的第二個問題是，如何保證每個 server 副本都能與所有的 agent 建立連接。

• 如何將請求轉(zhuǎn)發(fā)給正確的 agent –?在運行過程中，proxy server 在收到請求后，需根據(jù)請求的 destination IP，將請求轉(zhuǎn)發(fā)至位于對應(yīng) network region 內(nèi)的 agent。然而，ANP目前的實現(xiàn)，假設(shè)所有的節(jié)點都位于一個網(wǎng)絡(luò)空間內(nèi)， server 會隨機挑選一個 agent 轉(zhuǎn)發(fā)請求。因此，我們需要解決的第三個問題是，如何將請求正確地轉(zhuǎn)發(fā)給指定的 agent。

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

• 如何縮小 Tunnel 帶寬 – ANP 的一個核心設(shè)計思想，是使用 gRPC 封裝 KAS 所有對外 HTTP 請求。這里選擇 gRPC，主要是看重其對流（stream）的支持和清晰的接口規(guī)范，此外，強類型的客戶端和服務(wù)器端可以有效減少運行時錯誤，提高系統(tǒng)穩(wěn)定性。然而，我們也發(fā)現(xiàn)，相較于直接使用 TCP 協(xié)議，采用 ANP 也會帶來額外的開銷增加帶寬。從產(chǎn)品層面考慮，Tunnel 流量走的是公網(wǎng)，帶寬的增加也意味著用戶成本的增加。因此，一個非常重要的問題是，在提高系統(tǒng)穩(wěn)定性的同時，我們是否也能縮小帶寬？

Yurttunnel 設(shè)計解析

1. 制定?DNAT?規(guī)則轉(zhuǎn)發(fā)云端節(jié)點的請求

如前文所述，ANP 是基于上游新功能 EgressSelector 開發(fā)的，該功能允許用戶在啟動 KAS 時通過傳入 egress configuration 來要求 KAS 將 egress 請求轉(zhuǎn)發(fā)到指定的 proxy server。但由于我們需要兼顧新老版本的 Kubernetes 集群，并且考慮到，其他管控組件（Prometheus 和 metric server）并不支持 EgressSelector 特性，我們需要保證在無法使用 EgressSelector 的情況下也能將 KAS egress 請求轉(zhuǎn)發(fā)致 proxy server。為此，我們在每一個云端管控節(jié)點上都部署一個 Yurttunnel Server 副本，并在 Server 中內(nèi)嵌一個新組件 Iptabel Manager。Iptable Manager 會通過在宿主機的 Iptable 中的 OUTPUT 鏈中添加 DNAT 規(guī)則，將管控組件對節(jié)點的請求轉(zhuǎn)發(fā)致 Yurttunnel Server。

同時，當(dāng)啟用 EgressSelector 后，KAS 對外請求都遵循一個統(tǒng)一的格式，因此我們新增一個組件， ANP interceptor。ANP interceptor 會負責(zé)截取從 master 發(fā)來的 http 請求，并將其封裝成 EgressSelector 格式。Yurttunnel 請求轉(zhuǎn)發(fā)的具體流程見圖三。

圖三：Yurttunnel 請求轉(zhuǎn)發(fā)流程

2. 動態(tài)獲取 Server?副本數(shù)

在上一節(jié)中，我們提到，我們將采用負載均衡的方式來管理 yurttunnel server，所有的 ingress 請求都會通過 LB 分發(fā)給一個 server 副本。由于我們無法預(yù)測 LB 會挑選哪個 server 副本，我們必須保證每個 server 副本都要與所有的 agent 建立連接。這里，我們將使用 ANP 自帶的功能實現(xiàn)這一需求，具體流程如下：

• 在啟動 yurttunnel server 時，我們會將副本數(shù)（serverCount）傳入每個 server 副本中，并且為每個副本指定一個 server ID；

• agent 連接 LB 后，LB會隨機選擇一個 server 副本并讓其與 agent 建立長連接；

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

• agent 通過解析 ACK package，可以獲悉 server 副本的個數(shù)，并在本地記錄已連接的 serverID；

• 如果 agent 發(fā)現(xiàn)，本地連接的 server 副本數(shù)小于 serverCount，則會再次向 LB 發(fā)送連接請求，直至本地記錄的 serverID 數(shù)與 server Count 數(shù)一致為止。

該機制雖然幫助我們實現(xiàn)了 server 副本的全網(wǎng)段覆蓋。但同時，也存在不可忽視的缺點，由于 agent 無法選擇與哪個 server 副本建立連接，因此，為了連接所有的 server 副本，agent 必須反復(fù)訪問 LB。在這個過程中，server 由于還沒有與所有的 agent 建立連接，KAS 發(fā)來的請求可能無法轉(zhuǎn)發(fā)至對應(yīng)的節(jié)點。一個潛在的解決方案是，為每個 server 副本創(chuàng)建一個獨立的 LB，負責(zé)與 agent 之間的連接，同時在 agent 端記錄所有 server 副本對應(yīng) LB 的信息，這一方案能幫助 agent 快速地與所有的 server 副本建立連接。該方案的具體實現(xiàn)細節(jié)，目前仍在與上游社區(qū)的開發(fā)者討論中。

3. 為?ANP 添加代理策略

在 OpenYurt 的網(wǎng)絡(luò)模型下，邊緣節(jié)點分布在不同的 network region 中，隨機選擇的 agent 可能無法將請求轉(zhuǎn)發(fā)至位于其他 region 內(nèi)的節(jié)點上。因此我們不得不修改 ANP server 底層代理轉(zhuǎn)發(fā)的邏輯。然而，根據(jù)長期的經(jīng)驗，我們相信，proxy server 支持不同的代理策略，例如，將請求轉(zhuǎn)發(fā)至指定數(shù)據(jù)中心，region，或者指定主機，是一個較為通用的需求。經(jīng)過和 ANP 社區(qū)開發(fā)者討論，我們決定重構(gòu) ANP 管理 agent 連接的接口，允許用戶根據(jù)需求實現(xiàn)新的代理策略，并計劃將該 feature 最終合入上游代碼庫。目前重構(gòu)工作仍在進行中，在 Yurttunnel 第一個開源版本中，我們暫時采用以下配置：

• 在每個邊緣節(jié)點上部署一個 agent。

• agent 在 server 處登記時，使用 agent 所在節(jié)點的 IP 作為 agentID。

• server 在轉(zhuǎn)發(fā)請求時，通過匹配請求目標 IP 和 agentID，將請求轉(zhuǎn)發(fā)至對應(yīng)的 agent。

我們計劃在 OpenYurt 后續(xù)發(fā)布 Yurt Unit（邊緣節(jié)點分區(qū)管控）之后，配合新增的 ANP 代理轉(zhuǎn)發(fā)策略，實現(xiàn) agent 的分區(qū)部署，和請求的分區(qū)轉(zhuǎn)發(fā)。

4. 動態(tài)申請安全證書

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

5. 壓縮 Tunnel 帶寬，節(jié)約成本

在 3.5 中，我們提到，使用 gRPC 封裝 Tunnel 雖然可以提高傳輸穩(wěn)定性，但同時也會增加公網(wǎng)流量。這是否意味著穩(wěn)定性和性能，我們只能二選一？通過對不同用戶場景的分析，我們發(fā)現(xiàn)，在大多數(shù)情況下，用戶使用運維通道是為了獲取容器日志（即 kubectl log），而傳統(tǒng)日志文件，存在許多相同的文本信息，因此我們推斷使用 gzip 等壓縮算法能有效縮小帶寬。為了驗證這一假設(shè)，我們在 ANP 底層的 gRPC 庫中添加了 gzip compressor，并且對比了與使用原生 TCP 連接場景下的數(shù)據(jù)傳輸量。

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

表 1: 原生 TCP V.S. ANP (kubectl logs kube-proxy)

如表 1 所示，通過使用 ANP， 總傳輸數(shù)據(jù)量下降了 29.93%。

經(jīng)過長時間運行，容器的日志文本常常可以達到十幾兆，為了模擬獲取大文本日志的場景。我們創(chuàng)建了一包含 10.5M systemd log（即 journalctl）的 ubuntu 容器，同樣我們分別使用原生 TCP 連接和 ANP 傳輸該日志文件，并測量了 Tunnel 上的數(shù)據(jù)總量。

表 2: 原生 TCP V.S. ANP (large log file)

如表 2 所示，在日志文本較大的情況下，通過使用 ANP， 總傳輸數(shù)據(jù)量下降了 40.85%。

由此可見，相較于原生 TCP 連接，ANP 不僅能提供更高的傳輸穩(wěn)定性，還可以大幅降低公網(wǎng)流量。考慮到邊緣集群動輒上萬的節(jié)點規(guī)模，新的解決方案將幫助用戶在公網(wǎng)流量方面節(jié)約大量開銷。

Yurttunnel?系統(tǒng)架構(gòu)

圖四：Yurttunnel 系統(tǒng)架構(gòu)

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

• Yurttunnel Server?- 負責(zé)將 apiserver，prometheus，metrics server 等管控組件發(fā)往節(jié)點的請求，轉(zhuǎn)發(fā)至對應(yīng)的 agent。具體包括以下子組件：

  • ANP Proxy Server - 對 ANP gRPC server 的封裝，負責(zé)管理與 Yurttunnel Agent 之間的長連接，并轉(zhuǎn)發(fā)請求。
  • Iptable Manager - 修改管控節(jié)點的 DNAT 規(guī)則，以確保管控組件的請求能被轉(zhuǎn)發(fā)至 Yurttunnel Server。
  • Cert Manager - 為 Yurttunnel Server 生成 TLS 證書。
  • Request Interceptor - 將 KAS 對節(jié)點的 HTTP 請求封裝到符合 ANP 規(guī)則的 gRPC 包里。

• **Yurttunnel Agent?**- 與 Yurttunnel Server 主動建立連接，并將 Yurttunnel Server 發(fā)來的請求轉(zhuǎn)發(fā)給 Kubelet。具體包括兩個子組件：

  • ANP Proxy Agent - 對 ANP gRPC agent 的封裝，相較于上游，我們額外加入了 gzip compressor 以壓縮數(shù)據(jù)。
  • Cert Manager - 為 Yurttunnel Agent 生成 TLS 證書。

• Yurttunnel Server Service?- 通常是一個 SLB，負責(zé)將管控組件發(fā)來的請求分發(fā)給合適的 Yurttunnel Server 副本，保證 Yurttunnel 的高可用和負載均衡。

總結(jié)與展望

Yurttunnel 作為 OpenYurt 近期開源的重要組件，打通了 OpenYurt 集群的云邊通道，為邊緣集群上的容器運維提供了一個統(tǒng)一的入口。通過對上游解決方案進行改造，Yurttunnel 不僅提供了更高的傳輸穩(wěn)定性，也大幅降低了數(shù)據(jù)傳輸量。

OpenYurt 于 2020 年 5 月 29 日正式對外開源，借助社區(qū)和廣大開發(fā)者的力量快速成長，開源僅 3 個月后就正式成為 CNCF 沙箱級別邊緣計算云原生項目。未來，OpenYurt 將延續(xù) “Extending your upstream Kubernetes to edge” 的核心設(shè)計理念，在選擇與上游保持最大技術(shù)公約數(shù)的同時，發(fā)揚開源分享的精神，與廣大開發(fā)者一起推進 Kubernetes 社區(qū)的進步。

OpenYurt 已入圍 “2020 年度 10 大新銳開源項目”，歡迎大家點擊鏈接：https://www.infoq.cn/talk/sQ7eKfv1KW1A0kUafBgv，選擇“25 號”，為 OpenYurt 加油助力！

“阿里巴巴云原生關(guān)注微服務(wù)、Serverless、容器、Service Mesh 等技術(shù)領(lǐng)域、聚焦云原生流行技術(shù)趨勢、云原生大規(guī)模的落地實踐，做最懂云原生開發(fā)者的公眾號。”

總結(jié)

以上是生活随笔為你收集整理的OpenYurt 深度解读：如何构建 Kubernetes 原生云边高效协同网络？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。