Argo CD `argocd app confirm-deletion` 命令详解：删除/清理确认机制与 deletion-approved 注解-北京尧图网络

Argo CDargocd app confirm-deletion命令详解删除/清理确认机制与 deletion-approved 注解【免费下载链接】argo-cdDeclarative Continuous Deployment for Kubernetes项目地址: https://gitcode.com/GitHub_Trending/ar/argo-cd在 Argo CD 中当应用或资源设置了Deleteconfirm/Pruneconfirm同步选项时同步操作或级联删除会在真正执行删除动作前暂停等待人工确认。本文以argocd app confirm-deletion命令为核心完整讲清它的用法与参数并结合仓库源码说明其底层机制该命令本质上是给 Application 对象写入argocd.argoproj.io/deletion-approved时间戳注解使控制器判定“删除已被批准”并继续执行挂起的同步或清理。读完后你将能够独立完成带确认保护的删除/清理操作并理解确认时间戳的生效规则与资源级/应用级选项的覆盖关系。命令用途与适用场景argocd app confirm-deletion用于确认删除或清理prune应用资源。它服务于两类受保护场景详见同步选项文档资源删除确认Deleteconfirm关键资源如 Namespace不应在级联删除应用时被误删。设置该选项后删除同步操作会在删除任何应用资源前暂停并等待用户确认资源清理确认Pruneconfirm设置该选项后被标记资源从目标清单移除时不会自动被 prune同步操作会保持在 Syncing 状态直到清理被确认UI 中会出现 Confirm Pruning 按钮CLI 即对应本文命令。这两个选项可以设置在资源注解或应用级别# 资源级通过 sync-options 注解 metadata: annotations: argocd.argoproj.io/sync-options: Pruneconfirm# 应用级作为默认选项 apiVersion: argoproj.io/v1alpha1 kind: Application spec: syncPolicy: syncOptions: - Deleteconfirm - Pruneconfirm确认后除了通过 UI还可以使用 CLI本文命令或手动给 Application 打上argocd.argoproj.io/deletion-approved: RFC3339 时间戳注解。确认机制的设计动机见资源删除审批提案。命令语法与参数argocd app confirm-deletion APPNAME [flags]命令参数参数说明-N, --app-namespaceApplication 所在的 Kubernetes 命名空间。可与APPNAME组合也支持namespace:name限定名写法-h, --help显示帮助信息需要留意的一点从源码 cmd/argocd/commands/app.go 看--app-namespace的帮助文本复用了其他命令的措辞Namespace of the target application where the source will be appended但其实际用途是在argo.ParseFromQualifiedName(args[0], appNamespace)中解析出 Application 的命名空间即用于指定 Application 所在命名空间。从父命令继承的通用选项与当前仓库 CLI 生成文档一致--argocd-context string The name of the Argo-CD server context to use --auth-token string Authentication token; set this or the ARGOCD_AUTH_TOKEN environment variable --client-crt string Client certificate file --client-crt-key string Client certificate key file --config string Path to Argo CD config (default /home/user/.config/argocd/config) --controller-name string Name of the Argo CD Application controller; set this or the ARGOCD_APPLICATION_CONTROLLER_NAME environment variable when the controllers name label differs from the default, for example when installing via the Helm chart (default argocd-application-controller) --core If set to true then CLI talks directly to Kubernetes instead of talking to Argo CD API server --grpc-web Enables gRPC-web protocol. Useful if Argo CD server is behind proxy which does not support HTTP2. --grpc-web-root-path string Enables gRPC-web protocol. Useful if Argo CD server is behind proxy which does not support HTTP2. Set web root. -H, --header strings Sets additional header to all requests made by Argo CD CLI. (Can be repeated multiple times to add multiple headers, also supports comma separated headers) --http-retry-max int Maximum number to retries to establish http connection to Argo CD server --insecure Skip server certificate and domain verification --kube-context string Directs the command to the given kube-context --logformat string Set the logging format. One of: json|text (default json) --loglevel string Set the logging level. One of: debug|info|warn|error (default info) --plaintext Disable TLS --port-forward Connect to a random argocd-server port using port forwarding --port-forward-namespace string Namespace name which should be used for port forwarding --prompts-enabled Force optional interactive prompts to be enabled or disabled, overriding local configuration. If not specified, the local configuration value will be used, which is false by default. --redis-compress string Enable this if the application controller is configured with redis compression enabled. (possible values: gzip, none) (default gzip) --redis-haproxy-name string Name of the Redis HA Proxy; set this or the ARGOCD_REDIS_HAPROXY_NAME environment variable when the HA Proxys name label differs from the default, for example when installing via the Helm chart (default argocd-redis-ha-haproxy) --redis-name string Name of the Redis deployment; set this or the ARGOCD_REDIS_NAME environment variable when the Rediss name label differs from the default, for example when installing via the Helm chart (default argocd-redis) --repo-server-name string Name of the Argo CD Repo server; set this or the ARGOCD_REPO_SERVER_NAME environment variable when the servers name label differs from the default, for example when installing via the Helm chart (default argocd-repo-server) --server string Argo CD server address --server-crt string Server certificate file --server-name string Name of the Argo CD API server; set this or the ARGOCD_SERVER_NAME environment variable when the servers name label differs from the default, for example when installing via the Helm chart (default argocd-server)典型使用示例假设应用名为guestbook位于默认命名空间# 应用已因 Deleteconfirm / Pruneconfirm 暂停在确认等待状态时 argocd app confirm-deletion guestbook # 指定应用所在命名空间 argocd app confirm-deletion --app-namespace team-a guestbook # 或使用限定名写法 argocd app confirm-deletion team-a/guestbook底层实现写入 deletion-approved 注解命令的入口是 NewApplicationConfirmDeletionCommand其执行流程非常直接校验参数APPNAME必须恰好一个否则打印帮助并退出建立 gRPC 连接通过argocdClient.NewApplicationClientOrDieWithContext(ctx)获得 Application 客户端用argo.ParseFromQualifiedName(args[0], appNamespace)解析出应用名与命名空间再通过appIf.Get(...)拉取 Application 对象在 Application 的注解中写入确认时间戳annotations[common.AnnotationDeletionApproved] metav1.Now().Format(time.RFC3339)调用appIf.Update(...)提交更新Validate: new(false)表示跳过服务端校验最后输出Application guestbook updated successfully其中注解常量定义在 gitops-engine/pkg/sync/common/types.goAnnotationDeletionApproved argocd.argoproj.io/deletion-approved也就是说confirm-deletion命令并不直接触发删除而只是盖一个“已批准”的时间戳真正的删除/清理仍由 Application 控制器在后续调谐中执行。这也意味着你可以不用 CLI直接手动kubectl annotate该注解达到同样效果参见注解与标签文档中argocd.argoproj.io/deletion-approved条目其取值为 RFC3339 时间戳。控制器如何消费确认时间戳关键在于确认是“有时效”的时间戳必须不早于当前操作/删除的起点。Application 类型上的判定方法定义在 pkg/apis/application/v1alpha1/types.go// IsDeletionConfirmed checks whether the application has been approved for deletion. // It compares the timestamp stored in the AnnotationDeletionApproved annotation // with the provided since time. If the annotation is missing or has an invalid // timestamp format, it returns false. func (app *Application) IsDeletionConfirmed(since time.Time) bool { val : app.GetAnnotation(synccommon.AnnotationDeletionApproved) if val { return false } parsedVal, err : time.Parse(time.RFC3339, val) if err ! nil { return false } return parsedVal.After(since) || parsedVal.Equal(since) }注解缺失或时间戳格式非法时返回false注解时间早于since时同样不生效。这个设计保证每一轮新的同步操作或级联删除都需要一次新的确认旧的批准不会无限期有效。控制器在两个消费点使用它同步路径Pruneconfirmcontroller/sync.go 在构建同步上下文时传入sync.WithPruneConfirmed(app.IsDeletionConfirmed(state.StartedAt.Time)),since取同步操作的开始时间state.StartedAt。在 gitops-engine 侧sync_context.go 的WithPruneConfirmed设置pruneConfirmed字段执行阶段如果存在需要确认的 prune 任务且未确认则返回 pending 并输出等待信息可参见 sync_context_test.go 中的断言waiting for pruning confirmation of /Pod/my-podif !sc.pruneConfirmed { for _, task : range pruneTasks { if objRequiresPruneConfirmation(task.liveObj, sc.defaultPruneOption) { sc.log.WithValues(task, task).Info(Prune requires confirmation) return pending } } }应用删除路径Deleteconfirmcontroller/appcontroller.go 在处理级联删除时以 Application 的DeletionTimestamp作为sinceif app.CascadedDeletion() { deletionApproved : app.IsDeletionConfirmed(app.DeletionTimestamp.Time)即删除时间戳之后含写入的确认注解才算数——因此先argocd app delete打上了删除标记再执行confirm-deletion才能放行。这也解释了端到端测试夹具中的一个细节test/e2e/fixture/app/actions.go 中ConfirmDeletion()执行 CLI 后会刻意time.Sleep(3 * time.Second)注释说明这是为了避免容器间秒级时钟偏差导致的竞态——确认时间戳必须严格“不早于”操作起点否则判定不成立。确认选项的生效与覆盖规则Pruneconfirm/Deleteconfirm同时存在于资源级注解与应用级 syncOptions 时资源级选项总是覆盖应用级策略。controller/state_test.go 的表驱动测试覆盖了大量组合可归纳为应用级选项资源级选项是否需要确认无无否Deleteconfirm无是Pruneconfirm无是DeleteconfirmDeleteconfirm是DeleteconfirmDeletefoo被覆盖掉否PruneconfirmPrunefoo被覆盖掉否PruneconfirmDeleteconfirm混合场景仍需确认是资源级测试 TestPruneConfirmResourceLevel 还验证了即使应用级defaultPruneOption为true/false/confirm/未设置带Pruneconfirm注解的资源都会触发确认等待确认后pruneConfirmed true同一轮同步继续执行资源状态变为pruned。端到端验证从挂起到完成的完整流程test/e2e/app_management_test.go 中有两个端到端用例完整演练了本文命令的使用闭环资源级场景创建一个带argocd.argoproj.io/app-instance-name追踪注解和Pruneconfirm注解的 ConfigMap并通过 patch 给guestbook-ui-deployment.yaml加上Deleteconfirm注解。随后CreateApp().Sync()后操作状态持续为Running即暂停等待确认ConfirmDeletion()执行argocd app confirm-deletion后操作进入Succeeded应用恢复SyncedHealthyDelete(true)触发级联删除Application 进入等待删除确认状态DeletionTimestamp ! nil再次ConfirmDeletion()后应用被真正删除DoesNotExist()。应用级场景TestDeletionConfirmationAppLevel则直接在spec.syncPolicy.syncOptions中配置Deleteconfirm与Pruneconfirm验证流程完全一致——说明无论选项定义在哪个层级confirm-deletion都是同一把“确认钥匙”。小结与延伸阅读argocd app confirm-deletion的作用只有一个给 Application 写入argocd.argoproj.io/deletion-approved注解RFC3339 当前时间批准由Deleteconfirm/Pruneconfirm挂起的删除/清理实现见 cmd/argocd/commands/app.go确认具有时效性注解时间戳必须不早于同步操作开始时间或 Application 删除时间戳判定逻辑见 IsDeletionConfirmed消费点分别位于 controller/sync.go同步清理与 controller/appcontroller.go级联删除相关文档同步选项、注解与标签、argocd app 子命令索引。【免费下载链接】argo-cdDeclarative Continuous Deployment for Kubernetes项目地址: https://gitcode.com/GitHub_Trending/ar/argo-cd创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考

