mirror of https://github.com/istio/istio.io.git
Remove links to outdated code (#4424)
* Remove links to outdated code The code for this was removed in: https://github.com/istio/istio/pull/14678/files I don't read/speak ZH, so struggle to understand how to properly reword the text. In the interim, just remove the links from the ZH pages. * Fix a envoy doc link failures
This commit is contained in:
Steven Dake
Martin Taillefer
parent
8cad363b10
commit
64dd2961b7
|
|
@ -177,7 +177,7 @@ As shown in the figure above, services in the mesh access each other
|
|||
using their DNS names. All HTTP traffic bound to a service is automatically
|
||||
re-routed through Envoy. Envoy distributes the traffic across instances in
|
||||
the load balancing pool. While Envoy supports several
|
||||
[sophisticated load balancing algorithms](https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/load_balancing/load_balancing),
|
||||
[sophisticated load balancing algorithms](https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/upstream/load_balancing/load_balancing),
|
||||
Istio currently allows three load balancing modes:
|
||||
round robin, random, and weighted least request.
|
||||
|
||||
|
|
|
|||
|
|
@ -21,7 +21,7 @@ To evaluate the lifetime remaining for your root certificate, please refer to th
|
|||
We provide the following procedure for you to do the root transition.
|
||||
Note that the Envoy instances will be hot restarted to reload the new root certificates, which may impact long-lived connections.
|
||||
For details about the impacts and how Envoy hot restart works, please refer to
|
||||
[here](https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/hot_restart#arch-overview-hot-restart) and
|
||||
[here](https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/operations/hot_restart) and
|
||||
[here](https://blog.envoyproxy.io/envoy-hot-restart-1d16b14555b5).
|
||||
|
||||
## Scenarios
|
||||
|
|
@ -57,7 +57,7 @@ please follow the procedure and check whether you will be affected.
|
|||
|
||||
During the transition, the Envoy sidecars may be hot-restarted to reload the new certificates.
|
||||
This may have some impact on your traffic. Please refer to
|
||||
[Envoy hot restart](https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/hot_restart#arch-overview-hot-restart)
|
||||
[Envoy hot restart](https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/operations/hot_restart)
|
||||
and read [this](https://blog.envoyproxy.io/envoy-hot-restart-1d16b14555b5)
|
||||
blog post for more details.
|
||||
|
||||
|
|
|
|||
|
|
@ -38,7 +38,7 @@ In this mode, Istio tells Envoy to prioritize traffic to the workload instances
|
|||
the locality of the Envoy sending the request. When all instances are healthy, the requests
|
||||
remains within the same locality. When instances become unhealthy, traffic spills over to
|
||||
instances in the next prioritized locality. This behavior continues until all localities are
|
||||
receiving traffic. You can find the exact percentages in the [Envoy documentation](https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/load_balancing/priority#priority-levels).
|
||||
receiving traffic. You can find the exact percentages in the [Envoy documentation](https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/upstream/load_balancing/priority).
|
||||
|
||||
A typical prioritization for an Envoy with a locality of `us-west/zone2` is as follows:
|
||||
|
||||
|
|
|
|||
|
|
@ -95,7 +95,7 @@ distribution of traffic to endpoints based on the localities of where the
|
|||
traffic originates and where it will terminate. These localities are
|
||||
specified using arbitrary labels that designate a hierarchy of localities in
|
||||
{region}/{zone}/{sub-zone} form. For additional detail refer to
|
||||
<a href="https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/load_balancing/locality_weight">Locality Weight</a>
|
||||
<a href="https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/upstream/load_balancing/locality_weight">Locality Weight</a>
|
||||
The following example shows how to setup locality weights mesh-wide.</p>
|
||||
|
||||
<p>Given a mesh with workloads and their service deployed to “us-west/zone1/<em>”
|
||||
|
|
@ -152,7 +152,7 @@ and similarly us-west should failover to us-east.</p>
|
|||
<td>
|
||||
<p>Optional: only one of distribute or failover can be set.
|
||||
Explicitly specify loadbalancing weight across different zones and geographical locations.
|
||||
Refer to <a href="https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/load_balancing/locality_weight">Locality weighted load balancing</a>
|
||||
Refer to <a href="https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/upstream/load_balancing/locality_weight">Locality weighted load balancing</a>
|
||||
If empty, the locality weight is set according to the endpoints number within it.</p>
|
||||
|
||||
</td>
|
||||
|
|
|
|||
|
|
@ -79,7 +79,7 @@ spec:
|
|||
<h2 id="ConnectionPoolSettings">ConnectionPoolSettings</h2>
|
||||
<section>
|
||||
<p>Connection pool settings for an upstream host. The settings apply to
|
||||
each individual host in the upstream service. See Envoy’s <a href="https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/circuit_breaking">circuit
|
||||
each individual host in the upstream service. See Envoy’s <a href="https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/upstream/circuit_breaking">circuit
|
||||
breaker</a>
|
||||
for more details. Connection pool settings can be applied at the TCP
|
||||
level as well as at HTTP level.</p>
|
||||
|
|
@ -360,7 +360,7 @@ defines an export to all namespaces.</p>
|
|||
<section>
|
||||
<p>Load balancing policies to apply for a specific destination. See Envoy’s
|
||||
load balancing
|
||||
<a href="https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/load_balancing/load_balancing">documentation</a>
|
||||
<a href="https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/upstream/load_balancing/load_balancing">documentation</a>
|
||||
for more details.</p>
|
||||
|
||||
<p>For example, the following rule uses a round robin load balancing policy
|
||||
|
|
@ -577,7 +577,7 @@ TCP services. For HTTP services, hosts that continually return 5xx
|
|||
errors for API calls are ejected from the pool for a pre-defined period
|
||||
of time. For TCP services, connection timeouts or connection
|
||||
failures to a given host counts as an error when measuring the
|
||||
consecutive errors metric. See Envoy’s <a href="https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/outlier">outlier
|
||||
consecutive errors metric. See Envoy’s <a href="https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/upstream/outlier">outlier
|
||||
detection</a>
|
||||
for more details.</p>
|
||||
|
||||
|
|
|
|||
|
|
@ -6,4 +6,4 @@ weight: 0
|
|||
Istio integrates with distributed tracing systems in two different ways: [Envoy-based](#how-envoy-based-tracing-works) and [Mixer-based](#how-mixer-based-tracing-works) tracing integrations. For both tracing integration approaches, [applications are responsible for forwarding tracing headers](#istio-copy-headers) for subsequent outgoing requests.
|
||||
|
||||
You can find additional information in the Istio Distributed Tracing ([Jaeger](/docs/tasks/telemetry/distributed-tracing/jaeger/), [LightStep](/docs/tasks/telemetry/distributed-tracing/lightstep/), [Zipkin](/docs/tasks/telemetry/distributed-tracing/zipkin/)) Tasks and
|
||||
in the [Envoy tracing docs](https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/tracing#tracing).
|
||||
in the [Envoy tracing docs](https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/observability/tracing).
|
||||
|
|
|
|||
|
|
@ -83,7 +83,7 @@ Pilot 使用来自服务注册的信息，并提供与平台无关的服务发
|
|||
link="LoadBalancing.svg"
|
||||
caption="发现与负载均衡">}}
|
||||
|
||||
如上图所示，网格中的服务使用其 DNS 名称访问彼此。服务的所有 HTTP 流量都会通过 Envoy 自动重新路由。Envoy 在负载均衡池中的实例之间分发流量。虽然 Envoy 支持多种[复杂的负载均衡算法](https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/load_balancing/load_balancing)，但 Istio 目前仅允许三种负载均衡模式：轮询、随机和带权重的最少请求。
|
||||
如上图所示，网格中的服务使用其 DNS 名称访问彼此。服务的所有 HTTP 流量都会通过 Envoy 自动重新路由。Envoy 在负载均衡池中的实例之间分发流量。虽然 Envoy 支持多种[复杂的负载均衡算法](https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/upstream/load_balancing/load_balancing)，但 Istio 目前仅允许三种负载均衡模式：轮询、随机和带权重的最少请求。
|
||||
|
||||
除了负载均衡外，Envoy 还会定期检查池中每个实例的运行状况。Envoy 遵循熔断器风格模式，根据健康检查 API 调用的失败率将实例分类为不健康和健康两种。换句话说，当给定实例的健康检查失败次数超过预定阈值时，将会被从负载均衡池中弹出。类似地，当通过的健康检查数超过预定阈值时，该实例将被添加回负载均衡池。您可以在[处理故障](#故障处理)中了解更多有关 Envoy 的故障处理功能。
|
||||
|
||||
|
|
|
|||
|
|
@ -33,7 +33,7 @@ _Locality-prioritized load balancing_ 是 _locality load balancing_ 的默认行
|
|||
当所有实例都正常运行时，请求将保持在同一地点。
|
||||
当实例变得不健康时，流量会被调度到位于下一个优先级位置的实例上。
|
||||
这种行为一直持续到所有地点都接收到流量为止。
|
||||
您可以在 [Envoy 文档](https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/load_balancing/priority#priority-levels)中找到确切的百分比。
|
||||
您可以在 [Envoy 文档](https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/upstream/load_balancing/priority)中找到确切的百分比。
|
||||
|
||||
具有 `us-west/zone2` 地点标识的 Envoy 典型优先顺序如下：
|
||||
|
||||
|
|
|
|||
|
|
@ -18,7 +18,7 @@ weight: 50
|
|||
|
||||
## `ConnectionPoolSettings`
|
||||
|
||||
上游主机的连接池设置。这一设置会应用到上游服务中的每个主机上。可以参考 Envoy 的[断路器文档](https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/circuit_breaking)获取更多信息。这一设置在 TCP 和 HTTP 级别都是有效的。
|
||||
上游主机的连接池设置。这一设置会应用到上游服务中的每个主机上。可以参考 Envoy 的[断路器文档](https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/upstream/circuit_breaking)获取更多信息。这一设置在 TCP 和 HTTP 级别都是有效的。
|
||||
|
||||
例如下面的规则为 Redis 服务设置了一个名为 `myredissrv` 的规则，限制连接数上限为 100，连接超时限制为 30 毫秒。
|
||||
|
||||
|
|
@ -784,7 +784,7 @@ spec:
|
|||
|
||||
## `LoadBalancerSettings`
|
||||
|
||||
特定目标的负载均衡策略。阅读 [Envoy 负载均衡文档](https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/load_balancing/load_balancing)能够获得更多这方面的信息。
|
||||
特定目标的负载均衡策略。阅读 [Envoy 负载均衡文档](https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/upstream/load_balancing/load_balancing)能够获得更多这方面的信息。
|
||||
|
||||
例如下面的例子中，为所有指向 `ratings` 服务的流量指定了轮询调度算法负载均衡。
|
||||
|
||||
|
|
@ -852,11 +852,11 @@ spec:
|
|||
|`ROUND_ROBIN`|轮询调度策略。缺省。|
|
||||
|`LEAST_CONN`|使用一个 O(1) 复杂度的算法：随机选择两个健康主机，从中选择一个较少请求的主机提供服务。|
|
||||
|`RANDOM`|随机的负载均衡算法会随机选择一个健康主机。在没有健康检查策略的情况下，随机策略通常会比轮询调度策略更加高效。|
|
||||
|`PASSTHROUGH`|这个策略会直接把请求发给客户端要求的地址上。这个选项需要慎重使用。这是一种高级用例。参考 [Envoy 的 Original destination 负载均衡](https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/load_balancing/load_balancing) 一文进一步了解其应用方式。|
|
||||
|`PASSTHROUGH`|这个策略会直接把请求发给客户端要求的地址上。这个选项需要慎重使用。这是一种高级用例。参考 [Envoy 的 Original destination 负载均衡](https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/upstream/load_balancing/load_balancing) 一文进一步了解其应用方式。|
|
||||
|
||||
## `OutlierDetection`
|
||||
|
||||
熔断器的实现需要对每个上游服务主机进行追踪。对 HTTP 和 TCP 服务都可以生效。对 HTTP 服务来说，如果有主机持续返回 `5xx` 给 API 调用，会被踢出服务池，并持续一个预定义的时间长度；而对于 TCP 服务，到指定主机的连接超时和连接失败都会被记为错误次数，作为持续失败的指标进行统计。参考 Envoy 的 [outlier detection](https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/outlier) 可以获取更多信息。
|
||||
熔断器的实现需要对每个上游服务主机进行追踪。对 HTTP 和 TCP 服务都可以生效。对 HTTP 服务来说，如果有主机持续返回 `5xx` 给 API 调用，会被踢出服务池，并持续一个预定义的时间长度；而对于 TCP 服务，到指定主机的连接超时和连接失败都会被记为错误次数，作为持续失败的指标进行统计。参考 Envoy 的 [outlier detection](https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/upstream/outlier) 可以获取更多信息。
|
||||
|
||||
下面的规则为 `reviews` 服务设置了一个 100 个 TCP 连接，以及 1000 个 HTTP2 并发请求同时每个连接不能超过 10 请求的连接池。另外其中还配置了每五分钟扫描一次上游服务主机，连续失败 7 次返回 `5xx` 错误码的主机会被移出连接池 15 分钟。
|
||||
|
||||
|
|
|
|||
|
|
@ -24,7 +24,7 @@ Istio 采用基于角色的访问控制方式，本文内容涵盖了为 HTTP
|
|||
* 创建 Service Account `bookinfo-reviews`，并用它来重新部署 `reviews`（`reviews-v2` 和 `reviews-v3` 两个 Deployment）。
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl apply -f <(istioctl kube-inject -f @samples/bookinfo/platform/kube/bookinfo-add-serviceaccount.yaml@)
|
||||
$ kubectl apply -f <(istioctl kube-inject -f samples/bookinfo/platform/kube/bookinfo-add-serviceaccount.yaml)
|
||||
{{< /text >}}
|
||||
|
||||
{{< tip >}}
|
||||
|
|
|
|||
|
|
@ -28,7 +28,7 @@ keywords: [security,access-control,rbac,authorization]
|
|||
* 为 Bookinfo 应用创建 Service account。运行下列命令，分别为 `productpage` 和 `reviews` 服务创建 Service account：`bookinfo-productpage` 和 `bookinfo-reviews`：
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl apply -f <(istioctl kube-inject -f @samples/bookinfo/platform/kube/bookinfo-add-serviceaccount.yaml@)
|
||||
$ kubectl apply -f <(istioctl kube-inject -f samples/bookinfo/platform/kube/bookinfo-add-serviceaccount.yaml)
|
||||
{{< /text >}}
|
||||
|
||||
### 测试启用全局访问控制的可行性 {#test-enabling-authorization-globally}
|
||||
|
|
|
|||
|
|
@ -41,13 +41,13 @@ keywords: [security,access-control,rbac,tcp,authorization]
|
|||
* 创建新的 `ServiceAccount` 并在**启用自动注入**的网格中部署新版本的服务：
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl apply -f @samples/bookinfo/platform/kube/rbac/ratings-v2-add-serviceaccount.yaml@
|
||||
$ kubectl apply -f samples/bookinfo/platform/kube/rbac/ratings-v2-add-serviceaccount.yaml
|
||||
{{< /text >}}
|
||||
|
||||
* 创建新的 `ServiceAccount` 并在**没有启用自动注入**的网格中部署新版本的服务：
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl apply -f <(istioctl kube-inject -f @samples/bookinfo/platform/kube/rbac/ratings-v2-add-serviceaccount.yaml@)
|
||||
$ kubectl apply -f <(istioctl kube-inject -f samples/bookinfo/platform/kube/rbac/ratings-v2-add-serviceaccount.yaml)
|
||||
{{< /text >}}
|
||||
|
||||
### 配置应用使用新版本的服务
|
||||
|
|
@ -167,7 +167,7 @@ $ kubectl apply -f @samples/bookinfo/platform/kube/rbac/rbac-config-on-mongodb.y
|
|||
用下面的命令重新部署 `ratings:v2` 服务，并使用 `default` 服务账号运行该服务：
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl delete -f @samples/bookinfo/platform/kube/rbac/ratings-v2-add-serviceaccount.yaml@
|
||||
$ kubectl delete -f samples/bookinfo/platform/kube/rbac/ratings-v2-add-serviceaccount.yaml
|
||||
$ kubectl apply -f @samples/bookinfo/platform/kube/bookinfo-ratings-v2.yaml@
|
||||
{{< /text >}}
|
||||
|
||||
|
|
|
|||
|
|
@ -25,7 +25,7 @@ keywords: [安全,访问控制,rbac,鉴权]
|
|||
* 创建 Service account：`bookinfo-reviews`，并用这一身份部署 `reviews`（注意其中包含 `reviews-v2` 和 `reviews-v3` 两个版本）。
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl apply -f <(istioctl kube-inject -f @samples/bookinfo/platform/kube/bookinfo-add-serviceaccount.yaml@)
|
||||
$ kubectl apply -f <(istioctl kube-inject -f samples/bookinfo/platform/kube/bookinfo-add-serviceaccount.yaml)
|
||||
{{< /text >}}
|
||||
|
||||
{{< tip >}}
|
||||
|
|
|
|||
|
|
@ -8,4 +8,4 @@ Istio 以两种不同的方式与分布式追踪系统集成:
|
|||
这两种追踪集成方法，都由[应用程序负责为后续传出请求转发追踪的 header 信息](#istio-copy-headers)。
|
||||
|
||||
您可以在 Istio 分布式追踪（[Jaeger](/zh/docs/tasks/telemetry/distributed-tracing/jaeger/)、[LightStep](/zh/docs/tasks/telemetry/distributed-tracing/lightstep/)、[Zipkin](/zh/docs/tasks/telemetry/distributed-tracing/zipkin/)）任务以及
|
||||
[Envoy 追踪文档](https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/tracing#tracing) 中找到更多信息。
|
||||
[Envoy 追踪文档](https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/observability/tracing) 中找到更多信息。
|
||||
|
|
|
|||
Loading…
Reference in New Issue