1 WebAssembly 介绍​

WebAssembly（Wasm）是一种通用字节码技术，它可以将其他编程语言（如 Go、Rust、C/C++ 等）的程序代码编译为可在浏览器环境直接执行的字节码程序。

WebAssembly 的初衷之一是解决 JavaScript 的性能问题，让 Web 应用程序能够达到与本地原生应用程序类似的性能。作为底层 VM 的通用、开放、高效的抽象，许多编程语言，例如C、C++ 和 Rust，都可以将现有应用程序编译成 Wasm 的目标代码，以便它们在浏览器中运行。这将应用程序开发技术与运行时技术解耦，并大大提高了代码的可重用性。

Harbor 介绍​

Harbor 是由 VMware 开源的一款云原生制品仓库，Harbor 的核心功能是存储和管理 Artifact。Harbor 允许用户用命令行工具对容器镜像及其他 Artifact 进行推送和拉取，并提供了图形管理界面帮助用户查看和管理这些 Artifact。 在 Harbor 2.0 版本中，除容器镜像外，Harbor 对符合 OCI 规范的 Helm Chart、CNAB、OPA Bundle 等都提供了更多的支持。

Harbor 整体架构​

如上图所示是 Harbor 2.0 的架构图，从上到下可分为代理层、功能层和数据层。

• 代理层：代理层实质上是一个 Nginx 反向代理，负责接收不同类型的客户端请求，包括浏览器、用户脚本、Docker 等，并根据请求类型和 URI 转发给不同的后端服务进行处理。
• 功能层：
  • Portal：是一个基于 Argular 的前端应用，提供 Harbor 用户访问的界面。
  • Core：是 Harbor 中的核心组件，封装了 Harbor 绝大部分的业务逻辑。
  • JobService：异步任务组件，负责 Harbor 中很多比较耗时的功能，比如 Artifact 复制、扫描、垃圾回收等。
  • Docker Distribution：Harbor 通过 Distribution 实现 Artifact 的读写和存取等功能。
  • RegistryCtl：Docker Distribution 的控制组件。
  • Notary（可选）：基于 TUF 提供镜像签名管理的功能。
  • 扫描工具（可选）：镜像的漏洞检测工具。
  • ChartMuseum（可选）：提供 API 管理非 OCI 规范的 Helm Chart，随着兼容 OCI 规范的 Helm Chart 在社区上被更广泛地接受，Helm Chart 能以 Artifact 的形式在 Harbor 中存储和管理，不再依赖 ChartMuseum，因此 Harbor 可能会在后续版本中移除对 ChartMuseum 的支持。
• 数据层：
  • Redis：主要作为缓存服务存储一些生命周期较短的数据，同时对于 JobService 还提供了类似队列的功能。
  • PostgreSQL：存储 Harbor 的应用数据，比如项目信息、用户与项目的关系、管理策略、配置信息、Artifact 的元数据等等。
  • Artifact 存储：存储 Artifact 本身的内容，也就是每次推送镜像、Helm Chart 或其他 Artifact 时，数据最终存储的地方。默认情况下，Harbor 会把 Artifact 写入本地文件系统中。用户也可以修改配置，将 Artifact 存储在外部存储中，例如亚马逊的对象存储 S3、谷歌云存储 GCS、阿里云的对象存储 OSS 等等。

1 vcluster 介绍​

虚拟集群（virtual cluster, 简称 vcluster）是在常规的 Kubernetes 集群之上运行的一个功能齐全，轻量级，隔离性良好的 Kubernetes 集群。虚拟集群的核心思想是提供运行在“真实”Kubernetes 集群之上隔离的 Kubernetes 控制平面（例如 API Server）。与完全独立的“真实“集群相比，虚拟集群没有自己的工作节点或者网络，工作负载实际上还是在底层宿主集群上调度。

默认情况下，vcluster 作为一个包含 2 个容器的 Pod 运行。（由 StatefulSet 调度），包含：

• 控制平面：包含 API Server, Controller Manager, 数据存储。默认情况下使用 sqlite 作为数据存储，并且使用 k3s 运行 API Server 和 Controller Manager。
• Syncer 同步器：vcluster 本身并没有实际的工作节点或者网络，它使用 syncer 将虚拟集群中创建的资源复制到底层宿主集群中。

