GitOps中的安全

镜像是使用对容器注册表的只读访问来拉取的。CI工具没有被授予群集特权，因此不会给管道带来重大的安全风险。

特权分离

GitOps将CI与CD分开。这就是为什么它是将应用程序部署到Kubernetes的更安全的方法的原因之一。下表显示了GitOps如何在集群、CI和CD工具以及容器存储库之间分离读/写特权，从而为您的团队提供了创建更新的安全方法。

部署策略

当您计划定义整个应用程序部署和升级过程时，首先决定哪种部署策略适合您的应用程序和最终用户是很重要的。一般说来，在GitOps中，以下Kubernetes部署策略得到了很好的支持，并且可以从采用中受益：

滚动更新

默认情况下，Kubernetes提出了一个基本的滚动更新策略，该策略被整个行业普遍采用和使用。它基本上创建了一个新的副本集。当新的副本集用新版本创建Kubernetes吊舱时，旧的副本集缩小了旧的副本集。这种方法有一些挑战，比如对推出速度的控制较少，控制流向新版本的通信流的能力，以及访问基于外部监控工具的度量标准，以验证新推出是否成功。

蓝绿部署

蓝绿部署允许团队在运行应用程序的新版本的同时运行旧版本；微服务同时运行，然后将用户流量从旧版本切换到新版本。一旦新版本完全稳定，那么旧版本就会被拿下。GitOps家族中有一些工具，如Flagger和Argo-Rollout，它们有助于实现和实现这种方法。此策略相当简单，具有出色的回滚功能，并且在最佳情况下需要最少的停机时间。

金丝雀部署

对于canary部署，新版本通过在向所有用户推出更改之前，将更改缓慢地向最初的一小部分最终用户推出，从而降低了风险。金丝雀部署策略结合了蓝绿和滚动更新策略中的最佳策略，允许快速回滚、最小干扰和比蓝绿更优化的计算成本。
蓝绿战略和金丝雀战略也可以被视为渐进交付的各种方法。

GitOps的核心想法是依托一个Git存储库，该存储库始终含有代表生产环境预期状态的声明式配置，并通过自动化流程监管Git存储库，将生产环境与这个预期状态相匹配。当开发人员要部署新的应用程序或更新现有应用程序，只需更新存储库，自动化流程就会处理所有事情。如果集群的实际状态与 Git 仓库中定义的期望状态不匹配，Kubernetes reconcilers 会根据期望状态来调整当前的状态，最终使实际状态符合期望状态。