Argo CD 通知触发器排查指南argocd admin notifications trigger get命令详解【免费下载链接】argo-cdDeclarative Continuous Deployment for Kubernetes项目地址: https://gitcode.com/GitHub_Trending/ar/argo-cd本文以 Argo CD CLI 子命令argocd admin notifications trigger get为对象完整讲解该命令的用途、全部选项参数含从父命令继承的全局标志、集群内与集群外两种典型排障场景并结合仓库中 命令实现源码 与 内置触发器目录 剖析触发器trigger配置的加载机制。读完后你能够独立完成对 Argo CD 通知触发器配置的查看、本地校验与在 Pod 内验证并理解这些配置在集群中的实际存储位置。命令功能与基本用法argocd admin notifications trigger get用于打印Prints information about当前生效的通知触发器配置信息。通知触发器是 Argo CD 通知体系的“条件—动作”规则当应用状态满足某个表达式when条件时按触发器定义向指定接收者发送模板化通知。该命令适合在以下场景使用排查“为什么某个同步失败/健康降级没有收到通知”校验本地修改的argocd-notifications-cm配置是否被正确解析在集群内 Pod 中直接查看控制器实际加载的触发器清单。命令的标准格式与官方示例来自 命令参考文档argocd admin notifications trigger get [flags]# 打印所有已配置的触发器 argocd admin notifications trigger get # 以 YAML 格式打印 on-sync-failed 触发器定义 argocd admin notifications trigger get on-sync-failed -oyaml可以看出命令支持两种用法不带参数时列出全部触发器带触发器名称如on-sync-failed参数时只输出该触发器的定义。命令自身选项该命令自身只提供两个选项选项说明-h, --help显示get子命令帮助-o, --output string输出格式取值为json\|yaml\|wide\|name默认wide四种输出格式的适用场景wide默认表格化列出所有触发器适合快速概览yaml/json输出指定触发器的完整定义when、description、send、oncePer等字段适合粘贴进工单或做脚本化比对name只输出名称适合配合管道与其他命令组合使用。继承自父命令的选项argocd admin notifications命令组挂在argocd admin之下因此继承了大量与 kubeconfig、认证、连接方式相关的全局标志。以下按功能分组完整列出与 命令参考文档 保持一致与通知配置源相关的核心标志标志说明--config-map string本地argocd-notifications-cm.yaml文件路径。不指定时命令通过 kubeconfig 从集群中读取argocd-notifications-cmConfigMap--secret string本地argocd-notifications-secret.yaml文件路径取值:empty表示使用空的 Secret不含通知服务配置这两个标志是该命令组最重要的参数决定了配置数据的来源详见下文“数据来源”一节。kubeconfig 与命名空间标志说明--context string使用的 kubeconfig context 名称--kube-context string将命令定向到指定的 kube context--kubeconfig stringkube config 文件路径仅集群外执行时需要--cluster string使用的 kubeconfig 集群名称--user string使用的 kubeconfig 用户名称--server stringKubernetes API server 地址和端口-n, --namespace string本次 CLI 请求的命名空间作用域认证与 TLS标志说明--auth-token string认证 token也可用环境变量ARGOCD_AUTH_TOKEN设置--token string访问 API server 的 Bearer token--username string/--password string访问 API server 的基本认证用户名/密码--client-certificate string/--client-key stringTLS 客户端证书文件/密钥文件路径--client-crt string/--client-crt-key string客户端证书文件/证书密钥文件--certificate-authority string证书颁发机构的证书文件路径--server-crt string服务器证书文件--tls-server-name string提供时用于校验服务器证书否则使用访问服务器所用的主机名--insecure跳过服务器证书与域名校验--insecure-skip-tls-verify为 true 时不校验服务器证书有效性会使 HTTPS 连接不安全--plaintext禁用 TLS身份模拟Impersonation标志说明--as string操作时模拟的用户名--as-group stringArray操作时模拟的组可重复指定多个--as-uid string操作时模拟的 UID连接方式与 Argo CD 组件地址标志说明--argocd-context string使用的 Argo-CD 服务器上下文名称--argocd-repo-server stringArgo CD repo server 地址默认argocd-repo-server:8081--argocd-repo-server-plaintext使用明文非 TLS客户端连接 repo server--core为 true 时 CLI 直接对接 Kubernetes 而非 Argo CD API server--port-forward通过端口转发连接一个随机的 argocd-server 端口--port-forward-namespace string端口转发使用的命名空间--grpc-web启用 gRPC-web 协议适用于 Argo CD 服务器位于不支持 HTTP2 的代理之后的场景--grpc-web-root-path string启用 gRPC-web 协议并设置 web root--disable-compression为 true 时对所有请求关闭响应压缩--header strings为所有请求追加额外 header可重复支持逗号分隔--http-retry-max int建立到 Argo CD 服务器的 http 连接的最大重试次数--request-timeout string单个服务器请求的等待时长非零值需带时间单位如1s、2m0表示不超时默认0--proxy-url string提供时通过该代理 URL 连接--config stringArgo CD 配置文件路径文档中默认值为/home/user/.config/argocd/config组件名称与环境适配Helm 安装常见标志说明--controller-name stringArgo CD Application 控制器名称当其 name label 与默认值不同如 Helm chart 安装时设置对应环境变量ARGOCD_APPLICATION_CONTROLLER_NAME默认argocd-application-controller--repo-server-name stringRepo server 名称对应环境变量ARGOCD_REPO_SERVER_NAME默认argocd-repo-server--server-name stringAPI server 名称对应环境变量ARGOCD_SERVER_NAME默认argocd-server--redis-name stringRedis 部署名称对应环境变量ARGOCD_REDIS_NAME默认argocd-redis--redis-haproxy-name stringRedis HA Proxy 名称对应环境变量ARGOCD_REDIS_HAPROXY_NAME默认argocd-redis-ha-haproxy--redis-compress string应用控制器启用了 redis 压缩时设置可选值gzip、none默认gzip--prompts-enabled强制启用/禁用交互式提示覆盖本地配置本地配置默认 false日志标志说明--logformat string日志格式json或text默认json--loglevel string日志级别debug、info、warn、error默认info命令实现原理配置从哪里来从源码结构看整个argocd admin notifications命令组在 cmd/argocd/commands/admin/notifications.go 中通过 notifications-engine 库的cmd.NewToolsCommand构建toolsCommand : cmd.NewToolsCommand( notifications, argocd-admin notifications, applications, settings.GetFactorySettingsForCLI(func() service.Service { return argocdService }, argocd-notifications-secret, argocd-notifications-cm, false), func(_ context.Context, clientConfig clientcmd.ClientConfig) { ... })几个关键点配置对象固定为argocd-notifications-cmConfigMap与argocd-notifications-secretSecretGetFactorySettingsForCLI的调用参数明确指定了这两个资源名。trigger get读取的触发器清单来自argocd-notifications-cm的triggers字段接收者recipient服务配置来自argocd-notifications-secret。数据加载有两条路径不指定--config-map/--secret时命令通过当前 kubeconfig 直接读取集群中的 ConfigMap/Secret——这是“查看集群真实生效配置”的默认路径指定本地文件路径时命令完全离线工作不依赖集群适合在 CI 或本地校验即将提交的清单文件。Argo CD 服务初始化initFn闭包中会解析 kubeconfig、构造 dynamic client 与 repo-server clientset再调用service.NewArgoCDService初始化服务notifications.go。这解释了为什么即使在--core模式下直接对接 Kubernetes命令仍然需要有效的 kubeconfig 上下文。repo-server TLS 处理初始化函数还会读取ARGOCD_APP_CONFIG_PATH下reposerver/tls/tls.crt与ca.crt加载证书池默认路径来自common.DefaultAppConfigPath并通过--argocd-repo-server默认argocd-repo-server:8081与--argocd-repo-server-plaintext控制 repo server 的连接方式。实战场景场景一离线校验本地清单文件当你用文件管理而非kubectl直接改集群对象维护通知配置时可以先离线验证触发器是否能被解析。官方故障排查文档 给出的标准示例argocd admin notifications trigger get \ --config-map ./argocd-notifications-cm.yaml --secret :empty--secret :empty表示使用不含任何通知服务配置的“空 Secret”——因为trigger get只关心触发器定义不需要真实的 Slack/Grafana 等服务凭据。场景二配合 Kustomize 管道校验如果通知配置由 Kustomize 管理可以把kustomize build的完整输出通过标准输入喂给命令--config-map -表示从 stdin 读取kustomize build ./argocd-notifications | \ argocd-notifications \ template notify app-sync-succeeded guestbook --recipient grafana:argocd \ --config-map -场景三在集群内验证控制器实际加载的配置通过kubectl exec进入正在运行的argocd-notifications-controllerPod用其中的 CLI 直接查看“控制器视角”的触发器配置kubectl exec -it argocd-notifications-controller-pod-hash \ /usr/local/bin/argocd admin notifications trigger get同样也可以在任意平台借助官方镜像运行 CLIdocker run --rm -it -w /src -v $(pwd):/src \ quay.io/argoproj/argocd:version \ /app/argocd admin notifications trigger get \ --config-map ./argocd-notifications-cm.yaml --secret :empty场景四查看内置触发器的定义仓库的 notifications_catalog/triggers 目录收录了 Argo CD 内置触发器清单包括on-created、on-deleted、on-deployed、on-health-degraded、on-sync-failed、on-sync-running、on-sync-status-unknown、on-sync-succeeded共 8 个。以命令示例中提到的on-sync-failed为例on-sync-failed.yaml- when: app.status.operationState ! nil and app.status.operationState.phase in [Error, Failed] description: Application syncing has failed send: [app-sync-failed] oncePer: app.status.operationState?.syncResult?.revision执行argocd admin notifications trigger get on-sync-failed -oyaml输出的正是这类结构四个字段含义whenCEL 风格的条件表达式此处判定操作状态阶段为Error或Faileddescription人类可读的触发原因描述会出现在通知内容中send命中后要发送的模板名称列表对应notifications_catalog/templates中的模板oncePer按表达式结果去重保证同一revision的同步失败只通知一次。与其他通知排障命令的配合trigger get只是通知排障链的一环。结合 故障排查文档常用组合为命令作用argocd admin notifications trigger get查看触发器配置本文主角argocd admin notifications trigger run手动执行触发器验证条件与动作链路argocd admin notifications template get查看通知模板配置argocd admin notifications template notify用指定接收者手动发送模板消息验证通知服务凭据推荐的排障顺序是先用trigger get确认触发器存在且条件表达式正确再用trigger run模拟触发最后用template notify验证接收者链路。相关命令argocd admin notifications trigger - Notification triggers related commands【免费下载链接】argo-cdDeclarative Continuous Deployment for Kubernetes项目地址: https://gitcode.com/GitHub_Trending/ar/argo-cd创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考