网站源码安装,wordpress wp_enqueue_media,陕西网站推广公司,纪念平台网站建设大家好#xff0c;我是小碗汤#xff0c;今天分享一篇6张图深入理解GitOps#xff0c;内容硬核#xff0c;建议兄弟们收藏~在使用 K8s 的云原生应用中#xff0c;Serverless#xff0c;Devops 工具以及大量其他云技术。通常#xff0c;基础设施代码和应用程序代码是分开… 大家好我是小碗汤今天分享一篇6张图深入理解GitOps内容硬核建议兄弟们收藏~在使用 K8s 的云原生应用中ServerlessDevops 工具以及大量其他云技术。通常基础设施代码和应用程序代码是分开和单独部署的从而会导致系统状态和配置漂移、不稳定、错误配置变更等问题。GitOps 将 Git 与 GitOps Operator 工具结合在一起它们通常都在 K8s 中使 Git 为开发人员提供更高效、更安全、更集中的版本控制是 K8s 的集中式操作模型、可以更快发布版本。今天容器化已经成为在开发、测试和生产环境中运行应用程序的标准方式。因此容器编排已经成为部署过程中不可或缺的一部分。容器在一个独立的实例中运行应用程序及其所有依赖项类似于 VM但更轻量。它们与运行它们的主机共享操作系统内核存储和网络。容器可以在持续集成和持续部署过程中保证操作系统、依赖项和应用程序不变。目前为止Docker 仍是最流行的容器运行时。当多个容器同时运行时我们需要编排。可以在单个或少量 docker 服务器上部署许多容器但管理网络存储容器编排这就是 K8s 发挥作用的地方。K8s 是一种编排解决方案它抽象了运行多个容器的复杂性甚至是在多个集群中运行这些容器的复杂性。它接管了成百上千个容器的计算、网络和存储但它依赖这些底层基础设施。对 CI/CD 流程的理解在进入GitOps的核心概念之前先了解一下容器和k8s是如何兼容CI/CD Pipeline的。标准CI/ CD流程上图显示了一个标准的持续集成和交付过程。这个过程可能相当复杂便于理解我们尽量保持简单。这里首先由开发人员提交代码并将其推送到版本控制系统(通常是 git)。创建一个 pull 请求合并到主分支。一旦代码被合并它就会触发自动构建将这些提交的更改合并到一起。构建发生在 CI 服务器上如果构建和测试一切顺利则构建应用程序的容器镜像并将其推送到容器注册中心。这个过程被称为持续集成。代表应用程序不同版本的容器镜像存储在注册表中以便部署在不同的环境中进行测试。作为持续集成的扩展这些步骤被称为持续交付。当测试通过时可以触发应用程序新版本的自动化生产部署。CI/CD 过程中可能涉及多个手动步骤但是当随着时间推移开发过程变得成熟时可能会取消手动干预这称为持续部署。在持续交付过程中在k8s中设置预期的状态然后根据镜像创建单个容器。但是容器镜像在本质上是不可变的所以当我们需要更新已部署的应用程序时需要使用新代码和所有依赖项创建一个新的容器镜像。为了获得所需的状态k8s从远程注册表获取镜像并达到期望状态。我们需要为它提供一组k8s配置清单这些配置清单描述应用程序将如何运行。这些YAML清单引用容器镜像来标识部署的应用程序版本还包含其他配置如副本实例数、健康检查、安全和自动伸缩等。配置漂移问题K8s 将尝试根据YAML中的定义向期望状态接近它也将响应之后的用户请求来更改所需状态。这可以使用不依赖于YAML清单的命令(kubectl 命令)来完成。这些命令会改变期望状态配置开始偏离YAML清单中已经定义的内容。让我们用一个例子来理解它:这里简化了 CI/CD 过程以关注在一段时间内配置漂移问题是如何发生的。从v1版本的应用程序部署到k8s集群开始。我们已经定义的 CI/CD 流程用于按照我们预期的状态(DSC 1)将配置应用到集群。现在应用程序在集群中以定义的期望状态(DSC 1)运行了一段时间但最终出现了一些操作问题。例如由于流量突然增加应用数量需要在节点级扩容或一些安全配置需要立即应用到集群。为此需使用必要的命令改变配置改变已部署的应用程序。如下面所示图最终在生产环境中长时间运行应用程序后应用程序的版本 2 (App Version 2)已经准备好了新特性并上传工作负载清单以引用较新的镜像。同样我们的 CI/CD 将负责应用更新后的YAML清单并且我们将依赖 K8s 在期望的状态下优雅地处理更改。但理想状态是什么是更新后的清单引用了新的容器镜像吗它是我们在动态集群中所做的必要更改和新的工作负载清单的合并吗K8s 认为理想状态应该是什么这个问题的答案是K8s 会根据要求合并配置更改但是集群的状态将不再准确反映我们开始时使用的 YAML 配置清单。什么是 GitOps?配置漂移可能是一个严重的问题我们最好管理配置的完整性以便在 K8s 中配置的内容准确地反映预期。GitOps 就为了解决这个问题。它可以用来有效地管理配置并帮助实现可靠和自动化的部署。GITOPS是依赖于软件自动化建立期望状态的云原生应用程序的操作模型模式其使用版本控制系统作为提供自动连续交付的真实来源。所以 GitOps 通常描述的是期望的状态配置并将其存储在版本控制系统中它管理在期望状态下的变化。然后通过自动化代理(如 Flux 或 Argo CD)将这个期望的状态应用到目标环境(k8s但不一定)然后根据版本控制系统中可用的内容持续监视系统的实际状态。自动化代理可以是外部的也可以在系统内运行。他们连续监测系统并观察配置漂移的行为做一些操作可以配置为发出警报或者以自动化的方式进行修复。GitOps 的部署策略GitOps 的部署策略可以用推模型或拉模型来实现下面我们试着去理解这两种模型。Push Model在本文开头我们讨论了标准的 CI/CD 过程是怎样的即开发人员将代码推送到 VCS然后通过 pull request 触发 CI 构建。从那里产生的 docker 文件作为 CI 过程的结果存储在注册表。在 CD 过程中部署到 K8s 集群如下步骤 1,3,4,5 和 6 所示。Push部署策略Push 部署策略GitOps 的 Push 部署策略非常类似于 CI/CD 流程只是清单文件包含了定义 K8 服务器需要创建对象的配置。Manifest 文件也在 VCS 中管理可以是同一个 VCS也可以是单独的存储库。正如我们上面讨论的部署和监控应用程序的自动化过程可以是外部的也可以是内部的对于 Push 部署策略它是外部的通常由同一个 CI 服务器管理。CI 服务器可以执行kubectl apply命令将 manifest 应用到集群中。Pull Model在GitOps Pull场景中自动化不是从集群外部操作而是在集群内部部署一个代理。它作为Kubernetes Operator运行能够跟踪包含 K8s 清单的 VSC 仓库。Pull部署策略Pull 部署策略当它在集群中运行时它知道集群的实际状态。如果它检测到 VCS 中包含的真实源与集群中的实际状态之间存在差异它就会采取行动。要么发出告警要么试图通过与 VCS 的内容同步来调和差异。还可以将代理配置为以新镜像的形式监视远程容器注册表中应用程序代码的新版本。然后代理能够在 VCS 中更新清单并基于新镜像触发新的自动部署。由于 Pull 部署策略需要K8s Operator来执行操作我们需要为此寻找特定的工具。虽然有多种可用的工具但其中两个是最受欢迎的CNCF 也推荐了它们。例如Flux[1]和ArgoCD[2]。可以在官网中获得更多细节。本文是对 GitOps 的理解以及它如何解决配置漂移问题来实现系统的高级治理。深入研究 GitOps 工具看它们是如何实现的将在后续文章中做分析。本文翻译自https://reurl.cc/OpqNqX版权归原作者所有欢迎小伙伴们投稿原创文章~投稿格式markdown格式的md文件投稿邮箱: pubkubeinfo.cn参考资料[1]Flux: https://fluxcd.io/[2]ArgoCD: https://argo-cd.readthedocs.io/en/stable/点个在看你最好看
