Istio 自诞生以来，就因其使用 sidecar（与应用程序容器一起部署的可编程代理）而受到认可。这种架构选择使 Istio 用户无需对其应用程序进行大幅更改即可获得其优势。这些部署在应用程序容器旁边的可编程代理因无需对应用程序进行重大更改而带来了 Istio 的许多优势而受到欢迎。但总有改进的空间，现在 Istio 引入了 Ambient Mesh，这是其架构的重大演变。

Sidecar 模型：优点和局限性

传统 Istio 模型：

• Istio 将 Envoy 代理部署为工作负载 Pod 中的 sidecar。

Sidecar 的优点：

• 无需重构应用程序即可受益于 Istio 的功能。

Sidecar 的局限性：

• 侵入性：Sidecar 需要集成到应用程序中，影响其 Kubernetes Pod 规格并重定向 Pod 流量。这通常会导致需要重新启动应用程序 Pod。
• 资源利用不足：由于每个 sidecar 代理都专门分配给其配对的工作负载，因此资源分配可能会导致整个集群效率低下。
• 流量中断：Istio 的 sidecar 进行的流量捕获和 HTTP 处理对于某些应用程序来说可能会出现问题。

Ambient Mesh ：突破限制

Ambient Mesh 采用分层方法，分割 Istio 的功能：

• 基础层：安全覆盖层，负责路由并确保流量的零信任安全。
• 上层：当用户需要访问 Istio 的广泛功能时，可以启用 L7 处理，同时无需更改应用程序 Pod。

这种方法的优点包括：

• 允许增量采用 Istio：从无网格 -> 安全覆盖 -> 完整的 L7 处理。
• 不同环境模式下或与 sidecar 的工作负载之间的兼容性。

Ambient Mesh如何工作？

• Kubernetes 集群中的每个节点上都有一个共享代理 (ztunnel)，负责网格内的安全连接。

• Ztunnel 仅处理 L4 流量，将 Istio 的数据平面与应用程序问题分开。
• 当为命名空间激活环境模式时，会建立零信任覆盖（具有 mTLS、遥测、身份验证和 L4 授权）。
• 对于 L7 功能，命名空间可以部署一个或多个基于 Envoy 的路点代理。这些代理可以根据实时流量需求自动扩展。

安装Ambient Mesh

• 下载支持ambient mesh的最新版本 Istio alpha
• 安装 Kubernetes Gateway CRD，大多数 Kubernetes 集群默认情况下不安装

kubectl get crd gateways.gateway.networkingk8s.io &> /dev/null || \\
  { kubectl kustomize "github.com/kubernetes-sigs/gateway-api/config/crd/experimental?ref=v0.8.0" | kubectl apply -f -; }

• 该ambient配置文件旨在帮助您开始使用Ambient Mesh。ambient使用上面下载的命令在 Kubernetes 集群上安装带有配置文件的 Istio istioctl：

$ istioctl install --set profile=ambient --set "components.ingressGateways[0].enabled=true" --set "components.ingressGateways[0].name=istio-ingressgateway" --skip-confirmation
✔ Istio core installed
✔ Istiod installed
✔ CNI installed
✔ Ingress gateways installed
✔ Ztunnel installed
✔ Installation complete

• 使用以下命令验证已安装的组件：

$ kubectl get pods -n istio-system
NAME                                    READY   STATUS    RESTARTS   AGE
istio-cni-node-n9tcd                    1/1     Running   0          57s
istio-ingressgateway-5b79b5bb88-897lp   1/1     Running   0          57s
istiod-69d4d646cd-26cth                 1/1     Running   0          67s
ztunnel-lr7lz                           1/1     Running   0          69s
$ kubectl get daemonset -n istio-system
NAME             DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR            AGE
istio-cni-node   1         1         1       1            1           kubernetes.io/os=linux   70s
ztunnel          1         1         1       1            1           kubernetes.io/os=linux   82s

安全考虑

Ambient Mesh 优先考虑安全性：

• Ztunnel：虽然是共享资源，但 ztunnel 将其密钥限制为其节点上的工作负载，从而保持低风险。
• Waypoint 代理：这些共享资源仅限于一个服务帐户，从而减少了受损代理造成的潜在损害。
• Envoy 的角色：凭借其强大且经过实战考验的特性，Envoy 被认为比其配对的许多应用程序更安全。

性能和资源影响

• 资源效率：Ambient Mesh 的 ztunnel 减少了每个工作负载的预留。路径点代理的动态缩放还确保了资源优化。
• 延迟问题：虽然有人认为路点代理可能会引入延迟，但 Istio 认为与传统 sidecar 模型相比，可以通过减少 L7 处理来平衡这一点。

Sidecar 的未来是什么？

Ambient Mesh 的引入并不意味着 Sidecar 的终结。它们仍然适用于需要专用数据平面资源的场景，例如合规性或性能调整。Istio 将继续支持 sidecar，确保它们与 Ambient Mesh 协调工作。

总之，Ambient Mesh 代表着服务网格架构向前迈出了有希望的一步，解决了 sidecar 模型的一些挑战，并为用户提供了更大的灵活性和效率。