假设只有一个准入控制器 Pod 在运行，并且准入控制器有一个 webhook，会被 Pod 删除事件触发。
示例场景
一个命名空间中有 2 个 Pod（Pod A 和 Pod B）。 2 个不同的用户（Alice 和 Bob）同时执行 Pod 删除，其中：
在这个特定场景中，准入控制器是串行还是并行处理准入请求？换句话说，准入控制器会在 Pod B 之前处理 Pod A 的准入请求（反之亦然），还是会同时处理两个准入请求？
一般场景
准入请求从 API 服务器发送到准入控制器。一般来说，是否有可能同时向准入控制器发送多个准入请求？
如果是这样，准入控制器会通过一些内置的并行机制并行处理它们，还是准入控制器将它们排队并串行处理？
【问题讨论】：
由于在kube-api options 中我们可以看到--max-mutating-requests-inflight 和--max-requests-inflight 标志，它们用于确定服务器的总并发限制，我认为准入控制器也支持多线程。因为否则它将成为处理 API 请求的瓶颈。
这是真实而准确的建议，只要我们使用的是基础环境。
但另一方面，我们可以自定义环境并指定应如何处理请求。
为此可以使用API Priority and Fairness (APF)。与--max-mutating-requests-inflight 和--max-requests-inflight 相比，APF 以更细粒度的方式对请求进行分类和隔离。
如果没有启用 APF，API 服务器中的整体并发性会受到
kube-apiserver标志--max-requests-inflight和--max-mutating-requests-inflight的限制。启用 APF 后，这些标志定义的并发限制被求和，然后在一组可配置的 优先级 中分配总和。每个传入的请求都分配给一个优先级，每个优先级只会调度其配置允许的并发请求。
例如，默认配置包括领导选举请求、来自内置控制器的请求和来自 Pod 的请求的单独优先级。
所以，这是一个相当广泛的问题。这完全取决于我们使用的准入控制器：原始的还是自定义的，使用了哪些控件（--max-mutating-requests-inflight 和 --max-requests-inflight 命令行标志），APF 配置。
【讨论】：