istio
/
istio.io
mirror of https://github.com/istio/istio.io.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

zh-translation: fix typos and some sentences in concepts (#6163) 

* zh-translation: fix typos and some sentences in concepts

* fix 2 spelling errors
This commit is contained in:
Jimmy Song 2019-12-22 16:33:06 +08:00 committed by Istio Automation
parent e2b8bc2542
commit 142f5a2294
5 changed files with 73 additions and 85 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

25
content/zh/docs/concepts/observability/index.md
View File

@ -12,23 +12,23 @@ aliases:
- /zh/docs/concepts/policies-and-telemetry/
---
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) 的级别。
- [**分布式追踪**](#distributed-traces)。Istio 为每个服务生成分布式追踪 span，运维人员可以理解网格内服务的依赖和调用流程。
- [**访问日志**](#access-logs)。当流量流入网格中的服务时，Istio 可以生成每个请求的完整记录，包括源和目标的元数据。此信息使运维人员能够将服务行为的审查控制到单个[工作负载实例](/zh/docs/reference/glossary/#workload-instance) 的级别。
## 指标 {#metrics}
指标提供了一种以聚合的方式监控和理解行为的方法。
指标（Metric）提供了一种以聚合的方式监控和理解行为的方法。
为了监控服务行为，Istio 为服务网格中所有出入的服务流量都生成了指标。这些指标提供了关于行为的信息，例如总流量数、错误率和请求响应时间。
除了监控网格中服务的行为外，监控网格本身的行为也很重要。Istio 组件可以导出自身内部行为的指标，以提供对网格控制平面的功能和健康情况的洞察能力。
Istio 指标收集由操作人员配置来驱动。操作人员决定如何以及何时收集指标，以及指标本身的详细程度。这使得它能够灵活地调整指标收集来满足个性化需求。
Istio 指标收集由运维人员配置来驱动。运维人员决定如何以及何时收集指标，以及指标本身的详细程度。这使得它能够灵活地调整指标收集来满足个性化需求。
### 代理级别指标 {#proxy-level-metrics}
@ -36,10 +36,9 @@ Istio 指标收集从 sidecar 代理（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/)里的操作手册提供了有关控制代理级别指标生成的更多信息。
代理级别指标的例子：
@ -59,11 +58,11 @@ envoy_cluster_internal_upstream_rq{response_code="503",cluster_name="xds-grpc"}
除了代理级别指标之外，Istio 还提供了一组用于监控服务通信的面向服务的指标。这些指标涵盖了四个基本的服务监控需求：延迟、流量、错误和饱和情况。Istio 带有一组默认的[仪表板](/zh/docs/tasks/observability/metrics/using-istio-dashboard/)，用于监控基于这些指标的服务行为。
[默认的 Istio 指标](/zh/docs/reference/config/policy-and-telemetry/metrics/)由 Istio 提供的配置集定义并默认导出到 [Prometheus](/zh/docs/reference/config/policy-and-telemetry/adapters/prometheus/)。操作人员可以自由地修改这些指标的形态和内容，更改它们的收集机制，以满足各自的监控需求。
[默认的 Istio 指标](/zh/docs/reference/config/policy-and-telemetry/metrics/)由 Istio 提供的配置集定义并默认导出到 [Prometheus](/zh/docs/reference/config/policy-and-telemetry/adapters/prometheus/)。运维人员可以自由地修改这些指标的形态和内容，更改它们的收集机制，以满足各自的监控需求。
[收集指标](/zh/docs/tasks/observability/metrics/collecting-metrics/)任务为定制 Istio 指标生成提供了更详细的信息。
服务级别指标的使用完全是可选的。操作人员可以选择关闭指标的生成和收集来满足自身需要。
服务级别指标的使用完全是可选的。运维人员可以选择关闭指标的生成和收集来满足自身需要。
服务级别指标的例子：
@ -103,11 +102,11 @@ istio_requests_total{
## 分布式追踪 {#distributed-traces}
分布式追踪通过监控流经网格的单个请求，提供了一种监控和理解行为的方法。追踪使网格的操作人员能够理解服务的依赖关系以及在服务网格中的延迟源。
分布式追踪通过监控流经网格的单个请求，提供了一种监控和理解行为的方法。追踪使网格的运维人员能够理解服务的依赖关系以及在服务网格中的延迟源。
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/faq/distributed-tracing/) 中找到。
@ -119,7 +118,7 @@ Istio 为一个请求生成的分布式追踪数据：
访问日志提供了一种从单个工作负载实例的角度监控和理解行为的方法。
Istio 可以以一组可配置的格式集生成服务流量的访问日志，为操作人员提供日志记录的方式、内容、时间和位置的完全控制。Istio 向访问日志机制暴露了完整的源和目标元数据，允许对网络通信进行详细的审查。
Istio 可以以一组可配置的格式集生成服务流量的访问日志，为运维人员提供日志记录的方式、内容、时间和位置的完全控制。Istio 向访问日志机制暴露了完整的源和目标元数据，允许对网络通信进行详细的审查。
访问日志可以在本地生成，或者导出到自定义的后端基础设施，包括 [Fluentd](/zh/docs/tasks/observability/logs/fluentd/)。

6
content/zh/docs/concepts/policies/index.md
View File

@ -7,10 +7,10 @@ keywords: [policy,policies]
Istio 允许您为应用程序自定义策略，用以在运行时强制执行相应的规则，例如：
- 限流用于动态限制服务流量
- 限流用于动态限制发送给服务的流量
- Denials、白名单和黑名单用于限制服务的访问
- Header 的重写和重定向
Istio 还允许您创建自己的 [策略适配器](/zh/docs/tasks/policy-enforcement/control-headers)，比如，您自定义的授权行为。
Istio 还允许您创建自己的[策略适配器](/zh/docs/tasks/policy-enforcement/control-headers)，比如，您自定义的授权行为。
您必须为您的服务网格 [启用策略实施](/zh/docs/tasks/policy-enforcement/enabling-policy) 以后才能使用此功能。
您必须为您的服务网格[启用策略实施](/zh/docs/tasks/policy-enforcement/enabling-policy) 以后才能使用此功能。

46
content/zh/docs/concepts/security/index.md
View File

@ -54,13 +54,9 @@ Istio 中的安全性涉及多个组件：
## Istio 身份{#istio-identity}
身份是任何安全基础架构的基本概念。在服务间通信开始时，双方必须与其身份信息交换凭证以用于相互认证目的。
在客户端，根据[安全命名](/zh/docs/concepts/security/#secure-naming)信息检查服务器的标识，以查看它是否是该服务的授权运行程序。
在服务器端，服务器可以根据[授权策略](/zh/docs/concepts/security/#authorization-policy)确定客户端可以访问哪些信息，审核谁在什么时间访问了什么，根据服务向客户收费他们使用并拒绝任何未能支付账单的客户访问服务。
身份是任何安全基础架构的基本概念。在服务间通信开始时，双方必须与其身份信息交换凭证以用于相互认证目的。在客户端，根据[安全命名](/zh/docs/concepts/security/#secure-naming)信息检查服务器的标识，以查看它是否是该服务的授权运行程序。在服务器端，服务器可以根据[授权策略](/zh/docs/concepts/security/#authorization-policy)确定客户端可以访问哪些信息，审核谁在什么时间访问了什么，根据服务向客户收费并拒绝任何未能支付账单的客户访问服务。
在 Istio 身份模型中，Istio 使用一流的服务标识来确定服务的身份。
这为表示人类用户，单个服务或一组服务提供了极大的灵活性和粒度。
在没有此类身份的平台上，Istio 可以使用可以对服务实例进行分组的其他身份，例如服务名称。
在 Istio 身份模型中，Istio 使用一流的服务标识来确定服务的身份。这为表示人类用户，单个服务或一组服务提供了极大的灵活性和粒度。在没有此类身份的平台上，Istio 可以使用可以对服务实例进行分组的其他身份，例如服务名称。
不同平台上的 Istio 服务标识：
@ -70,7 +66,7 @@ Istio 中的安全性涉及多个组件：
- **GCP**： GCP 服务帐户
- **AWS**： AWS IAM 用户/角色 帐户
- **AWS**： AWS IAM 用户/角色帐户
- **本地（非 Kubernetes）**： 用户帐户、自定义服务帐户、服务名称、Istio 服务帐户或 GCP 服务帐户。
@ -80,8 +76,7 @@ Istio 中的安全性涉及多个组件：
[SPIFFE](https://spiffe.io/) 标准提供了一个框架规范，该框架能够跨异构环境引导和向服务发布身份。
Istio 和 SPIFFE 共享相同的身份文件：[SVID](https://github.com/spiffe/spiffe/blob/master/standards/SPIFFE-ID.md)（SPIFFE 可验证身份证件）。
例如，在 Kubernetes 中，X.509 证书的 URI 字段格式为 `spiffe://<domain>/ns/<namespace>/sa/<serviceaccount>`。
Istio 和 SPIFFE 共享相同的身份文件：[SVID](https://github.com/spiffe/spiffe/blob/master/standards/SPIFFE-ID.md)（SPIFFE 可验证身份证件）。例如，在 Kubernetes 中，X.509 证书的 URI 字段格式为 `spiffe://<domain>/ns/<namespace>/sa/<serviceaccount>`。
这使 Istio 服务能够建立和接受与其他 SPIFFE 兼容系统的连接。
Istio 安全性和 [SPIRE](https://spiffe.io/spire/)，它是 SPIFFE 的实现，在 PKI 实现细节上有所不同。
@ -90,18 +85,15 @@ Istio 提供更全面的安全解决方案，包括身份验证、授权和审
## PKI{#PKI}
Istio PKI 建立在 Istio Citadel 之上，可为每个工作负载安全地提供强大的工作负载标识。
Istio 使用 X.509 证书来携带 [SPIFFE](https://spiffe.io/) 格式的身份。
PKI 还可以大规模自动化密钥和证书轮换。
Istio PKI 建立在 Istio Citadel 之上，可为每个工作负载安全地提供强大的工作负载标识。Istio 使用 X.509 证书来携带 [SPIFFE](https://spiffe.io/) 格式的身份。PKI 还可用于大规模自动化密钥和证书轮换。
Istio 支持在 Kubernetes pod 和本地计算机上运行的服务。
目前，我们为每个方案使用不同的证书密钥配置机制。
Istio 支持在 Kubernetes pod 和本地计算机上运行的服务。目前，我们为每个方案使用不同的证书密钥配置机制。
### Kubernetes 方案{#Kubernetes-scenario}
1. Citadel 监视 Kubernetes `apiserver`，为每个现有和新的服务帐户创建 SPIFFE 证书和密钥对。Citadel 将证书和密钥对存储为 [Kubernetes secret](https://kubernetes.io/docs/concepts/configuration/secret/)。
1. 创建 pod 时，Kubernetes 会根据其服务帐户通过 [Kubernetes secret volume](https://kubernetes.io/docs/concepts/storage/volumes/#secret) 将证书和密钥对挂载到 pod。
1. 创建 pod 时，Kubernetes 会根据其服务帐户通过 [Kubernetes secret volume](https://kubernetes.io/docs/concepts/storage/volumes/#secret) 将证书和密钥对挂载到 pod 上。
1. Citadel 监视每个证书的生命周期，并通过重写 Kubernetes secret 自动轮换证书。
@ -140,28 +132,28 @@ Istio 提供了在 Kubernetes 中使用节点代理进行证书和密钥分配
1. 上述 CSR 过程会定期重复进行证书和密钥轮换。
{{< idea >}}
使用节点代理调试端点可以查看节点代理当前正在为其客户端代理提供服务的 secrets。访问代理程序端口 `8080` 上的 `/debug/sds/workload` 以获取当前工作负载 secrets，或访问 `/debug/sds/gateway` 以获取当前网关 secrets。
使用节点代理调试端点可以查看节点代理当前正在为其客户端代理提供服务的 secret。访问代理程序 `8080` 端口上的 `/debug/sds/workload` 以获取当前工作负载 secret，或访问 `/debug/sds/gateway` 以获取当前网关 secret。
{{< /idea >}}
## 认证{#authentication}
Istio 提供两种类型的身份验证：
- **传输身份验证**，也称为**服务到服务身份验证**：验证建立连接的直接客户端。
- **传输身份验证**，也称为**服务间身份验证**：验证建立连接的直接客户端。
Istio 提供 [双向 TLS](https://en.wikipedia.org/wiki/Mutual_authentication) 作为传输身份验证的完整堆栈解决方案。
您可以轻松打开此功能，而无需更改服务代码。这个解决方案：
- 为每个服务提供强大的身份，表示其角色，以实现跨群集和云的互操作性。
- 保护服务到服务通信和最终用户到服务通信。
- 保护服务到服务通信和最终用户到服务的通信。
- 提供密钥管理系统，以自动执行密钥和证书生成，分发和轮换。
- **来源身份认证**，也称为**最终用户身份验证**：验证作为最终用户或设备发出请求的原始客户端。Istio 通过 JSON Web Token（JWT）验证和 [ORY Hydra](https://www.ory.sh)、[Keycloak](https://www.keycloak.org)，[Auth0](https://auth0.com/)、[Firebase Auth](https://firebase.google.com/docs/auth/)、[Google Auth](https://developers.google.com/identity/protocols/OpenIDConnect) 和自定义身份验证来简化开发人员体验，并且轻松实现请求级别的身份验证。
- **来源身份认证**，也称为**最终用户身份验证**：验证作为最终用户或设备发出请求的原始客户端。Istio 通过 JSON Web Token（JWT）验证和 [ORY Hydra](https://www.ory.sh)、[Keycloak](https://www.keycloak.org)、[Auth0](https://auth0.com/)、[Firebase Auth](https://firebase.google.com/docs/auth/)、[Google Auth](https://developers.google.com/identity/protocols/OpenIDConnect) 和自定义身份验证来简化开发人员体验，并且轻松实现请求级别的身份验证。
在这两种情况下，Istio 都通过自定义 Kubernetes API 将身份认证策略存储在 `Istio 配置存储`中。 Pilot 会在适当的时候为每个代理保持最新状态以及密钥。此外，Istio 支持在宽容模式下进行身份验证，以帮助您了解策略更改在其生效之前如何影响您的安全状态。
在这两种情况下，Istio 都通过自定义 Kubernetes API 将身份认证策略存储在 Istio 配置存储中。Pilot 会在适当的时候为每个代理保持最新状态以及密钥。此外，Istio 支持在宽容模式（permissive mode）下进行身份验证，以帮助您了解策略更改在其生效之前如何影响您的安全状态。
### 双向 TLS 认证{#mutual-TLS-authentication}
Istio 隧道通过客户端和服务器端进行服务到服务通信 [Envoy 代理](https://envoyproxy.github.io/envoy/)。为了使客户端通过双向 TLS 调用服务端，请遵循以下步骤：
Istio 隧道通过客户端和服务器端进行服务间（service-to-service）通信 [Envoy 代理](https://envoyproxy.github.io/envoy/)。为了使客户端通过双向 TLS 调用服务端，请遵循以下步骤：
1. Istio 将出站流量从客户端重新路由到客户端的本地 sidecar Envoy。
@ -177,7 +169,7 @@ Istio 双向 TLS 具有一个宽容模式（permissive mode），允许 service
在运维人员希望将服务移植到启用了双向 TLS 的 Istio 上时，许多非 Istio 客户端和非 Istio 服务端通信时会产生问题。通常情况下，运维人员无法同时为所有客户端安装 Istio sidecar，甚至没有这样做的权限。即使在服务端上安装了 Istio sidecar，运维人员也无法在不中断现有连接的情况下启用双向 TLS。
启用宽容模式后，服务同时接受纯文本和双向 TLS 流量。这个模式为入门提供了极大的灵活性。服务中安装的 Istio sidecar 立即接受双向 TLS 流量而不会打断现有的纯文本流量。因此，运维人员可以逐步安装和配置客户端 Istio sidecars 发送双向 TLS 流量。一旦客户端配置完成，运维人员便可以将服务端配置为仅 TLS 模式。更多信息请访问[双向 TLS 迁移向导](/zh/docs/tasks/security/authentication/mtls-migration)。
启用宽容模式后，服务可以同时接受纯文本和双向 TLS 流量。这个模式为入门提供了极大的灵活性。服务中安装的 Istio sidecar 立即接受双向 TLS 流量而不会打断现有的纯文本流量。因此，运维人员可以逐步安装和配置客户端 Istio sidecar 发送双向 TLS 流量。一旦客户端配置完成，运维人员便可以将服务端配置为仅 TLS 模式。更多信息请访问[双向 TLS 迁移向导](/zh/docs/tasks/security/authentication/mtls-migration)。
#### 安全命名{#secure-naming}
@ -191,7 +183,7 @@ Istio 双向 TLS 具有一个宽容模式（permissive mode），允许 service
### 认证架构{#authentication-architecture}
您可以使用身份认证策略为在 Istio 网格中接收请求的服务指定身份验证要求。网格操作者使用 `.yaml` 文件来指定策略。部署后，策略将保存在 `Istio Config Store`。Pilot、Istio 控制器监视配置存储。一有任何的策略变更，Pilot 会将新策略转换为适当的配置，告知 Envoy sidecar 代理如何执行所需的身份验证机制。Pilot 可以获取公钥并将其附加到 JWT 验证配置。或者，Pilot 提供 Istio 系统管理的密钥和证书的路径，并将它们挂载到应用程序 pod 以进行双向 TLS。您可以在 [PKI 部分](/zh/docs/concepts/security/#PKI)中找到更多信息。Istio 异步发送配置到目标端点。代理收到配置后，新的身份验证要求会立即生效。
您可以使用身份认证策略为在 Istio 网格中接收请求的服务指定身份验证要求。网格操作者使用 `.yaml` 文件来指定策略。部署后，策略将保存在 Istio 配置存储中。Pilot、Istio 控制器监视配置存储。一有任何的策略变更，Pilot 会将新策略转换为适当的配置，告知 Envoy sidecar 代理如何执行所需的身份验证机制。Pilot 可以获取公钥并将其附加到 JWT 验证配置。或者，Pilot 提供 Istio 系统管理的密钥和证书的路径，并将它们挂载到应用程序 pod 以进行双向 TLS。您可以在 [PKI 部分](/zh/docs/concepts/security/#PKI)中找到更多信息。Istio 异步发送配置到目标端点。代理收到配置后，新的身份验证要求会立即生效。
发送请求的客户端服务负责遵循必要的身份验证机制。对于源身份验证（JWT），应用程序负责获取 JWT 凭据并将其附加到请求。对于双向 TLS，Istio 提供[目标规则](/zh/docs/concepts/traffic-management/#destination-rules)。运维人员可以使用目标规则来指示客户端代理使用 TLS 与服务器端预期的证书进行初始连接。您可以在 [双向 TLS 认证](/zh/docs/concepts/security/#mutual-TLS-authentication)中找到有关双向 TLS 如何在 Istio 中工作的更多信息。
@ -246,14 +238,14 @@ Istio 可以在命名空间范围或网络范围存储中存储身份认证策
- mtls: {}
{{< /text >}}
命名空间范围存储中的策略只能影响同一命名空间中的服务。网格范围内的策略可以影响网格中的所有服务。为防止冲突和滥用，只能在网状范围存储中定义一个策略。该策略必须命名为 `default` 并且有一个空的 `targets:` 部分。您可以在我们的[目标选择器部分](/zh/docs/concepts/security/#target-selectors)中找到更多信息。
命名空间范围存储中的策略只能影响同一命名空间中的服务。网格范围内的策略可以影响网格中的所有服务。为防止冲突和滥用，只能在网格范围存储中定义一个策略。该策略必须命名为 `default` 并且有一个空的 `targets:` 部分。您可以在我们的[目标选择器部分](/zh/docs/concepts/security/#target-selectors)中找到更多信息。
#### 目标选择器{#target-selectors}
身份认证策略的目标指定策略适用的服务。以下示例展示的是一个 `targets:` 部分，指定该策略适用于：
- 任何端口上的 `product-page` 服务。
- 端口 `9000` 上的评论服务。
- `9000` 端口上的 reviews 服务。
{{< text yaml >}}
targets:
@ -297,7 +289,7 @@ peers:
#### 来源身份认证{#origin-authentication}
`origins:` 部分定义了原始身份验证支持的身份验证方法和相关参数。Istio 仅支持 JWT 原始身份验证。但是，策略可以列出不同发行者的多个 JWT。与传输身份验证类似，只有一种列出的方法必须满足身份验证才能通过。
`origins:` 部分定义了原始身份验证支持的身份验证方法和相关参数。Istio 仅支持 JWT 原始身份验证。但是，策略可以列出不同发行者的多个 JWT。与传输身份验证类似，要想通过身份验证必须通过其中的一个。
以下示例策略为原始身份验证指定了一个 `origin:` 部分，该部分接受 Google 发布的 JWT。路径的 JWT 身份验证 `/health` 已禁用。
@ -369,7 +361,7 @@ Istio 的授权功能为 Istio 网格中的工作负载提供网格级别、命
### 授权策略{#authorization-policy}
要配置 Istio 授权策略，请创建一个 [`AuthorizationPolicy` resource](/zh/docs/reference/config/security/authorization-policy/)。
要配置 Istio 授权策略，请创建一个 [`AuthorizationPolicy` 资源](/zh/docs/reference/config/security/authorization-policy/)。
授权策略包括选择器和规则列表。
选择器指定策略所适用的**目标**，而规则指定什么**条件**下允许**谁**做**什么**。

63
content/zh/docs/concepts/traffic-management/index.md
View File

@ -13,7 +13,7 @@ aliases:
- /zh/docs/concepts/traffic-management/pilot.html
---
Istio 的流量路由规则可以让您很容易的控制服务之间的流量和 API 调用。Istio 简化了服务级别属性的配置，比如熔断器、超时和重试，并且能轻松的设置重要的任务，如 A/B 测试、金丝雀发布、基于流量百分比切分的概率发布等。它还提供了开箱即用的故障恢复特性，有助于增强应用的健壮性，从而更好地应对被依赖的服务或网络发生故障。
Istio 的流量路由规则可以让您很容易的控制服务之间的流量和 API 调用。Istio 简化了服务级别属性的配置，比如熔断器、超时和重试，并且能轻松的设置重要的任务，如 A/B 测试、金丝雀发布、基于流量百分比切分的概率发布等。它还提供了开箱即用的故障恢复特性，有助于增强应用的健壮性，从而更好地应对被依赖的服务或网络发生故障的情况。
Istio 的流量管理模型源于和服务一起部署的 {{< gloss >}}Envoy{{</ gloss >}} 代理。网格内服务发送和接收的所有流量（{{< gloss >}}data plane{{</ gloss >}}流量）都经由 Envoy 代理，这让控制网格内的流量变得异常简单，而且不需要对服务做任何的更改。
@ -21,7 +21,7 @@ Istio 的流量管理模型源于和服务一起部署的 {{< gloss >}}Envoy{{</
## Istio 流量管理介绍 {#introducing-Istio-traffic-management}
为了在网格中导流，Istio 需要知道所有的 endpoints 在哪里，它们属于哪个服务。为了定位到{{< gloss >}}service registry{{</ gloss >}}(服务注册中心)，Istio 会连接到一个服务发现系统。例如，如果您在 Kubernetes 集群上安装了 Istio，那么它将自动检测该集群中的服务和 endpoints。
为了在网格中导流，Istio 需要知道所有的 endpoint 在哪和属于哪个服务。为了定位到{{< gloss >}}service registry{{</ gloss >}}(服务注册中心)，Istio 会连接到一个服务发现系统。例如，如果您在 Kubernetes 集群上安装了 Istio，那么它将自动检测该集群中的服务和 endpoint。
使用此服务注册中心，Envoy 代理可以将流量定向到相关服务。大多数基于微服务的应用程序，每个服务的工作负载都有多个实例来处理流量，称为负载均衡池。默认情况下，Envoy 代理基于轮询调度模型在服务的负载均衡池内分发流量，按顺序将请求发送给池中每个成员，一旦所有服务实例均接收过一次请求后，重新回到第一个池成员。
@ -35,13 +35,13 @@ Istio 基本的服务发现和负载均衡能力为您提供了一个可用的
- [目标规则](#destination-rules)
- [网关](#gateways)
- [服务入口](#service-entries)
- [Sidecars](#sidecars)
- [Sidecar](#sidecars)
指南也对构建在 API 资源内的[网络弹性和测试](#network-resilience-and-testing)做了概述。
## 虚拟服务 {#virtual-services}
[虚拟服务](/zh/docs/reference/config/networking/virtual-service/#VirtualService)和[目标规则](#destination-rules)是 Istio 流量路由功能的关键拼图。虚拟服务让您配置如何在服务网格内将请求路由到服务，这基于 Istio 和平台提供的基本的连通性和服务发现能力。每个虚拟服务包含一组路由规则，Istio 按顺序评估它们，Istio 将每个给定的请求匹配到虚拟服务指定的实际目标地址。您的网格可以有多个虚拟服务，也可以没有，取决于您的使用场景。
[虚拟服务（Virtual Service）](/zh/docs/reference/config/networking/virtual-service/#VirtualService)和[目标规则（Destination Rule）](#destination-rules)是 Istio 流量路由功能的关键拼图。虚拟服务让您配置如何在服务网格内将请求路由到服务，这基于 Istio 和平台提供的基本的连通性和服务发现能力。每个虚拟服务包含一组路由规则，Istio 按顺序评估它们，Istio 将每个给定的请求匹配到虚拟服务指定的实际目标地址。您的网格可以有多个虚拟服务，也可以没有，取决于您的使用场景。
### 为什么使用虚拟服务？{#why-use-virtual-services}
@ -49,8 +49,7 @@ Istio 基本的服务发现和负载均衡能力为您提供了一个可用的
为什么这如此有用？就像在介绍中所说，如果没有虚拟服务，Envoy 会在所有的服务实例中使用轮询的负载均衡策略分发请求。您可以用您对工作负载的了解来改善这种行为。例如，有些可能代表不同的版本。这在 A/B 测试中可能有用，您可能希望在其中配置基于不同服务版本的流量百分比路由，或指引从内部用户到特定实例集的流量。
使用虚拟服务，您可以为一个或多个主机名指定流量行为。在虚拟服务中使用路由规则，告诉 Envoy 如何发送
虚拟服务的流量到适当的目标。路由目标地址可以是相同服务的版本，也可以是完全不同的服务。
使用虚拟服务，您可以为一个或多个主机名指定流量行为。在虚拟服务中使用路由规则，告诉 Envoy 如何发送虚拟服务的流量到适当的目标。路由目标地址可以是同一服务的不同版本，也可以是完全不同的服务。
一个典型的用例是将流量发送到被指定为服务子集的服务的不同版本。客户端将虚拟服务视为一个单一实体，将请求发送至虚拟服务主机，然后 Envoy 根据虚拟服务规则把流量路由到不同的版本。例如，“20%的调用转到新版本”或“将这些用户的调用转到版本 2”。这允许您创建一个金丝雀发布，逐步增加发送到新版本服务的流量百分比。流量路由完全独立于实例部署，这意味着实现新版本服务的实例可以根据流量的负载来伸缩，完全不影响流量路由。相比之下，像 Kubernetes 这样的容器编排平台只支持基于实例缩放的流量分发，这会让情况变得复杂。您可以在[使用 Istio 进行金丝雀部署](/zh/blog/2017/0.1-canary/)的文章里阅读到更多用虚拟服务实现金丝雀部署的内容。
@ -90,22 +89,22 @@ spec:
#### hosts 字段 {#the-hosts-field}
使用`hosts`字段列举虚拟服务的主机——即用户指定的目标或是路由规则设定的目标。这是客户端向服务发送请求时使用的一个或多个地址。
使用 `hosts` 字段列举虚拟服务的主机——即用户指定的目标或是路由规则设定的目标。这是客户端向服务发送请求时使用的一个或多个地址。
{{< text yaml >}}
hosts:
- reviews
{{< /text >}}
虚拟服务主机名可以是 IP 地址、DNS 名称，或者依赖于平台的一个简称（例如 Kubernetes 服务的短名称），隐式或显式地指向一个完全限定域名（FQDN）。您也可以使用通配符（"\*"）前缀，让您创建一组匹配所有服务的路由规则。虚拟服务的`hosts`字段实际上不必是 Istio 服务注册的一部分，它只是虚拟的目标地址。这让您可以为没有路由到网格内部的虚拟主机建模。
虚拟服务主机名可以是 IP 地址、DNS 名称，或者依赖于平台的一个简称（例如 Kubernetes 服务的短名称），隐式或显式地指向一个完全限定域名（FQDN）。您也可以使用通配符（“\*”）前缀，让您创建一组匹配所有服务的路由规则。虚拟服务的 `hosts` 字段实际上不必是 Istio 服务注册的一部分，它只是虚拟的目标地址。这让您可以为没有路由到网格内部的虚拟主机建模。
#### 路由规则 {#routing-rules}
在`http`字段包含了虚拟服务的路由规则，用来描述匹配条件和路由行为，它们把 HTTP/1.1、HTTP2 和 gRPC 等流量发送到 hosts 字段指定的目标（您也可以用`tcp`和`tls`片段为 [TCP](/zh/docs/reference/config/networking/virtual-service/#TCPRoute) 和未终止的 [TLS](/zh/docs/reference/config/networking/virtual-service/#TLSRoute) 流量设置路由规则）。一个路由规则包含了指定的请求要流向哪个目标地址，具有 0 或多个匹配条件，取决于您的使用场景。
在 `http` 字段包含了虚拟服务的路由规则，用来描述匹配条件和路由行为，它们把 HTTP/1.1、HTTP2 和 gRPC 等流量发送到 hosts 字段指定的目标（您也可以用 `tcp` 和 `tls` 片段为 [TCP](/zh/docs/reference/config/networking/virtual-service/#TCPRoute) 和未终止的 [TLS](/zh/docs/reference/config/networking/virtual-service/#TLSRoute) 流量设置路由规则）。一个路由规则包含了指定的请求要流向哪个目标地址，具有 0 或多个匹配条件，取决于您的使用场景。
##### 匹配条件 {#match-condition}
示例中的第一个路由规则有一个条件，因此以`match`字段开始。在本例中，您希望此路由应用于来自”jason“用户的所有请求，所以使用`headers`、`end-user` 和 `exact`字段选择适当的请求。
示例中的第一个路由规则有一个条件，因此以 `match` 字段开始。在本例中，您希望此路由应用于来自 ”jason“ 用户的所有请求，所以使用 `headers`、`end-user` 和 `exact` 字段选择适当的请求。
{{< text yaml >}}
- match:
@ -116,8 +115,7 @@ hosts:
##### Destination {#destination}
route 部分的`destination`字段指定了符合此条件的流量的实际目标地址。与虚拟服务的 host 不同，
destination 的 host 必须是存在于 Istio 服务注册中心的实际目标地址，否则 Envoy 不知道将请求发送到哪里。可以是一个有代理的服务网格，或者是一个通过服务入口被添加进来的非网格服务。本示例运行在 Kubernetes 环境中，host 名为一个 Kubernetes 服务名：
route 部分的 `destination` 字段指定了符合此条件的流量的实际目标地址。与虚拟服务的 `hosts` 不同，destination 的 host 必须是存在于 Istio 服务注册中心的实际目标地址，否则 Envoy 不知道该将请求发送到哪里。可以是一个有代理的服务网格，或者是一个通过服务入口被添加进来的非网格服务。本示例运行在 Kubernetes 环境中，host 名为一个 Kubernetes 服务名：
{{< text yaml >}}
route:
@ -126,13 +124,13 @@ route:
subset: v2
{{< /text >}}
请注意，在该示例和本页其它示例中，为了简单，我们使用 Kubernetes 的短名称设置 destination 的 hosts。在评估此规则时，Istio 会添加一个基于虚拟服务命名空间的域后缀，这个虚拟服务包含要获取主机的完全限定名的路由规则。在我们的示例中使用短名称也意味着您可以复制并在任何喜欢的命名空间中尝试它们。
请注意，在该示例和本页其它示例中，为了简单，我们使用 Kubernetes 的短名称设置 destination 的 host。在评估此规则时，Istio 会添加一个基于虚拟服务命名空间的域后缀，这个虚拟服务包含要获取主机的完全限定名的路由规则。在我们的示例中使用短名称也意味着您可以复制并在任何喜欢的命名空间中尝试它们。
{{< warning >}}
只有在目标主机和虚拟服务位于相同的 Kubernetes 命名空间时才可以使用这样的短名称。因为使用 Kubernetes 的短名称容易导致配置出错，我们建议您在生产环境中指定完全限定的主机名。
{{< /warning >}}
destination 片段还指定了 Kubernetes 服务的子集，将符合此规则条件的请求转入其中。在本例中子集名称是 v2。您可以在 [目标规则](#destination-rules) 章节中看到如何定义服务子集。
destination 片段还指定了 Kubernetes 服务的子集，将符合此规则条件的请求转入其中。在本例中子集名称是 v2。您可以在[目标规则](#destination-rules)章节中看到如何定义服务子集。
#### 路由规则优先级 {#routing-rule-precedence}
@ -149,7 +147,7 @@ destination 片段还指定了 Kubernetes 服务的子集，将符合此规则
### 路由规则的更多内容 {#more-about-routing-rules}
正如上面所看到的，路由规则是将特定流量子集路由到指定目标地址的强大工具。您可以在流量端口、header 字段、URI 等内容上设置匹配条件。例如，这个虚拟服务让用户发送请求到两个独立的服务：ratings 和 reviews，就好像它们是 `http://bookinfo.com/`这个更大的虚拟服务的一部分。虚拟服务规则根据请求的 URI 和指向适当服务的请求匹配流量。
正如上面所看到的，路由规则是将特定流量子集路由到指定目标地址的强大工具。您可以在流量端口、header 字段、URI 等内容上设置匹配条件。例如，这个虚拟服务让用户发送请求到两个独立的服务：ratings 和 reviews，就好像它们是 `http://bookinfo.com/` 这个更大的虚拟服务的一部分。虚拟服务规则根据请求的 URI 和指向适当服务的请求匹配流量。
{{< text yaml >}}
apiVersion: networking.istio.io/v1alpha3
@ -184,7 +182,7 @@ spec:
有些匹配条件可以使用精确的值，如前缀或正则。
您可以使用 AND 向同一个`match`块添加多个匹配条件，或者使用 OR 向同一个规则添加多个`match`块。对于任何给定的虚拟服务也可以有多个路由规则。这可以在单个虚拟服务中使路由条件变得随您所愿的复杂或简单。匹配条件字段和备选值的完整列表可以在[`HTTPMatchRequest` 参考](/zh/docs/reference/config/networking/virtual-service/#HTTPMatchRequest)中找到。
您可以使用 AND 向同一个 `match` 块添加多个匹配条件，或者使用 OR 向同一个规则添加多个 `match` 块。对于任何给定的虚拟服务也可以有多个路由规则。这可以在单个虚拟服务中使路由条件变得随您所愿的复杂或简单。匹配条件字段和备选值的完整列表可以在 [`HTTPMatchRequest` 参考](/zh/docs/reference/config/networking/virtual-service/#HTTPMatchRequest)中找到。
另外，使用匹配条件您可以按百分比”权重“分发请求。这在 A/B 测试和金丝雀发布中非常有用：
@ -210,7 +208,7 @@ spec:
- 重写 URL。
- 为调用这一目标地址的请求设置[重试策略](#retries)。
想了解如何利用这些操作，查看 [`HTTPRoute` 参考](/zh/docs/reference/config/networking/virtual-service/#HTTPRoute)。
想了解如何利用这些操作，查看 [`HTTPRoute` 参考](/zh/docs/reference/config/networking/virtual-service/#HTTPRoute)。
## 目标规则 {#destination-rules}
@ -222,7 +220,7 @@ spec:
### 负载均衡选项 {#load-balancing-options}
默认情况下，Istio 使用轮询的负载均衡策略，实例池中的每个实例依次获取请求。Istio 同时支持如下的负载均衡模型，可以在 destination rules 中为流向某个特定服务或服务子集的流量指定这些模型。
默认情况下，Istio 使用轮询的负载均衡策略，实例池中的每个实例依次获取请求。Istio 同时支持如下的负载均衡模型，可以在 `DestinationRule` 中为流向某个特定服务或服务子集的流量指定这些模型。
- 随机：请求以随机的方式转到池中的实例。
- 权重：请求根据指定的百分比转到实例。
@ -232,7 +230,7 @@ spec:
### 目标规则示例 {#destination-rule-example}
在下面的示例中，目标规则为 `my-svc`目标服务配置了 3 个具有不同负载均衡策略的子集：
在下面的示例中，目标规则为 `my-svc` 目标服务配置了 3 个具有不同负载均衡策略的子集：
{{< text yaml >}}
apiVersion: networking.istio.io/v1alpha3
@ -259,18 +257,17 @@ spec:
version: v3
{{< /text >}}
每个子集都是基于一个或多个 `labels` 定义的，在 Kubernetes 中它是附加到像 Pod 这种对象上的键/值对。这些标签应用于 Kubernetes 服务的Deployment并作为`metadata`来识别不同的版本。
每个子集都是基于一个或多个 `labels` 定义的，在 Kubernetes 中它是附加到像 Pod 这种对象上的键/值对。这些标签应用于 Kubernetes 服务的 Deployment 并作为 `metadata` 来识别不同的版本。
除了定义子集之外，目标规则对于所有子集都有默认的流量策略，而对于该子集，则有特定于子集的策略覆盖它。定义在 `subsets` 上的默认策略，为`v1`和`v3`子集设置了一个简单的随机负载均衡器。在`v2` 策略中，轮询负载均衡器被指定在相应的子集字段上。
除了定义子集之外，目标规则对于所有子集都有默认的流量策略，而对于该子集，则有特定于子集的策略覆盖它。定义在 `subsets` 上的默认策略，为 `v1` 和 `v3` 子集设置了一个简单的随机负载均衡器。在 `v2` 策略中，轮询负载均衡器被指定在相应的子集字段上。
## 网关 {#gateways}
使用一个[网关](/zh/docs/reference/config/networking/gateway/#Gateway)为网格来管理入站和出站流量，可以让您指定要进入或离开网格的流量。网关配置被用于运行在网格边界的独立 Envoy 代理，而不是服务工作负载的 sidecar 代理。
使用[网关](/zh/docs/reference/config/networking/gateway/#Gateway)为网格来管理入站和出站流量，可以让您指定要进入或离开网格的流量。网关配置被用于运行在网格边界的独立 Envoy 代理，而不是服务工作负载的 sidecar 代理。
与 Kubernetes Ingress API 这种控制进入系统流量的其他机制不同，Istio 网关让您充分利用流量路由的强大能力和灵活性。您可以这么做的原因是 Istio 的网关资源可以配置 4-6 层的负载均衡属性，如对外暴露的端口、TLS 设置等。作为替代应用层流量路由（L7）到相同的 API 资源，您绑定了一个常规的 Istio [虚拟服务](#virtual-services)到网关。这让您可以像管理网格中其他数据平面的流量一样去管理网关流量。
网关主要用于管理进入的流量，但您也可以配置出口网关。出口网关让您为离开网格的流量配置一个专用的出口
节点，这可以限制哪些服务可以或应该访问外部网络，或者启用[出口流量安全控制](/zh/blog/2019/egress-traffic-control-in-istio-part-1/)为您的网格添加安全性。您也可以使用网关配置一个纯粹的内部代理。
网关主要用于管理进入的流量，但您也可以配置出口网关。出口网关让您为离开网格的流量配置一个专用的出口节点，这可以限制哪些服务可以或应该访问外部网络，或者启用[出口流量安全控制](/zh/blog/2019/egress-traffic-control-in-istio-part-1/)为您的网格添加安全性。您也可以使用网关配置一个纯粹的内部代理。
Istio 提供了一些预先配置好的网关代理部署（`istio-ingressgateway` 和 `istio-egressgateway`）供您使用——如果使用我们的[演示安装](/zh/docs/setup/getting-started/)它们都已经部署好了；如果使用[默认或 sds 配置文件](/zh/docs/setup/additional-setup/config-profiles/)则只部署了入口网关。可以将您自己的网关配置应用到这些部署或配置您自己的网关代理。
@ -299,7 +296,7 @@ spec:
privateKey: /tmp/tls.key
{{< /text >}}
这个网关配置让 HTTPS 流量从 `ext-host.example.com` 通过 443 端口流入网格，但没有为请求指定任何路由规则。为想要工作的网关指定路由，您必须把网关绑定到虚拟服务上。正如下面的示例所示，使用虚拟服务的`gateways`字段进行设置：
这个网关配置让 HTTPS 流量从 `ext-host.example.com` 通过 443 端口流入网格，但没有为请求指定任何路由规则。为想要工作的网关指定路由，您必须把网关绑定到虚拟服务上。正如下面的示例所示，使用虚拟服务的 `gateways` 字段进行设置：
{{< text yaml >}}
apiVersion: networking.istio.io/v1alpha3
@ -317,18 +314,18 @@ spec:
## 服务入口 {#service-entries}
使用[服务入口](/zh/docs/reference/config/networking/service-entry/#ServiceEntry)来添加一个入口到 Istio 内部维护的服务注册中心。添加了服务入口后，Envoy 代理可以向服务发送流量，就好像它是网格内部的服务一样。配置服务入口允许您管理运行在网格外的服务的流量，它包括以下几种能力：
使用[服务入口（Service Entry）](/zh/docs/reference/config/networking/service-entry/#ServiceEntry)来添加一个入口到 Istio 内部维护的服务注册中心。添加了服务入口后，Envoy 代理可以向服务发送流量，就好像它是网格内部的服务一样。配置服务入口允许您管理运行在网格外的服务的流量，它包括以下几种能力：
- 为外部目标 redirect 和转发请求，例如来自 web 端的 API 调用，或者流向遗留老系统的服务。
- 为外部目标定义[重试](#retries)，[超时](#timeouts)和[故障注入](#fault-injection)策略。
- 为外部目标定义[重试](#retries)、[超时](#timeouts)和[故障注入](#fault-injection)策略。
- 添加一个运行在虚拟机的服务来[扩展您的网格](/zh/docs/examples/virtual-machines/single-network/#running-services-on-the-added-VM)。
- 从逻辑上添加来自不同集群的服务到网格，在 Kubernetes 上实现一个[多集群 Istio 网格](/zh/docs/setup/install/multicluster/gateways/#configure-the-example-services)。
- 从逻辑上添加来自不同集群的服务到网格，在 Kubernetes 上实现一个[多集群 Istio 网格](/zh/docs/setup/install/multicluster/gateways/#configure-the-example-services)。
您不需要为网格服务要使用的每个外部服务都添加服务入口。默认情况下，Istio 配置 Envoy 代理将请求传递给未知服务。但是，您不能使用 Istio 的特性来控制没有在网格中注册的目标流量。
### 服务入口示例 {#service-entry-example}
下面示例的 mesh-external 服务入口将`ext-resource`外部依赖项添加到 Istio 的服务注册中心：
下面示例的 mesh-external 服务入口将 `ext-resource` 外部依赖项添加到 Istio 的服务注册中心：
{{< text yaml >}}
apiVersion: networking.istio.io/v1alpha3
@ -348,7 +345,7 @@ spec:
您指定的外部资源使用 `hosts` 字段。可以使用完全限定名或通配符作为前缀域名。
您可以配置虚拟服务和目标规则，以更细粒度的方式控制到服务入口的流量，这与网格中的任何其他服务配置流量的方式相同。例如，下面的目标规则配置流量路由以使用双向 TLS 来保护到`ext-svc.example.com`外部服务的连接，我们使用服务入口配置了该外部服务：
您可以配置虚拟服务和目标规则，以更细粒度的方式控制到服务入口的流量，这与网格中的任何其他服务配置流量的方式相同。例如，下面的目标规则配置流量路由以使用双向 TLS 来保护到 `ext-svc.example.com` 外部服务的连接，我们使用服务入口配置了该外部服务：
{{< text yaml >}}
apiVersion: networking.istio.io/v1alpha3
@ -367,7 +364,7 @@ spec:
查看[服务入口参考](/zh/docs/reference/config/networking/service-entry)获取更多可能的配置项。
## Sidecars {#sidecars}
## Sidecar {#sidecars}
默认情况下，Istio 让每个 Envoy 代理都可以访问来自和它关联的工作负载的所有端口的请求，然后转发到对应的工作负载。您可以使用 [sidecar](/zh/docs/reference/config/networking/sidecar/#Sidecar) 配置去做下面的事情：
@ -376,7 +373,7 @@ spec:
您可能希望在较庞大的应用程序中限制这样的 sidecar 可达性，配置每个代理能访问网格中的任意服务可能会因为高内存使用量而影响网格的性能。
您可以指定将 sidecar 配置应用于特定命名空间中的所有工作负载，或者使用`workloadSelector`选择特定的工作负载。例如，下面的 sidecar 配置将`bookinfo`命名空间中的所有服务配置为仅能访问运行在相同命名空间和 Istio 控制平面中的服务（目前需要使用 Istio 的策略和遥测功能）：
您可以指定将 sidecar 配置应用于特定命名空间中的所有工作负载，或者使用 `workloadSelector` 选择特定的工作负载。例如，下面的 sidecar 配置将 `bookinfo` 命名空间中的所有服务配置为仅能访问运行在相同命名空间和 Istio 控制平面中的服务（目前需要使用 Istio 的策略和遥测功能）：
{{< text yaml >}}
apiVersion: networking.istio.io/v1alpha3
@ -480,7 +477,7 @@ spec:
- 终止：终止是崩溃失败。他们模仿上游服务的失败。终止通常以 HTTP 错误码或 TCP 连接失败的形式出现。
例如，下面的虚拟服务为千分之一的访问 `ratings`服务的请求配置了一个 5 秒的延迟：
例如，下面的虚拟服务为千分之一的访问 `ratings` 服务的请求配置了一个 5 秒的延迟：
{{< text yaml >}}
apiVersion: networking.istio.io/v1alpha3

18
content/zh/docs/concepts/what-is-istio/index.md
View File

@ -17,13 +17,13 @@ Istio 允许您连接、保护、控制和观察服务。
Istio 解决了开发人员和运维人员所面临的从单体应用向分布式微服务架构转变的挑战。了解它是如何做到这一点的可以让我们更详细地理解 Istio 的服务网格。
术语**服务网格**用来描述组成这些应用程序的微服务网络以及它们之间的交互。随着服务网格的规模和复杂性不断的增长，它将会变得越来越难以理解和管理。它的需求包括服务发现、负载均衡、故障恢复、度量和监控等。一个服务网格通常还有更复杂的操作需求，比如 A/B 测试、金丝雀发布、速率限制、访问控制和端到端认证。
术语**服务网格**用来描述组成这些应用程序的微服务网络以及它们之间的交互。随着服务网格的规模和复杂性不断的增长，它将会变得越来越难以理解和管理。它的需求包括服务发现、负载均衡、故障恢复、度量和监控等。服务网格通常还有更复杂的运维需求，比如 A/B 测试、金丝雀发布、速率限制、访问控制和端到端认证。
Istio 提供了对整个服务网格的行为洞察和操作控制的能力，以及一个完整的满足微服务应用各种需求的解决方案。
## 为什么使用 Istio？{#why-use-Istio}
通过负载均衡、服务到服务的身份验证、监控等方法，Istio 可以轻松地创建一个已经部署了服务的网络，而服务的代码更改[很少](/zh/docs/tasks/observability/distributed-tracing/overview/#trace-context-propagation) 甚至无需更改。通过在整个环境中部署一个特殊的 sidecar 代理为服务添加 Istio 的支持，而代理会拦截微服务之间的所有网络通信，然后使用其控制平面的功能来配置和管理 Istio，这包括：
通过负载均衡、服务间的身份验证、监控等方法，Istio 可以轻松地创建一个已经部署了服务的网络，而服务的代码只需[很少](/zh/docs/tasks/observability/distributed-tracing/overview/#trace-context-propagation)更改甚至无需更改。通过在整个环境中部署一个特殊的 sidecar 代理为服务添加 Istio 的支持，而代理会拦截微服务之间的所有网络通信，然后使用其控制平面的功能来配置和管理 Istio，这包括：
* 为 HTTP、gRPC、WebSocket 和 TCP 流量自动负载均衡。
@ -33,7 +33,7 @@ Istio 提供了对整个服务网格的行为洞察和操作控制的能力，
* 集群内（包括集群的入口和出口）所有流量的自动化度量、日志记录和追踪。
* 在具有强大的基于身份验证和授权的集群中实现安全的服务到服务间通信。
* 在具有强大的基于身份验证和授权的集群中实现安全的服务间通信。
Istio 为可扩展性而设计，可以满足不同的部署需求。
@ -47,7 +47,7 @@ Istio 简单的规则配置和流量路由允许您控制服务之间的流量
有了更好的对流量的可视性和开箱即用的故障恢复特性，您就可以在问题产生之前捕获它们，无论面对什么情况都可以使调用更可靠，网络更健壮。
请参考 [流量管理文档](/zh/docs/concepts/traffic-management/) 获取更多细节。
请参考[流量管理文档](/zh/docs/concepts/traffic-management/)获取更多细节。
### 安全{#security}
@ -55,7 +55,7 @@ Istio 的安全特性解放了开发人员，使其只需要专注于应用程
Istio 是独立于平台的，可以与 Kubernetes（或基础设施）的网络策略一起使用。但它更强大，能够在网络和应用层面保护{{<gloss>}}pod{{</gloss>}}到 pod 或者服务到服务之间的通信。
请参考 [安全文档](/zh/docs/concepts/security/) 获取更多细节。
请参考[安全文档](/zh/docs/concepts/security/)获取更多细节。
### 策略{#policies}
@ -65,19 +65,19 @@ Istio 允许您为应用程序配置自定义的策略并在运行时执行规
* Denials、白名单和黑名单用来限制对服务的访问
* Header 的重写和重定向
Istio 还容许你创建自己的[策略适配器](/zh/docs/tasks/policy-enforcement/control-headers) 来添加诸如自定义的授权行为。
Istio 还容许你创建自己的[策略适配器](/zh/docs/tasks/policy-enforcement/control-headers)来添加诸如自定义的授权行为。
请参考 [策略文档](/zh/docs/concepts/policies/) 获取更多细节。
请参考[策略文档](/zh/docs/concepts/policies/)获取更多细节。
### 可观察性{#observability}
Istio 健壮的追踪、监控和日志特性让您能够深入的了解服务网格部署。通过 Istio 的监控能力，可以真正的了解到服务的性能是如何影响上游和下游的；而它的定制Dashboard提供了对所有服务性能的可视化能力，并让您看到它如何影响其他进程。
Istio 健壮的追踪、监控和日志特性让您能够深入的了解服务网格部署。通过 Istio 的监控能力，可以真正的了解到服务的性能是如何影响上游和下游的；而它的定制 Dashboard 提供了对所有服务性能的可视化能力，并让您看到它如何影响其他进程。
Istio 的 Mixer 组件负责策略控制和遥测数据收集。它提供了后端抽象和中介，将一部分 Istio 与后端的基础设施实现细节隔离开来，并为运维人员提供了对网格与后端基础实施之间交互的细粒度控制。
所有这些特性都使您能够更有效地设置、监控和加强服务的 SLO。当然，底线是您可以快速有效地检测到并修复出现的问题。
请参考 [可观察性文档](/zh/docs/concepts/observability/) 获取更多细节。
请参考[可观察性文档](/zh/docs/concepts/observability/)获取更多细节。
## 平台支持{#platform-support}