第三屆雲原生程式設計挑戰賽是由阿里雲、Intel 主辦，雲原生應用平臺、天池聯合承辦的雲原生頂級賽事。自 2015 年開始，大賽已經成功舉辦了七屆，共吸引了超過 36000 支隊伍，覆蓋 10 餘個國家和地區，為全球熱愛技術的年輕人提供了一個探索雲原生技術、挑戰難題的舞臺。

在雲原生實踐不斷深化的過程中我們發現，隨著邊緣裝置和邊緣業務的規模增長，以及業務創新帶來的頻繁變更，在雲邊協同的邊緣場景架構體系下，“雲邊協同”正在面臨巨大的管理效率和成本挑戰。

作為本次大賽三大熱門技術領域之一，“邊緣容器”賽道的發起就希望在這樣的背景下，透過集結關注、熱愛雲原生的開發者的智慧、技術和能量，探索研究如何在雲邊協同的邊緣場景架構體系下，降低邊緣側元件的資源佔用率，實現一個高效的邊緣自治方案。

現在，雲原生程式設計挑戰賽“邊緣容器賽題”已經吹響集結號，全面開放報名，等待有能力、有魄力、有活力的開發者們前來挑戰！

## 參與邊緣容器賽道挑戰，瓜分 170,000 元現金獎勵

本次大賽面向全球開放，大賽分為初賽和決賽，各賽道初賽 TOP6 戰隊入圍決賽答辯。最終排行將根據初賽及決賽答辯成績綜合得出。

![1.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/e43a18ef1d024b7c9e8ad29562085dfd~tplv-k3u1fbpfcp-zoom-1.image "1.png")

## 專屬賽道獎勵，週週送不停

除了雲原生程式設計大賽官方獎勵，為了鼓勵更多開發者參與邊緣容器賽道挑戰，即日起，成功提交賽題任務並在每週排行榜中位列 Top 1 的使用者，均將獲得雲原生邊緣容器開源平臺 OpenYurt 定製隨行杯一個！（每人限一次）

![2.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/9b486b18f86c455f9ba70da2fd0b939c~tplv-k3u1fbpfcp-zoom-1.image "2.png")

## 明星導師

![3.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/a1dd73f14ae644118e2c327469877522~tplv-k3u1fbpfcp-zoom-1.image "3.png")

張傑，阿里云云原生技術專家，CNCF OpenYurt 開源社群核心成員

## 賽題解析

### 賽題背景

ACK@Edge 是阿里雲容器服務針對邊緣計算場景推出的雲邊一體化雲原生解決方案，主打“雲端託管、邊緣自治”的產品理念，為使用者提供雲邊多維度協同，海量異構算力管理，邊緣 AI 套件，可觀測，輕量化，彈性等能力。現已廣泛應用於邊緣雲、物聯網等典型邊緣計算場景，覆蓋交通、能源、新零售、智慧駕駛、CDN 等多個行業。同時，ACK@Edge 依託 CNCF OpenYurt 強大的社群生態，積極參與並協同社群持續打磨和完善裝置孿生、雲邊協同網路、高可用等領先技術能力。

![4.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/13c28d1eba9c4500b1d47863f5f43af3~tplv-k3u1fbpfcp-zoom-1.image "4.png")

為了解決在邊緣計算場景下雲邊網路通訊斷連時，保證邊緣側節點上業務可以自愈，OpenYurt 在邊緣側元件和 APIServer 之間新增 YurtHub 元件。邊緣側的元件（kubelet,kube-proxy..）對 api server 的請求，會首先經過 YurtHub 元件的然後再轉發給 api server，YurtHub 會將 api server 返回的資料快取到本地。當雲邊網路斷開時，Yurthub 還能將本地快取的資料返回給邊緣側元件。

但是在實踐過程中我們發現，在雲邊協同的邊緣場景架構體系下，有著大量的輕量級的裝置，這些裝置的配置相對比較低，降低邊緣側元件的資源佔用率，為裝置上的業務騰出更多的資源，已經成為了必須要解決的問題。

本賽題希望實現一個邊緣側的 edge-proxy 元件，負責轉發邊緣側元件例如 kubelet,kube-proxy 的請求，同時能夠將雲上 api server 返回的資料進行過濾，同時在返回給請求端時可以快取到本地，並儘可能的降低 cpu，記憶體等資源佔用率。

### 賽題解析

在 Kubernetes 系統中，list/watch 機制主要解決元件間實時資料的非同步同步。其中 List 請求是普通的 HTTP GET 請求，一次 List 請求將返回請求型別資源的全量資料。而 watch 請求是基於 HTTP 協議的 chunked 機制實現的長連線，用於實時通知請求資源的資料變化。相關的介紹可以參考：

<https:></https:>

