Shulou(Shulou.com)05/31 Report--

In this issue, the editor will bring you about how the APF in K8S is used. The article is rich in content and analyzes and narrates it from a professional point of view. I hope you can get something after reading this article.

Let's first take a look at the official description of K8S APF:

"controlling the behavior of Kubernetes API servers under overload is a critical task for cluster administrators. Kube-apiserver has some available controls (that is, the-- max-requests-inflight and-- max-mutating-requests-inflight command line flags) to limit the amount of outstanding work that will be accepted, thereby preventing a large number of requests that are overloaded on the inbound API server and may cause the API server to crash, but these flags are not sufficient to ensure that the most important requests pass during high traffic periods.

API Priority and Fairness (APF) is an alternative that can improve the above max-inflight limitations. APF classifies and isolates requests in a more fine-grained manner. It also introduces a limited number of queues, so no requests are rejected in very short emergencies. By using fair queuing technology to distribute requests from the queue, a poorly behaved K8S apiserver does not prevent other apiserver from accepting new requests, even if they have the same priority. "

To put it simply: Api server adds a current-limiting mechanism. Protection api is maliciously requested to consume resources and then die. However, due to the improper setting of the default weight value (the weighting of SA accessing workload-low is 20J account Token accessing global-default is 100th), it may cause the alarm problem of K8S cluster similar to KubeAPILatencyHigh, KubeAPIErrorsHigh, KubeAPIDown.

Https://github.com/kubernetes/kubernetes/pull/95259

If you find the alarm problem of KubeAPILatencyHigh, KubeAPIErrorsHigh, KubeAPIDown, use the following command to judge:

# oc get-- raw / debug/api_priority_and_fairness/dump_priority_levels

In the picture above, we see a lot of waiting for the workload-low line.

To solve this problem, the current method in OpenShift is to temporarily turn off the function of this APF:

# oc patch kubeapiserver cluster-- type=merge-p'{"spec": {"unsupportedConfigOverrides": {"apiServerArguments": {"feature-gates": ["APIPriorityAndFairness=false"]}'

After executing the command, follow the pod in openshift-kube-apiserver ns:

# oc get pods-n openshift-kube-apiserver-w

The pod of kube-api server is automatically rebuilt (first the pod of installer is automatically created, then the api-server pod is automatically rebuilt).

Rebuilt successfully:

It is important to note that if you want to upgrade OCP, restore this parameter before upgrading so as not to affect the upgrade of OCP.

# oc patch kubeapiserver cluster-- type=merge-p'{"spec": {"unsupportedConfigOverrides": {"apiServerArguments": {"feature-gates": ["APIPriorityAndFairness=true"} 'this is how the APF in K8S shared by the editor is used. If you happen to have similar doubts, please refer to the above analysis to understand. If you want to know more about it, you are welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.