mirror of https://github.com/istio/istio.io.git
[zh] Update /traffic-management/multicluster/ and its glossary (#14142)
* [zh] Update /traffic-management/multicluster/ and its referenced glossary * update network-topologies
This commit is contained in:
Michael
GitHub
parent
b822451df5
commit
ef6db405d6
|
|
@ -1,30 +1,30 @@
|
|||
---
|
||||
title: 多集群流量管理
|
||||
description: 如何配置流量在网格集群之间如何分发的。
|
||||
description: 配置如何在网格中的集群之间分发流量。
|
||||
weight: 70
|
||||
keywords: [traffic-management,multicluster]
|
||||
owner: istio/wg-networking-maintainers
|
||||
test: no
|
||||
---
|
||||
|
||||
在多集群网格中，可能需要特定于集群拓扑的流量规则。本文件描述了在多集群网格中管理流量的几种方法，
|
||||
在阅读本指南之前：
|
||||
在多集群网格中，可能需要特定于集群拓扑的流量规则。本文描述了在一个多集群网格中管理流量的几种方法。
|
||||
在阅读本指南之前，您需要：
|
||||
|
||||
1. 阅读[部署模型](/zh/docs/ops/deployment/deployment-models/#multiple-clusters)。
|
||||
1. 确保您部署的服务遵循以下概念{{< gloss "namespace sameness" >}}命名空间的相同{{< /gloss >}}。
|
||||
1. 确保您部署的服务遵循{{< gloss "namespace sameness" >}}命名空间相同{{< /gloss >}}的概念。
|
||||
|
||||
## 保持集群内的流量 {#keeping-traffic-in-cluster}
|
||||
|
||||
在某些情况下，默认的跨集群负载平衡操作是不可取的。为了保持流量的 "cluster-local" (即：
|
||||
从 `cluster-a` 发送的流量将只会到达 `cluster-a` 中的目的地)，
|
||||
使用 [`MeshConfig.serviceSettings`](/zh/docs/reference/config/istio.mesh.v1alpha1/#MeshConfig-ServiceSettings-Settings)
|
||||
在某些情况下，默认的跨集群负载均衡操作是不可取的。为了保持流量在 "cluster-local"
|
||||
(即从 `cluster-a` 发送的流量将只会到达 `cluster-a` 中的目的地)，
|
||||
需要使用 [`MeshConfig.serviceSettings`](/zh/docs/reference/config/istio.mesh.v1alpha1/#MeshConfig-ServiceSettings-Settings)
|
||||
将主机名或通配符标记为 `clusterLocal`。
|
||||
|
||||
例如，您可以为单个服务、特定命名空间中的所有服务或网格中的所有服务全局实施 "cluster-local" 流量管理，如下所示：
|
||||
|
||||
{{< tabset category-name="meshconfig" >}}
|
||||
|
||||
{{< tab name="per-service" category-value="service" >}}
|
||||
{{< tab name="按服务" category-value="service" >}}
|
||||
|
||||
{{< text yaml >}}
|
||||
serviceSettings:
|
||||
|
|
@ -36,7 +36,7 @@ serviceSettings:
|
|||
|
||||
{{< /tab >}}
|
||||
|
||||
{{< tab name="per-namespace" category-value="namespace" >}}
|
||||
{{< tab name="按命名空间" category-value="namespace" >}}
|
||||
|
||||
{{< text yaml >}}
|
||||
serviceSettings:
|
||||
|
|
@ -48,7 +48,7 @@ serviceSettings:
|
|||
|
||||
{{< /tab >}}
|
||||
|
||||
{{< tab name="global" category-value="global" >}}
|
||||
{{< tab name="全局" category-value="global" >}}
|
||||
|
||||
{{< text yaml >}}
|
||||
serviceSettings:
|
||||
|
|
@ -65,10 +65,10 @@ serviceSettings:
|
|||
## 分区服务 {#partitioning-services}
|
||||
|
||||
[`DestinationRule.subsets`](/zh/docs/reference/config/networking/destination-rule/#Subset)
|
||||
允许通过选择标签对服务进行分区。这些标签可以是来自Kubernetes metadata 的标签，
|
||||
也可以是来自 [built-in labels](/zh/docs/reference/config/labels/)。
|
||||
允许通过选择标签对服务进行分区。这些标签可以是来自 Kubernetes metadata 的标签，
|
||||
也可以是[内置标签](/zh/docs/reference/config/labels/)。
|
||||
这些内置标签之一的 `topology.istio.io/cluster` 在
|
||||
`DestinationRule` 的子集选择器中允许创建每个集群的子集。
|
||||
`DestinationRule` 的子集选择器中允许按集群创建子集。
|
||||
|
||||
{{< text yaml >}}
|
||||
apiVersion: networking.istio.io/v1beta1
|
||||
|
|
@ -86,10 +86,10 @@ spec:
|
|||
topology.istio.io/cluster: cluster-2
|
||||
{{< /text >}}
|
||||
|
||||
使用这些子集，您可以创建各种路由规则基于这些集群，如 [mirroring](/zh/docs/tasks/traffic-management/mirroring/)
|
||||
或者 [shifting](/zh/docs/tasks/traffic-management/traffic-shifting/)。
|
||||
使用这些子集，您可以基于这些集群创建各种路由规则，如[镜像](/zh/docs/tasks/traffic-management/mirroring/)
|
||||
或者[流量转移](/zh/docs/tasks/traffic-management/traffic-shifting/)。
|
||||
|
||||
这提供了另一种创建集群本地流量规则的选择，通过控制到达的目标集群的流量 `VirtualService`：
|
||||
这提供了另一种方案来创建集群内部流量规则，具体是在 `VirtualService` 中限制目标集群子集的流量：
|
||||
|
||||
{{< text yaml >}}
|
||||
apiVersion: networking.istio.io/v1beta1
|
||||
|
|
@ -118,9 +118,9 @@ spec:
|
|||
subset: cluster-2
|
||||
{{< /text >}}
|
||||
|
||||
使用这种基于子集的路由方式来控制本地集群流量，但：
|
||||
使用这种基于子集的路由方式可以控制集群内部流量，但
|
||||
[`MeshConfig.serviceSettings`](/zh/docs/reference/config/istio.mesh.v1alpha1/#MeshConfig-ServiceSettings-Settings)
|
||||
有一个缺点，它把 service-level proxy 和 topology-level proxy 混在了一起。
|
||||
比如，一个规则发送 10% 的流量给一个服务 `v2` 需要两倍的子集的数量。
|
||||
(例如： `cluster-1-v2`, `cluster-2-v2`)。
|
||||
有一个缺点：它把服务层面的代理和拓扑层面的代理混在了一起。
|
||||
比如，一个规则发送 10% 的流量给一个 `v2` 服务将需要两倍的子集的数量
|
||||
（例如 `cluster-1-v2`、`cluster-2-v2`）。
|
||||
这个处理方式最好限制在需要对集群的路由进行更多的精细化控制的场景下。
|
||||
|
|
|
|||
|
|
@ -15,20 +15,22 @@ status: Alpha
|
|||
## 向目的地的工作负载转发外部客户端属性（IP 地址、证书信息） {#forwarding-external-client-attributes-to-destination-workloads}
|
||||
|
||||
许多应用程序需要知道发起源请求的客户端 IP 地址和证书信息才能正常工作。
|
||||
值得注意的是填充了客户端 IP 的日志、验证工具以及安全工具。
|
||||
例如 Web Application Firewall（WAF），它应用这些信息来运行正确的规则集。
|
||||
反向代理的主要工作内容是给服务提供客户端属性。为了向目的地的工作负载转发这些客户端属性，
|
||||
代理使用 `X-Forwarded-For`（XFF）和 `X-Forwarded-Client-Cert`（XFCC）请求头。
|
||||
这些应用包括需要填充客户端 IP 的日志工具和审计工具，
|
||||
还包括一些需要此信息来正确应用规则集的安全工具，
|
||||
例如网络应用防火墙（Web Application Firewall, WAF）。
|
||||
为服务提供客户端属性的能力长时间以来是实现反向代理的一个保证。
|
||||
为了向目的地工作负载转发这些客户端属性，
|
||||
代理可以使用 `X-Forwarded-For`（XFF）和 `X-Forwarded-Client-Cert`（XFCC）请求头。
|
||||
|
||||
如今的网络千差万别，无论网络拓扑结构如何，对这些多样化属性的支持都是必要的。
|
||||
不管网络使用的是基于云的负载均衡、前置负载均衡、直接暴露在网络上的 Gateway、
|
||||
为许多中间代理服务的 Gateway，还是没有指定其他部署拓扑等，这些信息都是需要保存和转发。
|
||||
如今的网络千差万别，但无论网络拓扑结构如何，对这些多样化属性的支持都是必要的。
|
||||
不管网络使用的是基于云的负载均衡、本地负载均衡、直接暴露在互联网上的 Gateway、
|
||||
为许多中间代理服务的 Gateway，还是其他未指定的部署拓扑，这些信息都是需要保存和转发的。
|
||||
|
||||
虽然 Istio 提供一个 [Ingress Gateway](/zh/docs/tasks/traffic-management/ingress/ingress-control/)，
|
||||
但鉴于上述多样化架构的复杂性，无法提供合理的默认值，将客户端属性正确转发到目标工作负载。
|
||||
虽然 Istio 提供一个[入口网关](/zh/docs/tasks/traffic-management/ingress/ingress-control/)，
|
||||
但鉴于上述多样化架构的复杂性，想要将客户端属性正确转发到目的地工作负载，很难提供合理的默认值。
|
||||
随着 Istio 多集群部署模式越来越普遍，这个问题需要被越来越重视。
|
||||
|
||||
了解关于 `X-Forwarded-For` 更多信息，参考 IETF 的 [RFC](https://tools.ietf.org/html/rfc7239)。
|
||||
关于 `X-Forwarded-For` 的更多信息，参考 IETF 的 [RFC](https://tools.ietf.org/html/rfc7239)。
|
||||
|
||||
## 配置网络拓扑 {#configuring-network-topologies}
|
||||
|
||||
|
|
@ -45,7 +47,7 @@ spec:
|
|||
forwardClientCertDetails: <ENUM_VALUE>
|
||||
{{< /text >}}
|
||||
|
||||
在您的 Istio Ingress Gateway Pod 的 Spec 通过添加 `proxy.istio.io/config` 注解可以设置这两个配置。
|
||||
在您的 Istio 入口网关 Pod 的 spec 中通过添加 `proxy.istio.io/config` 注解也可以设置这两个配置。
|
||||
|
||||
{{< text syntax=yaml snip_id=none >}}
|
||||
...
|
||||
|
|
@ -56,19 +58,19 @@ spec:
|
|||
|
||||
### 配置 X-Forwarded-For 头 {#configuring-X-Forwarded-For-headers}
|
||||
|
||||
应用程序依靠反向代理来转发请求的客户端属性，如 `X-Forwarded-For` 请求头。
|
||||
应用程序依靠反向代理来转发请求中的客户端属性，如 `X-Forwarded-For` 请求头。
|
||||
然而由于 Istio 可以部署多样性的网络拓扑，您必须设置 Istio 网关代理上游的可信代理数量 `numTrustedProxies`，
|
||||
这样才能正确提取客户端地址。因为它将控制 Ingress Gateway 在 `X-Envoy-Eternal-Address` 头中填充的值，
|
||||
该值可以被上游服务可靠地用于访问客户的原始 IP 地址。
|
||||
这样客户端地址才能被正确提取。因为这将控制入口网关在 `X-Envoy-Eternal-Address` 头中填充的值，
|
||||
该值可以被上游服务可靠地用于访问客户端的原始 IP 地址。
|
||||
|
||||
例如，如果在 Istio Gateway 之前，有一个基于云的负载均衡和一个反向代理，设置 `numTrustedProxies` 为 `2`。
|
||||
例如，如果在 Istio Gateway 之前，有一个基于云的负载均衡和一个反向代理，可以设置 `numTrustedProxies` 为 `2`。
|
||||
|
||||
{{< idea >}}
|
||||
需要注意的是，在 Istio Gateway 代理前面的所有代理必须先解析 HTTP 流量，并将每一次转发信息附加到
|
||||
`X-Forwarded-For` 请求头中。如果 `X-Forwarded-For` 请求头中的条目数少于所配置的可信跳数
|
||||
Envoy 就直接回调下游地址作为可信客户地址。
|
||||
`X-Forwarded-For` 请求头中。如果 `X-Forwarded-For` 请求头中的条目数少于所配置的可信跳数，
|
||||
Envoy 就直接回调下游地址作为可信客户端地址。
|
||||
请参考 [Envoy 文档](https://www.envoyproxy.io/docs/envoy/latest/configuration/http/http_conn_man/headers#x-forwarded-for)
|
||||
去了解如何确定 `X-Forwarded-For` 头文件和受信任的客户地址。
|
||||
去了解如何确定 `X-Forwarded-For` 头文件和受信任的客户端地址。
|
||||
{{< /idea >}}
|
||||
|
||||
#### httpbin X-Forwarded-For 示例 {#example-using-X-Forwarded-For-capability-with-httpbin}
|
||||
|
|
@ -89,7 +91,7 @@ Envoy 就直接回调下游地址作为可信客户地址。
|
|||
{{< /text >}}
|
||||
|
||||
{{< idea >}}
|
||||
如果您之前安装了 Istio Ingress Gateway，请在第 1 步之后重启所有 Ingress Gateway Pod。
|
||||
如果您之前安装了 Istio 入口网关，请在第 1 步之后重启所有入口网关 Pod。
|
||||
{{</ idea >}}
|
||||
|
||||
1. 创建一个 `httpbin` 命名空间：
|
||||
|
|
@ -135,7 +137,7 @@ $ kubectl wait --for=condition=programmed gtw -n httpbin httpbin-gateway
|
|||
|
||||
{{< /tabset >}}
|
||||
|
||||
6) 基于您的 Istio Ingress Gateway 设置一个本地环境变量 `GATEWAY_URL`：
|
||||
6) 基于您的 Istio 入口网关设置一个本地环境变量 `GATEWAY_URL`：
|
||||
|
||||
{{< tabset category-name="config-api" >}}
|
||||
|
||||
|
|
@ -248,11 +250,12 @@ PROXY 协议不应该用于 L7 流量，也不应该在 L7 负载均衡器后使
|
|||
|
||||
如果外部负载均衡器配置为转发 TCP 流量并使用 PROXY 协议，Istio Gateway TCP 侦听器也必须配置为接受 PROXY 协议。
|
||||
启用该功能需要在 Gateway 工作负载上使用 `EnvoyFilter` 添加
|
||||
[Envoy PROXY 协议过滤器](https://www.envoyproxy.io/docs/envoy/latest/configuration/listeners/listener_filters/proxy_protocol)。示例：
|
||||
[Envoy PROXY 协议过滤器](https://www.envoyproxy.io/docs/envoy/latest/configuration/listeners/listener_filters/proxy_protocol)。
|
||||
示例：
|
||||
|
||||
{{< tabset category-name="config-api" >}}
|
||||
|
||||
{{< tab name="Istio APIs" category-value="istio-apis" >}}
|
||||
{{< tab name="Istio API" category-value="istio-apis" >}}
|
||||
|
||||
{{< text syntax=yaml snip_id=none >}}
|
||||
apiVersion: networking.istio.io/v1alpha3
|
||||
|
|
@ -262,13 +265,13 @@ metadata:
|
|||
namespace: istio-system
|
||||
spec:
|
||||
configPatches:
|
||||
- applyTo: LISTENER
|
||||
- applyTo: LISTENER_FILTER
|
||||
patch:
|
||||
operation: MERGE
|
||||
operation: INSERT_FIRST
|
||||
value:
|
||||
listener_filters:
|
||||
- name: envoy.listener.proxy_protocol
|
||||
- name: envoy.listener.tls_inspector
|
||||
name: proxy_protocol
|
||||
typed_config:
|
||||
"@type": "type.googleapis.com/envoy.extensions.filters.listener.proxy_protocol.v3.ProxyProtocol"
|
||||
workloadSelector:
|
||||
labels:
|
||||
istio: ingressgateway
|
||||
|
|
@ -286,13 +289,13 @@ metadata:
|
|||
namespace: istio-system
|
||||
spec:
|
||||
configPatches:
|
||||
- applyTo: LISTENER
|
||||
- applyTo: LISTENER_FILTER
|
||||
patch:
|
||||
operation: MERGE
|
||||
operation: INSERT_FIRST
|
||||
value:
|
||||
listener_filters:
|
||||
- name: envoy.listener.proxy_protocol
|
||||
- name: envoy.listener.tls_inspector
|
||||
name: proxy_protocol
|
||||
typed_config:
|
||||
"@type": "type.googleapis.com/envoy.extensions.filters.listener.proxy_protocol.v3.ProxyProtocol"
|
||||
workloadSelector:
|
||||
labels:
|
||||
istio.io/gateway-name: <GATEWAY_NAME>
|
||||
|
|
@ -304,7 +307,7 @@ spec:
|
|||
|
||||
客户端 IP 从 PROXY 协议中由 Gateway 获取，并在 `X-Forwarded-For` 和 `X-Envoy-External-Address` 头中设置（或附加）。
|
||||
请注意，PROXY 协议与 `X-Forwarded-For` 和 `X-Envoy-External-Address` 等 L7 请求头互斥。
|
||||
当 PROXY 协议与 `gatewayTopology` 配置一起使用时，在确定可信客户地址时会优先使用 `numTrustedProxies`
|
||||
当 PROXY 协议与 `gatewayTopology` 配置一起使用时，在确定可信客户端地址时会优先使用 `numTrustedProxies`
|
||||
和接收到的 `X-Forwarded-For` 头，PROXY 协议客户端信息将被忽略。
|
||||
|
||||
请注意，上面的示例仅将 Gateway 配置为接受传入的 PROXY 协议 TCP 流量。
|
||||
|
|
|
|||
|
|
@ -3,7 +3,9 @@ title: Namespace Sameness
|
|||
test: n/a
|
||||
---
|
||||
|
||||
在多集群网格中，[命名空间相同](https://github.com/kubernetes/community/blob/master/sig-multicluster/namespace-sameness-position-statement.md)，
|
||||
具有给定名称的所有命名空间都被认为是相同的命名空间。
|
||||
如果多个集群包含一个具有相同命名空间名称的 `Service`，它们将被识别为单个组合服务。
|
||||
在多集群网格中，适用[命名空间相同](https://github.com/kubernetes/community/blob/master/sig-multicluster/namespace-sameness-position-statement.md)规则，
|
||||
即所有具有相同给定名称的命名空间都被认为是同一个命名空间。
|
||||
如果多个集群包含具有相同命名空间名称的 `Service`，那这些 `Service` 将被识别为单个组合服务。
|
||||
默认情况下，对于给定的服务，流量是跨网格中的所有集群进行负载均衡的。
|
||||
|
||||
与**端口号**匹配的端口也必须具有相同的端口**名称**，才会被视为组合的 `service port`。
|
||||
|
|
|
|||
Loading…
Reference in New Issue