From 0fa884ba0704cf893f867ec005d24e676f0056db Mon Sep 17 00:00:00 2001 From: Qiming Teng Date: Sun, 26 Jun 2022 13:37:01 +0800 Subject: [PATCH] [zh-cn] Resync the flow control concept page --- .../cluster-administration/flow-control.md | 136 ++++++++++-------- 1 file changed, 74 insertions(+), 62 deletions(-) diff --git a/content/zh-cn/docs/concepts/cluster-administration/flow-control.md b/content/zh-cn/docs/concepts/cluster-administration/flow-control.md index 746a7b4e3b..7acd2ad4a7 100644 --- a/content/zh-cn/docs/concepts/cluster-administration/flow-control.md +++ b/content/zh-cn/docs/concepts/cluster-administration/flow-control.md @@ -38,8 +38,8 @@ API 优先级和公平性（APF）是一种替代方案，可提升上述最大 APF 以更细粒度的方式对请求进行分类和隔离。 它还引入了空间有限的排队机制，因此在非常短暂的突发情况下，API 服务器不会拒绝任何请求。 通过使用公平排队技术从队列中分发请求，这样， -一个行为不佳的 {{< glossary_tooltip text="控制器" term_id="controller" >}} -就不会饿死其他控制器（即使优先级相同）。 +一个行为不佳的{{< glossary_tooltip text="控制器" term_id="controller" >}}就不会饿死其他控制器 +（即使优先级相同）。 -{{< caution >}} -属于“长时间运行”类型的请求（主要是 watch）不受 API 优先级和公平性过滤器的约束。 +属于“长时间运行”类型的请求（主要是 `watch`）不受 API 优先级和公平性过滤器的约束。 如果未启用 APF 特性，即便设置 `--max-requests-inflight` 标志，该类请求也不受约束。 {{< /caution >}} - -或者，你也可以通过 -`--runtime-config=flowcontrol.apiserver.k8s.io/v1alpha1=true` +或者，你也可以通过 `--runtime-config=flowcontrol.apiserver.k8s.io/v1alpha1=true` 启用 API 组的 v1alpha1 版本。 -命令行标志 `--enable-priority-fairness=false` 将彻底禁用 APF 特性，即使其他标志启用它也是无效。 +命令行标志 `--enable-priority-fairness=false` 将彻底禁用 APF 特性， +即使其他标志启用它也是无效。 将请求划分到流中之后，APF 功能将请求分配到队列中。 -分配时使用一种称为 {{< glossary_tooltip term_id="shuffle-sharding" text="混洗分片（Shuffle-Sharding）" >}} +分配时使用一种称为{{< glossary_tooltip term_id="shuffle-sharding" text="混洗分片（Shuffle-Sharding）" >}} 的技术。 该技术可以相对有效地利用队列隔离低强度流与高强度流。 @@ -223,7 +220,8 @@ server. --> ### 豁免请求 {#Exempt-requests} -某些特别重要的请求不受制于此特性施加的任何限制。这些豁免可防止不当的流控配置完全禁用 API 服务器。 +某些特别重要的请求不受制于此特性施加的任何限制。 +这些豁免可防止不当的流控配置完全禁用 API 服务器。 ### PriorityLevelConfiguration {#PriorityLevelConfiguration} -一个 PriorityLevelConfiguration 表示单个隔离类型。每个 PriorityLevelConfigurations +一个 PriorityLevelConfiguration 表示单个隔离类型。每个 PriorityLevelConfiguration 对未完成的请求数有各自的限制，对排队中的请求数也有限制。 -PriorityLevelConfigurations 的并发限制不是指定请求绝对数量，而是在“并发份额”中指定。 -API 服务器的总并发量限制通过这些份额按例分配到现有 PriorityLevelConfigurations 中。 +PriorityLevelConfiguration 的并发限制不是指定请求绝对数量，而是在“并发份额”中指定。 +API 服务器的总并发量限制通过这些份额按例分配到现有 PriorityLevelConfiguration 中。 集群管理员可以更改 `--max-requests-inflight` （或 `--max-mutating-requests-inflight` ）的值， 再重新启动 `kube-apiserver` 来增加或减小服务器的总流量， -然后所有的 PriorityLevelConfigurations 将看到其最大并发增加（或减少）了相同的比例。 +然后所有的 PriorityLevelConfiguration 将看到其最大并发增加（或减少）了相同的比例。 +{{< caution >}} -{{< caution >}} -启用 APF 功能后，服务器的总并发量限制将设置为 +启用 APF 特性后，服务器的总并发量限制将设置为 `--max-requests-inflight` 和 `--max-mutating-requests-inflight` 之和。 可变请求和不可变请求之间不再有任何区别； 如果对于某种资源，你需要区别对待不同请求，请创建不同的 FlowSchema 分别匹配可变请求和不可变请求。 @@ -299,16 +297,19 @@ an HTTP 429 (Too Many Requests) error. A type of `Queue` means that requests above the threshold will be queued, with the shuffle sharding and fair queuing techniques used to balance progress between request flows. --> -当入站请求的数量大于分配的 PriorityLevelConfigurations 中允许的并发级别时， `type` 字段将确定对额外请求的处理方式。 +当入站请求的数量大于分配的 PriorityLevelConfiguration 中允许的并发级别时， +`type` 字段将确定对额外请求的处理方式。 `Reject` 类型，表示多余的流量将立即被 HTTP 429（请求过多）错误所拒绝。 `Queue` 类型，表示对超过阈值的请求进行排队，将使用阈值分片和公平排队技术来平衡请求流之间的进度。 -公平排队算法支持通过排队配置对优先级微调。 可以在[增强建议](#whats-next)中阅读算法的详细信息，但总之： +公平排队算法支持通过排队配置对优先级微调。 +可以在[增强建议](https://github.com/kubernetes/enhancements/tree/master/keps/sig-api-machinery/1040-priority-and-fairness)中阅读算法的详细信息， +但总之： +* 修改 `handSize` 允许你调整过载情况下不同流之间的冲突概率以及单个流可用的整体并发性。 {{< note >}} + -* 修改 `handSize` 允许你调整过载情况下不同流之间的冲突概率以及单个流可用的整体并发性。 - - {{< note >}} + --> 较大的 `handSize` 使两个单独的流程发生碰撞的可能性较小（因此，一个流可以饿死另一个流）， 但是更有可能的是少数流可以控制 apiserver。 较大的 `handSize` 还可能增加单个高并发流的延迟量。 @@ -356,11 +356,11 @@ given mouse (low-intensity flow) is squished by the elephants (high-intensity fl an illustrative collection of numbers of elephants. See https://play.golang.org/p/Gi0PLgVHiUg , which computes this table. --> -下表显示了有趣的随机分片配置集合， -每行显示给定的老鼠（低强度流）被不同数量的大象挤压（高强度流）的概率。 +下表显示了有趣的随机分片配置集合，每行显示给定的老鼠（低强度流） +被不同数量的大象挤压（高强度流）的概率。 表来源请参阅： https://play.golang.org/p/Gi0PLgVHiUg -{{< table caption = "Example Shuffle Sharding Configurations" >}} +{{< table caption = "混分切片配置示例" >}} 随机分片 | 队列数 | 1 个大象 | 4 个大象 | 16 个大象 |----------|-----------|------------|----------------|--------------------| @@ -377,21 +377,23 @@ https://play.golang.org/p/Gi0PLgVHiUg , which computes this table. | 6 | 1024 | 6.337324016514285e-16 | 8.09060164312957e-11 | 4.517408062903668e-07 | {{< /table >}} - -### FlowSchema {#FlowSchema} - +### FlowSchema + FlowSchema 匹配一些入站请求，并将它们分配给优先级。 每个入站请求都会对所有 FlowSchema 测试是否匹配， 首先从 `matchingPrecedence` 数值最低的匹配开始（我们认为这是逻辑上匹配度最高）， 然后依次进行，直到首个匹配出现。 +{{< caution >}} -{{< caution >}} 对一个请求来说，只有首个匹配的 FlowSchema 才有意义。 如果一个入站请求与多个 FlowSchema 匹配，则将基于 `matchingPrecedence` 值最高的请求进行筛选。 如果一个请求匹配多个 FlowSchema 且 `matchingPrecedence` 的值相同，则按 `name` 的字典序选择最小， @@ -480,6 +481,7 @@ this behavior. The four mandatory objects are as follows. * 强制的 `exempt` 优先级用于完全不受流控限制的请求：它们总是立刻被分发。 强制的 `exempt` FlowSchema 把 `system:masters` 组的所有请求都归入该优先级。 如果合适，你可以定义新的 FlowSchema，将其他请求定向到该优先级。 + -## 健康检查并发豁免 {#Health-check-concurrency-exemption} - +## 健康检查并发豁免 {#Health-check-concurrency-exemption} + 推荐配置没有为本地 kubelet 对 kube-apiserver 执行健康检查的请求进行任何特殊处理 ——它们倾向于使用安全端口，但不提供凭据。 在推荐配置中，这些请求将分配 `global-default` FlowSchema 和 `global-default` 优先级， @@ -694,6 +695,7 @@ requests from rate limiting. --> 如果添加以下 FlowSchema，健康检查请求不受速率限制。 +{{< caution >}} -{{< caution >}} 进行此更改后，任何敌对方都可以发送与此 FlowSchema 匹配的任意数量的健康检查请求。 如果你有 Web 流量过滤器或类似的外部安全机制保护集群的 API 服务器免受常规网络流量的侵扰， 则可以配置规则，阻止所有来自集群外部的健康检查请求。 @@ -720,7 +721,6 @@ and the priority level to which it was assigned, respectively. The API objects' names are not included in these headers in case the requesting user does not have permission to view them, so when debugging you can use a command like --> - ## 问题诊断 {#diagnostics} 启用了 APF 的 API 服务器，它每个 HTTP 响应都有两个额外的 HTTP 头： @@ -738,7 +738,7 @@ kubectl get prioritylevelconfigurations -o custom-columns="uid:{metadata.uid},na to get a mapping of UIDs to names for both FlowSchemas and PriorityLevelConfigurations. --> -来获取 UID 到 FlowSchema 的名称和 UID 到 PriorityLevelConfigurations 的名称的映射。 +来获取 UID 到 FlowSchema 的名称和 UID 到 PriorityLevelConfiguration 的名称的映射。 -{{< note >}} 在 Kubernetes v1.20 之前的版本中，标签 `flow_schema` 和 `priority_level` 的名称有时被写作 `flowSchema` 和 `priorityLevel`，即存在不一致的情况。 如果你在运行 Kubernetes v1.19 或者更早版本，你需要参考你所使用的集群 @@ -931,6 +931,8 @@ poorly-behaved workloads that may be harming system health. 记录请求队列的长度，由标签 `priority_level` 和 `flow_schema` 进一步区分。 每个排队中的请求都会为其直方图贡献一个样本，并在添加请求后立即上报队列的长度。 请注意，这样产生的统计数据与无偏调查不同。 + + {{< note >}} - {{< note >}} 直方图中的离群值在这里表示单个流（即，一个用户或一个名称空间的请求， 具体取决于配置）正在疯狂地向 API 服务器发请求，并受到限制。 相反，如果一个优先级的直方图显示该优先级的所有队列都比其他优先级的队列长， - 则增加 PriorityLevelConfigurations 的并发份额是比较合适的。 + 则增加 PriorityLevelConfiguration 的并发份额是比较合适的。 {{< /note >}} * `apiserver_flowcontrol_request_concurrency_limit` 是一个表向量， - 记录并发限制的计算值（基于 API 服务器的总并发限制和 PriorityLevelConfigurations + 记录并发限制的计算值（基于 API 服务器的总并发限制和 PriorityLevelConfiguration 的并发份额），并按标签 `priority_level` 进一步区分。 - {{< note >}} - 由于每个 FlowSchema 总会给请求分配 PriorityLevelConfigurations， + 由于每个 FlowSchema 总会给请求分配 PriorityLevelConfiguration， 因此你可以为一个优先级添加所有 FlowSchema 的直方图，以获取分配给 该优先级的请求的有效直方图。 {{< /note >}} @@ -1014,7 +1016,9 @@ serves the following additional paths at its HTTP[S] ports. kubectl get --raw /debug/api_priority_and_fairness/dump_priority_levels ``` - + 输出类似于： ```none @@ -1039,7 +1043,9 @@ serves the following additional paths at its HTTP[S] ports. kubectl get --raw /debug/api_priority_and_fairness/dump_queues ``` - + 输出类似于： ```none @@ -1063,7 +1069,9 @@ serves the following additional paths at its HTTP[S] ports. kubectl get --raw /debug/api_priority_and_fairness/dump_requests ``` - + 输出类似于： ```none @@ -1078,16 +1086,20 @@ serves the following additional paths at its HTTP[S] ports. --> 针对每个优先级别，输出中还包含一条虚拟记录，对应豁免限制。 - + 你可以使用以下命令获得更详细的清单： ```shell kubectl get --raw '/debug/api_priority_and_fairness/dump_requests?includeRequestDetails=1' ``` - - + 输出类似于： + ```none PriorityLevelName, FlowSchemaName, QueueIndex, RequestIndexInQueue, FlowDistingsher, ArriveTime, UserName, Verb, APIPath, Namespace, Name, APIVersion, Resource, SubResource, system, system-nodes, 12, 0, system:node:127.0.0.1, 2020-07-23T15:31:03.583823404Z, system:node:127.0.0.1, create, /api/v1/namespaces/scaletest/configmaps,