注意事项 佩雷夫 ：在Kubernetes社区中，正如我们在访问 KubeCon Europe 2019时亲眼所见，一种名为GitOps的趋势正在越来越流行。该术语是由 Weaveworks负责人Alexis Richardson相对较近地提出的 ，意味着为开发人员使用熟悉的工具（主要是Git，名称本身）解决操作问题。 特别是，我们正在谈论通过将Kubernetes的配置存储在Git中并自动将更改发布到集群来利用Kubernetes。 Matthias Jg在本文中讨论了此首次展示的两种方法。
去年
（实际上，这在2017年8月正式发生-大约是Transl。） ，出现了一种在Kubernetes中部署应用程序的新方法。 它称为GitOps，它基于在安全的Git存储库环境中完成部署版本跟踪的基本思想。
这种方法的主要优点如下 ：
- 对部署进行版本控制和更改历史记录 。 整个集群的状态存储在Git存储库中，并且部署仅通过提交进行更新。 此外，可以使用提交历史记录跟踪所有更改。
- 使用熟悉的Git命令进行回扣 。 简单的
git reset可以让您放弃部署中的更改； 过去的状态始终可用。 - 准备好访问控制 。 通常，Git系统包含许多机密数据，因此大多数公司都特别注意保护它。 因此，此保护扩展到部署操作。
- 部署策略 。 大多数Git系统最初都支持不同分支机构的策略-例如，只有拉取请求才能更新主服务器，而团队的另一名成员必须检查并接受更改。 与访问控制一样，相同的策略也适用于部署更新。
如您所见，GitOps方法具有许多优点。 在过去的一年中，有两种方法特别受欢迎。 一种基于推，另一种基于拉。 在查看它们之前，我们首先来看一下典型的Kubernetes部署是什么样的。
部署方法
近年来，在Kubernetes建立了各种部署方法和工具：
- 基于原生Kubernetes / Kustomize模板 。 这是将应用程序部署到Kubernetes的最简单方法。 开发人员创建基本的YAML文件并应用它们。 为了摆脱对相同模式的不断重写，开发了Kustomize（它将Kubernetes模式转换为模块）。 注意事项 佩雷夫 ：随着Kubernetes 1.14的发布，Kustomize已集成到kubectl中。
- 图表舵 。 Helm图表使您可以创建模板集，init容器，sidecar'ov等，这些模板用于以比基于模板的方法更灵活的配置选项来部署应用程序。 此方法基于模板YAML文件。 Helm用各种参数填充它们，然后将它们发送到集群组件Tiller，该组件将它们部署在集群中并允许更新和回滚。 重要的是，事实上，Helm只是将必要的值插入模板中，然后以与传统方法相同的方式应用它们（有关这一切的工作方式和使用方法的更多详细信息，请阅读我们在Helm上的文章 -大约。 ） 。 现成的Helm图表种类繁多，涵盖了各种各样的任务。
- 替代工具 。 有许多替代工具。 他们将所有模板文件转换为Kubernetes友好的YAML文件，然后应用它们，从而将它们统一起来。
在我们的工作中，我们不断将Helm图表用于重要工具（因为许多工具已经准备就绪，这大大简化了使用寿命），而Kubernetes则使用“干净的” YAML文件来部署我们自己的应用程序。
推拉
在最近的一篇博客文章中，我介绍了
Weave Flux工具，该工具使您可以将模板提交到Git存储库，并在每次提交或推送容器之后更新部署。 我的经验表明，该工具是推广拉动方法的主要工具之一，因此我经常会参考它。 如果您想了解更多有关如何使用它的信息，请单击此处的
链接 。
注意！ 两种方法都保留了使用GitOps的所有好处。基于拉的方法
拉取方法基于以下事实：所有更改都是从集群内部应用的。 在集群内部，有一个操作员定期检查关联的Git和Docker Registry存储库。 如果它们发生任何更改，则群集的状态将在内部更新。 通常认为这样的过程非常安全，因为没有外部客户端可以访问群集管理员权限。
优点：- 没有外部客户端有权更改群集；所有更新都是从内部滚动的。
- 一些工具还允许您将更新同步到Helm图表并将其绑定到集群。
- 可以扫描Docker Registry以获取新版本。 如果出现新映像，则Git存储库和部署将更新为新版本。
- 拉取工具可以分布在具有不同Git存储库和权限的不同名称空间中。 因此，可以使用多租户模型。 例如，团队A可以使用名称空间A，团队B可以使用名称空间B，而基础结构团队可以使用全局空间。
- 通常，工具非常轻巧。
- 结合使用Bitnami Sealed Secrets语句之类的工具，可以将加密的信息加密存储在Git存储库中，并在集群中进行检索。
- 由于部署是在群集内进行的，因此与CD管道没有通信。
缺点 ：
- 从Helm图表管理部署机密比平常要复杂得多，因为您首先必须在密封的机密中生成它们，然后使用内部运算符对其进行解密，然后才能将其用于拉取工具。 然后，您可以使用已部署的机密中的值在Helm中启动发行版。 最简单的方法是使用用于部署的所有Helm值创建一个秘密，将其解密并提交到Git中。
- 使用拉动方法，您会发现自己受拉动操作工具的束缚。 这限制了自定义群集中部署部署过程的能力。 例如，使用Kustomize的工作很复杂，因为必须在最终模板到达Git之前执行它。 我并不是说您不能使用单个工具，但是将它们集成到部署过程中比较困难。
基于推送的方法
在推入方法中，外部系统（主要是CD管道）在提交到Git存储库后或成功执行先前的CI管道的情况下开始部署到集群。 通过这种方法，系统可以访问群集。
优点 ：
- 安全性由Git存储库和构建管道决定。
- 部署Helm图表更容易；它支持Helm插件。
- 秘密易于管理，因为秘密可以在管道中使用，也可以加密形式存储在Git中（取决于用户的偏好）。
- 缺少与特定工具的绑定，因为可以使用其任何类型。
- 容器版本更新可以由组装管道触发。
缺点 ：
- 用于访问群集的数据位于构建系统内部。
- 通过拉动过程更新部署容器仍然更加容易。
- 它非常依赖CD系统，因为我们所需的管道可能最初是为Gitlab Runners编写的，然后团队决定切换到Azure DevOps或Jenkins ...，您将不得不迁移大量的构建管道。
底线：推还是拉？
与往常一样，每种方法都有其优点和缺点。 有些任务较容易完成，而另一项则较困难。 最初，我是手动进行部署的，但是在浏览了有关Weave Flux的几篇文章之后，我决定为所有项目实施GitOps流程。 对于基本模板来说，这很容易，但是后来我开始在使用Helm图表时遇到困难。 当时，Weave Flux仅提供了基本版的“ Helm Chart Operator”，但由于需要手动创建和应用机密，因此某些任务甚至更加复杂。 可以说，拉取方法更加安全，因为群集凭据在其外部无法使用，这大大提高了安全性，因此需要付出额外的努力。
经过一番思考，我得出了一个意想不到的结论，那就是事实并非如此。 如果我们谈论需要最大程度保护的组件，则此列表将包括机密和CI / CD系统，Git存储库的存储。 其中的信息非常脆弱，需要最大程度的保护。 此外，如果有人进入您的Git存储库并可以将代码推送到那里，那么他将能够部署所需的所有内容（无论选择哪种方法，都将被拉入或推送）并渗透到集群系统中。 因此，需要保护的最重要组件是Git存储库和CI / CD系统，而不是集群凭证。 如果对此类系统的策略和安全措施进行了调整，并且群集凭据仅作为机密信息检索到管道中，则拉取方法的额外安全性可能不如最初预期的那样有价值。
因此，如果拉动方法比较耗时且没有带来安全性提高，那么仅使用拉动方法是否不合逻辑？ 但是有人可能会说，在推入方法中，您过于依赖CD系统，为了避免将来的迁移，最好不要这样做。
我认为（一如既往），您应该使用更适合特定情况的组合或组合。 就我个人而言，我使用两种方法：针对基于拉的部署（主要包括我们自己的服务）编织Flux，以及使用Helm和插件的推送方法，该方法简化了将Helm图表应用于集群并允许您轻松创建机密信息。 我认为永远不会有一个适合所有情况的解决方案，因为总会有很多细微差别，并且它们取决于特定的应用程序。 同时，我强烈推荐GitOps-它大大简化了生活并提高了安全性。
希望我在该主题上的经验有助于确定哪种方法更适合您的部署类型，并且很高兴了解您的意见。
译者的PS注意
在pull模型的缺点中，有一个事实是很难在Git中放置呈现清单，但是，pull模型中的CD管道与部署分开存在，实际上变成了
Continuous Apply类别
管道 ，这是
不容置疑的 。 因此，将需要付出更多的努力才能从所有部署中收集它们的状态，并以某种方式允许访问日志/状态，最好是参考CD系统。
在这种意义上，推模型允许您至少提供一定的保证部署，因为可以使管道的寿命等于部署寿命。
我们测试了这两种模型，并得出与本文作者相同的结论：
- 拉模型适用于我们在大量集群上组织系统组件更新（请参阅有关addon-operator的文章 ）。
- 基于GitLab CI的推送模型非常适合使用Helm图表推出应用程序。 在此部署中，使用werf工具监视管道内的部署。 顺便说一下，在我们项目的背景下，当我们在KubeCon Europe'19的展位上讨论DevOps工程师面临的紧迫问题时，我们听到了持续不断的“ GitOps”。
译者的PPS
另请参阅我们的博客：