跳到主要内容

1.flux介绍

什么是 gitops​

仅仅为了使用而使用任何云原生工具是非常低效的，因为云原生应用程序需要大量维护。你不能只是部署然后忘记它们。那么，为什么你要首先开始使用GitOps？

在我看来，有两种主要情况下采用GitOps最佳实践非常有用：

  • 大团队中

如果你在一个大团队中工作，你不想让每个用户都访问你的 Kubernetes 资源并管理部署。相反，你可以将GitOps工具（如Flux或ArgoCD）与你的一个代码库关联起来，当 Kubernetes 清单发生变化或指定分支时，GitOps工具将负责将更新推送到你的Kubernetes集群中。

  • 个人或少数人合作

很多时候，使用特定的云原生工具来管理部署被认为是过度的。然而，如果你有一个高度动态的应用程序，并且希望长期管理它，通过ArgoCD或Flux自动管理更新流程非常有用。这将为你提供更深入的部署洞察。

什么是 Flux​

Flux 是一套面向 Kubernetes 的持续渐进式交付解决方案，具有开放性和可扩展性。可以帮助开发者和运维人员更加便捷的管理在Kubernetes上的应用程序。它以GitOps的方式来进行工作，也就是说，所有的配置变更都会在git仓库中进行，并且由FluxCD自动地应用到Kubernetes集群中。这种方式可以帮助团队更好地进行协作，并且可以在任何时间轻松地回滚到之前的状态。

核心概念​

以下是 Flux 中的一些核心概念以及名词解释，理解这些概念有助于帮助你更好的掌握 Flux。

GitOps​

GitOps 是一种管理你的基础设施和应用的方式，你的整个系统被声明性地描述并进行版本控制（最有可能在一个Git仓库中），且有一个自动化的过程来确保部署的环境匹配仓库中指定的状态。

helm​

一个Kubernetes的包管理工具，可以用来简化Kubernetes应用的部署和管理。

CRD​

Custom Resource Definition（CRD）：Kubernetes中的一个功能，允许用户创建自定义的资源类型。

Sources​

一个 source 定义了包含系统所需状态的仓库的来源和获取它的要求（例如，凭证，版本选择）。例如，来自SSH上的Git仓库的最新1.x标签。

sources 产生一个由其他 Flux 组件消费以执行操作的 artifact ，例如将 artifact 的内容应用到集群上。一个 source 可能被多个消费者共享以消除配置和/或存储的重复。

在定义的时间间隔内检查 source 的来源是否有更改，如果有符合条件的更新版本可用，则会生成新的 artifact。

所有的 sources 都在Kubernetes集群中指定为 custom resources，sources 可以包括GitRepository，OCIRepository，HelmRepository和Bucket资源。

Reconciliation​

Reconciliation 是确保给定状态（例如在集群中运行的应用程序、基础设施）与在某处以声明方式定义的所需状态（例如 Git 存储库）相匹配。

Flux中有各种这些的例子：

  • HelmRelease Reconciliation：确保 Helm 发布的状态与资源中定义的状态匹配，如果情况不是这样（包括HelmChart资源的修订版本更改），则执行发布。
  • Bucket Reconciliation：在给定的间隔上下载并归档声明的bucket的内容，并将其存储为一个 artifact，记录 artifact 的的修订版本和 artifact 本身在资源的状态。
  • Kustomization Reconciliation：确保在集群上部署的应用程序的状态与在 Git 或 OCI 仓库或 S3 bucket 中定义的资源匹配。

Kustomization​

Kustomization 自定义资源代表了 Flux 应该在集群中进行 reconcile 的一组本地Kubernetes资源（例如，kustomize overlay）。默认情况下，reconcile 每五分钟运行一次，但可以使用.spec.interval进行更改。如果你使用kubectl edit/patch/delete对集群进行任何更改，它们将立即被还原。你可以暂停 reconciliation 或将你的更改推送到Git仓库。

Bootstrap​

以 GitOps 方式安装 Flux 组件自身的过程被称为引导。应用程序清单被应用到集群，为 Flux 组件创建一个 GitRepository 和 Kustomization，然后将清单推送到现有的Git仓库（或创建一个新的）。Flux可以像管理其他资源一样管理自己。

Continuous Delivery​

续交付指的是频繁并可靠地交付软件更新的实践。

Continuous Deployment​

持续部署是一种实践，即一旦代码更改通过了自动化测试，就自动将其部署到生产环境。

Progressive Delivery​

渐进式交付通过向一部分用户逐步推出新功能或更新，建立在持续交付之上，使开发者能够在受控环境中测试和监控新功能，并在将其发布给所有人之前进行必要的调整。

开发者可以使用诸如功能标记、金丝雀发布和A/B测试之类的技术，来最大限度地减少引入可能会对用户造成伤害或中断业务操作的错误或错误的可能性。这些策略使新功能的控制和逐步推出成为可能，确保了平稳且成功的发布，增强了用户的信任并提高了整体用户体验。

Flux项目提供了一个名为Flagger的专门控制器，它实现了各种渐进式交付技术。有关更多信息，请查看Flagger部署策略。