GitOps 与声明式交付：仓库即真相，控制器持续对齐

星期三, 4月 8, 2026 | 1分钟阅读 | 更新于 星期三, 4月 8, 2026

@

GitOps 常被说成「把 Git 当数据库」，更贴近工程的说法是：Git 仓库里的声明式描述是期望状态，集群里的控制器不断对齐当前状态与期望状态。

和「脚本 SSH 部署」的差别

  • 传统脚本：每次执行是一次命令式动作，容易漂移、难审计。
  • GitOps：变更先合并进仓库，再自动或半自动应用到集群，历史可追溯、可回滚。

谁在「对齐」

  • 集群内（或侧车）的 Operator / Agent 周期性拉取或订阅仓库变更。
  • 发现差异时执行 apply 或 sync，并报告状态（成功、冲突、需人工）。

和 CI/CD 的关系

  • CI 管构建与制品：镜像、Helm chart、Kustomize 覆盖层。
  • CD / GitOps 管发布：把「已审核的清单」推到目标环境，权限与审批可放在仓库流程里（PR、CODEOWNERS）。

实践建议

  • 单仓库 vs 多仓库按团队规模选，关键是边界清晰与权限最小化。
  • 机密不要明文进 Git，用 sealed-secrets、外部密钥管理等与 GitOps 配合。

一句话

GitOps 的价值在于：把发布变成可审计、可回滚的变更流，而不是多一个炫酷工具。

关于我

大家好，我是 lew。这里主要记录学习、工作与阅读里的碎片想法——偏工程实践，少空话；写给自己备忘，也欢迎路过的你顺手翻翻。

经历与方向

从事互联网研发与技术管理十余年，长期负责团队建设、架构演进、技术选型与交付节奏；经历从客户端到服务端、从功能迭代到线上治理的完整链路，习惯在稳定性、成本与交付速度之间做权衡。

技术栈与工程

后端以 Golang、Node.js（及常见服务端框架）为主；在分布式与实时服务、微服务（RPC、服务发现、可观测）、容器与编排（Docker / Kubernetes）、CI/CD 与云上架构上有较多实践。数据侧熟悉多种关系型 / 文档型数据库、缓存与消息队列；关注高可用、安全与弹性，也关注研发协作与发布效率。

AI / 大模型工程化

持续跟进 LLM 落地与工程化，方向包括但不限于 RAG、LoRA、Agent、MCP、SKILL 等缩写所指领域；更关心「模型能力」如何与业务约束、数据边界、可观测与发布节奏对齐，而不是单点炫技。文里会尽量直接用这些缩写，避免冗长中文释义。

管理与协作

在敏捷与 Scrum 实践、跨职能沟通与版本迭代上有较多经验；习惯用可度量的目标、评审与回顾推动改进，而不是只堆流程文档。

学习

MBA 在读，侧重创新创业与组织管理，用来补足商业与战略视角，和技术判断互相校准。

博客里可能写什么
  • LLM 与 RAG、Agent 等在实际业务里的取舍与踩坑
  • 后端、分布式与可观测的一得之见
  • 工具链、CI/CD 与个人工作流里的「人机协作」节奏

若你也关心 LLM、RAG、软件工程或知识管理，欢迎偶尔回来看看。

联系可通过站点页脚邮箱；合作与交流请说明来意。