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 a872913cd4..c6db70c5f3 100644 --- a/content/zh-cn/docs/concepts/cluster-administration/flow-control.md +++ b/content/zh-cn/docs/concepts/cluster-administration/flow-control.md @@ -36,7 +36,7 @@ The API Priority and Fairness feature (APF) is an alternative that improves upon aforementioned max-inflight limitations. APF classifies and isolates requests in a more fine-grained way. It also introduces a limited amount of queuing, so that no requests are rejected in cases -of very brief bursts. Requests are dispatched from queues using a +of very brief bursts. Requests are dispatched from queues using a fair queuing technique so that, for example, a poorly-behaved {{< glossary_tooltip text="controller" term_id="controller" >}} need not starve others (even at the same priority level). @@ -81,16 +81,17 @@ APF 适用于 **watch** 请求。当 APF 被禁用时，**watch** 请求不受 ` API 优先级与公平性（APF）特性由命令行标志控制，默认情况下启用。 有关可用 kube-apiserver 命令行参数以及如何启用和禁用的说明， @@ -101,6 +102,13 @@ APF 的命令行参数是 "--enable-priority-and-fairness"。 (b) `v1beta3` 版本，默认被启用，在 1.29 中被弃用。 你可以通过添加以下内容来禁用 Beta 版的 `v1beta3` API 组： + ```shell kube-apiserver \ --runtime-config=flowcontrol.apiserver.k8s.io/v1beta3=false \ @@ -164,7 +172,7 @@ from succeeding. @@ -206,19 +214,19 @@ that is proportional to that estimated number. ### Execution time tweaks for watch requests API Priority and Fairness manages **watch** requests, but this involves a -couple more excursions from the baseline behavior. The first concerns -how long a **watch** request is considered to occupy its seat. Depending -on request parameters, the response to a **watch** request may or may not -begin with **create** notifications for all the relevant pre-existing -objects. API Priority and Fairness considers a **watch** request to be +couple more excursions from the baseline behavior. The first concerns +how long a **watch** request is considered to occupy its seat. Depending +on request parameters, the response to a **watch** request may or may not +begin with **create** notifications for all the relevant pre-existing +objects. API Priority and Fairness considers a **watch** request to be done with its seat once that initial burst of notifications, if any, is over. The normal notifications are sent in a concurrent burst to all -relevant **watch** response streams whenever the server is notified of an -object create/update/delete. To account for this work, API Priority +relevant **watch** response streams whenever the server is notified of an +object create/update/delete. To account for this work, API Priority and Fairness considers every write request to spend some additional -time occupying seats after the actual writing is done. The server +time occupying seats after the actual writing is done. The server estimates the number of notifications to be sent and adjusts the write request's number of seats and seat occupancy time to include this extra work. @@ -266,7 +274,7 @@ many instances should authenticate with distinct usernames @@ -365,12 +373,12 @@ nominal/assured limits were always applied without adjustment. -随机分片 | 队列数 | 1 个大象 | 4 个大象 | 16 个大象 +随机分片 | 队列数 | 1 头大象 | 4 头大象 | 16 头大象 |----------|-----------|------------|----------------|--------------------| | 12 | 32 | 4.428838398950118e-09 | 0.11431348830099144 | 0.9935089607656024 | | 10 | 32 | 1.550093439632541e-08 | 0.0626479840223545 | 0.9753101519027554 | @@ -512,7 +520,7 @@ with the highest `matchingPrecedence`. If multiple FlowSchemas with equal smaller `name` will win, but it's better not to rely on this, and instead to ensure that no two FlowSchemas have the same `matchingPrecedence`. --> -对一个请求来说，只有首个匹配的 FlowSchema 才有意义。 +对一个请求来说，只有首个匹配的 FlowSchema 才有意义。 如果一个入站请求与多个 FlowSchema 匹配，则将基于逻辑上最高优先级 `matchingPrecedence` 的请求进行筛选。 如果一个请求匹配多个 FlowSchema 且 `matchingPrecedence` 的值相同，则按 `name` 的字典序选择最小， 但是最好不要依赖它，而是确保不存在两个 FlowSchema 具有相同的 `matchingPrecedence` 值。 @@ -570,9 +578,9 @@ mandatory and suggested. ### Mandatory Configuration Objects The four mandatory configuration objects reflect fixed built-in -guardrail behavior. This is behavior that the servers have before +guardrail behavior. This is behavior that the servers have before those objects exist, and when those objects exist their specs reflect -this behavior. The four mandatory objects are as follows. +this behavior. The four mandatory objects are as follows. --> ### 强制的配置对象 {#mandatory-configuration-objects} @@ -613,8 +621,8 @@ this behavior. The four mandatory objects are as follows. ### Suggested Configuration Objects The suggested FlowSchemas and PriorityLevelConfigurations constitute a -reasonable default configuration. You can modify these and/or create -additional configuration objects if you want. If your cluster is +reasonable default configuration. You can modify these and/or create +additional configuration objects if you want. If your cluster is likely to experience heavy load then you should consider what configuration will work best. @@ -660,9 +668,11 @@ The suggested configuration groups requests into six priority levels: @@ -712,10 +722,10 @@ inconsistent with the server's guardrail behavior. @@ -743,16 +753,16 @@ alone. @@ -786,7 +796,7 @@ nor suggested but are annotated The suggested configuration gives no special treatment to the health check requests on kube-apiservers from their local kubelets --- which -tend to use the secured port but supply no credentials. With the +tend to use the secured port but supply no credentials. With the suggested config, these requests get assigned to the `global-default` FlowSchema and the corresponding `global-default` priority level, where other traffic can crowd them out. @@ -808,7 +818,7 @@ requests from rate limiting. * `apiserver_flowcontrol_rejected_requests_total` 是一个计数器向量， @@ -939,6 +949,16 @@ poorly-behaved workloads that may be harming system health. 因此你可以将一个优先级的所有 FlowSchema 的直方图相加，以得到分配给该优先级的请求的有效直方图。 {{< /note >}} + +* `apiserver_flowcontrol_nominal_limit_seats` 是一个测量向量， + 记录了每个优先级的额定并发限制。 + 此值是根据 API 服务器的总并发限制和优先级的配置额定并发份额计算得出的。 + @@ -949,7 +969,7 @@ poorly-behaved workloads that may be harming system health. high water marks of the number of queued requests, grouped by a label named `request_kind` whose value is `mutating` or `readOnly`. These high water marks describe the largest number seen in the one - second window most recently completed. These complement the older + second window most recently completed. These complement the older `apiserver_current_inflight_requests` gauge vector that holds the last window's high water mark of number of requests actively being served. @@ -976,7 +996,7 @@ poorly-behaved workloads that may be harming system health. nanosecond, of the number of requests broken down by the labels `phase` (which takes on the values `waiting` and `executing`) and `request_kind` (which takes on the values `mutating` and - `readOnly`). Each observed value is a ratio, between 0 and 1, of + `readOnly`). Each observed value is a ratio, between 0 and 1, of the number of requests divided by the corresponding limit on the number of requests (queue volume limit for waiting and concurrency limit for executing). @@ -1000,7 +1020,7 @@ poorly-behaved workloads that may be harming system health. histogram vector of observations, made at the end of each nanosecond, of the number of requests broken down by the labels `phase` (which takes on the values `waiting` and `executing`) and - `priority_level`. Each observed value is a ratio, between 0 and 1, + `priority_level`. Each observed value is a ratio, between 0 and 1, of a number of requests divided by the corresponding limit on the number of requests (queue volume limit for waiting and concurrency limit for executing). @@ -1015,13 +1035,13 @@ poorly-behaved workloads that may be harming system health. * `apiserver_flowcontrol_priority_level_seat_utilization` is a histogram vector of observations, made at the end of each nanosecond, of the utilization of a priority level's concurrency - limit, broken down by `priority_level`. This utilization is the - fraction (number of seats occupied) / (concurrency limit). This + limit, broken down by `priority_level`. This utilization is the + fraction (number of seats occupied) / (concurrency limit). This metric considers all stages of execution (both normal and the extra delay at the end of a write to cover for the corresponding notification work) of all requests except WATCHes; for those it considers only the initial stage that delivers notifications of - pre-existing objects. Each histogram in the vector is also labeled + pre-existing objects. Each histogram in the vector is also labeled with `phase: executing` (there is no seat limit for the waiting phase). --> @@ -1062,9 +1082,9 @@ poorly-behaved workloads that may be harming system health. * `apiserver_flowcontrol_request_concurrency_limit` 与 @@ -1087,8 +1107,8 @@ poorly-behaved workloads that may be harming system health. - 你可以查阅流控[参考文档](/zh-cn/docs/reference/debug-cluster/flow-control/)了解有关故障排查的更多信息。 - 有关 API 优先级和公平性的设计细节的背景信息，