diff --git a/content/zh/docs/ambient/usage/add-workloads/index.md b/content/zh/docs/ambient/usage/add-workloads/index.md index b420c33f07..ad5a5cac09 100644 --- a/content/zh/docs/ambient/usage/add-workloads/index.md +++ b/content/zh/docs/ambient/usage/add-workloads/index.md @@ -7,31 +7,32 @@ test: no --- 在大多数情况下，集群管理员将部署 Istio 网格基础设施。 -一旦 Istio 被成功部署并支持 Ambient {{< gloss "data plane" >}}数据平面{{< /gloss >}}模式， -它将透明地可供所有用户在已配置为使用它的命名空间中部署的应用程序中使用。 +一旦支持 Ambient {{< gloss "data plane" >}}数据平面{{< /gloss >}}模式的 Istio 被成功部署， +在配置为可以使用 Istio 的命名空间中，Istio 将完全可用于其中所有用户所部署的应用。 -## 为网格中的应用程序启用 Ambient 模式 {#enabling-ambient-mode-for-an-application-in-the-mesh} +## 为网格中的应用启用 Ambient 模式 {#enabling-ambient-mode-for-an-application-in-the-mesh} -要在 Ambient 模式下将应用程序或命名空间添加到网格， +要在 Ambient 模式下将应用或命名空间添加到网格， 请将 `istio.io/dataplane-mode=ambient` 标签添加到相应的资源。 您可以将此标签应用于命名空间或单个 Pod。 -就应用程序 Pod 而言，可以完全透明地无缝启用（或禁用）Ambient 模式。 +就应用 Pod 而言，可以完全透明地无缝启用（或禁用）Ambient 模式。 与 {{< gloss "sidecar" >}}Sidecar{{< /gloss >}} 数据平面模式不同， -无需重新启动应用程序即可将它们添加到网格中，并且它们不会显示为在其 Pod 中部署了额外的容器。 +无需重启应用即可将它们添加到网格中，并且这些应用不会显示为在其 Pod 中部署了额外的容器。 ### Layer 4 和 Layer 7 功能 {#layer-4-and-layer-7-functionality} 安全的 L4 覆盖支持身份验证和鉴权策略。 [了解 Ambient 模式下的 L4 策略支持](/zh/docs/ambient/usage/l4-policy/)。 要选择使用 Istio 的 L7 功能（例如流量路由）， -您需要[部署一个 waypoint 代理并注册您的工作负载以使用它](/zh/docs/ambient/usage/waypoint/)。 +您需要[部署 waypoint 代理并注册您的工作负载](/zh/docs/ambient/usage/waypoint/)。 ## 不同数据平面模式下的 Pod 间通信 {#communicating-between-pods-in-different-data-plane-modes} -使用 Ambient 数据平面模式的应用程序 Pod 与非 Ambient 端点 -（包括 Kubernetes 应用程序 Pod、Istio 网关或 Kubernetes Gateway API 实例） -之间的互操作性有多种选择。这种互操作性用于在同一 Istio 网格中无缝集成 Ambient 和非 Ambient 工作负载提供了多种选项， +使用 Ambient 数据平面模式的应用 Pod 与非 Ambient 端点 +（包括 Kubernetes 应用 Pod、Istio 网关或 Kubernetes Gateway API 实例） +之间的互操作性有多种选择。这种互操作性用于在同一 Istio 网格中无缝集成 +Ambient 和非 Ambient 工作负载提供了多种选项， 从而允许以最适合网格部署和操作的需求分阶段引入 Ambient 功能。 ### 网格外的 Pod {#pods-outside-the-mesh} @@ -96,6 +97,6 @@ Sidecar 注入标签（`istio-injection=enabled`）， | `istio.io/use-waypoint` | Beta | `Namespace`、`Service` 或 `Pod` | 使用流向标记资源的 waypoint 来实施 L7 策略。

有效值：`{waypoint-name}` 或 `none`。 | | `istio.io/waypoint-for` | Alpha | `Gateway` | 指定 waypoint 将处理流量的端点类型。

