From 595850ca21b448366611925a4aad78dd20bdba5c Mon Sep 17 00:00:00 2001 From: Tim Bannister Date: Mon, 9 Nov 2020 21:32:44 +0000 Subject: [PATCH] Revert pull request 24905 This reverts commit a9a7249330d4476e344f2e9161914f3f96536752, reversing changes made to 6d72006c7e2dc85a98556b7ccba2666e60e4f069 - because these commits were applied to the wrong branch. --- .../cluster-administration/flow-control.md | 37 ++++++++----------- 1 file changed, 15 insertions(+), 22 deletions(-) diff --git a/content/en/docs/concepts/cluster-administration/flow-control.md b/content/en/docs/concepts/cluster-administration/flow-control.md index 8ec8d5f8da..5b5653260a 100644 --- a/content/en/docs/concepts/cluster-administration/flow-control.md +++ b/content/en/docs/concepts/cluster-administration/flow-control.md @@ -331,13 +331,6 @@ PriorityLevelConfigurations. ### Metrics -{{< note >}} -In versions of Kubernetes before v1.20, the labels `flow_schema` and -`priority_level` were inconsistently named `flowSchema` and `priorityLevel`, -respectively. If you're running Kubernetes versions v1.19 and earlier, you -should refer to the documentation for your version. -{{< /note >}} - When you enable the API Priority and Fairness feature, the kube-apiserver exports additional metrics. Monitoring these can help you determine whether your configuration is inappropriately throttling important traffic, or find @@ -345,8 +338,8 @@ poorly-behaved workloads that may be harming system health. * `apiserver_flowcontrol_rejected_requests_total` is a counter vector (cumulative since server start) of requests that were rejected, - broken down by the labels `flow_schema` (indicating the one that - matched the request), `priority_level` (indicating the one to which + broken down by the labels `flowSchema` (indicating the one that + matched the request), `priorityLevel` (indicating the one to which the request was assigned), and `reason`. The `reason` label will be have one of the following values: * `queue-full`, indicating that too many requests were already @@ -359,8 +352,8 @@ poorly-behaved workloads that may be harming system health. * `apiserver_flowcontrol_dispatched_requests_total` is a counter vector (cumulative since server start) of requests that began - executing, broken down by the labels `flow_schema` (indicating the - one that matched the request) and `priority_level` (indicating the + executing, broken down by the labels `flowSchema` (indicating the + one that matched the request) and `priorityLevel` (indicating the one to which the request was assigned). * `apiserver_current_inqueue_requests` is a gauge vector of recent @@ -391,17 +384,17 @@ poorly-behaved workloads that may be harming system health. * `apiserver_flowcontrol_current_inqueue_requests` is a gauge vector holding the instantaneous number of queued (not executing) requests, - broken down by the labels `priority_level` and `flow_schema`. + broken down by the labels `priorityLevel` and `flowSchema`. * `apiserver_flowcontrol_current_executing_requests` is a gauge vector holding the instantaneous number of executing (not waiting in a - queue) requests, broken down by the labels `priority_level` and - `flow_schema`. + queue) requests, broken down by the labels `priorityLevel` and + `flowSchema`. * `apiserver_flowcontrol_priority_level_request_count_samples` is a histogram vector of observations of the then-current number of requests broken down by the labels `phase` (which takes on the - values `waiting` and `executing`) and `priority_level`. Each + values `waiting` and `executing`) and `priorityLevel`. Each histogram gets observations taken periodically, up through the last activity of the relevant sort. The observations are made at a high rate. @@ -409,7 +402,7 @@ poorly-behaved workloads that may be harming system health. * `apiserver_flowcontrol_priority_level_request_count_watermarks` is a histogram vector of high or low water marks of the number of requests broken down by the labels `phase` (which takes on the - values `waiting` and `executing`) and `priority_level`; the label + values `waiting` and `executing`) and `priorityLevel`; the label `mark` takes on values `high` and `low`. The water marks are accumulated over windows bounded by the times when an observation was added to @@ -418,7 +411,7 @@ poorly-behaved workloads that may be harming system health. * `apiserver_flowcontrol_request_queue_length_after_enqueue` is a histogram vector of queue lengths for the queues, broken down by - the labels `priority_level` and `flow_schema`, as sampled by the + the labels `priorityLevel` and `flowSchema`, as sampled by the enqueued requests. Each request that gets queued contributes one sample to its histogram, reporting the length of the queue just after the request was added. Note that this produces different @@ -435,12 +428,12 @@ poorly-behaved workloads that may be harming system health. * `apiserver_flowcontrol_request_concurrency_limit` is a gauge vector hoding the computed concurrency limit (based on the API server's total concurrency limit and PriorityLevelConfigurations' concurrency - shares), broken down by the label `priority_level`. + shares), broken down by the label `priorityLevel`. * `apiserver_flowcontrol_request_wait_duration_seconds` is a histogram vector of how long requests spent queued, broken down by the labels - `flow_schema` (indicating which one matched the request), - `priority_level` (indicating the one to which the request was + `flowSchema` (indicating which one matched the request), + `priorityLevel` (indicating the one to which the request was assigned), and `execute` (indicating whether the request started executing). {{< note >}} @@ -452,8 +445,8 @@ poorly-behaved workloads that may be harming system health. * `apiserver_flowcontrol_request_execution_seconds` is a histogram vector of how long requests took to actually execute, broken down by - the labels `flow_schema` (indicating which one matched the request) - and `priority_level` (indicating the one to which the request was + the labels `flowSchema` (indicating which one matched the request) + and `priorityLevel` (indicating the one to which the request was assigned). ### Debug endpoints