包含GitOps 的 CI/CD 流水线 [k8s]
包含GitOps 的 CI/CD 流水线 [k8s]
其基本思想是通过向Git提交变更并使用Pull Request（以下简称PR）进行审批来管理Kubernetes上的资源。
GitOps是一种实现持续交付的模型
作为CI/CD流水线的一部分，GitOps为应用程序构建/交付与运行它的位置之间提供了粘合剂。
GitOps提供了一种用于将应用程序交付到Kubernetes平台的模型，该模型确保了Git是唯一的事实来源并且充分利用Kubernetes平台上的功能。但值得注意的是，GitOps不能替代工具。恰恰相反，GitOps通过声明性的流程和工具来强化流程、提高其成熟度并帮助团队交付应用程序。
利用Git开发工具对云原生应用程序进行操作和管理。当将应用程序部署到Kubernetes时，Git应该是唯一的事实来源。当开发人员更改应用程序时，Git将自动把它们push到Kubernetes进行部署。而且，如果Kubernetes内的运行状态发生变化但与Git内的状态不一致，则它们会从Git内恢复到已知状态。
GitOps和CI/CD是十分重要的工作伙伴。
CI/CD可以让开发人员持续迭代、开发和部署应用程序。而迭代通常通过一个Git配置仓库进行（尽管也会有其他配置仓库）。在部署/交付阶段，构建的基于容器的应用程序被“push”到Kubernetes进行部署。GitOps会通过Kubernetes使用“pull”的方法来增强CI/CD模型，从而将运维层面带入部署/交付中。
如果听起来有点模糊，那么我们来定义一下GitOps的四条规则，让它更接地气。
- 将所有Kubernetes资源配置存储在Git中。
- 只使用Pull Request 来修改该Git仓库上的资源。
- 一旦修改了Git，立即将更改应用到集群中，并且完全自动化。
- 如果实际状态与所需的状态有偏差，要么纠正它，要么提醒操作人员。
GitOps将允许我们将应用的持续集成（CI）流程与部署流程分开，因为部署流程将根据环境仓库的变化而不是作为CI流程的一部分来启动。
GitOps 与 CI / CD区别
在一条典型的 CI/CD 流水线当中，CI 工具负责运行测试、构建镜像、检查 CVE 并将新镜像重新部署至集群当中，具体如下图所示。
GitOps 方法的区别在于，其中的部署部分不再由 CI 工具完成，而是由操作程序通过集群内 Pod 中的运行进程完成（由 Flux 负责实现）。
下图所示为在 Kubernetes 集群当中使用 GitOps 时所需要用到的各组件。
参考
https://www.rongsoft.com/article/2020/03/190847321006/
https://blog.csdn.net/weixin_37098404/article/details/102707574