Argo CD `argocd app confirm-deletion` 命令详解：删除/清理确认机制与 deletion-approved 注解

相关推荐

Kubo IPFSWatch：用 Go 守护进程监控本地目录并自动将变更内容上链 IPFS 的实战指南

libSQL 源码详解：sqlite3-jni，在 Java 中一比一映射 SQLite3 C API

Flutter表单开发实战：剧本杀组队功能实现

更多资讯

TiDB 保存点实操：长事务部分回滚避坑

浙大数据可视化课程学习笔记

ARIMA-SSA-LSTM组合模型：时间序列预测的完整实战指南

基于协同过滤与SVD的Steam游戏推荐系统设计与实现

基于MATLAB/Simulink的机器人强化学习自适应控制实践指南

【Selenium（五）】

今日更新

AI驱动的自动化专利分析平台技术解析

LeetCode-Go 题解：1252. Cells with Odd Values in a Matrix（奇数值单元格计数）双解法剖析

在线答疑系统Java毕设实战：Spring Boot前后端分离与状态流转

本周精选

AI驱动的自动化专利分析平台技术解析

LeetCode-Go 题解：1252. Cells with Odd Values in a Matrix（奇数值单元格计数）双解法剖析

在线答疑系统Java毕设实战：Spring Boot前后端分离与状态流转

本月热门

基于YOLO的焊缝缺陷检测：从数据标注到工业部署全流程实践

分布式服务的决策记录

创业产品的首版范围

读完文章，想聊聊您的网站？