雲原生愛好者周刊：目前 WebAssembly 的最佳應用場景有哪些？

本文轉載自查看原文 2021-08-17 16:59 101

雲原生一周動態要聞：

Istio 1.11 發布

Facebook、Google、Isovalent、微軟和 Netflix 宣布成立 eBPF 基金會

GitHub 工程團隊將開發環境遷移到 Codespaces

Sysdig 宣布對 Sysdig Monitor 進行重大改進

開源項目推薦

文章推薦

WebAssembly(Wasm) 是一種基於堆棧虛擬機的二進制指令格式，可以將 C/C++/Rust 等高級語言轉成 JS 引擎可以運行的代碼，使客戶端和服務器應用程序能夠在 Web 上部署。WebAssembly 的優勢在於它可以將游戲、視頻編輯、3D 渲染或音樂制作這些瀏覽器之外的軟件功能帶入 Web 端，擁有在 Web 上高效運行游戲等場景的能力，非常有前景。

目前 WebAssembly 已經推出很長一段時間了，到底有哪些項目用到了 WebAssembly 呢？我列舉幾個比較有趣的項目。

1、Google 地圖網頁版之前只能運行在 Chrome 瀏覽器中，使用 WebAssembly 重構后可以運行在任意瀏覽器中，目前還在開發中，地址：https://earth.google.com/static/wasm/

2、v86 是一個基於 Rust 和 WebAssembly 的開源項目，它模擬了兼容 x86 的 CPU 和硬件，可以直接在瀏覽器里運行虛擬機。

關於 WebAssembly 的更多應用場景，可以參考 Made with WebAssembly 這個網站。

雲原生動態

Istio 1.11.0 發布

Istio 1.11.0 是 2021 年發布的第三個版本。Kubernetes 1.18.0 到 1.22.x 都支持 Istio 1.11.0。

以下是此版本的一些亮點：

CNI 插件（測試版）

Istio CNI 插件替代了 istio-init 執行相同網絡功能的容器，但不需要 Istio 用戶啟用提升的 Kubernetes 權限。

CNI 插件可以與其他插件鏈接，並支持大多數托管的 Kubernetes 實現。
外部控制平面（測試版）

去年，Istio 引入了一種新的部署模型，其中集群的控制平面在該集群之外進行管理。這允許管理控制平面的網格所有者和在網格中部署和配置服務的網格用戶之間的關注點分離。在單獨的集群中運行的外部控制平面可以控制單個數據平面集群或多集群網格的多個集群。

在 1.11 中，此功能已升級為 Beta。
網關注入

網關注入將網關的管理移動到與 sidecar 代理相同的方法。您在全局代理上設置的配置將應用於您的網關，並且不可能的復雜配置（例如，將網關作為 DaemonSet 運行）現在很容易。您還可以在集群升級后通過重新啟動 pod 將網關更新到最新版本。
Kubernetes 多集群服務 (MCS) 支持（實驗性）

Kubernetes 項目正在構建一個多集群服務 API，允許服務所有者或網格管理員控制跨網格的服務及其端點的導出。

Istio 1.11 增加了對多集群服務的實驗性支持。啟用后，服務端點的可發現性取決於客戶端位置以及服務是否已導出。與客戶端位於同一集群中的端點將始終可被發現。然而，不同集群中的端點只有在導出到網格時才能被客戶端發現。

詳情見

Facebook、谷歌、Isovalent、微軟和 Netflix 宣布成立 eBPF 基金會

近年來，基於 eBPF 的項目數量呈爆炸式增長，並且越來越多的項目宣布有意開始采用該技術。eBPF 正迅速成為基礎設施軟件領域最具影響力的技術之一。因此，優化項目之間的協作並確保 eBPF 的核心得到良好維護，並為 eBPF 的光明未來配備清晰的路線圖和願景的需求很高。這就是 eBPF 基金會的用武之地，並成立了一個 eBPF 指導委員會來處理 eBPF 的技術方向和願景。

eBPF 是一個完全獨立的項目，提供對 BPF 的向后兼容性，被稱為“Linux 最新的超級大國”。eBPF 為 Linux 內核提供了一種使用即時 (JIT) 編譯器代表用戶執行自定義操作的方法，同時還提供了一個完全沙盒化的環境。本質上，eBPF 允許擴展 Linux 內核而無需實際更改它。

詳情見

GitHub 工程團隊將開發環境遷移到 Codespaces

GitHub 官方宣布，負責 github.com 的工程團隊已將開發環境遷移至 Codespaces。

GitHub 表示，他們長期投入了大量時間和精力來為團隊打造一個“開箱即用”的本地開發環境，讓新員工可以迅速配置和運行 github.com 的本地實例。但現實情況是，雖然付出了許多努力，這樣的開發環境卻依舊十分脆弱。任何看似無害的變更都可能會導致本地環境失效，更糟糕的是，這種情況往往需要數小時的寶貴開發時間來恢復。

考慮到工程師的開發環境各不相同，而且每個人都有自己習慣的特殊癖好。GitHub 受到 Codespaces 啟發，他們可以像對待基礎設施一樣對待開發環境，也就是說沒有什么是不可替換，或者不可或缺的，並且如果出現意外情況，可在已知的良好狀態下提供一個新的 Codespaces 然后重新開始工作。

GitHub 表示，遷移到 Codespaces 解決了現有開發環境的脆弱性和單軌模型，激勵他們進一步推動改進產品，並提升了整體的開發體驗。

詳情見

Sysdig 宣布對 Sysdig Monitor 進行重大改進，從根本上簡化 Prometheus 的采用

隨着組織構建現代雲應用程序，Prometheus 正迅速成為監控基於 Kubernetes 的工作負載的首選工具。開發人員和 SRE 依賴 Prometheus 作為監控的開放標准，它提供廣泛的功能並有助於避免供應商鎖定。然而，隨着 Prometheus 環境在整個組織中激增，管理基礎架構、導出器、儀表板和警報變得復雜且耗時。此外，組織還面臨時間序列的長期存儲、信息孤島以及缺乏跨所有應用程序和基礎架構的環境健康狀況的全局視圖。學習 PromQL（Prometheus 的查詢語言）以及如何有效使用它可能需要數月時間，這會降低團隊正確分析其指標的能力。

Sysdig 正在通過對其托管 Prometheus 服務進行新的增強來解決這些問題：

Sysdig Monitor 現在提供 Prometheus 監控集成的自動發現和輔助部署，以及預配置的儀表板、警報和新的集成管理界面。
Sysdig 通過引入 PromQL Explorer 使用戶更容易學習和使用 PromQL，以便用戶快速制作查詢，將重要的歸零，然后立即將這些查詢添加到儀表板和警報中。
Sysdig 還引入了在攝取時添加自動標簽的功能，以幫助客戶將其 PromQL 查詢的復雜性降低多達 90%。
Sysdig 正在添加對 Prometheus remote_write 的支持，以便組織可以將 Prometheus 指標卸載到 Sysdig 以進行長期存儲。
Sysdig Monitor 與 Prometheus 原生兼容。

詳情見