Kubernetes Admission Controller Webhook执行是否具备竞态安全性？

指标计数器是否需要加锁 #

要不要加锁完全取决于你的服务运行模型和计数器实现逻辑：

• 如果你用的是单进程单线程串行处理所有Webhook请求的模型，不存在并发写计数器的场景，不需要加锁。
• 如果你用的是常规的多线程/多协程并发Webhook服务，计数器存在于进程内存中：必须加锁或者使用语言提供的原子操作类（比如Go的sync/atomic、Python的multiprocessing.Value、Java的AtomicInteger）。普通的++自增操作不是原子的，并发场景下会出现计数丢失的竞态问题，比如两个请求同时读到值为1，各自加1后都写回2，最终计数比预期少1。
• 如果你的Webhook是多实例部署，计数器存在Redis等集中式存储中：如果直接调用存储端的原子递增接口（比如Redis的INCR命令），不需要自己加锁；如果是先读计数、本地加1再写回的逻辑，必须加分布式锁避免竞态。

Admission Controller的请求处理逻辑 #

Kubernetes的Admission Controller完全支持并发处理多个准入请求：

• kube-apiserver本身是多线程并发架构，不同的独立准入请求会被并行处理，不会串行排队。比如同时收到2个不同Deployment的创建请求，两个请求的准入流程会同时执行。
• 只有针对同一个请求的多个准入插件才会串行执行：Mutating类型的准入插件会先按照配置的顺序逐个执行修改资源的逻辑，全部执行完后再按配置顺序逐个执行Validating类型的准入插件做校验，同一请求的多个准入步骤不会并行。
• 如果是针对同一个资源的多个并发更新请求，会先经过kube-apiserver的资源版本冲突校验，冲突的请求会被直接拒绝，只有校验通过的请求才会进入准入流程。

内容的提问来源于stack exchange，提问作者jtee