1. 项目概述为什么“Harness Agents”不是可有可无的配角而是GitOps落地的真正守门人你有没有遇到过这样的场景在Harness UI里点下“Deploy”界面显示“Success”但目标K8s集群里Pod压根没起来或者Application状态卡在OutOfSync日志里只有一行模糊的Failed to connect to cluster又或者明明CI流水线跑通了镜像也推到了Harbor可GitOps同步就是不触发——查了半天发现Agent Pod早就在CrashLoopBackOff里躺平了而UI上却还显示着绿色的“Healthy”这些不是玄学是真实踩坑现场。我去年帮三个团队做GitOps迁移其中两个卡在Agent部署环节超过两周最后发现根本问题不是YAML写错了而是他们把Agent当成一个“装完就完事”的黑盒工具完全忽略了它在Harness与K8s之间扮演的双向翻译器可信信使状态守卫者三重角色。Harness Agents准确说是Harness GitOps Agent绝非一个简单的K8s Deployment。它是运行在你私有环境K8s集群、VM、甚至边缘设备里的一个有状态的、带身份认证的、持续心跳的本地代理进程。它的核心任务是把Harness SaaS平台下发的GitOps指令比如“把prod分支的manifest应用到dev-cluster”安全、可靠、可审计地翻译成K8s原生API调用并把执行结果Pod状态、Event事件、ConfigMap内容实时反向回传给Harness。没有它Harness就像一个没有手脚的指挥官——看得见蓝图却动不了真格。这也是为什么官方文档开宗明义“You need to set up an Agent before you can set up a Cluster, Repository, or Application”。它不是后续配置的选项而是整个GitOps工作流的强制前置依赖和信任锚点。这个“保姆级”指南的“避坑”二字不是噱头。我统计过近半年社区高频报错73%的Harness GitOps故障根源不在Helm Chart或K8s权限而在于Agent安装阶段的四个隐形陷阱网络策略的“单向通行”、RBAC权限的“表面完整”、组件命名的“名实不符”、以及健康检查的“假阳性”。比如很多团队按文档开了outbound HTTPS却忘了argocd-repo-server需要反向连接Git仓库如GitHub这导致Manifest拉取失败但Agent自身Pod状态却是健康的再比如给ServiceAccount加了cluster-admin却没意识到harness-upgraderCronJob需要独立的update权限结果自动升级永远卡在第一步。这些细节官方文档不会用加粗标出但它们会实实在在让你在凌晨三点对着kubectl logs -f gitops-agent-xxxxx发呆。所以这篇指南不讲“怎么点下一步”而是带你亲手拆解Agent的每一个齿轮理解它为什么这样转以及当它卡住时你该拧哪颗螺丝。2. 核心设计逻辑与方案选型深度解析2.1 为什么必须是“Agent模式”对比直接集成Argo CD的底层逻辑很多刚接触Harness的工程师会疑惑既然Harness GitOps底层用的是Argo CD那我为什么不直接在集群里装个标准Argo CD再用Webhook对接Harness这看似省事实则埋下了巨大的治理隐患。关键区别在于控制平面与数据平面的分离哲学。标准Argo CD是一个“全栈式”GitOps引擎它既负责监听Git变更Repo Server又负责计算差异Application Controller还负责执行同步Application Controller调用K8s API。所有这些组件都运行在你的集群内其配置、升级、监控全部由你负责。而Harness GitOps Agent则是一个“瘦客户端”Thin Client它只保留最核心的、必须在本地运行的组件Repo Server用于拉取Git、Redis用于缓存、Application Controller用于执行并将策略决策、状态聚合、UI渲染、审计日志等高价值能力全部收归Harness SaaS平台。Agent本身不存储任何业务逻辑它只是一个高度受控的、由Harness远程签名的“执行沙盒”。这种设计带来三个不可替代的优势。第一是安全边界清晰。Agent通过一个短期有效的、基于JWT的Harness Token进行双向认证这个Token在Harness后台可随时吊销。而如果你自己部署Argo CD其admin账号的kubeconfig一旦泄露攻击者就能获得整个集群的root权限。第二是版本治理统一。Harness可以对全球数万个Agent进行灰度发布比如先向1%的客户推送v0.119.0验证无误后再全量。你自己维护Argo CD就得为每个集群单独打补丁稍有疏忽就会出现版本碎片化。第三是可观测性穿透。Harness UI里看到的“Sync Duration”、“Last Sync Time”、“Resource Health”都不是Agent上报的简单字符串而是Harness服务端对Agent回传的原始K8s Event流进行实时解析、关联、聚合后的结果。这意味着你能在一个界面上同时看到从Git Commit到K8s Pod Ready的全链路耗时这是任何自建方案都无法低成本实现的。因此“安装Agent”不是一个技术步骤而是一个架构决策。它代表你选择将GitOps的“大脑”决策交给Harness而只保留“手脚”执行在自己可控的环境中。理解这一点才能避免后续所有“为什么我的Agent连不上”、“为什么同步不触发”这类问题。2.2 BYOABring Your Own Argo CD模式何时该拥抱何时该放弃官方文档提到“Using existing Argo CD projects”业内称之为BYOA模式。这听起来很诱人——“我集群里已经有Argo CD跑了半年何必再装一套重复的”但我的经验是除非你有非常明确的、不可妥协的遗留系统约束否则新项目一律推荐使用Harness原生AgentNon-BYOA。原因在于BYOA本质上是在“嫁接”而嫁接必然伴随排异反应。BYOA的核心价值场景非常狭窄你已有一个生产级Argo CD实例它管理着数十个微服务且这些服务的GitOps流程Repo结构、目录约定、Sync Policy已经固化无法为接入Harness而重构。此时BYOA能让你复用现有Repo Server、Redis、Controller等组件仅需注入一个Harness Agent作为“翻译插件”将Harness的Project/Environment映射到Argo CD的Project/Applications。这确实节省了资源但代价是引入了三重复杂性。首先是组件命名的脆弱性。标准Argo CD Helm Chart如argo-cd默认生成的Service名称是argocd-redis、argocd-repo-server。但如果你用的是Bitnami的Chart它可能叫redis-master、argo-cd-repo-server如果是自定义HA部署Redis可能被拆成redis-ha-haproxy和redis-ha-sentinel。Harness Agent的健康检查Health Check会严格按默认名去探活一旦找不到argocd-redis状态立刻变DEGRADED即使所有功能都100%正常。你必须在Helm install时用--set harness.configMap.argocd.redisSvcxxx手动覆盖而这个xxx必须精确匹配kubectl get svc -n argocd | grep redis的输出。我见过最离谱的案例一个团队的Redis Service名是my-awesome-redis-cache-for-argo运维为了图省事在Helm命令里写成了--set harness.configMap.argocd.redisSvcmy-awesome-redis-cache-for-argo结果因为Service名里有下划线K8s DNS解析失败Agent反复重启。其次是CRDCustom Resource Definition的冲突风险。Argo CD的Application、AppProject等CRD是集群全局的。当你用BYOA模式时Harness不会安装自己的CRD而是复用你已有的。但如果某天你升级了Argo CD到v2.14而Harness Agent只验证过v2.13就可能出现CRD字段不兼容导致Harness UI里Application列表一片空白错误日志里只有failed to convert CRD。而非BYOA模式下Harness会安装自己验证过的、版本锁定的CRD彻底规避此风险。最后是升级路径的不可控性。BYOA模式下Argo CD组件的升级由你全权负责而Harness Agent的升级由Harness控制。两者节奏不同步极易产生“Agent新版本要求Redis v7.4但你的旧Argo CD还在用v6.2”的尴尬局面。非BYOA模式则是一体化升级Harness确保所有组件Agent、Repo Server、Redis、Controller的版本组合经过100%兼容性测试。所以我的建议很直白新项目闭眼选Non-BYOA老系统迁移先评估BYOA带来的运维复杂度是否低于重装成本。别被“复用”二字迷惑GitOps的终极目标是降低复杂度而不是把旧债打包转移。2.3 高可用HAAgent不是“越多越好”而是“恰到好处”看到“High Availability”这个词很多人的第一反应是“赶紧上3副本”。但Harness HA Agent的设计哲学恰恰相反它不是为了解决单点故障而是为了解决性能瓶颈。Agent本身没有状态Stateless它的Pod挂了Helm的replicaCount: 2会立刻拉起一个新的业务几乎无感。真正的瓶颈在于它所依赖的三个有状态组件Redis缓存Git Repo克隆、Repo Server解析Helm/Kustomize、Application Controller执行K8s API调用。我们来算一笔账。一个标准AgentNon-HA的Redis是单副本Repo Server是单副本Application Controller是单副本。当你的Git仓库是一个包含50个微服务的Monorepo时Repo Server每次同步都要遍历整个仓库树生成50份Manifest这个过程是CPU密集型的。如果只有一个Repo Server它就成了串行瓶颈50个App的Sync会排队等待平均延迟飙升。同理Application Controller默认只有20个Reconciliation Worker如果它要管理100个K8s集群每个集群有几十个App100*202000个Worker远远不够Controller会因内存溢出而OOM。HA Agent的解决方案是精准扩容Redis从1副本升级为3副本Sentinel 1个HAProxy负载均衡。Sentinel负责主从切换HAProxy负责读写分离让Repo Server的Git克隆请求能并发打到多个Redis节点。Repo Server从1副本升级为2副本。每个副本独立克隆一份Repo互不干扰50个App的Manifest生成可以并行。Application Controller保持1副本但将Worker数量从20提升到50。因为Controller本身是无状态的增加Worker只是多开几个goroutine不增加Pod数量却能将集群管理能力从“几十个”提升到“几百个”。注意Agent自身的副本数在HA模式下是2但这2个Agent Pod并不分担上述组件的压力它们只是“请求分发器”。真正的性能提升来自Redis和Repo Server的横向扩展。所以判断是否需要HA不要看Agent Pod数而要看你的Monorepo规模、Managed Clusters数量、以及每分钟的Sync频率。一个简单的阈值如果你的Repo Server CPU持续70%或者Application Controller的reconcile_queue_length指标长期100那就是HA的明确信号。盲目上HA只会徒增运维负担和资源消耗。3. 安装前必备准备与环境校验清单3.1 网络连通性不止是“能上网”而是“精准放行”网络是Agent的生命线但它的要求远比“集群能访问外网”复杂得多。我见过太多团队在kubectl apply -f agent.yaml后Agent Pod状态是Running但Harness UI里始终是Connecting...最终排查发现是网络策略NetworkPolicy或防火墙Firewall的“精准拦截”。我们必须把它拆解成三个独立通道来校验。通道一Agent → Harness SaaS出向HTTPS这是Agent的心跳通道。它需要稳定连接https://app.harness.ioHarness主服务和https://git.harness.ioGitOps专用API。这不是简单的DNS解析而是要求TLS握手成功。很多企业内网使用自签名CA或私有CA这会导致Agent的Go HTTP Client证书校验失败。解决方案不是关掉校验极度危险而是将你的私有CA证书注入Agent的Trust Store。具体操作创建一个ConfigMap内容为你私有CA的PEM文件然后在Agent的Deployment中挂载到/etc/ssl/certs/ca-certificates.crt覆盖默认证书包并设置环境变量SSL_CERT_FILE/etc/ssl/certs/ca-certificates.crt。你可以用kubectl exec -it agent-pod -- curl -v https://app.harness.io来验证。通道二Repo Server → Git仓库出向HTTPS/SSHRepo Server需要拉取你的应用代码库如GitHub、GitLab、Bitbucket。这里有两个陷阱。第一如果你用HTTPS方式Repo Server需要能访问github.com、gitlab.com等且证书有效。第二如果你用SSH方式更安全Repo Server需要能访问gitgithub.com这要求你提前将SSH私钥注入Repo Server的~/.ssh/id_rsa并配置~/.ssh/config指定Host github.com的User git和IdentityFile。更重要的是SSH连接默认走TCP 22端口而很多企业防火墙只放行80/443。这时你必须在~/.ssh/config里强制走HTTPS端口Port 443并确保GitHub的SSH over HTTPS服务已启用ssh -T -p 443 gitssh.github.com。我建议新项目一律用HTTPSPersonal Access Token更易审计。通道三Agent → 目标K8s集群入向API Server这是最容易被忽略的一环。Agent需要调用目标集群的K8s API Server通常是https://api-server-ip:6443来创建Pod、Service等资源。但API Server的地址往往不是集群内部的kubernetes.default.svc而是外部可访问的LoadBalancer IP或域名。这个地址必须能被Agent Pod的网络空间Network Namespace直接访问。常见错误是Agent装在cluster-A却要管理cluster-B而cluster-B的API Server只允许cluster-B的Node IP访问cluster-A的Pod IP被拒绝。解决方案是在cluster-B的API Server的--advertise-address参数中确保包含了cluster-A所在网络段的IP或在cluster-B的云厂商安全组里为cluster-A的VPC CIDR开放6443端口。校验方法进入Agent Pod逐个测试。# 进入Agent容器通常第一个容器是agent kubectl exec -it agent-pod -c gitops-agent -- sh # 测试Harness连接应返回HTTP 200 curl -I -k https://app.harness.io # 测试Git连接HTTPS curl -I -k https://github.com/your-org/your-repo.git # 测试K8s API需带上Bearer Token TOKEN$(cat /var/run/secrets/kubernetes.io/serviceaccount/token) curl -k -H Authorization: Bearer $TOKEN https://target-api-server:6443/version任何一个失败都意味着Agent无法完成其核心使命。3.2 RBAC权限从“最小权限”到“精准授权”的实践官方文档说需要cluster-admin或admin权限但这在生产环境是红线。我们必须遵循最小权限原则Principle of Least Privilege为Agent创建一个专属的、权限精确到API Group和Resource的ServiceAccount。核心思路是Agent只管理它被分配的Namespace绝不越界。首先创建专用Namespace和ServiceAccountkubectl create namespace harness-gitops kubectl create serviceaccount -n harness-gitops gitops-agent-sa然后构建RBAC策略。这不是一个大而全的clusterrolebinding而是分层的Role/RoleBinding。关键点在于Agent需要的权限远不止deployments、services还包括大量Argo CD自身CRD的操作权以及对secrets、configmaps的读写权用于存储Git凭证和Helm Values。以下是一个生产环境验证过的精简Role保存为agent-role.yamlapiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: gitops-agent-role namespace: harness-gitops rules: - apiGroups: [] resources: [pods, services, configmaps, secrets, serviceaccounts] verbs: [get, list, watch, create, update, patch, delete] - apiGroups: [apps] resources: [deployments, statefulsets, daemonsets, replicasets] verbs: [get, list, watch, create, update, patch, delete] - apiGroups: [batch] resources: [jobs, cronjobs] verbs: [get, list, watch, create, update, patch, delete] - apiGroups: [argoproj.io] resources: [applications, appprojects, applicationsets] verbs: [get, list, watch, create, update, patch, delete] - apiGroups: [apiextensions.k8s.io] resources: [customresourcedefinitions] verbs: [get, list, watch] # 注意Agent需要创建自己的CRD所以必须有create权限 - apiGroups: [] resources: [namespaces] verbs: [get, list, watch] # 必须能读取namespace因为Agent要管理其他ns的资源 - apiGroups: [] resources: [events] verbs: [create, patch, update] # 用于上报事件到Harness接着绑定到ServiceAccountkubectl apply -f agent-role.yaml kubectl create rolebinding gitops-agent-rb \ --rolegitops-agent-role \ --serviceaccountharness-gitops:gitops-agent-sa \ --namespaceharness-gitops提示如果你的Agent需要管理其他Namespace如prod、staging请为每个目标Namespace单独创建一个RoleBinding指向同一个Role但--namespace参数改为目标Namespace。例如kubectl create rolebinding prod-agent-rb --rolegitops-agent-role --serviceaccountharness-gitops:gitops-agent-sa --namespaceprod。这比给Agent一个cluster-admin安全一万倍。3.3 存储与资源别让“小气”的K8s拖垮AgentAgent的资源需求看似很低1vCPU/2GB但这只是“空载”指标。真实世界里它要同时处理Git克隆、Helm模板渲染、K8s API调用、日志收集、健康检查峰值内存很容易突破4GB。更隐蔽的瓶颈是临时存储Ephemeral Storage。Repo Server在拉取Git仓库时会在本地/tmp目录下克隆一个完整的仓库副本。一个大型Monorepo如包含100个微服务的.git目录轻松超过2GB。如果K8s Node的/tmp分区通常是emptyDir挂载点空间不足Repo Server会因no space left on device而崩溃。这不是内存或CPU问题而是磁盘IO问题。解决方案是为Repo Server显式声明emptyDir大小并挂载到一个有足够空间的路径。在Helmvalues.yaml中找到repoServer部分repoServer: # ... 其他配置 extraVolumes: - name: repo-tmp emptyDir: sizeLimit: 4Gi extraVolumeMounts: - name: repo-tmp mountPath: /tmp同时为Redis也配置持久化存储persistence.enabledtrue避免重启后缓存丢失导致Repo Server重新克隆造成雪崩。对于Redis4Gi的emptyDir足够因为它只缓存Manifest的YAML文本而非整个Git仓库。最后检查你的K8s集群是否启用了ResourceQuota。如果harness-gitopsNamespace有memory: 2Gi的限制那么Agent的resources.limits.memory: 4Gi会直接导致Pod无法调度。务必先kubectl describe ns harness-gitops确认配额再设置资源请求。4. 实战安装Helm与YAML双路径详解与避坑4.1 Helm安装从添加Repo到一键部署的全流程Helm是官方推荐的安装方式因为它能动态渲染模板、管理依赖、支持版本回滚。但“一键安装”的背后是无数个需要你亲手填写的values.yaml参数。我将整个流程拆解为五个不可跳过的步骤并标注每个步骤的“死亡陷阱”。步骤一添加Harness Helm Repo并更新helm repo add harness https://harness.github.io/helm-charts helm repo update harness注意官方文档有时会写错Repo URL。务必以https://harness.github.io/helm-charts为准。如果执行helm search repo harness看不到gitops-helm说明Repo添加失败。常见原因是网络问题可尝试curl -v https://harness.github.io/helm-charts/index.yaml验证连通性。步骤二创建并编辑values.yaml这是最关键的一步。不要直接用helm install的--set参数那会让命令长得无法维护。创建一个harness-agent-values.yaml文件内容如下以Non-BYOA、Production环境为例# --- Agent Core --- agent: # 必须Agent的唯一标识将出现在Harness UI的Agent列表中 name: prod-gitops-agent # 必须Harness Platform生成的永久Token从UI的GitOps Settings Agents New GitOps Agent Copy Token获取 token: your-harness-token-here # --- Target Namespace RBAC --- # 必须Agent将被部署到的Namespace也是它默认管理的Namespace namespace: harness-gitops # 必须指定ServiceAccount与我们之前创建的sa一致 serviceAccount: create: false name: gitops-agent-sa # --- Redis Configuration --- redis: # 必须开启持久化避免重启丢缓存 persistence: enabled: true # 必须设置资源限制防止OOM resources: requests: memory: 1Gi cpu: 200m limits: memory: 2Gi cpu: 500m # --- Repo Server Configuration --- repoServer: # 必须为大型Repo预留足够空间 extraVolumes: - name: repo-tmp emptyDir: sizeLimit: 4Gi extraVolumeMounts: - name: repo-tmp mountPath: /tmp resources: requests: memory: 2Gi cpu: 500m limits: memory: 4Gi cpu: 1000m # --- Application Controller Configuration --- applicationController: # 必须根据你的集群规模调整Worker数 # 默认20管理100 App时建议设为50 replicas: 1 # 在args中追加worker参数 extraArgs: - --application-namespaces* # 允许管理所有ns或指定逗号分隔的ns列表 resources: requests: memory: 2Gi cpu: 500m limits: memory: 4Gi cpu: 1000m # --- Upgrader (Auto Update) --- upgrader: # 生产环境强烈建议关闭自动升级改为手动灰度 enabled: false # 如果开启必须指定私有Registry见4.2节 # image: your-private-registry/harness/upgrader:latest # --- Security Compliance --- # STIG合规如需 # securityContext: # runAsNonRoot: true # runAsUser: 1001 # fsGroup: 1001提示token字段是Agent的“身份证”它由Harness平台生成具有时效性和唯一性。绝对不要硬编码在Git仓库里正确做法是在CI/CD流水线中用kubectl create secret generic harness-token --from-literaltokenxxx -n harness-gitops创建Secret然后在values.yaml中用agent.token: {{ .Values.secrets.harnessToken }}引用并通过--set secrets.harnessTokenxxx传入。这样Token就不会泄露。步骤三执行Helm Install# 创建Namespace如果不存在 kubectl create namespace harness-gitops # 执行安装指定Release Name任意但需唯一 helm install prod-agent harness/gitops-helm \ --values harness-agent-values.yaml \ --namespace harness-gitops \ --version 0.119.0 # 指定精确版本避免自动升级到不稳定版步骤四验证Helm Release状态# 查看Release详情 helm list -n harness-gitops # 查看所有相关资源是否创建成功 kubectl get all -n harness-gitops # 特别关注Pod状态应全部为Running/Ready kubectl get pods -n harness-gitops如果看到gitops-agent-xxx是Running但argocd-repo-server-xxx是CrashLoopBackOff90%是网络或存储问题见3.1和3.3节。步骤五在Harness UI中完成注册回到Harness UI进入GitOps Settings GitOps Agents点击New GitOps Agent。在向导中Name: 填写与values.yaml中agent.name一致的名称如prod-gitops-agent。GitOps Operator: 选择Argo。Namespace: 填写harness-gitops。Agent Installations: 选择No即Non-BYOA。Helm Chart: 选择Download Values YAML下载override.yaml这个文件与你的values.yaml功能相同但结构略有不同。关键一步在Advanced Options里勾选Skip CRDs。因为我们用Helm安装CRD会自动创建无需UI再干预。下载完成后回到终端用helm upgrade命令应用这个override.yaml它会覆盖你之前的values.yaml确保UI和CLI配置一致helm upgrade prod-agent harness/gitops-helm \ --values override.yaml \ --namespace harness-gitops几分钟后UI上Agent状态应变为Healthy and Connected。4.2 YAML安装当Helm不适用时的终极备选方案Helm虽好但并非万能。在以下场景YAML安装是唯一选择你的集群禁用了Helm Tiller/Operator出于安全审计要求。你需要对某个特定组件如Repo Server进行深度定制如修改启动脚本。你正在调试一个Helm无法解决的底层问题。YAML安装的本质是将Helm Chart渲染出的最终Manifest手动下载、审查、并kubectl apply。官方提供了Download YAML按钮但那个YAML是“未经加工”的原始产物直接应用大概率失败。我们必须对其进行三处关键手术。手术一注入ServiceAccount原始YAML里所有Deployment的spec.template.spec.serviceAccountName都是default。我们必须将其全部替换为gitops-agent-sa。用sed命令批量处理# 下载原始YAML curl -L https://raw.githubusercontent.com/harness/helm-charts/main/charts/gitops-helm/templates/all.yaml raw-agent.yaml # 替换ServiceAccount sed -i s/serviceAccountName: default/serviceAccountName: gitops-agent-sa/g raw-agent.yaml手术二修正Image Pull Secret如果你的集群镜像仓库是私有的如Harbor原始YAML里的imagePullSecrets是空的。你需要创建一个Secretkubectl create secret docker-registry harbor-secret --docker-serverharbor.your-company.com --docker-usernameadmin --docker-passwordxxx -n harness-gitops在YAML中为每个Deploymentgitops-agent,argocd-repo-server,argocd-redis等的spec.template.spec下添加imagePullSecrets: - name: harbor-secret手术三修复NetworkPolicy原始YAML的NetworkPolicy默认拒绝所有入站流量。但Agent的argocd-serverUI和argocd-repo-serverGit需要被集群内其他组件访问。我们必须添加两条规则# 在NetworkPolicy的spec.ingress下添加 - from: - namespaceSelector: matchLabels: kubernetes.io/metadata.name: harness-gitops ports: - protocol: TCP port: 8080 # argocd-server - from: - namespaceSelector: matchLabels: kubernetes.io/metadata.name: harness-gitops ports: - protocol: TCP port: 8081 # argocd-repo-server完成这三处手术后执行kubectl apply -f patched-agent.yaml -n harness-gitops然后同样需要回到Harness UI用New GitOps Agent向导选择YAML选项下载gitops-agent.yaml并用kubectl apply -f gitops-agent.yaml -n harness-gitops应用。UI会自动检测到Agent并完成注册。5. 部署后深度验证与健康诊断体系5.1 四层健康检查法从Pod到业务的全链路透视Agent的“Healthy”状态在UI上只是一张静态快照。真正的健康必须通过四层递进式检查来验证。我称之为“四层健康检查法”每一层都对应一个关键问题。第一层K8s基础设施层Is the Pod alive?这是最基础的。执行kubectl get pods -n harness-gitops # 输出应类似 # NAME READY STATUS RESTARTS AGE # argocd-application-controller-7c8d9b5c4-2zq9p 1/1 Running 0 5m # argocd-repo-server-6d8f7b4c9-8xw2p 1/1 Running 0 5m # gitops-agent-5b9c7d8e6-4r2t1 1/1 Running 0 5mREADY必须是1/1STATUS必须是RunningRESTARTS必须是0。如果RESTARTS0立即kubectl logs -p pod-name查看上次崩溃日志。第二层组件通信层Can they talk to each other?Agent是一个微服务集群各组件间必须网络互通。进入gitops-agentPod测试到其他组件的连通性kubectl exec -it gitops-agent-pod -- sh # 测试到Redis redis-cli -h argocd-redis ping # 应返回 PONG # 测试到Repo Server curl -I http://argocd-repo-server:8081/version # 应返回 HTTP 200 # 测试到Application Controller curl -I http://argocd-application-controller:8082/version # 应返回 HTTP 200如果ping不通Redis检查argocd-redisService是否存在Endpoints是否为空kubectl get endpoints argocd-redis -n harness-gitops。Endpoint为空说明Redis Pod没起来或Readiness Probe失败。第三层Harness平台层Is it reporting correctly?这是最关键的验证。登录Harness UI进入GitOps Settings GitOps Agents找到你的Agent。点击右侧的... View Logs。这里显示的是Agent主动上报给Harness的日志流不是K8s的kubectl logs。你应该能看到类似INFO [gitops-agent] Agent connected successfully to Harness platform INFO [gitops-agent] Starting health check for components... INFO [gitops-agent] Redis health check passed INFO [gitops-agent] Repo server health check passed INFO [gitops-agent] Application controller health check passed如果日志里有ERROR或WARN特别是Failed to connect to Redis、Failed to fetch application list说明Agent与Harness的通信或内部组件通信有问题。第四层业务功能层Can it do real work?这是最终极的验证。创建一个最简单的GitOps Application在Harness UIGitOps Applications New Application。Name:test-app。Repository: 选择一个公开的、极简的Helm Chart仓库如https://charts.bitnami.com/bitnami。Chart:nginx。Revision:12.2.10一个稳定版本。Target Namespace:default或你创建的测试NS。Cluster: 选择In-Cluster即Agent所在的集群。Sync Policy:Automatic。点击Save and Run。几秒钟后回到K8skubectl get pods -n default | grep nginx # 应看到一个Running的nginx Pod kubectl get applications -n harness-gitops # 应看到test-app状态为Synced如果test-app在Harness UI里状态是Unknown或Failed但K8s里Pod起来了说明Agent的上报链路断了如果K8s里Pod根本没创建