List/Watch 機制是 Kubernetes 中實現叢集控制模組最核心的設計之一，它採用統一的非同步訊息處理機制，保證了訊息的實時性、可靠性、順序性和效能等，為宣告式風格的 API 奠定了良好的基礎。Informer 模組是 Kubernetes 中的基礎元件，負責各元件與 api server 的資源與事件同步。Kubernetes 中的元件，如果要訪問 Kubernetes 中的 Object，絕大部分情況下會使用 Informer 中的 Lister()方法，而非直接請求 Kubernetes API。

![5.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/da906d0759ad4d9ca5fec3bf8872b580~tplv-k3u1fbpfcp-zoom-1.image "5.png")

**client-go：**

Reflector：reflector 用來 watch 特定的 K8s API 資源。具體的實現是透過 ListAndWatch 的方法，watch 可以是 K8s 內建的資源或者是自定義的資源。當 reflector 透過 watch API 接收到有關新資源例項存在的通知時，它使用相應的 list API 獲取新建立的物件，並將其放入 watchHandler 函式內的 Delta Fifo 佇列中。

Informer：informer 從 Delta Fifo 佇列中彈出物件。執行此操作的功能是 processLoop。base controller 的作用是儲存物件以供以後檢索，並呼叫我們的控制器將物件傳遞給它。

Indexer：索引器提供物件的索引功能。典型的索引用例是基於物件標籤建立索引。Indexer 可以根據多個索引函式維護索引。Indexer 使用執行緒安全的資料儲存來儲存物件及其鍵。

### 雲邊挑戰

上述 List watch 機制適合在網路通訊質量比較好的資料中心內執行， 但是在雲邊場景，雲邊網路連線不可靠的情況下帶來很大的挑戰。以 kubelet 為例，若 kubelet 與雲上的 api Server 網路斷開， 此時主機傳送了重啟， 按照 list-watch 的邏輯， kubelet  要首先透過 api Server list 全量屬於本主機上的 pod 資料， 然後再透過 CRI 介面對 POD 進行重建，由於雲邊網路斷開，kubelet 無法透過 list 機制獲取本主機上的 pod 資料，自然無法對 pod 進行重建，導致業務無法正常執行。

### 解決方案

因此我們需要在邊緣側新增一個元件 edge-proxy, edge-proxy 元件包含能力主要有邊緣元件(如 kubelet 等)的 pods, configmaps 的 list/watch 請求的轉發，以及對 kube-api server 返回 response 的過濾和快取處理。總結一句話就是實現一個帶有資料過濾和快取功能的 7 層反向代理。不過這裡的 7 層請求是 Kubernetes 系統中定製的 List/Watch 請求。同時 edge-proxy 在離線狀態下還能返回 kubelet ,kube-proxy 這些邊緣側元件 list-watch 的資料，充當離線的 api Server。

7 層請求的代理轉發，如果雲邊網路通訊正常時，請求需要轉發到雲端 kube-apiserver。而當雲邊網路斷連時，list 請求需要返回本地的快取資料。

kube-apiserver 返回 response 的過濾和快取處理，首先返回給請求端的資料應該過濾完成的。而快取和過濾的處理先後順序並沒有要求，選手可以根據自身需求來決定。但是需要注意 List/Watch 請求的 response 資料不太一樣，List 請求的 response 中可以一次性讀取出全量資料，而 Watch 請求屬於雲端實時推送，是長連線，當雲端有資料變化時，才能從 response 中讀取雲端推送過來的變化資料。不管是 List，還是 Watch 請求，edge-proxy 都需要返回給請求方過濾好之後的資料。

同時針對大規模 response 資料的過濾，快取，以及返回等功能，如何高效且實時的處理，將直接影響到處理的效率，以及 edge-proxy 消耗的資源。

### 解題思路

實現一個帶資料過濾和快取功能的 7 層反向代理：

-   當接收到 List 請求時，可以考慮直接轉發到雲端 kube-apiserver。當請求轉發失敗時（網路斷開），則使用本地快取資料返回到請求方。當然需要保證返回資料是符合過濾需求的。
-   針對 http.Response 資料的快取和返回處理，儘可能實現並行處理，這樣減少對返回處理的阻塞，從而可能獲得更好的處理效率。
-   http.Response 資料的過濾處理建議可以在快取前執行。當雲邊網路斷連時，從本地快取返回的資料將不需要進行二次過濾。
-   Watch 請求的 http.Response 資料是 chunked 機制的實時資料推送，可以考慮採用類似流資料的處理方案來解決。

### 如何拿到好成績

最終成績由資料正確性和處理效率來決定，建議在保證正確性的基礎上，可以各類最佳化手段(如樂觀鎖等)來提升處理效率。期待各位選手都取得自己滿意的成績。

點選[此處](https://tianchi.aliyun.com/specials/promotion/Tianchi_2022CloudNativeCompetition)，立即報名！

【週週有獎】雲原生程式設計挑戰賽“邊緣容器”賽道邀你來戰！

相關文章