导读
GitOps是一种云原生运维模型，将软件开发领域面向Git的最佳实践扩展到了Ops，与云原生运维所需的基于配置的方法保持一致。GitOps具有充分的资格来抽象化大规模处理临时软件资产所需的环境、部署和配置之间的所有差异，有望在规模上甚至在机群级别上起作用。
DevOps背后的自动化故事主要围绕CI/CD，即持续集成和部署，从而为生产做好工作代码的准备。
然而，部署并非这一流程的终点。代码发布往往是被忽略的步骤——将新软件展示给客户和最终用户，同时确保满足业务的持续目标。
在传统的本地和云环境中，要实现这种以客户为中心的CI/CD快速部署非常困难。但是，当将其部署到Kubernetes驱动的云原生环境时，由于运维环境的超大规模和即时性，需要重新的端到端思考——如何将软件发布到生产环境中以及如何运维。
对云原生计算的空前需求
虽然目前大多数企业都在加紧摸索Kubernetes部署，但部分行业，尤其是电信行业，已经开始展望空前的规模需求。
作为5G扩建的一部分，电信公司正在基站和存在点建立小型数据中心。但是“小型”是一个具有误导性的形容词，因为这些数据中心本身本质上就是云，每个数据中心可能运行数十万甚至数百万个Kubernetes集群。
从电信业务的角度来看，产品经理希望能够以复杂、动态的方式向客户推出新服务。他们可能希望向一小部分客户推出新功能，然后随着时间的推移扩展其部署。他们可能会针对地理位置而推出特定的产品。或者，他们可能会通过合规性限制来划分不同的服务类别。
此外，电信公司一马当先。许多行业，从银行业到汽车业，再到媒体业，也在寻求利用类似的功能来提高市场份额和客户价值。
此类企业可能希望向其各自客户群的不同细分市场尽可能推出广泛多样的服务产品。同样，他们的技术基础设施及支持人员的规模也远远超出了几年前的需求。
一方面，这种针对短暂性和规模的业务需求的爆炸性增长正在推动Kubernetes生态系统异常迅速地走向成熟。
另一方面，所有这些尖端技术都必须发挥切实的作用。而这正是云原生运维的用武之地。
云原生运维的基础
云原生计算采用既定的“基础设施即代码”原则，并将其扩展到模型驱动、基于配置的基础设施。云原生还利用了“shift left”、基础设施不变原则，偏重可扩展性而非定制性，这本身就是一种模型驱动的实践。
尽管要实现云原生计算的目标，需要模型驱动、基于配置的软件部署方法，但是这不足以应对在云原生环境中确保已部署软件的规模和短暂性的挑战。
软件团队必须将这种可配置性扩展到生产环境中，对生产中的持续变化作出预期和处理。为此，必须使用金丝雀部署、蓝/绿部署、自动回滚和其他技术来应对和利用生产环境中不断发生的、无法预测的变化。
跨不同的生产环境中进行提取也是一个重要的挑战。无论是不同的公共云、不同的Kubernetes发行版，还是将云和本地环境混合在一起的混合IT挑战（可能出于合规性原因），云原生发布编排都必须抽象化此类差异，以便提供一致的、基于配置的方法，跨此类差异实现自动化部署。
依赖性管理也是必不可少的。无论是单个微服务之间的依赖关系，还是对提供其他类型软件组件访问权限的 API 的依赖关系，重要的是，即使单个组件是临时的，意外的依赖关系也不得破坏部署。
最后，软件团队必须能够应对空前的规模。Kubernetes本身是按规模构建的，其架构可将微服务部署到容器中，将容器部署到pod中，将pod部署到集群中，但是光有集群还不够。
企业已经在研究复杂的多集群Kubernetes部署。软件团队还必须考虑集群组、集群组的“机群”。这样的机群通常会覆盖多个区域或数据中心，这给云原生部门带来了更大的挑战。
GitOps：云原生运维模型
一个有用的、极简的做法是，云原生 区将组织需要进行的所有工作简化，使Kubernetes能够在“3天”内全面投入生产。
Day 0是计划日。Day 1是部署Kubernetes和其他云原生生态系统的日子。Day 2则代表大规模全面运维的日子。
业内将如此复杂、相互关联的一系列任务划分为3个独立的日子，突显出了一个重要的事实：迄今为止，Day 2的任务一直未受到重视。为了充分关注Day 2的问题， 区创造了一个术语：GitOps。
GitOps的名字来自广受欢迎的开源代码管理工具Git。然而，SCM主要关注软件生命周期的预发布部分，但GitOps比Git更关注Ops。
GitOps将软件开发领域面向Git的最佳实践扩展到了Ops，与云原生运维所需的基于配置的方法保持一致——直到现在，团队才使用Git来管理和部署配置以及源代码。
由于GitOps具有充分的资格来抽象化大规模处理临时软件资产所需的环境、部署和配置之间的所有差异，因此这种方法有望在规模上甚至在机群级别上起作用。
GitOps还承诺提供一种新的软件治理方法，以解决瓶颈问题。在传统的软件开发（包括Agile）中，质量控制或变更控制委员会的审查要求可能会使软件部署停滞不前。取而代之的是，GitOps对导致这种缓慢的政策进行了抽象化处理，使组织能够更好地利用自动化来快速交付适当的软件管理。
供应商和开源项目逐步升级到云原生平台
云原生计算的核心是开源软件，因此，开源项目在云原生运维中发挥先锋作用是合乎逻辑的。
例如，用于Kubernetes的Argo CD是声明性的、以GitOps为中心的CD工具。同样，Tekton是用于创建CI/CD系统的灵活开源框架，允许开发人员跨云提供商和本地系统进行构建、测试和部署。
但是，从许多方面来看，此类项目只是云原生运维难题中的冰山一角，将这些难题集中在一起的是供应商。首先，许多供应商推销基于模型驱动的配置方法。这里有几个例子。
例如，Digital.ai软件公司采用模型驱动的可扩展方法，使更改易于执行并可以传播到所有环境。借助Digital.ai，开发人员无需为每个部署实例维护复杂的脚本或工作流。
Octopus Deploy公司采用类似的方法，使用模型驱动的Ops配置在异构环境（例如，本地和云）中提供简单的配置抽象。
借助Octopus，开发人员可以将这些脚本放入Octopus中并对其进行参数化处理，从而创建抽象的配置和展现形式，而不必为每个环境编写单独的脚本。与单独的CI/CD工具、ops工具和runbook自动化不同，Octopus提供了一个跨所有工具、环境和平台的部署工具。
与Octopus类似，ShuttleOps公司将大量连接器、自己编码的应用程序和基础设施配置封装起来，并将它们作为管道工作流中的步骤进行参数化。然后将结果 告给所选的编排和管理工具。
CircleCI（Circle互联 服务公司）和Cloudbees公司是另外两个通过声明性配置文件表示完整部署的供应商。
许多供应商还解决了生产中微服务（以及其他组件）之间相互依赖性的问题。Cloud66公司使开发人员和架构师能够以抽象但确定的方式定义服务依赖关系。这些依赖关系定义了运维必须管理的工作流。
接着，Cloud66可以告诉开发人员何时需要某个特定软件的新版本来解决这种依赖关系，并且告诉运维人员他们需要做什么来支持它。
Harness公司提供所谓的“连续交付抽象模型”，该模型使用模板消除依赖关系。CDAM通过自动回滚解决了上游和下游微服务依赖关系的影响。
运作中的GitOps
有多家供应商将云原生运维与GitOps产品整合在一起。
在WeaveWorks公司，GitOps具有环境感知能力，可生成代表其所需状态的整个系统模型。WeaveWorks支持多种变体，例如，本地自定义平台即服务——作为同一综合模型的一部分。WeaveWorks利用分布式数据库进行配置，这些配置可能支持数百万个集群，并且可以在高延迟和偶尔断开连接的环境中工作。
GitLab公司是另一家提供显式GitOps支持的供应商。GitLab提供了一个单一的平台，它将基础设施作为代码方法，将配置和策略定义为“代码”，同时利用自动化将更改与Git合并请求一起应用。
GitLab中的这种自动化支持解决了许多治理问题，因为它可以减少审批瓶颈。GitLabs的GitOps策略全都涉及自动化，例如，自动回滚。GitLab还支持版本证据，它可以对每个版本中包含的所有内容以及相关的元数据进行审计跟踪。
D2IQ公司推出了自己的GitOps产品，称之为GitNative，它结合了GitOps和Kubernetes原生CI/CD。目标是通过从DevOps到GitOps再到GitNative的全生命周期Git自动化，最大限度地提高速度、规模和质量。
D2IQ采用了基础设施不可变的方式——利用Kubernetes API和原语。D2IQ Kubernetes Platform既是无服务器又无状态的，也可在本地运行。D2IQ还同时利用了Argo CD和Tekton开源项目。
以机群的规模航行
“Day 2 Kubernetes部署“的关键在于它们能否处理数以百万计的大规模集群。
一些供应商在推销这种功能。WeaveWorks提供集群管理，它运行在客户选择的托管Kubernetes平台上，还可以进行应用程序管理，包括发布自动化和可扩展到机群的渐进式CD。
Vamp.io BV利用基于Kubernetes的环境为包含大量临时微服务的应用程序提供发布编排。该供应商为DevOps提供了版本编排，可以完全自动化发布，包括A/B测试，细粒度分段和多租户发布。
D2IQ提供大规模GitOps，可以很好地处理大量异构节点，包括集群、集群组和机群。D2IQ还提供单一管理平面来治理Kubernetes集群的机群。
最后
对于”传统”企业中的任何人来说，他们很容易看到云原生部署的大规模性和短暂性特征，并想知道他们的组织是否需要遵循这些模式的软件，这些软件与当今企业环境中他们熟悉的大多数软件有着天壤之别。
请记住，如果一种技术能力能够提高某些组织推出满足客户需求的差异化产品和服务的能力，那么他们的竞争对手也必须利用类似的能力，否则就会面临失去竞争力的风险，最终无法生存。
换句话说，云原生计算已经到来。它已经为那些利用这些能力向各自市场提供差异化产品和服务的企业提供大规模性和短暂性。如果您的组织不尽快跟上这股潮流，您的未来就会问题重重。不要掉队！
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！