mirror of https://github.com/istio/istio.io.git
Sync Ambient overview and remove ztunnel docs into Chinese (#15095)
This commit is contained in:
Wilson Wu
GitHub
parent
d61aece3fe
commit
400eff0ed9
|
|
@ -1,83 +0,0 @@
|
|||
---
|
||||
title: 流量路由
|
||||
description: 了解流量如何在 Ambient 网格中的工作负载之间路由。
|
||||
weight: 2
|
||||
owner: istio/wg-networking-maintainers
|
||||
test: no
|
||||
---
|
||||
|
||||
在 {{< gloss "ambient" >}}Ambient 模式{{< /gloss >}}中，工作负载分为 3 类：
|
||||
1. **脱离网格：**这是一个标准 Pod，未启用任何网格功能。
|
||||
1. **网格内：**这是一个 Pod，其流量被 {{< gloss >}}ztunnel{{< /gloss >}} 在 4 层拦截。
|
||||
在此模式下，可以对 Pod 流量实施 L4 策略。可以通过在 Pod 的命名空间上设置 `istio.io/dataplane-mode=ambient` 标签来为 Pod 启用此模式。
|
||||
这将为该命名空间中的所有 Pod 启用**网格内**模式。
|
||||
1. **启用 waypoint：**这是一个“网格内”的 Pod，**并且**部署了 {{< gloss "waypoint" >}}waypoint 代理{{< /gloss >}}。
|
||||
|
||||
根据工作负载所属的类别，请求路径会有所不同。
|
||||
|
||||
## Ztunnel 路由 {#ztunnel-routing}
|
||||
|
||||
### 出站 {#outbound}
|
||||
|
||||
当处于 Ambient 模式中的 Pod 发出出站请求时，它将被透明地重定向到 Ztunnel，
|
||||
由 Ztunnel 来决定如何转发请求以及转发到哪儿。总之，流量路由行为就像 Kubernetes 默认的流量路由一样；
|
||||
到 `Service` 的请求将被发送到 `Service` 内的一个端点，
|
||||
而直接发送到 `Pod` IP 的请求则将直接转到该 IP。
|
||||
|
||||
然而，根据目的地的权能，可能会出现不同的行为。
|
||||
如果目的地也被添加到网格中，或以其他方式具有 Istio 代理权能（例如 Sidecar），
|
||||
请求将被升级为加密的 {{< gloss "HBONE" >}}HBONE 隧道{{< /gloss >}}。
|
||||
如果目的地有一个 waypoint 代理，除了升级到 HBONE 之外，该请求还将被转发到该 waypoint 以执行 L7 策略。
|
||||
|
||||
请注意，在向 `Service` 发出请求的情况下，如果该服务**具有**一个 waypoint，
|
||||
则该请求将被发送到其 waypoint 以对流量实施 L7 策略。
|
||||
类似地，在向 `Pod` IP 发出请求的情况下，如果 Pod **具有**一个 waypoint，
|
||||
则该请求将被发送到其 waypoint，以对流量实施 L7 策略。由于可以改变 `Deployment` 中与 Pod 关联的标签，
|
||||
因此从技术上讲，某些 Pod 可以使用 waypoint，而其他 Pod 则不能。通常建议用户避免这种高级用例。
|
||||
|
||||
### 入站 {#inbound}
|
||||
|
||||
当处于 Ambient 模式中的 Pod 收到一个入站请求时，它将被透明地重定向到 Ztunnel。
|
||||
当 Ztunnel 收到请求时，它将应用鉴权策略并仅在请求与策略匹配时转发请求。
|
||||
|
||||
Pod 可以接收 HBONE 流量或纯文本流量。这两种流量默认都可以被 Ztunnel 接受。
|
||||
因为来源自网格外的请求在评估鉴权策略时没有对等身份，
|
||||
所以用户可以设置一个策略，要求进行身份验证（可以是**任何**身份验证或特定身份验证），以阻止所有纯文本流量。
|
||||
|
||||
当目标启用 waypoint 时，如果来源位于 Ambient 网格中，
|
||||
则来源的 ztunnel 确保请求**必定**会通过强制执行策略的 waypoint。
|
||||
但是，网格外部的工作负载对 waypoint 代理一无所知，因此即使目标启用了 waypoint，
|
||||
它也会直接将请求发送到目标，而不通过任何 waypoint 代理。
|
||||
目前，来自 Sidecar 和网关的流量也不会通过任何 waypoint 代理，并且它们将在未来版本中意识到 waypoint 代理。
|
||||
|
||||
## Waypoint 路由 {#waypoint-routing}
|
||||
|
||||
waypoint 以独占方式接收 HBONE 请求。
|
||||
收到请求后，waypoint 将确保流量适用于使用它的 `Pod` 或 `Service`。
|
||||
|
||||
接受流量后，waypoint 将在转发之前强制执行 L7 策略
|
||||
（例如 `AuthorizationPolicy`、`RequestAuthentication`、`WasmPlugin`、`Telemetry` 等）。
|
||||
|
||||
对与直接发送到 `Pod` 的，请求将在应用策略后才会被直接转发。
|
||||
|
||||
对于发送到 `Service` 的请求，waypoint 还将应用路由和负载均衡。
|
||||
默认情况下，`Service` 会简单地将请求路由到本身，在其端点之间进行负载均衡。
|
||||
这可以重载为针对 `Service` 的路由。
|
||||
|
||||
例如，以下策略将确保到 `echo` 服务的请求被转发到 `echo-v1`：
|
||||
|
||||
{{< text yaml >}}
|
||||
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
|
||||
{{< /text >}}
|
||||
|
|
@ -0,0 +1,62 @@
|
|||
---
|
||||
title: 概述
|
||||
description: Istio Ambient 数据平面模式概述。
|
||||
weight: 1
|
||||
owner: istio/wg-docs-maintainers-english
|
||||
test: no
|
||||
---
|
||||
|
||||
在 **Ambient 模式**下，Istio 使用每个节点的
|
||||
Layer 4（L4）代理和可选的每个命名空间的 Layer 7（L7）代理来实现其[功能](/zh/docs/concepts)。
|
||||
|
||||
这种分层方法允许您以更加增量的方式采用 Istio，根据需要在每个命名空间的基础上，
|
||||
从无网格平滑过渡到安全的 L4 覆盖，再到完整的 L7 处理和策略。 此外，
|
||||
在不同 Istio {{< gloss "data plane" >}}数据平面{{< /gloss >}}模式下运行的工作负载可以无缝互操作，
|
||||
允许用户根据随时间变化的特定需求混合和匹配功能。
|
||||
|
||||
由于工作负载 Pod 不再需要在 Sidecar 中运行代理才能参与网格，
|
||||
因此 Ambient 模式通常被非正式地称为“无 Sidecar 网格”。
|
||||
|
||||
## 工作原理 {#how-it-works}
|
||||
|
||||
Ambient 模式将 Istio 的功能分为两个不同的层。在底层，**ztunnel** 安全覆盖处理流量的路由和零信任安全。
|
||||
除此之外，在需要时，用户可以启用 L7 **waypoint 代理**来访问 Istio 的全部功能。
|
||||
waypoint 代理虽然比单独的 ztunnel 覆盖更重，但仍然作为基础设施的 Ambient 组件运行，
|
||||
不需要对应用程序 Pod 进行修改。
|
||||
|
||||
{{< tip >}}
|
||||
使用 Sidecar 模式的 Pod 和工作负载可以与使用 Ambient 模式的 Pod 共存于同一网格内。
|
||||
术语“Ambient 网格”是指被安装时就支持 Ambient 模式的 Istio 网格，它可以支持使用任一类型数据平面的网格 Pod。
|
||||
{{< /tip >}}
|
||||
|
||||
有关 Ambient 模式的设计以及它如何与 Istio {{< gloss "control plane" >}}控制平面{{< /gloss >}}交互的详细信息，
|
||||
请参阅[数据平面](/zh/docs/ambient/architecture/data-plane)和[控制平面](/zh/docs/ambient/architecture/control-plane)架构文档。
|
||||
|
||||
## ztunnel
|
||||
|
||||
ztunnel（Zero Trust tunnel，零信任隧道）组件是一个专门构建的基于每个节点的代理，
|
||||
为 Istio 的 Ambient 数据平面模式提供支持。
|
||||
|
||||
ztunnel 负责安全连接和验证网格内的工作负载。ztunnel 代理是用 Rust 编写的，
|
||||
旨在处理 L3 和 L4 功能，例如 mTLS、身份验证、L4 鉴权和遥测。
|
||||
ztunnel 不会终止工作负载 HTTP 流量或解析工作负载 HTTP 标头。
|
||||
ztunnel 确保 L3 和 L4 流量高效、安全地传输到 waypoint 代理，
|
||||
在 waypoint 代理中实现了 Istio 的全套 L7 功能，例如 HTTP 遥测和负载均衡。
|
||||
|
||||
术语“安全覆盖”用于统一描述通过 ztunnel 代理在 Ambient 网格中实现的 L4 网络功能集。
|
||||
在传输层，这是通过称为 [HBONE](/zh/docs/ambient/architecture/hbone)
|
||||
的基于 HTTP CONNECT 的流量隧道协议来实现的。
|
||||
|
||||
## waypoint 代理 {#waypoint-proxies}
|
||||
|
||||
waypoint 代理是 {{< gloss >}}Envoy{{</ gloss >}} 代理的部署；与 Istio 用于 Sidecar 数据平面模式的引擎相同。
|
||||
|
||||
waypoint 代理在应用程序 Pod 之外运行。它们的安装、升级和扩展独立于应用程序。
|
||||
|
||||
Istio 在 Ambient 模式下的一些用例可以仅通过 L4 安全覆盖功能来解决，
|
||||
并且不需要 L7 功能，因此不需要部署 waypoint 代理。需要高级流量管理和 L7 网络功能的用例将需要部署 waypoint。
|
||||
|
||||
| 应用程序部署用例 | Ambient 模式配置 |
|
||||
| ------------------------------- | -------------------------- |
|
||||
| 通过双向 TLS、客户端应用程序流量的加密和隧道数据传输、L4 授权、L4 遥测实现零信任网络 | 仅 ztunnel（默认） |
|
||||
| 如上所述，加上高级 Istio 流量管理功能（包括 L7 授权、遥测和 VirtualService 路由） | ztunnel 及 waypoint 代理 |
|
||||
Loading…
Reference in New Issue