Kubernetes中重建已删除LoadBalancer Service是否存在预期竞态条件？

复现流程 #

在Azure Kubernetes Services（AKS）环境按顺序执行以下操作，可观测到明确的竞态问题：

• 基于Helm chart执行helm install命令，部署类型为LoadBalancer的Service资源
• 执行helm uninstall命令删除上一步创建的Service资源
• 操作间隔极短的前提下，再次执行helm install命令重建同名Service资源

触发原理 #

LoadBalancer类型Service默认配置finalizer机制，负责保障关联的底层云负载均衡资源完成垃圾回收：当Kubernetes API服务器对删除请求返回成功响应时，Service对应的底层云资源并未完成实际清理，该Service资源仅被标记为待删除（Terminating）状态。
当三步操作间隔足够短时，第二次helm install操作不会触发实际的资源重建逻辑，最终会出现Helm侧显示Release已安装成功，但集群内实际不存在对应Service资源的不一致异常。

责任边界疑问 #

目前需要确认该现象是否属于Kubernetes/Helm的预期设计行为：

• 若不属于预期行为，是否需要向Kubernetes社区提交Bug，推动优化API Server逻辑，直接拒绝对处于删除流程中的Service的修改请求
• 还是需要向Helm社区提交Bug，推动优化Helm的资源校验逻辑，在安装前识别处于待删除状态的同名资源，阻止无效的重复重装操作

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