vcluster 中的资源分为两种：

• 高级（纯虚拟）：这部分资源只存在于虚拟集群中，例如 Deployment、StatefulSet、CRD 等。
• 低级（同步资源）：一些底层的 Kubernetes 资源需要同步到底层宿主集群中，例如 Pod、Service、Persistent Volume 等等。

vcluster 有以下特点：

• 可使用集群层面的资源：在虚拟集群中允许租户使用 CRD、Namespaces、ClusterRole 等资源，这比通过命名空间隔离的方式功能更加强大。
• 轻量级：vcluster 默认使用 k3s 构建虚拟集群，k3s 是一个经过认证的轻量级 Kubernetes 发行版，100% 兼容 Kubernetes API，它将 Kubernetes 的组件编译为小于 100 MB 的单个二进制文件，默认禁用所有不需要的 Kubernetes 功能，例如 Pod 调度器或某些控制器，这使得 k3s 的内存使用仅仅为常规 k8s 的一半。另外 vcluster 还支持其他发行版，例如 k0s 或常规 k8s。
• 经济高效：创建虚拟集群比“真正的“集群更加便宜和高效，最少只需要创建单个 vcluster Pod（包含 API server, syncer, 后端存储）。
• 良好的隔离性：每个虚拟集群有独立的控制平面和接入点，并且可以对虚拟集群的网络和工作负载进行限制。
• 没有性能下降：Pod 实际上被部署在底层主机集群中，因此它们在运行时根本不会受到性能影响。
• 减少宿主集群上的开销：高级资源（例如 Deployment、StatefulSet、CRD ）仅保留在虚拟集群中而不会到达底层宿主集群，从而大大减少对底层宿主集群 Kubernetes API Server 的请求数量。
• 易于部署 ：vcluster 可以通过 vcluster CLI、helm、kubectl、cluster api、Argo CD 等多种工具进行部署（它本质上只是一个 StatefulSet 资源）。
• 单一命名空间封装：每个虚拟集群及其所有的工作负载都位于底层宿主集群的单一命名空间内。
• 灵活和多功能：vcluster 支持不同的后端存储（例如 sqlite、mysql、postgresql 和 etcd）、插件，允许自定义资源的同步策略，你甚至还可以在 vcluster 中部署 vcluster。

使用虚拟集群相比创建单独的 Kubernetes 集群更经济高效，同时相较于命名空间的隔离方式则能够提供更好的多租户和隔离特性。下表对命名空间、vcluster 和单独的 Kubernetes 集群 3 种方式在隔离性、多租户访问、成本等方面进行了对比。

Submariner 是一个完全开源的项目，可以帮助我们在不同的 Kubernetes 集群之间（无论是在本地还是云端）实现网络通信。Submariner 有以下功能：

• 跨集群的 L3 连接
• 跨集群的服务发现
• Globalnet 支持 CIDR 重叠
• 提供命令行工具 subctl 简化部署和管理
• 兼容各种 CNI

1 Submariner 架构​

Submariner 是一个用于连接 Kubernetes 集群的跨集群网络解决方案，可以实现集群之间的服务发现、网络通信等功能。

Prometheus 是一个开源的监控和告警系统，专门用于收集、存储和查询各种应用、系统和基础设施的实时指标数据。Prometheus 具备多维数据模型、灵活的查询语言（PromQL）、高效的存储等特点，广泛应用于 Kubernetes 集群监控、服务可用性监控、性能分析等场景。

Grafana 是一款流行的开源数据可视化工具，可以与 Prometheus 等各种数据源集成，为用户提供丰富、实用的监控图表和仪表盘。

在本文中，将介绍如何利用 Prometheus 对 Submariner 进行监控，并通过 Grafana 展示监控数据的图表。我们可以通过监控了解 Submariner 多集群的连接状态，连接延时等指标，并及时发现潜在的问题。

