GitOps的四条原则

GitOps 把持续部署这件事拆解成四条彼此支撑的原则：系统期望状态必须声明式表达（只写”要什么”，不写”怎么做到”，比如 Kubernetes 清单描述的是目标状态而非操作步骤）；这份期望状态要存在一个强制版本化、不可变的地方（用 Git 存，天然带完整变更历史，任何时刻都能回滚到某个历史提交）；有专门的软件代理（如 Argo CD、Flux）自动从这个源拉取期望状态，而不是靠外部工具主动推送变更进集群；这个代理要持续观察集群实际状态和 Git 里期望状态是否一致，一旦出现偏离就自动纠正，让集群状态始终收敛到 Git 记录的目标。四条原则环环相扣：没有声明式表达，”自动拉取后如何应用”就无从谈起；没有版本化不可变，”持续协调”时都不知道该收敛到哪个历史版本。发散：这套原则本质是把 Kubernetes 控制器”观测实际状态、努力逼近期望状态”这个内部工作机制，原样套用到了”部署”这个更高层的操作上——GitOps 不是发明了新范式，而是把集群本来就有的协调循环模式复用到了应用交付层。