TL;DR用 Cursor 的 AI 能力写 GitOps 配置用 Git 仓库作为唯一真相源用 Argo CD 自动同步到服务器。整个流程改代码 → Push → 自动部署——不需要 SSH不需要手动操作服务器。1. 先说个真实的场景以前运维团队管服务器流程是这样的开发说「服务该上线了」丢过来一个压缩包运维连上服务器scp 传文件解压配环境变量改个配置要登三台服务器每台改法还不完全一样出事了回滚先问「上次是哪个版本来着」这个流程有几个致命问题不可追溯——没有人知道「当前服务器上跑的是什么版本的代码」不可重复——「在我机器上能跑」但「在服务器上不行」不可协作——多人改同一台服务器不知道谁改了什么GitOps 解决的就是这三个问题。它把Git 仓库变成唯一的真相源——服务器上应该跑什么Git 说了算而不是 SSH 进去手动改。而 Cursor 的作用是让写 GitOps 配置这件事从「查文档改模板」变成「说出你想要什么Cursor 帮你生成」。2. GitOps 是什么GitOps 不是什么新概念原理很简单你把期望的基础设施状态以代码的形式写在 Git 仓库里一个自动化工具Argo CD / Flux持续盯着这个仓库一旦发现仓库里的状态和服务器上实际的状态不一致就自动把服务器同步成仓库里描述的样子。类比一下传统运维 你手动把衣服叠好放到柜子里可能放错、放乱GitOps 你写了一张「衣柜配置单」有个人 24 小时盯着这张单子一旦衣柜和单子不一样就自动改过来核心工具是 Argo CDKubernetes 场景或者类似的开源工具。不管用什么工具GitOps 核心原则不变声明式你描述「我要什么」不是「我要做什么」版本控制每一次变更都是一次 Git commit可追溯、可回滚自动同步Git 变了我就自动同步不需要人工干预3. Cursor 在 GitOps 里的角色Cursor 本身不是 GitOps 工具它的作用是让写 GitOps 配置变得极快。GitOps 配置通常是 YAML 文件Kubernetes 场景下需要写 Deployment、Service、ConfigMap、Ingress、Secret……每个资源的字段少则十几个、多则几十个。纯手写费时费力查文档又容易出错。Cursor 的 Composer 模式可以直接用自然语言生成配置比如你可以说在 Cursor Composer 里输入帮我写一个 Nginx Deployment 的 YAML 配置 - 副本数 2 - 镜像 nginx:1.25 - 端口 80 - 内存限制 256MiCPU 限制 500m - 配置健康检查 /health 路径 - 用 ConfigMap 挂载 nginx.confCursor 会生成一个完整的 YAML 文件你检查一遍、修改细节然后提交到 Git 仓库。Argo CD 检测到变更自动同步到集群。整个流程变成了说需求 → Cursor 生成 → 提交 Git → 自动部署。4. 完整实操从零搭建 Cursor GitOps 工作流4.1 整体架构GitHub 仓库存放所有 YAML 配置↓Webhook 通知Argo CD持续监听 Git 仓库↓自动同步Kubernetes 集群实际运行的服务器↓Cursor本地编辑器用来写 YAML 提交 Git4.2 准备工作你需要准备一个 Kubernetes 集群本地用 Minikube或者云上 EKS/GKE/ACKGitHub 仓库公开私有都行Cursor 编辑器或其他 IDE但 Cursor 的 AI 能力最强kubectl 已配置好集群访问4.3 Step 1初始化 GitOps 仓库结构1创建 Git 仓库并初始化目录结构bash# 创建仓库结构 mkdir my-gitops cd my-gitops git init # 标准 GitOps 目录结构 mkdir -p apps/nginx mkdir -p apps/backend-api mkdir -p apps/frontend mkdir -p infra/cert-manager mkdir -p infra/ingress-nginx mkdir -p clusters/production mkdir -p clusters/staging目录结构说明apps/ —— 每个应用一个子目录infra/ —— 基础设施组件Nginx Ingress、Cert-Manager 等clusters/ —— 不同环境的配置production / staging2安装 Argo CDbash# 安装 Argo CDKubernetes 必须先装 kubectl create namespace argocd kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml # 等待 Argo CD 所有 Pod 运行起来 kubectl get pods -n argocd -w3获取 Argo CD 登录密码并暴露 UIbash# 获取初始密码用户名是 admin kubectl -n argocd get secret argocd-initial-admin-secret \\ -o jsonpath{.data.password} | base64 -d # 通过 NodePort 暴露 Argo CD UI生产环境建议用 Ingress kubectl patch svc argocd-server -n argocd -p {spec:{type:NodePort}}4.4 Step 2用 Cursor 生成第一个应用配置打开 Cursor在 apps/nginx/ 目录下创建文件。你不需要手写——直接用 Cursor 的 Composer 模式让它生成。Cursor Composer 输入生成一个完整的 Nginx Deployment Service YAML 配置 - 应用名nginx-web - 命名空间default - 副本数2 - 镜像nginx:1.25-alpine - 容器端口80 - Service 类型ClusterIP - 资源配置CPU 100m / 内存 128Mi - 配置一个 /health 的 HTTP 存活探针 - 挂载一个 ConfigMap里面是自定义的 nginx.confCursor 生成的内容大概是这个样子apps/nginx/deployment.yamlapiVersion: apps/v1 kind: Deployment metadata: name: nginx-web namespace: default labels: app: nginx-web spec: replicas: 2 selector: matchLabels: app: nginx-web template: metadata: labels: app: nginx-web spec: containers: - name: nginx image: nginx:1.25-alpine ports: - containerPort: 80 resources: requests: cpu: 100m memory: 128Mi livenessProbe: httpGet: path: /health port: 80 initialDelaySeconds: 10 periodSeconds: 5 volumeMounts: - name: nginx-config mountPath: /etc/nginx/conf.d volumes: - name: nginx-config configMap: name: nginx-web-config --- apiVersion: v1 kind: ConfigMap metadata: name: nginx-web-config namespace: default data: default.conf: | server { listen 80; location /health { return 200 healthy; add_header Content-Type text/plain; } } --- apiVersion: v1 kind: Service metadata: name: nginx-web-svc namespace: default spec: selector: app: nginx-web ports: - port: 80 targetPort: 804.5 Step 3配置 Argo CD 指向 Git 仓库有了 YAML 文件下一步是把 Argo CD 和 Git 仓库关联起来。1在 Argo CD 里创建 ApplicationApplication 是 Argo CD 的核心概念——一个 Application 对应 Git 仓库里的一个应用。apps/nginx/application.yamlapiVersion: argoproj.io/v1alpha1 kind: Application metadata: name: nginx-web namespace: argocd spec: project: default source: repoURL: https://github.com/yourname/my-gitops.git targetRevision: HEAD path: apps/nginx destination: server: https://kubernetes.default.svc namespace: default syncPolicy: automated: prune: true # 自动删除 Git 里没有的资源 selfHeal: true # 自动修复和 Git 不一致的配置 allowEmpty: false⚠️ 注意automated 字段设为 true 后Argo CD 会自动同步。任何 push 到 main 分支的变更都会直接部署到生产环境。建议先在 staging 环境关闭 automated用 manual sync 验证后再开启。2提交到 GitArgo CD 自动检测并同步bashcd my-gitops git add . git commit -m feat: add nginx-web deployment git remote add origin https://github.com/yourname/my-gitops.git git push -u origin main现在 Argo CD 的 UI 里你应该能看到 nginx-web 应用从 OutOfSync 变成 Synced。4.6 Step 4用 Cursor 管理多环境配置真实场景一般有多个环境staging、production。多环境管理的最佳实践是用 Kustomize 或 Helm。这里用 Kustomize更轻量Cursor 生成起来更简单。Cursor Composer 输入为 nginx-web 应用生成 Kustomize 多环境配置 - base/ 目录放公共配置deployment.yaml, service.yaml - overlays/staging/ 目录副本数 1镜像 tag 用 :stable - overlays/production/ 目录副本数 3镜像 tag 用 :latest配置 HPA 自动扩缩容 每个目录需要有 kustomization.yamlCursor 生成的目录结构最终目录结构apps/nginx/ ├── base/ │ ├── deployment.yaml │ ├── service.yaml │ └── kustomization.yaml ├── overlays/ │ ├── staging/ │ │ ├── kustomization.yaml # 副本数: 1, tag: stable │ │ └── config.yaml │ └── production/ │ ├── kustomization.yaml # 副本数: 3, tag: latest │ ├── config.yaml │ └── hpa.yaml # HorizontalPodAutoscaler └── application.yaml5. 典型使用场景场景一改配置不用登服务器比如要把 nginx 的副本数从 2 改成 5在 Cursor 里打开 overlays/production/deployment-patch.yaml让 Cursor 帮你改 replicas: 5提交 GitArgo CD 30 秒内自动同步不需要 SSH不需要 kubectl apply场景二新版本上线一键回滚bash# 查看部署历史每次变更有 commit message git log --oneline # 回滚到上一个版本 git revert HEAD git push # Argo CD 自动同步回滚后的状态场景三多服务协同变更一次提交假设你改了一个共享 ConfigMap同时影响了 nginx 和 backend-api 两个服务。传统做法是分别登录两台服务器改配置。GitOps 做法bash# 一次提交改了三个文件 git add shared-configmap/config.yaml \\ apps/nginx/overlays/production/config.yaml \\ apps/backend-api/overlays/production/config.yaml git commit -m fix: 更新共享配置影响 nginx 和 backend-api git pushArgo CD 检测到 Git 变更一次性把三个服务的配置都同步正确了。这就是 GitOps 的原子性——要么全部改成功要么不改。6. Cursor GitOps 工作流全貌步骤操作工具1说需求Cursor 生成 YAML 配置Cursor Composer2检查/修改配置Cursor Editor3提交到 Git 仓库Git4Argo CD 检测到变更Argo CD5自动同步到 Kubernetes 集群Argo CD Sync6出问题了git revert 回滚Git核心理念你只需要和两样东西打交道——Cursor写代码和 Git管理变更。服务器本身不需要你登录操作。7. 常见的坑Argo CD 检测延迟Argo CD 默认每 3 分钟轮询一次 Git。如果需要更快用 Webhook 触发立即同步GitHub 设置 → Webhooks → 指向 Argo CDSecrets 管理YAML 里不能直接写明文密码用 Sealed Secrets 或 Vault 动态注入生产环境的 automated 要谨慎建议生产环境用 Argo CD 的 OutOfSync 手动 Approve 模式防止误操作8. 总结Cursor GitOps 这个组合解决的不是「用什么工具部署」的问题而是「谁来控制服务器」的问题。传统模式里服务器状态是「人说了算」——人 SSH 进去改了什么服务器就变成什么。问题是人不可靠。GitOps 模式里服务器状态是「Git 说了算」——Git 仓库里的配置是什么服务器就同步成什么。Git 是代码代码可以被 review、被回滚、被测试。Cursor 的作用是降低 GitOps 配置的门槛——你不需要记住所有 YAML 字段你只需要描述你想要什么它帮你生成。一个人管几十台服务器在以前是运维团队的活。现在一个工程师 Cursor Argo CD能做到。如果对你有帮助欢迎在评论区聊聊你的 GitOps 实践。