有效值：`service`、`workload`、`none` 或 `all`。该标签是可选的，默认值为 `service`。 | -为了使您的 `istio.io/use-waypoint` 标签值有效，您必须确保为将处理流量的资源类型配置 waypoint。 +为了使您的 `istio.io/use-waypoint` 标签值有效，您必须确保为处理流量的资源类型配置 waypoint。 默认情况下，waypoint 接受服务流量。例如，当您通过 `istio.io/use-waypoint` 标签将 -Pod 标记为使用特定 waypoint 时，该 waypoint 应被标记为 `istio.io./waypoint-for`，且值为 `workload` 或 `all`。 +Pod 标记为使用特定 waypoint 时，该 waypoint 应打上 `istio.io./waypoint-for` 标签，取值为 `workload` 或 `all`。 diff --git a/content/zh/docs/ambient/usage/waypoint/index.md b/content/zh/docs/ambient/usage/waypoint/index.md index de5cd8dec7..58af49c17f 100644 --- a/content/zh/docs/ambient/usage/waypoint/index.md +++ b/content/zh/docs/ambient/usage/waypoint/index.md @@ -1,6 +1,6 @@ --- title: 配置 waypoint 代理 -description: 通过可选的 Layer 7 代理获得全套 Istio 功能。 +description: 通过可选的 Layer 7 代理获得完整的 Istio 功能集。 weight: 30 aliases: - /zh/docs/ops/ambient/usage/waypoint @@ -11,41 +11,41 @@ test: no **waypoint 代理** 是基于 Envoy 代理的可选部署，用于将 Layer 7（L7）处理添加到一组定义的工作负载中。 -waypoint 代理的安装、升级和扩展独立于应用程序；应用程序所有者应该不知道它们的存在。 -与在每个工作负载旁边运行 Envoy 代理实例的 Sidecar {{< gloss "data plane" >}}数据平面{{< /gloss >}}模式相比， +waypoint 代理的安装、升级和扩缩独立于应用；应用所有者不会感知到它们的存在。 +与每个工作负载并行运行 Envoy 代理实例的 Sidecar {{< gloss "data plane" >}}数据平面{{< /gloss >}}模式相比， 所需的代理数量可以大大减少。 -一个或一组 waypoint 可以在具有相似安全边界的应用程序之间共享。 +一个或一组 waypoint 可以在具有相似安全边界的应用之间共享。 这可能是特定工作负载的所有实例，或者命名空间中的所有工作负载。 -与 {{< gloss "sidecar" >}}Sidecar{{< /gloss >}} 模式相反，在 Ambient 模式下， +与 {{< gloss "sidecar" >}}Sidecar{{< /gloss >}} 模式相比，在 Ambient 模式下， 策略由**目标** waypoint 强制执行。在许多方面，waypoint 充当资源（命名空间、服务或 Pod）的网关。 Istio 强制所有进入资源的流量都经过 waypoint，然后 waypoint 强制执行该资源的所有策略。 ## 您需要 waypoint 代理吗？ {#do-you-need-a-waypoint-proxy} -Ambient 的分层方法允许用户以更加增量的方式采用 Istio， +Ambient 的分层方法允许用户以更细致的递进方式采用 Istio， 从无网格平滑过渡到安全的 L4 覆盖，再到完整的 L7 处理。 Ambient 模式的大部分功能都是由 ztunnel 节点代理提供的。 ztunnel 的范围仅限于处理 Layer 4（L4）的流量，因此它可以作为共享组件安全地运行。 -当您配置重定向到某个 waypoint 时，流量将通过 ztunnel 转发到该 waypoint。 -如果您的应用程序需要以下任何 L7 网格函数，您将需要使用 waypoint 代理： +当您配置重定向到某个 waypoint 时，流量将由 ztunnel 转发到该 waypoint。 +如果您的应用需要以下任一 L7 网格功能，您将需要使用 waypoint 代理： * **流量管理**：HTTP 路由和负载均衡、熔断、限流、故障注入、重试、超时 -* **安全性**：基于请求类型或 HTTP Header 等基于 L7 的丰富授权策略 +* **安全性**：基于请求类型或 HTTP 头等 L7 原装特性的丰富授权策略 * **可观察性**：HTTP 指标、访问日志、链路追踪 -## 部署一个 waypoint 代理 {#deploy-a-waypoint-proxy} +## 部署 waypoint 代理 {#deploy-a-waypoint-proxy} waypoint 代理使用 Kubernetes Gateway 资源被以声明方式部署。 -您可以使用 istioctl experimental 子命令来生成、应用或列出这些资源。 +您可以使用 istioctl experimental 子命令来生成、应用或列举这些资源。 -部署 waypoint 后，整个命名空间（或您选择的任何服务或 Pod）必须为[已注册](#useawaypoint)才能使用它。 +部署 waypoint 后，整个命名空间（或您选择的任何服务或 Pod）必须先[注册](#useawaypoint)才能使用。 -在为特定命名空间部署 waypoint 代理之前， -请确认该命名空间带有 `istio.io/dataplane-mode: ambient` 标签： +您在为特定命名空间部署 waypoint 代理之前， +请先确认该命名空间带有 `istio.io/dataplane-mode: ambient` 标签： {{< text bash >}} $ kubectl get ns -L istio.io/dataplane-mode @@ -55,7 +55,7 @@ default Active 24h ambient {{< /text >}} `istioctl` 可以为 waypoint 代理生成 Kubernetes Gateway 资源。 -例如，要为 `default` 命名空间生成名为 `waypoint` 的 waypoint 代理，该代理可以处理命名空间中服务的流量： +例如，要为 `default` 命名空间生成名为 `waypoint` 的 waypoint 代理，该代理可以处理命名空间中这些服务的流量： {{< text bash >}} $ istioctl experimental waypoint generate --for service -n default @@ -73,9 +73,9 @@ spec: protocol: HBONE {{< /text >}} -请注意，Gateway 资源具有被设置为 `gatewayClassName` 的 `istio-waypoint` 标签， -这表明它是 Istio 提供的 waypoint。Gateway 资源标有 `istio.io/waypoint-for: service`， -表示该 waypoint 可以处理服务的流量，这是默认的。 +请注意，Gateway 资源具有设置为 `gatewayClassName` 的 `istio-waypoint` 标签， +这表明它是 Istio 所提供的 waypoint。Gateway 资源标有 `istio.io/waypoint-for: service`， +表示该 waypoint 默认可以处理这些服务的流量。 要直接部署 waypoint 代理，请使用 `apply` 代替 `generate`： @@ -84,7 +84,7 @@ $ istioctl experimental waypoint apply -n default waypoint default/namespace applied {{< /text >}} -或者，您可以直接部署被生成的 Gateway 资源： +或者，您可以部署生成的 Gateway 资源： {{< text bash >}} $ kubectl apply -f - <}} -当 Gateway 资源被应用后，Istiod 会监控资源，自动为用户部署和管理相应的 waypoint 部署和服务。 +当 Gateway 资源被应用后，Istiod 会监控资源，自动为用户部署和管理相应的 waypoint Deployment 和服务。 ### waypoint 流量类型 {#waypoint-traffic-types} 默认情况下，waypoint 仅处理发往其命名空间中**服务**的流量。 -做出这种选择是因为单独针对 Pod 的流量很少， -并且通常被用于例如 Prometheus 抓取的内部目的，而且通过 L7 处理的额外开销是不需要的。 +做出这种选择是因为单独指向 Pod 的流量很少， +并且通常被用于 Prometheus 抓取等内部目的， +而且通过 L7 处理会产生额外开销，这是预期之外的开销。 waypoint 也可以处理所有流量，仅处理直接发送到集群中**工作负载**（Pod 或 VM）的流量， -或者根本不处理任何流量。被重定向到 waypoint 的流量类型由具有 `istio.io/waypoint-for` 标签的 `Gateway` 对象确定。 +或者根本不处理任何流量。被重定向到 waypoint 的流量类型由`Gateway` 对象上的 `istio.io/waypoint-for` 标签决定。 -`istioctl experimental waypoint apply` 的 `--for` 参数可用于更改重定向到 waypoint 的[流量类型](#waypoint-traffic-types)： +`istioctl experimental waypoint apply` 的 `--for` 参数可用于更改重定向到 waypoint +的[流量类型](#waypoint-traffic-types)： | `waypoint-for` 值 | 流量类型 | | ----------------- | ------- | @@ -127,7 +129,7 @@ waypoint 也可以处理所有流量，仅处理直接发送到集群中**工作 当 waypoint 代理被部署后，除非您显式配置某些资源来使用它，否则它默认不会被任何资源使用。 -要使命名空间、服务或 Pod 能够使用 waypoint，请添加带有 waypoint 名称值的 `istio.io/use-waypoint` 标签。 +要使命名空间、服务或 Pod 能够使用 waypoint，请添加 `istio.io/use-waypoint` 标签，取值为 waypoint 名称。 {{< tip >}} 大多数用户希望将 waypoint 应用到整个命名空间，我们建议您从这种方法开始。 @@ -149,22 +151,24 @@ namespace/default labeled {{< /text >}} 当一个命名空间被注册为使用 waypoint 后，使用 Ambient 数据平面模式的任何 Pod -向该命名空间中运行的任何服务发出的任何请求都将通过 waypoint 进行路由，以进行 L7 处理和策略执行。 +向该命名空间中运行的任何服务发出的所有请求都将通过 waypoint 进行路由，以进行 L7 处理和策略执行。 如果您喜欢更精细的操作粒度，而不是对整个命名空间使用 waypoint， -则可以仅注册特定服务或 Pod 来使用 waypoint。如果您只需要命名空间中的某些服务的 L7 功能， +则可以仅注册特定服务或 Pod 来使用 waypoint。如果您只需要命名空间中的某些服务具有 L7 功能， 如果您只想将 `WasmPlugin` 之类的扩展应用于特定服务，或者如果您正在通过其 Pod IP 地址调用 Kubernetes -[无头服务](https://kubernetes.io/zh-cn/docs/concepts/services-networking/service/#headless-services)。 +[无头服务](https://kubernetes.io/zh-cn/docs/concepts/services-networking/service/#headless-services)， +这可能很有用。 {{< tip >}} 如果命名空间和服务上都存在 `istio.io/use-waypoint` 标签， -则只要服务的 waypoint 可以处理 `service` 或 `all` 的流量，该服务的 waypoint 优先级就高于名称空间的 waypoint。 +则只要服务的 waypoint 可以处理 `service` 或 `all` 的流量， +该服务的 waypoint 优先级就高于命名空间的 waypoint。 同样，Pod 上的标签优先级高于命名空间标签。 {{< /tip >}} ### 配置服务以使用特定 waypoint {#configure-a-service-to-use-a-specific-waypoint} -使用示例 [Bookinfo 应用程序](/zh/docs/examples/bookinfo/)中的服务， +使用示例 [Bookinfo 应用](/zh/docs/examples/bookinfo/)中的服务， 我们可以为 `reviews` 服务部署一个名为 `reviews-svc-waypoint` 的 waypoint： {{< text bash >}} @@ -172,22 +176,23 @@ $ istioctl experimental waypoint apply -n default --name reviews-svc-waypoint waypoint default/reviews-svc-waypoint applied {{< /text >}} -标记 `reviews` 服务以使用 `reviews-svc-waypoint` waypoint： +为 `reviews` 服务打标签以使用 `reviews-svc-waypoint` waypoint： {{< text bash >}} $ kubectl label service reviews istio.io/use-waypoint=reviews-svc-waypoint service/reviews labeled {{< /text >}} -从网格中的 Pod 到 `reviews` 服务的任何请求现在都将通过 `reviews-svc-waypoint` waypoint 进行路由。 +从网格中的 Pod 到 `reviews` 服务的所有请求现在都将通过 `reviews-svc-waypoint` waypoint 进行路由。 ### 配置 Pod 以使用特定 waypoint {#configure-a-pod-to-use-a-specific-waypoint} 为 `reviews-v2` Pod 部署一个名为 `reviews-v2-pod-waypoint` 的 waypoint。 {{< tip >}} -回想一下，waypoint 的默认设置是针对服务；由于我们明确希望以 Pod 为目标， -因此需要使用 `istio.io/waypoint-for: workload` 标签，我们可以通过使用 istioctl 的 `--for workload` 参数来生成该标签。 +回想一下，waypoint 默认指向服务；由于我们明确希望以 Pod 为目标， +所以需要使用 `istio.io/waypoint-for: workload` 标签， +我们可以通过使用 istioctl 的 `--for workload` 参数来生成此标签。 {{< /tip >}} {{< text bash >}} @@ -202,5 +207,5 @@ $ kubectl label pod -l version=v2,app=reviews istio.io/use-waypoint=reviews-v2-p pod/reviews-v2-5b667bcbf8-spnnh labeled {{< /text >}} -从 Ambient 网格中的 Pod 到 `reviews-v2` Pod IP 的任何请求现在都将通过 +从 Ambient 网格中的 Pod 到 `reviews-v2` Pod IP 的所有请求现在都将通过 `reviews-v2-pod-waypoint` waypoint 进行路由，以进行 L7 处理和策略执行。