kube-apiserver限流机制原理
内容提要
本文介绍了kubernetes中kube-apiserver的限流机制。在kubernetes 1.18版本之前，kube-apiserver只能根据请求类型进行限流，容易导致系统阻塞。而在1.18版本后，引入了APIPriorityAndFairness（APF）作为默认的限流方式，可以根据请求对象、请求者身份、命名空间等更细粒度地进行限流。APF通过FlowSchema和PriorityLevelConfiguration两个资源配置限流策略。FlowSchema用于匹配请求，PriorityLevelConfiguration用于定义限流细节。文章还介绍了APF的处理过程和实战操作。
延伸解读
从粗放到精细：限流机制的演进动因
Kubernetes 1.18版本前，kube-apiserver仅按请求是否变更分为两类，通过启动参数限制最大并发数。这种粗粒度限流下，单个客户端的大量请求就可能阻塞整个apiserver，影响其他客户端。APF的引入正是为了解决分类颗粒度粗、隔离性差和缺乏优先级的问题，使限流能基于请求对象、身份、命名空间等维度进行。
APF核心资源如何协同工作
APF通过FlowSchema和PriorityLevelConfiguration两个资源实现限流。FlowSchema根据rules匹配请求，并关联一个PriorityLevelConfiguration；后者定义并发上限、队列数、队列长度及无法处理时的行为（排队或拒绝）。多个FlowSchema可关联同一个PriorityLevelConfiguration，但一个FlowSchema只能关联一个。这种设计让不同请求获得独立的限流配置，互不干扰。
公平调度与隔离：APF如何保护apiserver
当请求匹配FlowSchema后，会根据DistinguisherMethod分组并分配固定队列。若PriorityLevelConfiguration达到并发上限，请求进入所属队列等待，恶意用户只能撑爆自己的队列，不影响同PriorityLevelConfiguration中的其他队列。未达上限时，fair queuing算法从所有队列中公平选取请求执行，避免饿死，保证同一优先级内各队列被处理机会平等。
实战观察：如何确认限流已触发
创建自定义FlowSchema和PriorityLevelConfiguration后，可通过kubectl get --raw /debug/api_priority_and_fairness/dump_priority_levels查看限流状态。若返回的waitingRequests非0，说明已达到最大并发数，有请求进入等待队列；若PriorityLevelConfiguration资源不为空闲，同样表示已达到并发上限。这为验证限流规则是否生效提供了直接依据。
Q&A
kube-apiserver的限流机制有什么重要性？
kube-apiserver的限流机制可以提升系统的健壮性，防止恶意请求导致服务崩溃，从而保证整个kubernetes集群的可用性。
kubernetes 1.18版本之前的限流机制是怎样的？
在1.18版本之前，kube-apiserver仅根据请求类型（变更和非变更）进行限流，容易导致系统阻塞。
APIPriorityAndFairness（APF）是如何改进限流机制的？
APF通过更细粒度的分类和隔离请求，支持根据请求对象、请求者身份和命名空间等进行限流，提升了系统的公平性和隔离性。
FlowSchema和PriorityLevelConfiguration在APF中有什么作用？
FlowSchema用于匹配请求并定义分类规则，PriorityLevelConfiguration则定义限流细节和优先级，二者共同配置限流策略。
APF的处理过程是怎样的？
APF处理过程包括请求与FlowSchema匹配、分配队列和公平调度，确保请求根据优先级和公平性被处理。
如何在APF中创建新的限流规则？
可以通过定义新的FlowSchema和PriorityLevelConfiguration资源来创建限流规则，指定匹配条件和限流细节。
