Kubernetes Operator是否应删除非自身管控的集群资源？

核心结论 #

允许独立部署的Operator删除其他Operator管控的Pod不属于通用实践，你此前的认知符合Operator的核心设计规范。

具体说明 #

• Operator的核心设计边界是仅操作自身通过OwnerReference绑定管控的资源，跨Operator操作第三方资源会直接破坏Kubernetes的声明式一致性逻辑：如果两个Operator对同一Pod的状态有不同的预期，极易出现资源冲突、循环调度、状态异常等不可预期的故障。
• 你当前场景中Operator B的实现属于非常不合理的方案，Secret更新后需要重载应用配置的需求，有多种符合Kubernetes设计规范的解法：
  • 如果你使用的是Kubernetes 1.19及以上版本，可以在Deployment的Pod模板中添加标注关联Secret的哈希值，Secret变更时哈希值变化会自动触发Deployment的滚动更新，不需要额外控制器介入
  • 部署通用的配置重载控制器，自动监控关联Secret/ConfigMap的变更，触发对应负载的滚动更新
  • 改造应用本身支持配置热重载，监听到挂载的SSL密钥文件变更后自动加载新证书，完全不需要重启Pod
  • 如果两个Operator都是自研可控的，可以在Operator A中添加对关联Secret的监听逻辑，Secret变更时由Operator A自己触发管控负载的更新，不需要Operator B跨边界操作资源

特殊场景说明 #

如果确实存在跨Operator协作的需求，也需要通过自定义资源状态、约定的资源标注等方式实现松耦合协作，绝对不建议直接硬编码操作其他Operator管控的负载资源。

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