From f5b4bafcfeb97f96c77a2a47d15f9f14a6bd6443 Mon Sep 17 00:00:00 2001 From: kentchenjh Date: Thu, 6 Aug 2020 21:22:14 +0800 Subject: [PATCH] [zh] Fix for best-practices traffic-management (#7879) * update index.md * fix spell typo * fix spell typo again --- .../traffic-management/index.md | 46 +++++++++---------- 1 file changed, 23 insertions(+), 23 deletions(-) diff --git a/content/zh/docs/ops/best-practices/traffic-management/index.md b/content/zh/docs/ops/best-practices/traffic-management/index.md index 5805952fe4..b13d42cf7f 100644 --- a/content/zh/docs/ops/best-practices/traffic-management/index.md +++ b/content/zh/docs/ops/best-practices/traffic-management/index.md @@ -18,9 +18,9 @@ aliases: 即使最初您的服务只有一个版本，但是一旦你想要部署第二个版本，为了防止其以不受控制的方式接收流量，你需要在启用新版本 **之前** 配置路由规则。 -依赖 Istio 默认循环路由的另一个潜在问题，在于 Istio 的目标规则评估算法的微妙之处。路由请求时，Envoy 首先评估虚拟服务中的路由规则，以决定是否路由特定子集。当且仅当这样才能激活与该子集相对应的目标规则策略。因此，如果您将流量 **明确地** 路由到相应的子集，则 Istio 应该只应用您为特定子集定义的策略。 +依赖 Istio 默认循环路由的另一个潜在问题，在于 Istio 的 `DestinationRule` 评估算法的微妙之处。路由请求时，Envoy 首先评估 `VirtualService` 中的路由规则，以决定是否路由特定子集。当且仅当这样才能激活与该子集相对应的 `DestinationRule` 策略。因此，如果您将流量 **明确地** 路由到相应的子集，则 Istio 应该只应用您为特定子集定义的策略。 -例如，将以下目标规则视为 *reviews* 服务定义的唯一配置，即相应的 `VirtualService` 定义中没有路由规则： +例如，将以下 `DestinationRule` 视为 *reviews* 服务定义的唯一配置，即相应的 `VirtualService` 定义中没有路由规则： {{< text yaml >}} apiVersion: networking.istio.io/v1alpha3 @@ -79,8 +79,8 @@ spec: ## 控制配置在命名空间之间的共享{#cross-namespace-configuration} -您可以在一个命名空间中定义虚拟服务，目标规则或服务条目，然后将它们导出到其他命名空间，然后在其他命名空间中重用它们。 -Istio 默认情况下会将所有流量管理资源导出到所有命名空间，但是您可以使用 `exportTo` 字段覆盖可见性。例如，只有相同命名空间中的客户端可以使用以下虚拟服务： +您可以在一个命名空间中定义 `VirtualService` ， `DestinationRule` 或 `ServiceEntry` ，然后将它们导出到其他命名空间，然后在其他命名空间中重用它们。 +Istio 默认情况下会将所有流量管理资源导出到所有命名空间，但是您可以使用 `exportTo` 字段覆盖可见性。例如，只有相同命名空间中的客户端可以使用以下 `VirtualService` ： {{< text yaml >}} apiVersion: networking.istio.io/v1alpha3 @@ -102,13 +102,13 @@ spec: 您可以像使用 `networking.istio.io/exportTo` 批注一样控制 Kubernetes `Service` 的可见性。 {{< /tip >}} -在特定命名空间中设置目标规则的可见性并不能保证会使用该规则。将目标规则导出到其他命名空间可以使您在其它命名空间中使用它，但是要在请求时真正应用该目标规则，命名空间也必须位于目标规则查找路径上： +在特定命名空间中设置 `DestinationRule` 的可见性并不能保证会使用该规则。将 `DestinationRule` 导出到其他命名空间可以使您在其它命名空间中使用它，但是要在请求时真正应用该 `DestinationRule` ，命名空间也必须位于 `DestinationRule` 查找路径上： 1. 客户端命名空间 1. 服务命名空间 1. Istio 根配置命名空间（默认是 `istio-system`） -例如，有以下目标规则： +例如，有以下 `DestinationRule` ： {{< text yaml >}} apiVersion: networking.istio.io/v1alpha3 @@ -123,26 +123,26 @@ spec: maxConnections: 100 {{< /text >}} -假设您在命名空间 `ns1` 中创建此目标规则。 +假设您在命名空间 `ns1` 中创建此 `DestinationRule` 。 -如果从 `ns1` 中的客户端向 `myservice` 服务发送请求，则将应用目标规则，因为它在查找路径的第一个命名空间中，即在客户端命名空间中。 +如果从 `ns1` 中的客户端向 `myservice` 服务发送请求，则将应用该 `DestinationRule` ，因为它在查找路径的第一个命名空间中，即在客户端命名空间中。 -如果现在从另一个命名空间（例如 `ns2`）发送请求，则客户端将不再与目标规则 `ns1` 处于相同的命名空间。因为相应的服务 `myservice.default.svc.cluster.local` 也不在 `ns1` 中，而是在 `default` 命名空间中，所以在查找路径的第二个命名空间中也找不到目标规则 ，即服务命名空间。 +如果现在从另一个命名空间（例如 `ns2`）发送请求，则客户端将不再与 `DestinationRule` 处于相同的命名空间，即 `ns1` 。因为相应的服务 `myservice.default.svc.cluster.local` 也不在 `ns1` 中，而是在 `default` 命名空间中，所以在查找路径的第二个命名空间中也找不到 `DestinationRule` ，即服务命名空间。 -即使将 `myservice` 服务导出到所有命名空间，并因此在 `ns2` 中可见，并且目标规则也导出到包括 `ns2` 在内的所有命名空间。来自 `ns2` 的请求依然不会应用该规则，因为它不在查找路径上的任何命名空间中。 +即使将 `myservice` 服务导出到所有命名空间，并因此在 `ns2` 中可见，并且 `DestinationRule` 也导出到包括 `ns2` 在内的所有命名空间。来自 `ns2` 的请求依然不会应用该规则，因为它不在查找路径上的任何命名空间中。 -您可以通过在与相应服务相同的命名空间（在此示例中为 `default`）中创建目标规则来避免此问题。然后，它将应用于任何命名空间中的客户端请求。您也可以将目标规则移至 `istio-system` 命名空间，即查找路径上的第三个命名空间，尽管不建议这样做，除非目标规则是适用于所有命名空间的全局配置，并且这需要管理员权限。 +您可以通过在与相应服务相同的命名空间（在此示例中为 `default`）中创建 `DestinationRule` 来避免此问题。然后，它将应用于任何命名空间中的客户端请求。您也可以将 `DestinationRule` 移至 `istio-system` 命名空间，即查找路径上的第三个命名空间，尽管不建议这样做，除非 `DestinationRule` 是适用于所有命名空间的全局配置，并且这需要管理员权限。 -Istio 使用这种受限制的目标规则查找路径有两个原因： +Istio 使用这种受限制的 `DestinationRule` 查找路径有两个原因： -1. 防止定义覆盖完全不相关的命名空间中的服务行为的目标规则。 -1. 当同一主机有多个目标规则时，可以有一个清晰的查找顺序。 +1. 防止定义覆盖完全不相关的命名空间中的服务行为的 `DestinationRule` 。 +1. 当同一host有多个 `DestinationRule` 时，可以有一个清晰的查找顺序。 -## 将大型虚拟服务和目标规则拆分为多个资源{#split-virtual-services} +## 将大型 `VirtualService` 和 `DestinationRule` 拆分为多个资源{#split-virtual-services} -当不方便在单个 `VirtualService` 或 `DestinationRule` 资源中为特定主机定义完整的路由规则或策略集时，最好在多个资源中递增地指定主机的配置。如果将这些目标规则绑定到网关，Pilot 会合并这些目标规则和虚拟服务。 +当不方便在单个 `VirtualService` 或 `DestinationRule` 资源中为特定host定义完整的路由规则或策略集时，最好在多个资源中递增指定host的配置。如果将这些 `DestinationRule` 绑定到网关，Pilot 会合并这些 `DestinationRule` 和 `VirtualService` 。 -考虑绑定到入口网关的 `VirtualService` 的情况，该应用程序暴露了使用基于路径的委派给多个实现服务的应用程序主机，如下所示： +考虑一下这种情况，一个 `VirtualService` 绑定到入口网关上，并将应用的host暴露出来，该host基于路径代理了多个服务，如下所示： {{< text yaml >}} apiVersion: networking.istio.io/v1alpha3 @@ -216,17 +216,17 @@ metadata: name: myapp-... {{< /text >}} -当为现有主机应用第二个及更多的 `VirtualService`时，`istio-pilot` 会将附加的路由规则合并到主机的现有配置中。但是，在使用此功能时，有一些注意事项。 +当为已存在的host创建第二个及更多的 `VirtualService`时，`istio-pilot` 会将额外的路由规则合并到host现有配置中。但是，在使用此功能时，有一些注意事项。 -1. 尽管会保留任何给定源 `VirtualService` 中规则的评估顺序，但跨资源的顺序是 UNDEFINED。换句话说，无法保证片段配置中规则的评估顺序，因此，只有在片段规则之间没有冲突的规则或者顺序依赖性时，它才具有可预测的行为。 +1. 尽管会保留任何给定源 `VirtualService` 中规则的评估顺序，但跨资源的顺序是不确定的。换句话说，无法保证片段配置中规则的评估顺序，因此，只有在片段规则之间没有冲突的规则或者顺序依赖性时，它才具有可预测的行为。 1. 片段中应该只有一个“catch-all”规则（即与任何请求路径或 header 都匹配的规则）。所有这些“catch-all”规则将在合并配置中移至列表的末尾，但是由于它们捕获了所有请求，因此，首先应用的那个规则，实际上会覆盖并禁用其它的规则。 -1. 如果想将 `VirtualService` 绑定到网关，则只能以这种方式进行分段。sidecar 不支持主机合并。 +1. 如果想将 `VirtualService` 绑定到网关，则只能以这种方式进行分段。sidecar不支持host合并。 也可以使用类似的合并语义和限制将 `DestinationRule` 分段。 -1. 在这里，它应该只是同一主机的多个目标规则中任何给定子集的一种定义。如果有多个同名，则使用第一个定义，并丢弃随后的所有重复项。不支持子集内容的合并。 -1. 同一主机只能有一个顶级的 `trafficPolicy`。在多个目标规则中定义了顶级 `trafficPolicy` 时，将使用第一个策略。之后的所有顶级 `trafficPolicy` 配置都将被丢弃。 -1. 与虚拟服务合并不同，目标规则合并在 sidecar 和 gateway 中均有效。 +1. 在这里，它应该只是同一host的多个 `DestinationRule` 中任何给定子集的一种定义。如果有多个同名，则使用第一个定义，并丢弃随后的所有重复项。不支持子集内容的合并。 +1. 同一host只能有一个顶级的 `trafficPolicy`。在多个 `DestinationRule` 中定义了顶级 `trafficPolicy` 时，将使用第一个策略。之后的所有顶级 `trafficPolicy` 配置都将被丢弃。 +1. 与 `VirtualService` 合并不同， `DestinationRule` 合并在 sidecar 和 gateway 中均有效。 ## 避免重新配置服务路由时出现 503 错误{#avoid-5-0-3-errors-while-reconfiguring-service-routes}