在正常的Kubernetes CI/CD工艺中，发生以下过程：
- 从git克隆代码
- 构建和推送Docker映像
- 使用更新的代码更新kubernetes部署
根据gitops定义
- GitOps是持续部署的一种新方法，它将Git作为声明性基础设施和应用程序的单一真实来源，提供修订和变更控制。使用GitOps，系统通过提交拉取请求（以及后续合并）来运行，以实现Git存储库中表示的系统所需状态。*
我对gitops的理解是，当你更新git中的任何东西时（因为这是事实的来源），kubernetes的期望状态会改变为最新的状态，并且部署最新的代码。
不带gitops的传统CI/CD的最终结果：新代码作为kubernetes部署进行部署
gitops的最终结果：新代码作为kubernetes部署进行部署
我想不出有什么区别。如果你听起来很奇怪，我很抱歉。但是我是个新手，正在探索gitops。
提前感谢您的回复
3条答案
按热度按时间cidc1ykv1#
CICD关注整个链条：
加上许多其他步骤之间。这就是为什么它是一个持续的集成和部署。你也可以说，一个端到端的过程。
GitOps并不关心你的代码、Docker构建等等，它纯粹关注于保持你的应用更新（部署部分），在极端的形式下，渐进式交付完全自动化，包括流量转移、健康检查、自动回退等。
除此之外，还有其他一些有时很重要的小细节，比如推与拉、集群自治、关注点分离。
lndjwyie2#
GitOps不过是将CI/CD原则扩展到应用程序代码之外：简单。你可以考虑使用Git作为事实的来源，结合Terraform（供应），Ansible（配置管理）和Kubernetes（编排）作为例子...为了实现保持Git作为你的基础设施的1：1反映的目标。这不是什么新鲜事，不要担心这些花哨的术语...
vq8itlhq3#
简短的回答- GitOps是一个框架，CI/CD是一个过程！
GitOps致力于利用Git作为事实的来源，并授权开发人员执行IT操作。它通过持续集成和持续交付自动化Git工作流（CI/CD）。让我举一个例子-我有一个Kubernetes集群，我为它设置了CI/CD管道以实现自动化，然而，我们曾经看到有人直接在群集上手动更改应用程序版本的事件我们利用GitOps来声明我的集群，这样每当有人进行手动更改时，它就会覆盖并将其恢复到在Git中声明的原始状态（使用GitOps代理，如Flux）。