调试容器化工作负载和 Pod 是每位使用 Kubernetes 的开发人员和 DevOps 工程师的日常任务。通常情况下，我们简单地使用 kubectl logs 或者 kubectl describe pod 便足以找到问题所在，但有时候，一些问题会特别难查。这种情况下，大家可能会尝试使用 kubectl exec，但有时候这样也还不行，因为 Distroless 等容器甚至不允许通过 SSH 进入 shell。那么，如果以上所有方法都失败了，我们要怎么办？

Kubernetes v1.18 版本新增的 kubectl debug 命令，允许调试正在运行的 pod。它会将名为 EphemeralContainer（临时容器）的特殊容器注入到问题 Pod 中，让我们查看并排除故障。

临时容器其实是 Pod 中的子资源，类似普通 container。但与普通容器不同的是，临时容器不用于构建应用程序，而是用于检查。 我们不会在创建 Pod 时定义它们，而使用特殊的 API 将其注入到运的行 Pod 中，来运行命令并检查 Pod 环境。除了这些不同，临时容器还缺少一些基本容器的字段，例如 ports、resources。

1 OpenID Connect（OIDC）介绍​

OAuth（Open Authorization）是一个关于授权（authorization）的开放网络标准，允许用户授权第三方应用访问他们存储在其他服务提供者上的信息，而不需要将用户名和密码提供给第三方应用。OAuth 在全世界得到了广泛的应用，目前的版本是 2.0 。

OpenID Connect (OIDC) 是一种身份验证协议，基于 OAuth 2.0 系列规范。OAuth2 提供了 access_token 来解决授权第三方客户端访问受保护资源的问题，OpenID Connect 在这个基础上提供了 id_token 来解决第三方客户端标识用户身份的问题。

OpenID Connect 的核心在于，在 OAuth2 的授权流程中，同时提供用户的身份信息（id_token）给到第三方客户端。id_token 使用JWT（JSON Web Token）格式进行封装，得益于 JWT 的自包含性，紧凑性以及防篡改机制等特点，使得 id_token 可以安全地传递给第三方客户端程序并且易于验证。

JSON Web Token（JWT）是一个开放的行业标准（RFC 7519），它定义了一种简洁的、自包含 的协议格式，用于在通信双方间传递 JSON 对象，传递的信息经过数字签名可以被验证和信任。想要了解 JWT 的详细内容参见 JWT（JSON Web Token）。

Kubectl patch 命令允许用户对运行在 Kubernetes 集群中的资源进行局部更新。相较于我们经常使用的 kubectl apply 命令，kubectl patch 命令在更新时无需提供完整的资源文件，只需要提供要更新的内容即可。

Kubectl patch 支持以下 3 种 patch 类型：

• strategic patch（默认）：根据不同字段 patchStrategy 决定具体的合并 patch 策略。 Strategic merge patch 并非通用的 RFC 标准，而是 Kubernetes 特有的一种更新 Kubernetes 资源对象的方式。与 JSON merge patch 和 JSON patch 相比，strategic merge patch 更为强大。
• JSON merge patch：遵循 JSON Merge Patch, RFC 7386[1] 规范，根据 patch 中提供的期望更改的字段及其对应的值，更新到目标中。
• JSON patch：遵循 JSON Patch, RFC 6902[2] 规范，通过明确的指令表示具体的操作。

1 Ambient Mesh 介绍​

Istio 的传统模式是将 Envoy proxy 作为 sidecar 部署在工作负载的 Pod 中，虽然与重构应用程序相比，sidecar 具有显著的优势，但是仍然会产生一些限制：

• 侵入性：sidecar 必须通过修改 Kubernetes Pod 的配置和重定向流量来“注入”应用程序。因此，安装和升级 sidecar 需要重新启动 Pod，这将会对工作负载产生影响。
• 资源利用率低：由于在每个工作负载 Pod 都注入了 sidecar 代理 ，因此 Pod 必须为 sidecar 预留足够的 CPU 和内存资源，从而导致整个集群的资源利用率不足。
• 流量中断：流量捕获和 HTTP 处理通常是由 Istio 的 sidecar 完成的，计算需要消耗大量的资源，并且可能会破坏一些不符合 HTTP 实现的应用程序。