Kubernetes API 和流量控制：管理请求数量和排队进程_kube-apiserver服务流量突然增大-CSDN博客

本文链接：https://blog.csdn.net/2401_84281698/article/details/137868539

先自我介绍一下，小编浙江大学毕业，去过华为、字节跳动等大厂，目前阿里P7

深知大多数程序员，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年最新Golang全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上Go语言开发知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

如果你需要这些资料，可以添加V获取：vip1024b （备注go）

正文

然后，同样的事情再次发生。

我们认为限制对 API 的并发 cilium-agent 请求的数量是个好主意。在这种情况下，稍微慢一点的 LIST 请求执行不会影响 Cilium 的性能。

解决方案

我们创建了以下内容和清单：FlowSchema``PriorityLevelConfiguration

apiVersion: flowcontrol.apiserver.k8s.io/v1beta1
kind: FlowSchema
metadata:
name: cilium-pods
spec:
distinguisherMethod:
type: ByUser
matchingPrecedence: 1000
priorityLevelConfiguration:
name: cilium-pods
rules:

resourceRules:
apiGroups:
‘cilium.io’
clusterScope: true
namespaces:
‘*’
resources:
‘*’
verbs:
‘list’
subjects:
group:
name: system:serviceaccounts:d8-cni-cilium
kind: Group

apiVersion: flowcontrol.apiserver.k8s.io/v1beta1
kind: PriorityLevelConfiguration
metadata:
name: cilium-pods
spec:
type: Limited
limited:
assuredConcurrencyShares: 5
limitResponse:
queuing:
handSize: 4
queueLengthLimit: 50
queues: 16
type: Queue

…并将它们部署到集群中。

重新启动 cilium-agent 不再导致显著的内存消耗变化。因此，我们能够将节点资源削减到原始资源。

我们做了什么，这些操作如何帮助消除多个 Kubernetes API 请求时的问题？阅读下面的细分。

在 Kubernetes API 中管理请求

在 Kubernetes 中，请求队列管理由 API 优先级和公平性（APF）处理。默认情况下，它在 Kubernetes 1.20 及更高版本中处于启用状态。API 服务器还提供了两个参数，（默认为 400）和（默认为 200），用于限制请求数量。如果启用了 APF，则将这两个参数相加，这就是 API 服务器的总并发限制的定义方式。--max-requests-inflight``--max-mutating-requests-inflight

也就是说，还有一些更精细的细节需要考虑：

长时间运行的 API 请求（例如，在 Pod 中查看日志或执行命令）不受 APF 限制的约束，WATCH 请求也不受限制。
还有一个特殊的预定义优先级，称为。来自此级别的请求将立即得到处理。exempt

APF 确保 Cilium 代理请求不会“限制”用户 API 请求。APF 还允许您设置限制，以确保无论 K8s API 服务器负载如何，重要请求始终得到处理。

您可以使用以下两个资源配置 APF：

PriorityLevelConfiguration这定义了一个可用的优先级。
FlowSchema将每个传入请求映射到单个 .PriorityLevelConfiguration

优先级配置

每个都有自己的并发限制（份额）。总并发限制按其份额的比例分配给现有用户。PiorityLevelConfiguration``PriorityLevelConfigurations

让我们按照以下示例计算该限制：

~# kubectl get prioritylevelconfigurations.flowcontrol.apiserver.k8s.io
NAME TYPE ASSUREDCONCURRENCYSHARES QUEUES HANDSIZE QUEUELENGTHLIMIT AGE
catch-all Limited 5 193d
d8-serviceaccounts Limited 5 32 8 50 53d
deckhouse-pod Limited 10 128 6 50 90d
exempt Exempt 193d
global-default Limited 20 128 6 50 193d
leader-election Limited 10 16 4 50 193d
node-high Limited 40 64 6 50 183d
system Limited 30 64 6 50 193d
workload-high Limited 40 128 6 50 193d
workload-low Limited 100 128 6 50 193d

首先，将所有（260）相加。AssuredConcurrencyShares
现在，计算请求限制，例如，优先级：（400+200）/260*100 = 每秒 230 个请求。workload-low

让我们更改其中一个值，看看会发生什么。例如，让我们从 10 增加到 100。请求限制将降至（400+200）/350*100 = 每秒 171 个请求。AssuredConcurrencyShares``deckhouse-pod

通过增加 AssuredConcurrencyShares 数量，我们增加了特定级别的查询限制，但降低了所有其他级别的查询限制。

如果优先级中的请求数大于允许的限制，则请求将排队。您可以选择自定义队列参数。您还可以将 APF 配置为立即丢弃超出特定优先级限制的请求。

让我们看一下下面的例子：

在这里，优先级配置为具有 .如果没有其他自定义优先级，则每秒会产生 12 个请求。请求队列设置为 200 个请求（），并创建 16 个内部队列，以便更均匀地分配来自不同代理的请求。AssuredConcurrencyShares = 5``handSize * queueLengthLimit

关于 K8s 流量控制中优先级配置的一些重要细节：

拥有更多队列可减少流之间的冲突次数，但会增加内存使用量。将其设置为禁用公平性逻辑，但仍允许对请求进行排队。1
增加渲染，可以在不忽略单个请求的情况下处理高流量突发。但是，查询的处理速度较慢，并且需要更多的内存。queueLengthLimit
通过更改，可以调整流之间发生冲突的可能性，以及在高负载情况下单个流可用的整体并发性。handSize

这些参数是通过实验选择的：

一方面，我们需要确保此优先级的请求不会处理得太慢。
另一方面，我们需要确保 API 服务器不会因突然的流量峰值而过载。

流架构

现在让我们继续讨论资源。它的作用是将请求映射到相应的 .FlowSchema``PriorityLevel

其主要参数有：

matchingPrecedence：定义应用顺序。数字越小，优先级越高。这样，您就可以从更具体的案例到更一般的案例编写重叠。FlowSchema``FlowSchemas
rules：定义请求过滤规则;格式与 Kubernetes RBAC 中的格式相同。
distinguisherMethod：指定一个参数（用户或命名空间），用于在将请求转发到优先级时将请求分成流。如果省略该参数，则所有请求都将分配给同一流。

例：