[zh] Fix links in zh localization (1)

This commit is contained in:
Qiming Teng
2020-12-04 14:10:01 +08:00
parent dcdf3f0bac
commit 482351ef2a
20 changed files with 229 additions and 180 deletions
@@ -23,10 +23,8 @@ topology of the cluster. For example, a service can specify that traffic be
preferentially routed to endpoints that are on the same Node as the client, or
in the same availability zone.
-->
`Service` 拓扑可以让一个服务基于集群的 `Node` 拓扑进行流量路由。例如,一个服务可以指定流量是被优先路由到一个和客户端在同一个 `Node` 或者在同一可用区域的端点。
服务拓扑(Service Topology)可以让一个服务基于集群的 Node 拓扑进行流量路由。
例如,一个服务可以指定流量是被优先路由到一个和客户端在同一个 Node 或者在同一可用区域的端点。
<!-- body -->
@@ -51,50 +49,20 @@ with it, while intrazonal traffic does not. Other common needs include being abl
to route traffic to a local Pod managed by a DaemonSet, or keeping traffic to
Nodes connected to the same top-of-rack switch for the lowest latency.
-->
## 介绍 {#introduction}
默认情况下,发往 `ClusterIP` 或者 `NodePort` 服务的流量可能会被路由到任意一个服务后端的地址上。从 Kubernetes 1.7 开始,可以将“外部”流量路由到节点上运行的 pod 上,但不支持 `ClusterIP` 服务,更复杂的拓扑 &mdash; 比如分区路由 &mdash; 也还不支持。通过允许 `Service` 创建者根据源 `Node` 和目的 `Node` 的标签来定义流量路由策略,`Service` 拓扑特性实现了服务流量的路由。
默认情况下,发往 `ClusterIP` 或者 `NodePort` 服务的流量可能会被路由到任意一个服务后端的地址上。
从 Kubernetes 1.7 开始,可以将“外部”流量路由到节点上运行的 Pod 上,但不支持 `ClusterIP` 服务,
更复杂的拓扑 &mdash; 比如分区路由 &mdash; 也还不支持。
通过允许 `Service` 创建者根据源 `Node` 和目的 `Node` 的标签来定义流量路由策略,
服务拓扑特性实现了服务流量的路由。
通过对源 `Node` 和目的 `Node` 标签的匹配,运营者可以使用任何符合运营者要求的度量值来指定彼此“较近”和“较远”的节点组。例如,对于在公有云上的运营者来说,更偏向于把流量控制在同一区域内,因为区域间的流量是有费用成本的,而区域内的流量没有。其它常用需求还包括把流量路由到由 `DaemonSet` 管理的本地 Pod 上,或者把保持流量在连接同一机架交换机的 `Node` 上,以获得低延时。
<!--
## Prerequisites
The following prerequisites are needed in order to enable topology aware service
routing:
* Kubernetes 1.17 or later
* Kube-proxy running in iptables mode or IPVS mode
* Enable [Endpoint Slices](/zh/docs/concepts/services-networking/endpoint-slices/)
-->
## 前提条件 {#prerequisites}
为了启用拓扑感知服务路由功能,必须要满足以下一些前提条件:
* Kubernetes 的版本不低于 1.17
* Kube-proxy 运行在 iptables 模式或者 IPVS 模式
* 启用 [端点切片](/zh/docs/concepts/services-networking/endpoint-slices/)功能
<!--
## Enable Service Topology
To enable service topology, enable the `ServiceTopology` feature gate for
kube-apiserver and kube-proxy:
```
--feature-gates="ServiceTopology=true"
```
-->
## 启用 `Service` 拓扑 {#enable-service-topology}
要启用 `Service` 拓扑,就要给 kube-apiserver 和 kube-proxy 启用 `ServiceTopology` 功能:
```
--feature-gates="ServiceTopology=true"
```
通过对源 `Node` 和目的 `Node` 标签的匹配,运营者可以使用任何符合运营者要求的度量值
来指定彼此“较近”和“较远”的节点组。
例如,对于在公有云上的运营者来说,更偏向于把流量控制在同一区域内,
因为区域间的流量是有费用成本的,而区域内的流量没有。
其它常用需求还包括把流量路由到由 `DaemonSet` 管理的本地 Pod 上,或者
把保持流量在连接同一机架交换机的 `Node` 上,以获得低延时。
<!--
## Using Service Topology
@@ -116,11 +84,21 @@ be used to mean "any topology". This catch-all value, if used, only makes sense
as the last value in the list.
-->
## 使用 `Service` 拓扑 {#using-service-topology}
## 使用服务拓扑 {#using-service-topology}
如果集群启用了 `Service` 拓扑功能后,就可以在 `Service` 配置中指定 `topologyKeys` 字段,从而控制 `Service` 的流量路由。此字段是 `Node` 标签的优先顺序字段,将用于在访问这个 `Service` 时对端点进行排序。流量会被定向到第一个标签值和源 `Node` 标签值相匹配的 `Node`。如果这个 `Service` 没有匹配的后端 `Node`,那么第二个标签会被使用做匹配,以此类推,直到没有标签。
如果集群启用了服务拓扑功能后,就可以在 `Service` 配置中指定 `topologyKeys` 字段,
从而控制 `Service` 的流量路由。
此字段是 `Node` 标签的优先顺序字段,将用于在访问这个 `Service` 时对端点进行排序。
流量会被定向到第一个标签值和源 `Node` 标签值相匹配的 `Node`
如果这个 `Service` 没有匹配的后端 `Node`,那么第二个标签会被使用做匹配,
以此类推,直到没有标签。
如果没有匹配到,流量会被拒绝,就如同这个 `Service` 根本没有后端。这是根据有可用后端的第一个拓扑键来选择端点的。如果这个字段被配置了而没有后端可以匹配客户端拓扑,那么这个 `Service` 对那个客户端是没有后端的,链接应该是失败的。这个字段配置为 `"*"` 意味着任意拓扑。这个通配符值如果使用了,那么只有作为配置值列表中的最后一个才有用。
如果没有匹配到,流量会被拒绝,就如同这个 `Service` 根本没有后端。
换言之,系统根据可用后端的第一个拓扑键来选择端点。
如果这个字段被配置了而没有后端可以匹配客户端拓扑,那么这个 `Service`
对那个客户端是没有后端的,链接应该是失败的。
这个字段配置为 `"*"` 意味着任意拓扑。
这个通配符值如果使用了,那么只有作为配置值列表中的最后一个才有用。
<!--
If `topologyKeys` is not specified or empty, no topology constraints will be applied.
@@ -139,14 +117,18 @@ traffic as follows.
none are available within this zone:
`["topology.kubernetes.io/zone", "*"]`.
-->
如果 `topologyKeys` 没有指定或者为空,就没有启用这个拓扑约束。
如果 `topologyKeys` 没有指定或者为空,就没有启用这个拓扑功能
一个集群中,其 `Node` 的标签被打为其主机名,区域名和地区名
那么就可以设置 `Service``topologyKeys` 的值,像下面的做法一样定向流量了。
一个集群中,其 `Node` 的标签被打为其主机名,区域名和地区名。那么就可以设置 `Service``topologyKeys` 的值,像下面的做法一样定向流量了。
* 定向到同一个 `Node` 上的端点,`Node` 上没有端点存在时就失败:配置 `["kubernetes.io/hostname"]`
* 偏向定向到同一个 `Node` 上的端点,回退同一区域的端点上,然后是同一地区,其它情况下就失败:配置 `["kubernetes.io/hostname", "topology.kubernetes.io/zone", "topology.kubernetes.io/region"]`这或许很有用,例如,数据局部性很重要的情况下。
* 偏向于同一区域,但如果此区域中没有可用的终结点,则回退到任何可用的终结点:配置 `["topology.kubernetes.io/zone", "*"]`
* 只定向到同一个 `Node` 上的端点,`Node` 上没有端点存在时就失败:
配置 `["kubernetes.io/hostname"]`
* 偏向定向到同一个 `Node` 上的端点,回退同一区域的端点上,然后是同一地区,
其它情况下就失败:配置 `["kubernetes.io/hostname", "topology.kubernetes.io/zone", "topology.kubernetes.io/region"]`
这或许很有用,例如,数据局部性很重要的情况下
* 偏向于同一区域,但如果此区域中没有可用的终结点,则回退到任何可用的终结点:
配置 `["topology.kubernetes.io/zone", "*"]`
<!--
## Constraints
@@ -168,25 +150,22 @@ traffic as follows.
## 约束条件 {#constraints}
* `Service` 拓扑和 `externalTrafficPolicy=Local` 是不兼容的,所以 `Service` 不能同时使用这两种特性。但是在同一个集群的不同 `Service` 上是可以分别使用这两种特性的,只要不在同一个 `Service` 上就可以。
* 服务拓扑和 `externalTrafficPolicy=Local` 是不兼容的,所以 `Service` 不能同时使用这两种特性。
但是在同一个集群的不同 `Service` 上是可以分别使用这两种特性的,只要不在同一个 `Service` 上就可以。
* 有效的拓扑键目前只有:`kubernetes.io/hostname``topology.kubernetes.io/zone` `topology.kubernetes.io/region`,但是未来会推广到其它的 `Node` 标签。
* 有效的拓扑键目前只有:`kubernetes.io/hostname``topology.kubernetes.io/zone`
`topology.kubernetes.io/region`,但是未来会推广到其它的 `Node` 标签。
* 拓扑键必须是有效的标签,并且最多指定16个。
* 通配符:`"*"`,如果要用,必须是拓扑键值的最后一个值。
* 通配符:`"*"`,如果要用,必须是拓扑键值的最后一个值。
## {{% heading "whatsnext" %}}
<!--
* Read about [enabling Service Topology](/docs/tasks/administer-cluster/enabling-service-topology)
* Read [Connecting Applications with Services](/docs/concepts/services-networking/connect-applications-service/)
-->
* 阅读关于[用服务拓扑](/docs/tasks/administer-cluster/enabling-service-topology)
* 阅读[用 `Services` 连接应用程序](/zh/docs/concepts/services-networking/connect-applications-service/)
* 阅读关于[启用服务拓扑](/zh/docs/tasks/administer-cluster/enabling-service-topology/)
* 阅读[用服务连接应用程序](/zh/docs/concepts/services-networking/connect-applications-service/)