以下是问题发生时的内存消耗图:
内存消耗高达 50 GB。后来,我们发现,由于某些因素,Cilium pod 正在向 API 大量发送 LIST 请求。由于集群很大,并且有大量的节点(超过 200 个),同时请求会大大增加使用的内存量。
我们与客户达成一致,操作一个测试窗口,重新启动了 Cilium 代理,我们发现以下情况:
- 其中一个 API 服务器上的负载正在增长。
- 它消耗内存。
- 它耗尽了节点上的所有内存。
- 然后崩溃了。
- 请求已重定向到另一台服务器。
- 然后,同样的事情再次发生。
我们认为限制对 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 <none> <none> <none> 193d
d8-serviceaccounts Limited 5 32 8 50 53d
deckhouse-pod Limited 10 128 6 50 90d
exempt Exempt <none> <none> <none> <none> 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 配置为立即丢弃超出特定优先级限制的请求。
让我们看一下下面的例子:
---
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
在这里,优先级配置为具有 .如果没有其他自定义优先级,则每秒会产生 12 个请求。请求队列设置为 200 个请求 (),并创建 16 个内部队列,以便更均匀地分配来自不同代理的请求。AssuredConcurrencyShares = 5``handSize * queueLengthLimit
关于 K8s 流量控制中优先级配置的一些重要细节:
- 拥有更多队列可减少流之间的冲突次数,但会增加内存使用量。将其设置为禁用公平性逻辑,但仍允许对请求进行排队。
1
- 增加渲染,可以在不忽略单个请求的情况下处理高流量突发。但是,查询的处理速度较慢,并且需要更多的内存。
queueLengthLimit
- 通过更改 ,可以调整流之间发生冲突的可能性,以及在高负载情况下单个流可用的整体并发性。
handSize
这些参数是通过实验选择的:
- 一方面,我们需要确保此优先级的请求不会处理得太慢。
- 另一方面,我们需要确保 API 服务器不会因突然的流量峰值而过载。
流架构
现在让我们继续讨论资源。它的作用是将请求映射到相应的 .FlowSchema``PriorityLevel
其主要参数有:
matchingPrecedence
:定义应用顺序。数字越小,优先级越高。这样,您就可以从更具体的案例到更一般的案例编写重叠。FlowSchema``FlowSchemas
rules
:定义请求过滤规则;格式与 Kubernetes RBAC 中的格式相同。distinguisherMethod
:指定一个参数(用户或命名空间),用于在将请求转发到优先级时将请求分成流。如果省略该参数,则所有请求都将分配给同一流。
例:
---
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
在上面的示例中,我们选取了所有 LIST 请求,包括集群范围的请求以及从所有命名空间发送到所有资源的请求。主题包括来自服务帐户的所有请求。apiGroup: cilium.io``d8-cni-cilium
我如何找出请求所在的位置和请求?FlowSchema``PriorityLevelConfiguration
响应时,API 服务器会提供特殊标头 X-Kubernetes-PF-FlowSchema-UID 和 X-Kubernetes-PF-PriorityLevel-UID。您可以使用它们来查看请求的去向。