花了3小时排坑我终于搞懂了ArgoCD到底运行在哪里一次从sed命令找不到到GitOps灵魂觉醒的排坑实录一、一切从一个找不到开始作为一个刚入坑GitOps的萌新我信心满满地在Windows PowerShell里敲下了这行命令powershellsed -i s|elishatheodore/kubernetes-microservices|zxcspider/kubernetes-microservices|g gitops/argocd/application.yaml结果迎来了熟悉的红色报错textsed : 无法将sed项识别为 cmdlet、函数、脚本文件或可运行程序的名称。好家伙Windows不认sed这我认了。但接下来我遇到的一系列问题让我开始思考一个更本质的问题我到底在操作什么Git仓库里的文件还是集群里正在运行的东西带着这个困惑我开始了ArgoCD的排坑之旅。而当我终于搞明白ArgoCD到底运行在哪里的那一刻GitOps的大门才算真正向我敞开。二、误入歧途我以为ArgoCD是运行在Git里的刚开始接触ArgoCD时我有个天真的理解ArgoCD是不是像个Git钩子我push代码它就触发一下把YAML文件拼好发给K8s这个理解不全错但漏掉了最关键的一半。顺着这个思路我犯了两个典型错误错误一在Windows上硬刚Linux命令我试图用sed修改application.yaml文件完全没意识到sed是Unix/Linux工具Windows默认没有-i 是macOS BSD sed的语法Windows就算装了GNU sed也不认后来我用PowerShell原生命令解决了这个问题但那是后话了错误二以为改完Git文件就万事大吉我手动改完values-prod.yaml里的replicaCount提交推送然后盯着终端等结果完全不知道ArgoCD其实是一个一直在集群里跑着的程序。三、醍醐灌顶ArgoCD到底运行在哪在经历了以下操作后我终于找到了答案1. 我安装了ArgoCD在K8s集群里安装的powershellkubectl apply --server-side --force-conflicts -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml注意看-n argocdArgoCD是安装在Kubernetes集群的argocd命名空间里的。2. 查看ArgoCD的Podpowershellkubectl get pods -n argocd输出大概是这样的textNAME READY STATUS RESTARTS AGE argocd-application-controller-0 1/1 Running 0 5m argocd-applicationset-controller-xxxxxxxxx-xxxxx 1/1 Running 0 5m argocd-dex-server-xxxxxxxxx-xxxxx 1/1 Running 0 5m argocd-redis-xxxxxxxxx-xxxxx 1/1 Running 0 5m argocd-repo-server-xxxxxxxxx-xxxxx 1/1 Running 0 5m argocd-server-xxxxxxxxx-xxxxx 1/1 Running 0 5m看到了吗ArgoCD是一组Pod它们跑在Kubernetes集群内部。四、灵魂拷问ArgoCD到底在维护什么搞清楚了ArgoCD的运行位置下一个问题自然来了ArgoCD到底是在维护Git里的YAML文件还是在维护集群里真正运行的资源为了验证这个问题我做了两个实验实验一绕过Git直接改集群powershell# 把副本数从1改成5Git里定义的是1 kubectl scale deployment camp-dev-backend -n camp-dev --replicas5过了一两分钟再查看powershellkubectl get deployment camp-dev-backend -n camp-dev结果副本数又变回1了ArgoCD的selfHeal: true机制生效了——它检测到集群状态与Git定义不符直接在集群内部执行了kubectl scale ... --replicas1。实验二在集群里创建Git中没有的资源powershellkubectl create configmap test-config -n camp-dev几分钟后powershellkubectl get configmap test-config -n camp-dev # Error from server (NotFound): configmaps test-config not foundprune: true机制生效了——ArgoCD发现这个ConfigMap不在Git定义中直接在集群里把它删了。五、结论ArgoCD是集群里的强迫症管家经过这番折腾我得出了明确的结论ArgoCD运行在Kubernetes集群内部它维护的目标是集群里正在运行的Pod、Service、ConfigMap等实际资源而不是Git仓库里的YAML文件。把Git和ArgoCD的关系比作蓝图和施工队再合适不过角色载体位置作用蓝图Git仓库YAML文件GitHub/GitLab定义应该是什么样施工队ArgoCDPodK8s集群内部让集群变成蓝图的样子工地Kubernetes集群云端或本地服务器资源真正运行的地方Git定义理想状态ArgoCD在集群里不断纠偏两者组成闭环。六、完整的GitOps工作流附实操代码6.1 你的Application定义文件yamlapiVersion: argoproj.io/v1alpha1 kind: Application metadata: name: camp-prod namespace: argocd spec: source: repoURL: https://github.com/xxx/kubernetes-microservices.git targetRevision: main path: helm/camp helm: valueFiles: - values.yaml # 基础变量 - ../../environments/values-prod.yaml # 生产覆盖 destination: server: https://kubernetes.default.svc namespace: camp-prod syncPolicy: automated: prune: true # 自动删除Git中没有的资源 selfHeal: true # 自动纠正集群与Git的差异6.2 状态定义在Git的哪个文件根据你的Application配置最终状态由两个文件叠加决定基础helm/camp/values.yaml覆盖优先级更高environments/values-prod.yaml所以你要改生产环境配置就去改environments/values-prod.yaml。6.3 修改配置并验证完整闭环powershell# 1. 修改Git文件 vim environments/values-prod.yaml # 把 replicaCount: 1 改成 replicaCount: 3 # 2. 提交并推送 git add . git commit -m 将生产环境副本数从1调整为3 git push # 3. 查看ArgoCD自动同步 # 打开浏览器访问 https://localhost:8080 # 观察 Application 从 OutOfSync 变为 Synced # 4. 验证集群已变更 kubectl get pods -n camp-prod | grep camp-dev-backend # 现在有3个Pod了七、踩坑记录给同样在Windows上玩ArgoCD的你坑1Windows下没有sed命令遇到执行sed -i报CommandNotFoundException解决1用PowerShell原生替换powershell(Get-Content -Path 文件路径) -replace 旧内容,新内容 | Set-Content -Path 文件路径解决2装Git for Windows在Git Bash里运行坑2安装ArgoCD时CRD注解过长遇到metadata.annotations: Too long: may not be more than 262144 bytes原因client-side apply把所有YAML内容塞进了annotation解决用server-side apply force-conflictspowershellkubectl apply --server-side --force-conflicts -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml坑3Windows下base64命令也不存在遇到base64 -d报CommandNotFoundException解决用PowerShell的.NET方法解码powershell[System.Text.Encoding]::UTF8.GetString([System.Convert]::FromBase64String((kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath{.data.password})))坑4找不到argocd-initial-admin-secret原因新版ArgoCDv2.4密码管理方式变化解决从argocd-secret中提取或重置powershellkubectl -n argocd get secret argocd-secret -o jsonpath{.data.admin\.password} | base64 -d坑5修改路径找不到文件遇到Get-Content : 找不到路径D:\k8sproject\gitops\argocd\application.yaml原因没有进入项目根目录解决cd D:\k8sproject\kubernetes-microservices后再操作八、最终总结记住这三句话就够了序号一句话总结1ArgoCD运行在Kubernetes集群内部不是GitHub Actions里的一个任务2ArgoCD维护的是集群里的实际资源Pod、Service、ConfigMap不是硬盘上的YAML文件3Git是声明理想状态ArgoCD在集群里持续纠偏两者形成闭环附加题理解自愈 修剪的灵魂selfHeal: true有人在集群里乱改ArgoCD立刻改回来prune: true有人在集群里乱建资源ArgoCD立刻删掉两者结合集群Git定义的精确镜像分毫不差这就是GitOps的终极奥义你只管改Git剩下的交给ArgoCD。这篇博客基于我在Windows环境下从零搭建ArgoCD、排坑、验证的全过程写成希望能帮到和我一样在GitOps路上踩坑的同行者。如果觉得有用点个赞再走吧
)
