1. GitOps应用持续交付模型
GitOps是一种应用持续交付模型，它的核心思想是将应用程序的声明式编排甚至基础架构编排都存放在Git源仓库中。实际上，将任何能够被描述的内容都存放在Git源仓库中。GitOps的主要应用场景是满足云原生环境下的持续交付，云原生环境为GitOps应用持续交付模型发挥作用提供了一定的基础条件。
（1）不可变基础设施
在应用从开发测试到上线的过程中，通常需要把应用频繁部署到开发环境、测试环境和生产环境中，相比于不可变基础设施，在传统的可变架构时代，通常需要系统管理员保证所有环境的一致性。而随着时间的推移，这种靠人工维护的环境一致性是很难维持的，环境的不一致又会导致应用越来越容易出错。在云原生结构中，借助Kubernetes和容器技术，不可变基础设施使得我们可以以一个全新的方式面对应用的交付。GitOps就是一种依托不可变基础设施产生的应用交付方式。
（2）声明式的容器编排
Kubernetes是一个云原生的容器平台，提供了声明式API的特性。声明式的特性意味着可以在把应用真正部署到集群之前有预见性地知道将会运行哪些组件及每个组件的详细配置，应用系统的整个配置文件集可以在Git源仓库中进行版本控制、更新和回滚。
以下是GitOps应用持续交付模型的一些特性。
（1）Git作为应用变更的唯一入口
Git是GitOps应用持续交付模型最基础的元素，使用Git可以操作应用交付的所有阶段，如版本控制、历史记录查看、代码评审、代码合并和回滚等，把声明性基础架构和应用程序全部存储在Git源仓库中，可以方便地监控集群中应用的变更情况。
（2）拉式流水线
在GitOps发布模型之前，用户大多都在使用推式流水线。推式流水线是指用户在提交代码到Git源仓库后，主动触发一个集群外部的构建和部署任务，这个任务负责将Git源仓库中的更新同步到集群环境中。在这个过程中，构建和部署任务所在的外部环境需要获取集群部署的相关权限，增加了集群机密信息泄漏的风险。在拉式流水线模式下，GitOps引擎部署在集群内，所有集群机密信息都保存在集群内部，根据用户指定的同步策略，自动手动拉取Git源仓库端的应用更新部署并将其同步至集群环境中。
（3）可观测性
可观测性是GitOps应用持续交付模型中非常重要的一个特性，它指的是通过与Git源仓库中的声明性基础设施进行差异化对比来观测实际环境中应用的运行状态，任何差异项都会被认为是异常的。GitOps是通过引入Diffs来完成这个工作的，便于用户验证当前应用的运行状态是否和Git源仓库中描述的一致，同时也能主动提醒用户不一致状态的详细信息。
GitOps流水线应用交付过程可以大致描述为以下4个步骤，整个过程如下所示。
1）应用管理员提交应用编排配置到Git源仓库中。
2）GitOps引擎定期自动检查Git源仓库是否有更新，若有更新，则开始拉式流水线。
3）GitOps引擎将Git源仓库中更新的应用编排文件拉取下来并同步部署到集群中。
4）GitOps引擎实时监测应用在实际环境中的运行状态，与Git源仓库中对应用的声明式描述做对比，并将差异项反馈给应用管理员。
若应用管理员需要对应用进行更新，则将声明式编排文件更新并推送至Git源仓库，GitOps引擎会自动完成接下来的应用交付流程。
GitOps应用持续交付模型能够为用户带来以下好处。
（1）提升研发效能
从Git端的版本控制到GitOps引擎的反馈，整个流程循环可控，大大提升了应用迭代的频率，从而加快了产品新功能上线的速度。此外，开发者只需要关心产品和业务，不需要关心复杂的部署交付流程。
（2）安全审批和审计
Git源仓库具备完整的角色访问控制和审批审计能力，既能满足合规性要求，又能提升系统的安全性和稳定性。
（3）提升应用运维效率
GitOps采用标准化的基础设施，能保证端到端的一致性。此外，GitOps引擎能够自动对比和发现应用实际运行状态与声明状态的差异，帮助应用管理员实时监控应用异常状况。
（4）更快的平局恢复时间
借助基础设施环境的一致性以及Git系统的版本控制能力，当线上系统发生任何预期之外的状况时，我们都可以迅速回滚应用版本及时止损，同时也能快速在预发和测试环境复现问题，定位到具体是哪个git commit提交导致了这次异常问题。
标签：GitOps,Git,交付,仓库,持续,集群,应用 From： https://www.cnblogs.com/muzinan110/p/17066828.html