KubeEdge創始人 課後答疑——《KubeEdge架構與核心技術》

2019年11月14日視頻直播了KubeEdge系列課程的第一課《KubeEdge架構與核心技術》，課程首先介紹了雲原生、邊緣計算的發展歷程，從持續狂熱的Kubernetes到飛速發展的邊緣計算。再針對邊緣計算網絡不穩定、資源有限等條件下，分析了KubeEdge項目如何將雲原生生態的衆多標準與優點帶到邊緣計算。包括在K8s的應用編排、調度能力之上，構建的雲邊協同、邊緣自治、應用管理、設備管理等能力。

本次課程的回放地址：

媒體中心​huaweicloud.bugu.mudu.tv

 

課後以下問題講師進行了詳細解答：

Q1 ：KubeEdge雲和邊的數據協同有什麼優點？

A1 ：K8s的原生架構中， Node (Kubelet) 是經過List-watch機制主動與Master通訊。List-watch機制有幾個特色：

1.事件傳輸沒有ACK類的校驗機制，要依賴數據中心穩定的網絡保證不丟事件

2. 每次網絡斷開，Node側都會重新執行List操做(取回全部數據)，要依賴數據中心穩定的網絡保證長鏈接不頻繁斷開，不然對Master及網絡都是很大的損耗。

在邊緣場景下，衆所周知網絡都是很不穩定的，包括丟失數據、鏈接斷開等。針對不穩定的網絡，在KubeEdge雲邊協同的設計中：

1. 咱們把List-watch中的事件取出來，加了ACK校驗機制，只有邊緣收到數據且回覆ACK信息，雲端才認爲發送成功，反之則進行重試。

2. 在網絡斷開(確認節點離線)後，雲端會將待同步數據持久化，等到邊緣節點上線，再將緩存的待發送數據逐一下發，3. 針對未發送的消息實時檢查合併去重，避免網絡震盪。

KubeEdge的雲邊協同機制不只保證了雲和邊之間數據的可靠傳輸，也避免了網絡不穩定時從新List形成的網絡壓力。

 

Q2 ：KubeEdge目前是如何解決邊緣節點自治能力的？

A2 ：KubeEdge會邊緣將收到的應用、設備元數據都進行本地持久化。相比Kubelet在內存中緩存對象的方式，能夠有效保證節點離線、故障恢復時的業務自治和快速自愈。

 

Q3 ：邊緣節點離線後，依賴數據屢次變動，邊緣應用和雲端數據的最終一致是怎麼保證的？

A3 ： KubeEdge目前的應用管理等操做都須要經過K8s master進行，針對邊緣節點離線場景主要提供自治的能力，既本地持久化的數據僅用於管理節點上的應用和設備，雲邊通訊恢復時，節點將同步雲依據來自CloudCore的最新消息更新本地元數據。這裏稍有不一樣的是邊緣設備管理，對設備指望狀態的設置須要經過Device CRD中的Desired State來操做（從雲到邊），而設備實際狀態的上報會體如今Reported State中（從邊到雲），兩個方向的數據同步不會衝突。

 

Q4 ：KubeEdge與K3s的區別是什麼？

A4 ：首先是架構選型問題，K3s選擇的是在邊緣運行整個K8s集羣的方案，不具有云邊協同的能力；其次K3s雖然對K8s作了輕量化，但總體資源要求仍然較高，沒法運行在IOT Hub、工業網關等小型設備中。

KubeEdge針對邊緣場景的優化包括：

1. 針對邊緣網絡不穩定的狀況，增長了雲邊數據協同的可靠性傳輸、邊緣元數據持久化，減小了網絡不穩定形成的壓力震盪，實現了邊緣離線自治的能力，在雲邊斷聯、節點故障恢復時保證業務不受影響。

2. 針對邊緣資源不足的狀況，對Kubelet進行輕量化裁剪，支持在256MB的設備上運行。

3. 針對複雜多樣的邊緣設備管理，KubeEdge定義了一套通用的設備管理API（K8s CRD）以及設備協議解耦層，用戶能夠方便地使用KubeEdge進行管理各類邊緣設備。

 

Q5 ：中心K8s對邊緣節點的管理主要操做有哪些？

A5 ： KubeEdge運行在K8s完整的應用調度、管理能力之上，意味着KubeEdge的雲端不負責應用的調度、管理，只是將調度到邊緣節點的應用、設備元數據下發到邊緣。KubeEdge在雲端的核心組件是CloudCore，包含EdgeController、DeviceController、CloudHub三個模塊，EdgeController、DeviceController負責將應用、設備元數據下發到邊緣，同時未來自邊緣的節點狀態、應用狀態、設備狀態刷新到K8s集羣中；CloudHub負責直接與邊緣通訊。

Q6 ：新版本邊緣節點的service仍是僅支持hostPort嗎，nodeport是否支持？

A6 ：從KubeEdge 1.1版本開始集成了CRI，意味着用戶可使用CNI插件來配置網絡，再也不限制於hostport。NodePort是K8s中服務訪問的概念，須要經過Kube-proxy來配置，目前在邊緣端還不支持。另外KubeEdge提供了EdgeMesh實現邊緣應用間的互訪。

Q7 ：邊緣節點的Docker容器鏡像是從整個雲-邊k8s系通通一的鏡像倉庫拉取的嗎？

A7 ：只要邊緣端可以訪問到的鏡像倉庫，都可以用來拉取鏡像。

Q8 ：PPT裏提到"KubeEdge 用於將容器化應用程序編排功能擴展到Edge的主機。" 那麼，是把雲上的應用下沉到edge、還把終端設備上的應用提高到edge呢？

A8 ：KubeEdge做爲應用管理平臺時，能夠在雲端統一管控，既能夠把應用部署到雲端節點，也能夠部署到邊緣節點。用戶能夠根據自身需求，將雲端的部分業務下沉到邊緣。若是須要將終端設備上的應用部署到邊緣節點，也能夠經過KubeEdge來部署。

Q9 ：邊緣側的各個應用是怎麼通訊的？好比一個作sql過濾的應用和另外一個作數據分析的應用是經過hub統一轉發的，仍是應用間就同步了，亦是經過mqtt等協議？同步異步消息分別怎麼實現的？

A9 ：目前KubeEdge中使用EdgeMesh機制來作邊緣端應用的互訪，不須要經過hub與mqtt轉發，在EdgeMesh實現應用互通的前提下，同步異步消息依賴用戶應用自身的機制。

Q10 ：KubeEdge節點和普通節點都在 kubectl get node 中獲取到，這二者有什麼區別？

A10 ：沒有本質區別，KubeEdge的邊緣組件會將Node經過雲邊協同通道註冊到K8s Master，惟一的不一樣是普通節點由Kubelet直接訪問Master完成節點註冊，KubeEdge是經過雲邊協同通道註冊，API都是一致的。

Q11：KubeEdge的 modbus協議是用什麼設備調試的？

A11： 目前開發調試中使用modbus slave來調試。

Q12 ：KubeEdge的安全層是怎麼作的？

A12 ：KubeEdge雲邊協同使用了安全的WebSocket通道。對於應用間的安全互訪要依賴用戶本身配置安全證書等。

Q13 ：KubeEdge邊緣節點能管理GPU設備嗎？

A13 ：邊緣節點能夠經過DevicePlugin來管理GPU設備。

 

 

項目的地址（歡迎Star、Folk，各類Issue、PR）：

     kubeedge/kubeedge