KubeEdge v0.2釋出

KubeEdge在18年11月24日的上海KubeCon上宣佈開源的一個開源專案，旨在依託K8S的容器編排和排程能力，實現雲邊協

同、計算下沉、海量裝置的平滑接入。

KubeEdge脫胎於華為雲IEF服務，是第一個具備在生產環境部署能力的邊緣計算領域開源專案。前幾天K8S IOT/Edge工作組

釋出了關於邊緣計算的白皮書，並將KubeEdge作為K8S在IOT/Edge場景下的參考架構。

KubeEdge架構上包含兩部分，分別是雲端和邊緣側。雲端負責應用和配置的下發，邊緣側則負責執行邊緣應用和管理接入

裝置。

在v0.2版本中，KubeEdge團隊決定開放雲端程式碼，這樣KubeEdge v0.1和v0.2的釋出分別創造了兩個記錄：

全球首個開源的支援容器部署的邊緣計算平臺；
全球首個開放雲邊協同能力的邊緣計算平臺；

KubeEdge v0.2 的釋出意味著任何人都可以在自己的環境中部署一個完整的涵蓋雲、邊、裝置的邊緣計算解決方案。另外

本次更新還在 v0.1 的基礎上新增了雲上兩個重要元件，分別是：CloudHub和EdgeController，架構如下所示：

其中：

Cloudhub負責接收EdgeHub同步到雲端的資訊；

EdgeController用於控制K8S API Server與邊緣的節點、應用和配置的狀態同步；

使用者可以直接透過kubectl命令列在雲端管理邊緣節點、裝置和應用，使用習慣與K8S原生的完全一致，無需重新適應。

Rancher釋出輕量級Kubernetes

發行版 K3s

近期，容器管理軟體提供商 Rancher Labs宣佈推出輕量級的 Kubernetes 發行版 K3s，這款產品專為在資源有限的環境中

執行 Kubernetes 的研發和運維人員設計。

根據Rancher描述，為了減少執行Kubernetes所需記憶體，k3s主要專注於以下三個方向的變化：

刪除舊的、非必須的程式碼

整合正在執行的打包程式

使用 containerd 代替 Docker 作為執行時的容器引擎

除了 etcd 之外，引入 SQLite 作為可選的資料儲存

k3s官方描述的主要使用場景為：

邊緣計算

與應用程式繫結使用

嵌入式裝置

整體來看，k3s相當於kubernetes針對邊緣計算等特殊場景的裁剪和最佳化，而並非專門專門邊緣計算場景的解決方案，未來

可能還需要長足的演進和適配過程。

阿里宣佈開源 Flutter 應用框架

Fish Redux

3 月 5 日，閒魚宣佈在 GitHub 上開源 Fish Redux，Fish Redux 是一個基於 Redux 資料管理的組裝式 flutter 應用框架

特別適用於構建中大型的複雜應用，它最顯著的特徵是函式式的程式設計模型、可預測的狀態管理、可插拔的元件體系、最佳

的效能表現。

Redux 是來自前端社群的一個用來做可預測易除錯的資料管理的框架，所有對資料的增刪改查等操作都由 Redux 來集中

負責。Redux 核心僅僅關心資料管理，不關心具體什麼場景來使用它，這是它的優點同時也是它的缺點。在實際使用 Redux

中可能面臨兩個具體問題：

Redux 的集中和 Component 的分治之間的矛盾；
Redux 的 Reducer 需要一層層手動組裝，帶來的繁瑣性和易錯性；

Fish Redux 透過 Redux 做集中化的可觀察的資料管理，並且針對傳統 Redux 在使用層面上的缺點，在面向端側 flutter

頁面緯度開發的場景中，透過更好更高的抽象，做了改良。

開源之後，閒魚打算透過以下方式來維護 Fish Redux：

透過後續的一系列的對外宣傳，吸引更多的開發者加入或者使用。

配合後續的一系列的閒魚 Flutter 移動中介軟體矩陣做開源；

進一步提供，一系列的配套的開發輔助除錯工具，提升上層 Flutter 開發效率和體驗；

又現雲平臺當機

企業應如何儘量避免損失

北京時間2019年3月2日23:55分左右開始，監控發現華北2地域部分ECS例項及部分EMR、RDS on ECS、DTS、DBS例項及

服務狀態異常，事後於3月3日阿里雲工程師緊急排查處理，並且逐步恢復異常例項。

細數這兩年，國際主流雲廠商在安全性和可靠性層面做了不少努力，但所有服務都不可能百分百穩定，儘管雲平臺會發生故

障，但企業對雲的信賴度依然很高。Gartner 研究主管 Sid Nag 曾表示，雲服務市場的增長速度比幾乎所有 IT 市場都要快

其中大部分增長是以傳統非雲服務為代價，尤其是基於雲端計算的 IaaS 需求在繼續增長，預計將在未來 5 年呈現最快增長趨勢。

在雲端計算出現之前，企業內部自建資料中心依舊會出現很多問題，不少問題甚至是致命的。上雲之後，公有云廠商至少可以

幫助技術能力有限的企業進行合理範圍內的監控、預警和備份。不可否認，雲的出現確實解決了現階段企業在計算、儲存等

方面的很多問題。但作為企業而言，完全依靠雲端計算廠商提供安全性的做法是不可取的。

雲環境的同城雙活、異地災備等方案基本就緒，儘量在經濟和人員條件可行的情況下使用這些分散風險的方法。如果故障只

出在一個伺服器叢集，採用異地災備方案可以在最快時間切換到另一個叢集，從而保持系統可用。雖然還是會有中斷，但是

可以最快時間恢復。

按照此模式，雲下系統做雲上災備也是防範傳統環境出現可用性問題的一種重要手段。作為企業的 IT 人員，日常做到以下四

點可以儘可能避免雲故障帶來的損失。

•備份、備份，還是備份，要異機異地；

•資料容災；

•業務雙活；

•定期對災備和雙活進行演練。

從統計上看，中小企業的運維水平遠低於主流雲平臺，故障機率要高得多，損失更不可控。因此，不必對雲服務故障抱有

恐懼，只需要保持正常的認知和高度災備意識即可。

相關服務請訪問： https://support.huaweicloud.com/cce/index.html?utm_content=cce_helpcenter_2019

Cloud Native Weekly |面對雲平臺當機，企業如何止損