mirror of https://github.com/istio/istio.io.git
[zh]improve observability wasm deployment traffic-management (#12999)
Signed-off-by: xin.li <xin.li@daocloud.io>
This commit is contained in:
my-git9
GitHub
parent
8ee897a91d
commit
daee6396e8
|
|
@ -11,34 +11,54 @@ aliases:
|
|||
- /zh/docs/concepts/policies-and-telemetry/config/
|
||||
- /zh/docs/concepts/policies-and-telemetry/
|
||||
owner: istio/wg-policies-and-telemetry-maintainers
|
||||
test: no
|
||||
test: n/a
|
||||
---
|
||||
|
||||
Istio 为网格内所有的服务通信生成详细的遥测数据。这种遥测技术提供了服务行为的**可观测性**，使运维人员能够排查故障、维护和优化应用程序，而不会给服务的开发人员带来任何额外的负担。通过 Istio，运维人员可以全面了解到受监控的服务如何与其他服务以及 Istio 组件进行交互。
|
||||
Istio 为网格内所有的服务通信生成详细的遥测数据。这种遥测技术提供了服务行为的**可观测性**，
|
||||
使运维人员能够排查故障、维护和优化应用程序，而不会给服务的开发人员带来任何额外的负担。
|
||||
通过 Istio，运维人员可以全面了解到受监控的服务如何与其他服务以及 Istio 组件进行交互。
|
||||
|
||||
Istio 生成以下类型的遥测数据，以提供对整个服务网格的可观测性：
|
||||
|
||||
- [**指标**](#metrics)。Istio 基于 4 个监控的黄金标识（延迟、流量、错误、饱和）生成了一系列服务指标。Istio 还为[网格控制平面](/zh/docs/ops/deployment/architecture/)提供了更详细的指标。除此以外还提供了一组默认的基于这些指标的网格监控仪表板。
|
||||
- [**分布式追踪**](#distributed-traces)。Istio 为每个服务生成分布式追踪 span，运维人员可以理解网格内服务的依赖和调用流程。
|
||||
- [**访问日志**](#access-logs)。当流量流入网格中的服务时，Istio 可以生成每个请求的完整记录，包括源和目标的元数据。此信息使运维人员能够将服务行为的审查控制到单个[工作负载实例](/zh/docs/reference/glossary/#workload-instance)的级别。
|
||||
- [**指标**](#metrics)。Istio 基于 4 个监控的黄金标识（延迟、流量、错误、饱和）生成了一系列服务指标。
|
||||
Istio 还为[网格控制平面](/zh/docs/ops/deployment/architecture/)提供了更详细的指标。
|
||||
除此以外还提供了一组默认的基于这些指标的网格监控仪表板。
|
||||
- [**分布式追踪**](#distributed-traces)。Istio 为每个服务生成分布式追踪 span，
|
||||
运维人员可以理解网格内服务的依赖和调用流程。
|
||||
- [**访问日志**](#access-logs)。当流量流入网格中的服务时，
|
||||
Istio 可以生成每个请求的完整记录，包括源和目标的元数据。
|
||||
此信息使运维人员能够将服务行为的审查控制到单个[工作负载实例](/zh/docs/reference/glossary/#workload-instance)的级别。
|
||||
|
||||
## 指标 {#metrics}
|
||||
|
||||
指标（Metric）提供了一种以聚合的方式监控和理解行为的方法。
|
||||
|
||||
为了监控服务行为，Istio 为服务网格中所有出入网格，以及网格内部的服务流量都生成了指标。这些指标提供了关于行为的信息，例如总流量数、错误率和请求响应时间。
|
||||
为了监控服务行为，Istio 为服务网格中所有出入网格，
|
||||
以及网格内部的服务流量都生成了指标。这些指标提供了关于行为的信息，
|
||||
例如总流量数、错误率和请求响应时间。
|
||||
|
||||
除了监控网格中服务的行为外，监控网格本身的行为也很重要。Istio 组件可以导出自身内部行为的指标，以提供对网格控制平面的功能和健康情况的洞察能力。
|
||||
除了监控网格中服务的行为外，监控网格本身的行为也很重要。
|
||||
Istio 组件可以导出自身内部行为的指标，
|
||||
以提供对网格控制平面的功能和健康情况的洞察能力。
|
||||
|
||||
### 代理级别指标 {#proxy-level-metrics}
|
||||
|
||||
Istio 指标收集从 sidecar 代理（Envoy）开始。每个代理为通过它的所有流量（入站和出站）生成一组丰富的指标。代理还提供关于它本身管理功能的详细统计信息，包括配置信息和健康信息。
|
||||
Istio 指标收集从 sidecar 代理（Envoy）开始。
|
||||
每个代理为通过它的所有流量（入站和出站）生成一组丰富的指标。
|
||||
代理还提供关于它本身管理功能的详细统计信息，包括配置信息和健康信息。
|
||||
|
||||
Envoy 生成的指标提供了资源（例如监听器和集群）粒度上的网格监控。因此，为了监控 Envoy 指标，需要了解网格服务和 Envoy 资源之间的连接。
|
||||
Envoy 生成的指标提供了资源（例如监听器和集群）粒度上的网格监控。
|
||||
因此，为了监控 Envoy 指标，需要了解网格服务和 Envoy 资源之间的连接。
|
||||
|
||||
Istio 允许运维人员在每个工作负载实例上选择生成和收集哪个 Envoy 指标。默认情况下，Istio 只支持 Envoy 生成的统计数据的一小部分，以避免依赖过多的后端服务，还可以减少与指标收集相关的 CPU 开销。然而，运维人员可以在需要时轻松地扩展收集到的代理指标集。这支持有针对性地调试网络行为，同时降低了跨网格监控的总体成本。
|
||||
Istio 允许运维人员在每个工作负载实例上选择生成和收集哪个 Envoy 指标。
|
||||
默认情况下，Istio 只支持 Envoy 生成的统计数据的一小部分，
|
||||
以避免依赖过多的后端服务，还可以减少与指标收集相关的 CPU 开销。
|
||||
然而，运维人员可以在需要时轻松地扩展收集到的代理指标集。
|
||||
这支持有针对性地调试网络行为，同时降低了跨网格监控的总体成本。
|
||||
|
||||
[Envoy 文档](https://www.envoyproxy.io/docs/envoy/latest/)包括了 [Envoy 统计信息收集](https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/observability/statistics.html?highlight=statistics)的详细说明。[Envoy 统计](/zh/docs/ops/diagnostic-tools/proxy-cmd/)里的操作手册提供了有关控制代理级别指标生成的更多信息。
|
||||
[Envoy 文档](https://www.envoyproxy.io/docs/envoy/latest/)包括了
|
||||
[Envoy 统计信息收集](https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/observability/statistics.html?highlight=statistics)的详细说明。
|
||||
[Envoy 统计](/zh/docs/ops/diagnostic-tools/proxy-cmd/)里的操作手册提供了有关控制代理级别指标生成的更多信息。
|
||||
|
||||
代理级别指标的例子：
|
||||
|
||||
|
|
@ -56,9 +76,13 @@ envoy_cluster_internal_upstream_rq{response_code="503",cluster_name="xds-grpc"}
|
|||
|
||||
### 服务级别指标 {#service-level-metrics}
|
||||
|
||||
除了代理级别指标之外，Istio 还提供了一组用于监控服务通信的面向服务的指标。这些指标涵盖了四个基本的服务监控需求：延迟、流量、错误和饱和情况。Istio 带有一组默认的[仪表板](/zh/docs/tasks/observability/metrics/using-istio-dashboard/)，用于监控基于这些指标的服务行为。
|
||||
除了代理级别指标之外，Istio 还提供了一组用于监控服务通信的面向服务的指标。
|
||||
这些指标涵盖了四个基本的服务监控需求：延迟、流量、错误和饱和情况。
|
||||
Istio 带有一组默认的[仪表板](/zh/docs/tasks/observability/metrics/using-istio-dashboard/)，
|
||||
用于监控基于这些指标的服务行为。
|
||||
|
||||
默认情况下，[标准 Istio 指标]((/zh/docs/reference/config/metrics/))会导出到 [Prometheus](/zh/docs/ops/integrations/prometheus/)。
|
||||
默认情况下，[标准 Istio 指标](/zh/docs/reference/config/metrics/)会导出到
|
||||
[Prometheus](/zh/docs/ops/integrations/prometheus/)。
|
||||
|
||||
服务级别指标的使用完全是可选的。运维人员可以选择关闭指标的生成和收集来满足自身需要。
|
||||
|
||||
|
|
@ -93,17 +117,24 @@ istio_requests_total{
|
|||
|
||||
### 控制平面指标 {#control-plane-metrics}
|
||||
|
||||
Istio 控制平面还提供了一组自我监控指标。这些指标容许监控 Istio 自己的行为（这与网格内的服务有所不同）。
|
||||
Istio 控制平面还提供了一组自我监控指标。这些指标容许监控 Istio
|
||||
自己的行为（这与网格内的服务有所不同）。
|
||||
|
||||
有关这些被维护指标的更多信息，请查看[参考文档](/zh/docs/reference/commands/pilot-discovery/#metrics)。
|
||||
|
||||
## 分布式追踪 {#distributed-traces}
|
||||
|
||||
分布式追踪通过监控流经网格的单个请求，提供了一种监控和理解行为的方法。追踪使网格的运维人员能够理解服务的依赖关系以及在服务网格中的延迟源。
|
||||
分布式追踪通过监控流经网格的单个请求，提供了一种监控和理解行为的方法。
|
||||
追踪使网格的运维人员能够理解服务的依赖关系以及在服务网格中的延迟源。
|
||||
|
||||
Istio 支持通过 Envoy 代理进行分布式追踪。代理自动为其应用程序生成追踪 span，只需要应用程序转发适当的请求上下文即可。
|
||||
Istio 支持通过 Envoy 代理进行分布式追踪。代理自动为其应用程序生成追踪 span，
|
||||
只需要应用程序转发适当的请求上下文即可。
|
||||
|
||||
Istio 支持很多追踪系统，包括 [Zipkin](/zh/docs/tasks/observability/distributed-tracing/zipkin/)、[Jaeger](/zh/docs/tasks/observability/distributed-tracing/jaeger/)、[LightStep](/zh/docs/tasks/observability/distributed-tracing/lightstep/)、[Datadog](https://www.datadoghq.com/blog/monitor-istio-with-datadog/)。运维人员控制生成追踪的采样率（每个请求生成跟踪数据的速率）。这允许运维人员控制网格生成追踪数据的数量和速率。
|
||||
Istio 支持很多追踪系统，包括 [Zipkin](/zh/docs/tasks/observability/distributed-tracing/zipkin/)、
|
||||
[Jaeger](/zh/docs/tasks/observability/distributed-tracing/jaeger/)、
|
||||
[LightStep](/zh/docs/tasks/observability/distributed-tracing/lightstep/)、
|
||||
[Datadog](https://www.datadoghq.com/blog/monitor-istio-with-datadog/)。
|
||||
运维人员控制生成追踪的采样率（每个请求生成跟踪数据的速率）。这允许运维人员控制网格生成追踪数据的数量和速率。
|
||||
|
||||
更多关于 Istio 分布式追踪的信息可以在[分布式追踪 FAQ](/zh/about/faq/distributed-tracing/) 中找到。
|
||||
|
||||
|
|
@ -115,7 +146,9 @@ Istio 为单个请求生成的分布式追踪示例：
|
|||
|
||||
访问日志提供了一种从单个工作负载实例的角度监控和理解行为的方法。
|
||||
|
||||
Istio 能够以一组可配置的格式为服务流量生成访问日志，使操作员可以完全控制日志记录的方式、内容、时间和地点。有关更多信息，请参阅[获取 Envoy 的访问日志](/zh/docs/tasks/observability/logs/access-log/)。
|
||||
Istio 能够以一组可配置的格式为服务流量生成访问日志，
|
||||
使操作员可以完全控制日志记录的方式、内容、时间和地点。
|
||||
有关更多信息，请参阅[获取 Envoy 的访问日志](/zh/docs/tasks/observability/logs/access-log/)。
|
||||
|
||||
Istio 访问日志示例：
|
||||
|
||||
|
|
|
|||
|
|
@ -7,7 +7,8 @@ owner: istio/wg-policies-and-telemetry-maintainers
|
|||
test: n/a
|
||||
---
|
||||
|
||||
WebAssembly 是一种沙盒技术，可以用于扩展 Istio 代理（Envoy）的能力。Proxy-Wasm 沙盒 API 取代了 Mixer 作为 Istio 主要的扩展机制。
|
||||
WebAssembly 是一种沙盒技术，可以用于扩展 Istio 代理（Envoy）的能力。
|
||||
Proxy-Wasm 沙盒 API 取代了 Mixer 作为 Istio 主要的扩展机制。
|
||||
|
||||
WebAssembly 沙盒的目标：
|
||||
|
||||
|
|
@ -34,8 +35,10 @@ Istio 扩展（Proxy-Wasm 插件）有几个组成部分：
|
|||
|
||||
## 例子 {#example}
|
||||
|
||||
[这里](https://github.com/envoyproxy/envoy-wasm/tree/19b9fd9a22e27fcadf61a06bf6aac03b735418e6/examples/wasm)是用 C++ 为过滤器实现 Proxy-Wasm 插件的例子。
|
||||
您可以按照[本指南](https://github.com/istio-ecosystem/wasm-extensions/blob/master/doc/write-a-wasm-extension-with-cpp.md)使用 C++ 实现 Wasm 扩展。
|
||||
[这里](https://github.com/envoyproxy/envoy-wasm/tree/19b9fd9a22e27fcadf61a06bf6aac03b735418e6/examples/wasm)是用
|
||||
C++ 为过滤器实现 Proxy-Wasm 插件的例子。
|
||||
您可以按照[本指南](https://github.com/istio-ecosystem/wasm-extensions/blob/master/doc/write-a-wasm-extension-with-cpp.md)使用
|
||||
C++ 实现 Wasm 扩展。
|
||||
|
||||
## 生态 {#ecosystem}
|
||||
|
||||
|
|
|
|||
|
|
@ -9,16 +9,23 @@ owner: istio/wg-environments-maintainers
|
|||
test: n/a
|
||||
---
|
||||
|
||||
我们确定了以下大体原则，以帮助您充分利用 Istio deployment。这些最佳实践旨在限制不良配置带来的影响，并使 deployment 管理变得更加轻松。
|
||||
我们确定了以下大体原则，以帮助您充分利用 Istio deployment。
|
||||
这些最佳实践旨在限制不良配置带来的影响，并使 deployment 管理变得更加轻松。
|
||||
|
||||
## 部署较少的集群{#deploy-fewer-clusters}
|
||||
|
||||
应该在少量的大型集群（而不是大量的小型集群）中部署 Istio。最好的做法是使用[命名空间租赁](/zh/docs/ops/deployment/deployment-models/#namespace-tenancy)来管理大型集群，而不是将集群添加到部署中。按照这种方法，您可以在每个区域或区域中的一两个集群上部署 Istio。然后，您可以在每个区域或区域的一个集群上部署控制平面，以提高可靠性。
|
||||
应该在少量的大型集群（而不是大量的小型集群）中部署 Istio。
|
||||
最好的做法是使用[命名空间租赁](/zh/docs/ops/deployment/deployment-models/#namespace-tenancy)来管理大型集群，
|
||||
而不是将集群添加到部署中。按照这种方法，您可以在每个区域或区域中的一两个集群上部署 Istio。
|
||||
然后，您可以在每个区域或区域的一个集群上部署控制平面，以提高可靠性。
|
||||
|
||||
## 在靠近用户的地方部署集群{#deploy-clusters-near-your-users}
|
||||
|
||||
在全球部署集群，实现 **在地理位置上靠近终端用户**。这有助于降低 deployment 的延迟。
|
||||
在全球部署集群，实现**在地理位置上靠近终端用户**。
|
||||
这有助于降低 deployment 的延迟。
|
||||
|
||||
## 跨多个可用区域进行部署{#deploy-across-multiple-availability-zones}
|
||||
|
||||
跨多个地域以及相同地域下不同区域部署集群。这种方法可以限制部署 {{< gloss "failure domain" >}}故障域{{< /gloss >}}的大小，有助于避免全局故障。
|
||||
跨多个地域以及相同地域下不同区域部署集群。这种方法可以限制部署
|
||||
{{< gloss "failure domain" >}}故障域{{< /gloss >}}的大小，
|
||||
有助于避免全局故障。
|
||||
|
|
|
|||
|
|
@ -18,11 +18,16 @@ test: no
|
|||
尽管默认的 Istio 行为就可以在没有配置任何规则的情况下，将任何来源的流量发送到目标服务的所有版本。
|
||||
但是，在 Istio 里的最佳做法是，从一开始就为每一个服务创建具有默认路由的 `VirtualService`。
|
||||
|
||||
即使最初您的服务只有一个版本，但是一旦你想要部署第二个版本，为了防止其以不受控制的方式接收流量，你需要在启用新版本 **之前** 配置路由规则。
|
||||
即使最初您的服务只有一个版本，但是一旦你想要部署第二个版本，为了防止其以不受控制的方式接收流量，
|
||||
你需要在启用新版本**之前**配置路由规则。
|
||||
|
||||
依赖 Istio 默认循环路由的另一个潜在问题，在于 Istio 的 `DestinationRule` 评估算法的微妙之处。路由请求时，Envoy 首先评估 `VirtualService` 中的路由规则，以决定是否路由特定子集。当且仅当这样才能激活与该子集相对应的 `DestinationRule` 策略。因此，如果您将流量 **明确地** 路由到相应的子集，则 Istio 应该只应用您为特定子集定义的策略。
|
||||
依赖 Istio 默认循环路由的另一个潜在问题，在于 Istio 的 `DestinationRule` 评估算法的微妙之处。
|
||||
路由请求时，Envoy 首先评估 `VirtualService` 中的路由规则，以决定是否路由特定子集。
|
||||
当且仅当这样才能激活与该子集相对应的 `DestinationRule` 策略。因此，如果您将流量 **明确地** 路由到相应的子集，
|
||||
则 Istio 应该只应用您为特定子集定义的策略。
|
||||
|
||||
例如，将以下 `DestinationRule` 视为 *reviews* 服务定义的唯一配置，即相应的 `VirtualService` 定义中没有路由规则：
|
||||
例如，将以下 `DestinationRule` 视为 *reviews* 服务定义的唯一配置，
|
||||
即相应的 `VirtualService` 定义中没有路由规则：
|
||||
|
||||
{{< text yaml >}}
|
||||
apiVersion: networking.istio.io/v1alpha3
|
||||
|
|
@ -62,7 +67,8 @@ spec:
|
|||
version: v1
|
||||
{{< /text >}}
|
||||
|
||||
更好的方法是，在 `VirtualService` 定义中为服务定义适当的路由规则。例如，为“reviews:v1”添加一个简单的路由规则：
|
||||
更好的方法是，在 `VirtualService` 定义中为服务定义适当的路由规则。
|
||||
例如，为“reviews:v1”添加一个简单的路由规则：
|
||||
|
||||
{{< text yaml >}}
|
||||
apiVersion: networking.istio.io/v1alpha3
|
||||
|
|
@ -81,8 +87,10 @@ spec:
|
|||
|
||||
## 控制配置在命名空间之间的共享{#cross-namespace-configuration}
|
||||
|
||||
您可以在一个命名空间中定义 `VirtualService` ， `DestinationRule` 或 `ServiceEntry` ，然后将它们导出到其他命名空间，然后在其他命名空间中重用它们。
|
||||
Istio 默认情况下会将所有流量管理资源导出到所有命名空间，但是您可以使用 `exportTo` 字段覆盖可见性。例如，只有相同命名空间中的客户端可以使用以下 `VirtualService` ：
|
||||
您可以在一个命名空间中定义 `VirtualService` ， `DestinationRule` 或 `ServiceEntry` ，
|
||||
然后将它们导出到其他命名空间，然后在其他命名空间中重用它们。
|
||||
Istio 默认情况下会将所有流量管理资源导出到所有命名空间，但是您可以使用 `exportTo` 字段覆盖可见性。
|
||||
例如，只有相同命名空间中的客户端可以使用以下 `VirtualService` ：
|
||||
|
||||
{{< text yaml >}}
|
||||
apiVersion: networking.istio.io/v1alpha3
|
||||
|
|
@ -104,7 +112,9 @@ spec:
|
|||
您可以像使用 `networking.istio.io/exportTo` 批注一样控制 Kubernetes `Service` 的可见性。
|
||||
{{< /tip >}}
|
||||
|
||||
在特定命名空间中设置 `DestinationRule` 的可见性并不能保证会使用该规则。将 `DestinationRule` 导出到其他命名空间可以使您在其它命名空间中使用它，但是要在请求时真正应用该 `DestinationRule` ，命名空间也必须位于 `DestinationRule` 查找路径上：
|
||||
在特定命名空间中设置 `DestinationRule` 的可见性并不能保证会使用该规则。
|
||||
将 `DestinationRule` 导出到其他命名空间可以使您在其它命名空间中使用它，
|
||||
但是要在请求时真正应用该 `DestinationRule` ，命名空间也必须位于 `DestinationRule` 查找路径上：
|
||||
|
||||
1. 客户端命名空间
|
||||
1. 服务命名空间
|
||||
|
|
@ -127,13 +137,21 @@ spec:
|
|||
|
||||
假设您在命名空间 `ns1` 中创建此 `DestinationRule` 。
|
||||
|
||||
如果从 `ns1` 中的客户端向 `myservice` 服务发送请求，则将应用该 `DestinationRule` ，因为它在查找路径的第一个命名空间中，即在客户端命名空间中。
|
||||
如果从 `ns1` 中的客户端向 `myservice` 服务发送请求，则将应用该 `DestinationRule` ，
|
||||
因为它在查找路径的第一个命名空间中，即在客户端命名空间中。
|
||||
|
||||
如果现在从另一个命名空间（例如 `ns2`）发送请求，则客户端将不再与 `DestinationRule` 处于相同的命名空间，即 `ns1` 。因为相应的服务 `myservice.default.svc.cluster.local` 也不在 `ns1` 中，而是在 `default` 命名空间中，所以在查找路径的第二个命名空间中也找不到 `DestinationRule` ，即服务命名空间。
|
||||
如果现在从另一个命名空间（例如 `ns2`）发送请求，则客户端将不再与 `DestinationRule` 处于相同的命名空间，
|
||||
即 `ns1` 。因为相应的服务 `myservice.default.svc.cluster.local` 也不在 `ns1` 中，
|
||||
而是在 `default` 命名空间中，所以在查找路径的第二个命名空间中也找不到 `DestinationRule` ，即服务命名空间。
|
||||
|
||||
即使将 `myservice` 服务导出到所有命名空间，并因此在 `ns2` 中可见，并且 `DestinationRule` 也导出到包括 `ns2` 在内的所有命名空间。来自 `ns2` 的请求依然不会应用该规则，因为它不在查找路径上的任何命名空间中。
|
||||
即使将 `myservice` 服务导出到所有命名空间，并因此在 `ns2` 中可见，
|
||||
并且 `DestinationRule` 也导出到包括 `ns2` 在内的所有命名空间。来自 `ns2` 的请求依然不会应用该规则，
|
||||
因为它不在查找路径上的任何命名空间中。
|
||||
|
||||
您可以通过在与相应服务相同的命名空间（在此示例中为 `default`）中创建 `DestinationRule` 来避免此问题。然后，它将应用于任何命名空间中的客户端请求。您也可以将 `DestinationRule` 移至 `istio-system` 命名空间，即查找路径上的第三个命名空间，尽管不建议这样做，除非 `DestinationRule` 是适用于所有命名空间的全局配置，并且这需要管理员权限。
|
||||
您可以通过在与相应服务相同的命名空间（在此示例中为 `default`）中创建 `DestinationRule` 来避免此问题。
|
||||
然后，它将应用于任何命名空间中的客户端请求。您也可以将 `DestinationRule` 移至 `istio-system` 命名空间，
|
||||
即查找路径上的第三个命名空间，尽管不建议这样做，除非 `DestinationRule` 是适用于所有命名空间的全局配置，
|
||||
并且这需要管理员权限。
|
||||
|
||||
Istio 使用这种受限制的 `DestinationRule` 查找路径有两个原因：
|
||||
|
||||
|
|
@ -142,9 +160,12 @@ Istio 使用这种受限制的 `DestinationRule` 查找路径有两个原因：
|
|||
|
||||
## 将大型 `VirtualService` 和 `DestinationRule` 拆分为多个资源{#split-virtual-services}
|
||||
|
||||
当不方便在单个 `VirtualService` 或 `DestinationRule` 资源中为特定host定义完整的路由规则或策略集时，最好在多个资源中递增指定host的配置。如果将这些 `DestinationRule` 绑定到网关，Pilot 会合并这些 `DestinationRule` 和 `VirtualService` 。
|
||||
当不方便在单个 `VirtualService` 或 `DestinationRule` 资源中为特定host定义完整的路由规则或策略集时，
|
||||
最好在多个资源中递增指定host的配置。如果将这些 `DestinationRule` 绑定到网关，
|
||||
Pilot 会合并这些 `DestinationRule` 和 `VirtualService` 。
|
||||
|
||||
考虑一下这种情况，一个 `VirtualService` 绑定到入口网关上，并将应用的host暴露出来，该host基于路径代理了多个服务，如下所示：
|
||||
考虑一下这种情况，一个 `VirtualService` 绑定到入口网关上，并将应用的host暴露出来，
|
||||
该host基于路径代理了多个服务，如下所示：
|
||||
|
||||
{{< text yaml >}}
|
||||
apiVersion: networking.istio.io/v1alpha3
|
||||
|
|
@ -173,7 +194,9 @@ spec:
|
|||
...
|
||||
{{< /text >}}
|
||||
|
||||
这种配置的缺点是，任何底层微服务的其他配置（例如，路由规则）也将需要包含在这个配置文件中，而不是包含在与各个服务团队关联或可能由各个服务团队拥有的单独资源中。有关详细信息，请参见[路由规则没有对 ingress gateway 请求生效](/zh/docs/ops/common-problems/network-issues/#route-rules-have-no-effect-on-ingress-gateway-requests)。
|
||||
这种配置的缺点是，任何底层微服务的其他配置（例如，路由规则）也将需要包含在这个配置文件中，
|
||||
而不是包含在与各个服务团队关联或可能由各个服务团队拥有的单独资源中。有关详细信息，
|
||||
请参见[路由规则没有对 ingress gateway 请求生效](/zh/docs/ops/common-problems/network-issues/#route-rules-have-no-effect-on-ingress-gateway-requests)。
|
||||
|
||||
为避免此问题，最好将 `myapp.com` 的配置分解为多个 `VirtualService`，每个后端服务一个。例如：
|
||||
|
||||
|
|
@ -218,7 +241,8 @@ metadata:
|
|||
name: myapp-...
|
||||
{{< /text >}}
|
||||
|
||||
当为已存在的host创建第二个及更多的 `VirtualService`时，`istio-pilot` 会将额外的路由规则合并到host现有配置中。但是，在使用此功能时，有一些注意事项。
|
||||
当为已存在的host创建第二个及更多的 `VirtualService`时，`istio-pilot` 会将额外的路由规则合并到host现有配置中。
|
||||
但是，在使用此功能时，有一些注意事项。
|
||||
|
||||
1. 尽管会保留任何给定源 `VirtualService` 中规则的评估顺序，但跨资源的顺序是不确定的。换句话说，无法保证片段配置中规则的评估顺序，因此，只有在片段规则之间没有冲突的规则或者顺序依赖性时，它才具有可预测的行为。
|
||||
1. 片段中应该只有一个“catch-all”规则（即与任何请求路径或 header 都匹配的规则）。所有这些“catch-all”规则将在合并配置中移至列表的末尾，但是由于它们捕获了所有请求，因此，首先应用的那个规则，实际上会覆盖并禁用其它的规则。
|
||||
|
|
@ -232,9 +256,14 @@ metadata:
|
|||
|
||||
## 避免重新配置服务路由时出现 503 错误{#avoid-5-0-3-errors-while-reconfiguring-service-routes}
|
||||
|
||||
在设置路由规则以将流量定向到服务的某个版本（子集）时，必须注意确保子集在路由中使用之前是可用的。否则，在重新配置期间，对服务的调用可能返回 503 错误。
|
||||
在设置路由规则以将流量定向到服务的某个版本（子集）时，必须注意确保子集在路由中使用之前是可用的。
|
||||
否则，在重新配置期间，对服务的调用可能返回 503 错误。
|
||||
|
||||
使用单个 `kubectl` 调用（例如，`kubectl apply -f myVirtualServiceAndDestinationRule.yaml`）创建定义相应子集的 `VirtualServices` 和 `DestinationRules` 是不够的，因为资源（是从配置服务器传播的，即 Kubernetes API 服务器）以最终一致的方式添加到 Pilot 实例的。如果 `VirtualService` 在定义的子集 `DestinationRule` 到达之前使用了子集，则 Pilot 生成的 Envoy 配置将引用不存在的上游池。结果就是出现 HTTP 503 错误，直到对于 Pilot 来说所有配置对象都是可用的。
|
||||
使用单个 `kubectl` 调用（例如，`kubectl apply -f myVirtualServiceAndDestinationRule.yaml`）
|
||||
创建定义相应子集的`VirtualServices` 和 `DestinationRules` 是不够的，
|
||||
因为资源（是从配置服务器传播的，即 Kubernetes API 服务器）以最终一致的方式添加到 Pilot 实例的。
|
||||
如果 `VirtualService` 在定义的子集 `DestinationRule` 到达之前使用了子集，则 Pilot 生成的 Envoy
|
||||
配置将引用不存在的上游池。结果就是出现 HTTP 503 错误，直到对于 Pilot 来说所有配置对象都是可用的。
|
||||
|
||||
为保证服务在配置带有子集的路由时的停机时间为零，请按照下述“先接后断”的流程进行操作：
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue