云原生爱好者周刊：目前 WebAssembly 的最佳应用场景有哪些？

云原生一周动态要闻：

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 原生兼容。

详情见

本文由博客一文多发平台 OpenWrite 发布！