寻找无人使用的 Webhook、每6秒查询一次的 Operator：KubeVirt 主仓库 PR 在 2 天 16 小时内合并的过程

结果：已合并 (2026-10-20 16:05, kubevirt/kubevirt#19499). 截至 2026-10-29，暂无包含此变更的版本发布。 实际上，此内容取自 GitHub 的 PR、评审、行内评论、时间线、检查记录，KubeVirt 源码（PR 的基础提交 580886af），以及贡献记录的实测原始数据（operator 指标原值、reconcile 间隔）和草稿。时间均为韩国时间。

目录

• 一句话总结
• 1. 问题所在：59 天内 843,995 次 404
• 2. 原因：源码中的哪一行
• 3. 做了什么修改：diff 要点
• 4. 反应：一条行内评论，两个批准
• 5. 收获：开源贡献小贴士
• 链接

一句话总结

1. 问题所在：59 天内 843,995 次 404

TT Lab 使用 KubeVirt 运行学员的练习 VM。在 2026-10-17 仅通过读取命令浏览 TT Lab 集群的 KubeVirt 组件时 （贡献记录的 measure/kv），我们直接获取了 leader virt-operator 导出的 kubevirt_rest_client_requests_total 指标。 当时的版本是 KubeVirt v1.9.0、Kubernetes v1.34.10，该 operator 已经运行了 59 天。计数器是进程启动后累计的值。

收到 404 的 GET 请求数量与每次 reconcile 进行一次的 LIST nodes 在个位数上完全一致。这意味着每次 reconcile 准确无误地产生一次 404。这个 404 占 operator 总请求的 5.4%（843,995 ÷ 15,509,446），除了 4 个之外，占了所有非 2xx 响应（共 843,999 个）的全部。

统计当天 leader operator 日志中的 237 行「Handling KubeVirt resource」，reconcile 间隔最小 6.007 秒、中位数 6.055 秒、最大 6.088 秒（共 236 个区间）。59 天除以 6.055 秒大约是 84 万 2 千次，与计数器基本吻合（计算）。reconcile 每 6 秒运行一次本身是由于 Lease 续期引起的独立问题，此前已有相关 issue（#19342）和 修复 PR（#19417，截至 2026-10-29 处于开启状态）。我们发现的是叠加在之上的另一个问题。无论 reconcile 每几秒运行一次，这个 GET 请求从一开始就是完全没有必要的。

虽然没有造成明显的危害，但正如 PR 正文中所写，这些 404 请求在 VirtOperatorRESTErrorsBurst 警报监控的错误率下方总是垫底约 5% 的基础底噪。由于远未达到警报阈值（80%）因此不会触发警报，但它们会掩盖仪表盘上的真正错误。

2. 原因：源码中的哪一行

行号以 PR 的基础提交 580886af 为准。

• 每次 reconcile 调用的 createOrDeleteContainerPathVolumesWebhook 如果功能门控 ContainerPathVolumes 开启，就会创建 Webhook virt-launcher-pod-mutator ；如果关闭，就会删除已有的 Webhook。
• 问题出在关闭的情况。 第 273–285 行 首先查看 Informer 缓存，如果没有，就会带着「缓存可能尚未填满」的注释直接向 API Server 发送 GET 请求。如果是 404 则返回并表示没有需要删除的内容。
• 这个门控默认是关闭的，对于从未开启过门控的集群，该 Webhook 从一开始就不存在。因此缓存每次都是空的，每次都会发出 GET 请求，每次都会返回 404。

那么，「缓存可能尚未填满」的担忧是有道理的吗？controller 在开始工作之前会等待多个 Informer 同步。 kubevirt.go 第 169–194 行 的 hasSynced 列表中。其中包含了验证 Webhook Informer（第 180 行 ValidationWebhook），但唯独漏掉了变更 Webhook Informer（MutatingWebhook）。因此，对缓存的不信任是有原因的，需要修复的地方应该是同步列表，而不是 GET 请求。

这个直接 GET 是随 Webhook 一起在 #16662（VEP 165，2026-02-24 合并）中引入的。

3. 做了什么修改：diff 要点

 # pkg/virt-operator/kubevirt.go: 시작 전에 기다리는 인포머 목록
 			informers.ValidationWebhook.HasSynced() &&
+			informers.MutatingWebhook.HasSynced() &&

 # pkg/virt-operator/resource/apply/admissionregistration.go
-	// Feature gate is disabled, delete the webhook if it exists
+	// Feature gate is disabled, delete the webhook if it exists.
 	_, exists, _ := r.stores.MutatingWebhookCache.Get(webhook)
-	if !exists {
-		// Also check directly in case cache is not populated
-		_, err := r.k8sClient.AdmissionregistrationV1().MutatingWebhookConfigurations().Get(
-			context.Background(), webhook.Name, metav1.GetOptions{})
-		... (404 면 nil, 그 밖의 오류면 반환, 있으면 exists = true)
-	}

一旦缓存变得可信，缓存中不存在就意味着没有需要删除的内容，因此无需发送 API 请求。如果是开启过又关闭了门控的情况，由于 operator 创建的 Webhook 始终挂载着 Informer 所挑选的 managed-by 标签，因此会显示在缓存中并像以前一样被删除。PR 正文中也说明了这一选择的代价：如果有人手动剥离了该标签，operator 将无法看到该 Webhook 并将其删除。operator 通过标签挑选的其他对象也采用相同的方式处理。虽然也考虑过「仅在首次同步之前保留 GET」的方案，但因为需要维护额外的一个状态，最终还是选择了只需增加一行的同步方案。

测试扩展了原有的单元测试「should not create virt-launcher-pod-mutator webhook when disabled」。我们设置了当伪客户端以该 Webhook 名称记录 get 哪怕一次时就判定为失败。PR 正文中记载的结果如下（Go 1.27.2, linux/amd64, GOFLAGS=-mod=vendor, main 6e80bca).

