环境数据平面

在 环境模式 下，工作负载可以分为 3 类

1. 未加入服务网格：一个标准的 Pod，没有启用任何服务网格功能。Istio 和环境 数据平面 未启用。
2. 已加入服务网格：一个包含在环境 数据平面 中的 Pod，其流量在第 4 层被 标签。
3. 已加入服务网格，启用了路径点：一个已加入服务网格且部署了 路径点代理 的 Pod。在这种模式下，可以针对 Pod 流量执行第 7 层策略。可以通过设置 istio.io/use-waypoint 标签来启用此模式。有关更多详细信息，请参阅 标签。

取决于工作负载属于哪一类，流量路径会有所不同。

网内路由

出站

当环境服务网格中的 Pod 发出出站请求时，它将被 透明地重定向 到节点本地 ztunnel，后者将确定请求的转发位置和方式。通常，流量路由的行为与 Kubernetes 的默认流量路由相同；发送到 Service 的请求将被发送到 Service 中的端点，而直接发送到 Pod IP 的请求将直接发送到该 IP。

但是，取决于目标的能力，会发生不同的行为。如果目标也已添加到服务网格中，或者以其他方式具有 Istio 代理功能（例如 Sidecar），则请求将被升级为加密的 HBONE 隧道。如果目标具有路径点代理，除了升级到 HBONE 外，请求还将被转发到该路径点以执行第 7 层策略。

请注意，对于发送到 Service 的请求，如果该服务具有路径点，则该请求将被发送到其路径点以对流量应用第 7 层策略。同样，对于发送到 Pod IP 的请求，如果该 Pod具有路径点，则该请求将被发送到其路径点以对流量应用第 7 层策略。由于可以在 Deployment 中更改与 Pod 关联的标签，因此在技术上可以使一些 Pod 使用路径点，而另一些则不使用。一般建议用户避免这种高级用例。

入站

当环境服务网格中的 Pod 接收入站请求时，它将被 透明地重定向 到节点本地 ztunnel。当 ztunnel 接收请求时，它将应用授权策略，并且仅在请求通过这些检查时才转发请求。

Pod 可以接收 HBONE 流量或明文流量。默认情况下，ztunnel 会接受这两种流量。来自服务网格外部的请求在评估授权策略时没有对等身份，用户可以设置一个策略要求身份（任何身份或特定身份）来阻止所有明文流量。

当目标启用了路径点时，如果源在环境服务网格中，源的 ztunnel 将确保请求将通过执行策略的路径点。但是，服务网格外部的工作负载不知道路径点代理，因此它将直接发送请求到目标，而不会通过任何路径点代理，即使目标启用了路径点。目前，来自 Sidecar 和网关的流量也不会通过任何路径点代理，并且将在将来的版本中让他们知道路径点代理。

数据平面详细信息

身份

环境服务网格中工作负载之间的所有入站和出站第 4 层 TCP 流量都受到数据平面的保护，使用通过 HBONE、ztunnel 和 x509 证书实现的 mTLS。

如 mTLS 所强制执行的，源和目标必须具有唯一的 x509 身份，并且必须使用这些身份来建立该连接的加密通道。

这要求 ztunnel 代表代理工作负载管理多个不同的工作负载证书 - 每个节点本地 Pod 的每个唯一身份（服务帐户）一个证书。Ztunnel 的自身身份从未用于工作负载之间的 mTLS 连接。

在获取证书时，ztunnel 将使用其自身身份向 CA 进行身份验证，但会请求另一个工作负载的身份。至关重要的是，CA 必须强制执行 ztunnel 具有请求该身份的权限。拒绝请求在节点上未运行的身份。这是为了确保受损的节点不会危及整个服务网格。

这种 CA 强制执行由 Istio 的 CA 使用 Kubernetes 服务帐户 JWT 令牌执行，该令牌对 Pod 信息进行编码。这种强制执行也是任何与 ztunnel 集成的替代 CA 的要求。

Ztunnel 将请求节点上所有身份的证书。它根据接收到的 控制平面 配置来确定这一点。当在节点上发现新身份时，它将被排队以低优先级获取，作为一种优化。但是，如果请求需要尚未获取的特定身份，则会立即请求该身份。

此外，Ztunnel 将处理这些证书在即将到期时进行轮换。

遥测

Ztunnel 发射了完整的 Istio 标准 TCP 指标 集。

第 4 层流量的数据平面示例

下图描绘了环境数据平面。

该图显示了添加到环境服务网格中的多个工作负载，这些工作负载运行在 Kubernetes 集群的节点 W1 和 W2 上。每个节点上都有一个 ztunnel 代理实例。在这种情况下，应用程序客户端 Pod C1、C2 和 C3 需要访问 Pod S1 提供的服务。不需要高级的第 7 层功能，例如第 7 层流量路由或第 7 层流量管理，因此第 4 层数据平面足以获得 mTLS 和第 4 层策略执行 - 不需要路径点代理。

该图显示了运行在节点 W1 上的 Pod C1 和 C2 与运行在节点 W2 上的 Pod S1 相连。

C1 和 C2 之间的 TCP 流量通过 ztunnel 创建的 HBONE 连接安全地隧道化。 双向 TLS (mTLS) 用于加密以及被隧道化的流量的相互认证。 SPIFFE 身份用于识别连接两端的负载。有关隧道协议和流量重定向机制的更多详细信息，请参阅有关 HBONE 和 ztunnel 流量重定向 的指南。

请注意，本地流量 - 图中所示从 Pod C3 到工作节点 W2 上的目标 Pod S1 的流量 - 也通过本地 ztunnel 代理实例，以便 L4 授权和 L4 遥测等 L4 流量管理功能将在流量上以相同的方式强制执行，无论它是否跨越节点边界。

启用航路点的网内路由

Istio 路标专用于接收 HBONE 流量。在收到请求后，路标将确保流量是针对使用它的 Pod 或 Service 的。

在接受流量后，路标将在转发之前强制执行 L7 策略（例如 AuthorizationPolicy、RequestAuthentication、WasmPlugin、Telemetry 等）。

对于直接请求 Pod 的请求，请求在应用策略后将直接转发。

对于请求 Service 的请求，路标也将应用路由和负载均衡。默认情况下，Service 只会路由到自身，在其端点之间执行 L7 负载均衡。这可以通过该 Service 的路由进行覆盖。

例如，以下策略将确保对 echo 服务的请求转发到 echo-v1。

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: echo
spec:
  parentRefs:
  - group: ""
    kind: Service
    name: echo
  rules:
  - backendRefs:
    - name: echo-v1
      port: 80

下图显示了 ztunnel 和路标之间的数据路径，如果配置了路标以执行 L7 策略。这里 ztunnel 使用 HBONE 隧道将流量发送到路标代理以进行 L7 处理。处理完成后，路标通过第二个 HBONE 隧道将流量发送到托管选定服务目标 Pod 的节点上的 ztunnel。通常，路标代理可能位于与源 Pod 或目标 Pod 相同的节点上，也可能不在同一节点上。