GitOps中推送与拉取两种风格的区别 – thenewstack

自从出现第一个“基础结构即代码”工具以来，人们就意识到对版本进行环境定义的版本控制和自动执行更改是很有意义的。您可以说那些早期的先驱者正在使用Git进行操作。或者，您可以将其称为GitOps。
就像敏捷，DevOps或云原生一样，经常有人可能会问：“我们真的需要另一个营销流行语吗？作为既是工程师又是营销人员的人，我认为GitOps一词的产生更多是出于工程需求，而不是营销需求。
软件工程的基本原则是抽象实践。我们将可重复的步骤抽象到函数中，将函数抽象到库中，将库抽象到框架中，然后将这些框架一起构建到工具中，然后不断进行抽象，直到获得Kubernetes。这与在我们的语言中使用抽象的概念非常相似。
您可以使用一个单词“ GitOps”作为一个简单概括，让人们可以知晓其中更丰富和更深层的含义。
但是，当您知道如何调用API却不了解底层执行时可能会出现麻烦，因此调用GitOps也会返回意外结果。
对于GitOps的两种主要风格：“ 推送push”和“ 拉取pull”确实是这种情况。那么，推和拉GitOps之间真的有什么区别吗？
 
Push
在这种样式中，您使用CI / CD（连续集成/连续交付）管道将更改推送到您的环境，管道由代码提交或合并触发。
好处：

• 简便性：由于push使用了易于理解的CI / CD工具，因此对于组织中最广泛的工程师来说，它将是最容易使用的工具。这通常意味着您可以更快地开始，并拥有更广泛的协作池。
• 灵活性：如今，大多数拉式GitOps代理仅在Kubernetes中运行。如果要部署到Kubernetes以外的任何其他设备，则需要将配置推送到该环境。可以使用在Kubernetes群集中运行的pull GitOps代理来协调对外部目标（如VM和裸机）的部署，但最终您将回到推送状态。该代理正在推动那些环境。您最终需要管理许多相同的安全问题，即在环境外部存储凭据以及打开网络防火墙端口以允许入站连接。
• 效率：针对您的云原生和传统工作负载，采用相同的部署方法进行标准化可以提高您的效率。通过减少认知开销，您可以更轻松地入职和培训新团队成员，同时确保现有团队成员专注于解决问题，而不是了解多种技术。
• 优化的带宽：使用Kubernetes代理不断轮询您的Git存储库以查找更改可能不是几个群集的问题，但是从规模上讲，您可以体验到有意义的网络资源消耗。此外，如果您的Git和容器注册表工具需要处理来自数百个群集的请求，并且不断轮询状态，则它可能会承受巨大的负担。您可以缩短轮询间隔，但同时也会增加代码提交和部署之间的延迟。借助推式GitOps，您可以在快速，低延迟的部署中获得两全其美的优势，同时将网络和工具的负担降至最低。

• 原生云：如果您的全部或大部分工作负载都在Kubernetes中运行，那么使用代理进行部署可以是简单有效的选择。与所有其他Kubernetes运营商一样，使用和管理CD代理也是如此。
• 安全性：使用pull GitOps可以降低安全性和合规性风险。由于CD代理在群集内部运行，因此无需在外部CI中存储凭据。同样，您可以减少或消除防火墙中允许入站连接的漏洞。
• 一致性：推送GitOps通常仅在一个方向上工作，从Git存储库到环境。拉动GitOps的工作方向也相反。代理不仅可以轮询Git存储库和容器注册表中的更改，还可以将群集状态与Git中定义的状态进行比较。在手动或从其他来源对集群进行更改的情况下，这可以检测和纠正配置偏差。可以将推式CI / CD设置为定期轮询您的环境，将运行状态与已定义状态进行比较，并在配置发生漂移时恢复到已定义状态，但这是您需要设置的额外内容。大多数Pull GitOps代理都带有此双向比较，作为一项功能，您无需使用其他设置即可简单地使用该代理。