其中有一次是 ./pkg/virt-operator/resource/apply/ 的 TestInstallStrategy 失败了，但在修复版和未修复版中重新运行均未复现，这也如实记录在了正文中。该输出的原始文件未单独保存在记录中。我们并未将修复后的 operator 部署到 TT Lab 集群中重新测量 404 是否消失（未实测）。因为 TT Lab 集群仍然是 v1.9.0，且目前没有包含此变更的版本发布。

关于 AI 的使用，我们作了如下声明。KubeVirt 的 AI 贡献政策建议使用 AI 工具时在提交说明尾部（Assisted-by:·Co-authored-by:·Generated-by:）中予以说明，同时依然要求进行 DCO 签名。 Assisted-by: Claude 我们在提交中附加了 Signed-off-by 和 47a37b0a ，并在 PR 模板的「AI Contributions」栏中勾选，并在正文末尾添加了「借助 Claude 追踪了指标中的原因并编写了变更和测试的草稿，本人已审查每一行代码，上述数字测量自我本人的集群」这一段落。有一个细节没有按原则进行：根据评审修改后重新生成的提交

在 GitHub 上显示为未签名提交（unsigned）。似乎是在重写提交时漏掉了原则 3 的 SSH 签名。

合并

评审的内容只有一条行内评论。最初提交的版本中，在被删除的 GET 位置有五行注释。解释内容为：「controller 等待 Webhook Informer 同步，由于 Webhook 始终挂载着标签，因此如果缓存中没有则说明无需删除，如果此时向 API Server 查询，会导致所有不使用该门控的集群在每次 reconcile 时产生 404 GET」。评审员表示不确定这是否算是一个严重问题。由于 Webhook 的创建或删除会由事件处理器捕获并重新加入队列，因此意见是注释可以去掉。

确实如此。即使在同步前的短暂间隙缓存为空，一旦 Webhook 出现，Informer 也会再次触发 reconcile。也就是说，注释夸大了这个 GET 的作用。删除了五行注释并修改提交重新上传后，简短回复了「Informer 在添加和删除时无论如何都会重新放回队列，注释夸大了作用，已移除」。结果，PR 的代码仅保留了增加的一行和删除的 GET 块。 virt-operator approver 是 /approve 目录下 OWNERS 中的人员，也是引入该直接 GET 的 #16662 的作者。留下的留言是

以及一句感谢。包含 2 阶段 e2e 在内的 42 个检查全部通过，第二天下午 tide 进行了合并。记录中将此 PR 记载为选定 KubeVirt 作为主力技术栈后进入主仓库的第一笔合并。

• 「5. 收获：开源贡献小贴士operator 自身的指标是最好的复现方式。「
• 「」客户端请求计数器会按代码路径记录。关于 404 数量等于 reconcile 数量的一行数据证明了「每次 reconcile 准确无误地发生一次」的主张。既不需要翻看日志，也不需要挂载调试器。在删除绕过代码之前，先修复产生绕过的原因。」直接使用 GET 是因为无法信任缓存，而无法信任缓存的原因是同步列表中漏掉的一行。加上那一行后，删除 GET 就变得安全了。旁边已经存在同类 informer (ValidationWebhook) 成为了最简短的依据。
• 「编写注释不是为了说服审阅者。」我曾在 PR 正文中详细解释了本应留在代码注释中的内容，结果受到了批评。留在代码中的内容应该只记录只要代码不改变就始终为真的事实，而为什么这次要修改则应该保留在提交信息和 PR 正文中。
• 「不受信任的贡献者无法直接运行测试。」KubeVirt 仓库中外部作者无法通过 /ok-to-test 触发测试，必须由协作者输入 /test all 。因此，在 PR 正文中以数字形式记录本地测试结果（修复前失败，修复后通过）显得更加重要。
• 「检查修改后的提交是否也带有签名。」根据审阅意见重新创建提交时漏掉了签名。虽然通过了 DCO，但这与原则不符。在 push 之前执行 git log --show-signature -1 一次即可确认。

Titi 的一句话。 据说看门大叔每隔 6 秒就会敲一次仓库的门，并问道：“这里有箱子吗？”可仓库里从一开始就没有那个箱子。虽然只要看一下笔记本就行，但因为笔记本的列表中唯独漏掉了那个仓库，所以才无法信任。帮他在笔记本上补记了一行之后，持续了两个月、敲了 84 万多次门的事情就消失了。至于那张写着“为什么需要敲门”的长篇大论的字条，因为别人说“那个可以拿掉”，所以就撕掉了。

链接

所有资料均于 2026-10-29 查阅。

• PR: kubevirt/kubevirt#19499 （合并提交 6443e168)
• 修改后的源码（基础提交）： admissionregistration.go 第 266–301 行, kubevirt.go 第 169–194 行
• 引入直接 GET 的 PR: kubevirt/kubevirt#16662
• 6秒 reconcile: Issue #19342, PR #19417
• KubeVirt AI 贡献政策: https://github.com/kubevirt/community/blob/main/ai-contribution-policy.md
• 同一天在同一调查中产出的 CDI PR: 第 7 篇，containerized-data-importer#4319