使用 Flux2 管理您的 Kubernetes 集群
在本文中,我们将一起了解如何使用 Flux 2 和 Gitops 方法管理 Kubernetes 集群。 GitOps : 基于同步的方法 GitOps 是自动化部署容器化应用程序和基础设施的良好实践的组合。您无需推送更改,而是在 Kubernetes 集群中拉取和同步代码更改。 简单来说: GitOps 是一种使用同步机制和 Git 存储库作为所有配置和代码的真实来源进行 DevOps 的方式。
在本文中,我们将一起了解如何使用 Flux 2 和 Gitops 方法管理 Kubernetes 集群。
GitOps : 基于同步的方法
GitOps 是自动化部署容器化应用程序和基础设施的良好实践的组合。您无需推送更改,而是在 Kubernetes 集群中拉取和同步代码更改。
简单来说:
GitOps 是一种使用同步机制和 Git 存储库作为所有配置和代码的真实来源进行 DevOps 的方式。
下面是一个经典模型,开发人员使用 CICD 管道通过 Gitlab CI 构建和部署他们的应用程序,Ops 管理集群并设置基础设施服务。
在新的 GitOps 模型中,不允许直接在集群中进行手动操作和更改:
集群状态现在与 git 代码存储库同步,而不是直接进行更改:
当检测到存储库中的更改时,会自动安装和更新基础架构服务和应用程序。这种机制是通过集群中的控制器来完成的,这些控制器检测源代码或 Docker 图像标签中的变化。
助焊剂 2
Flux 是一种工具,用于将 Kubernetes 集群与代码存储库同步,并在有新代码或要部署的修改时自动更新。
需要注意的是,每个动作都是在“拉动”中完成的,Flux 和 Kubernetes 为保持状态更新所做的操作直接连接到资源。这对安全性非常有用,例如,您不再需要将 Kubernetes API 暴露给 SaaS 中的外部 CICD 工具。
Flux 版本 2 (“v2”) 从头开始构建,使用 Kubernetes 的 API 扩展系统,并与 Prometheus 和 Kubernetes 生态系统的其他核心组件集成。在版本 2 中,Flux 支持多租户和同步任意数量的 Git 存储库,以及其他长期要求的功能。 Flux v2 使用 GitOps Toolkit 构建,这是一组可组合的 API 和用于在 Kubernetes 之上构建持续交付的专用工具。
Flux 2 围绕控制器构建,控制器管理源和部署的生命周期,无论是 Helm 包还是标准 Kubernetes Yaml 文件。
为什么它很酷?
最重要的是,您随时都知道您的 Kubernetes 集群已设置为从代码存储库定义的所需状态。这意味着您不必自己操作集群,这要归功于同步机制,一切都是完全自动化的。
传统上,当您使用 CICD 工具进行经典集群操作时,一旦完成最后一次交付,在下一次交付之前,您不知道集群的状态。
例如,考虑在您的组织中管理许多 Kubernetes 集群,并且您需要更改例如公共资源。使用这种方法,集群将意识到他们有资源可以在其配置中进行修改。您将不再需要连接到每个集群的 Kube API 来为其下达更改命令。
因此,在集群上操作资源更容易、更快捷,但也更加工业化和可控。
使用 Kustomize 操作配置
Kustomize 用于构建配置代码并操作 Helm 图表及其值。例如,您可以使用 Kustomize 模板为不同的 Kubernetes 集群设置自定义 Helm 值,而无需复制代码。这允许最大程度地保持通用配置代码的唯一性,不同文件中的每个集群只需要特定参数。
自动图像更新
自动镜像更新由 Flux2 通过扫描容器镜像注册表并根据标签从定义的策略触发部署更新来完成。
支持 3 种类型的策略:
-
正则表达式
-
日历版本控制
-
语义版本控制
此功能是可选的,但语义版本控制可能是操作和控制图像更新的最佳方式。
如果 Flux 在扫描镜像 registry 时检测到策略允许的新标签,Flux 将自动替换部署的 yaml 文件中的标签,并将更改推送到远程 Git 存储库。这在 Flux 术语中称为 Git 协调。
然后同步触发使用新映像的部署更新。这对于进行持续交付并确保存储库计算当前 K8S 集群状态非常有用。
简单用例:在 2 个集群上设置基础设施服务
为了轻松快速地开始展示 Flux 2 的强大功能,我们将采用以下用例:管理 2 个名为“kube-prod”和“kube-dev”的 Kubernetes 集群的基础设施服务配置,一个生产集群和一个开发集群簇。我们希望首先使用默认配置自动部署 Ingress-nginx 的 Helm 图表,然后为每个集群使用不同配置的 Prometheus-operator。
通量设置和凭据
安装 Flux cli 并配置本地 kube 配置上下文(prod&dev):
$ curl -s https://toolkit.fluxcd.io/install.sh |须藤重击
现在 Flux Cli 二进制文件已在您的本地环境中设置,您可以在每个 Kubernetes 集群上设置 Flux。
$ export GITHUB_TOKENu003dxxxxxxmysupertokenxxxxx$flux bootstrap github --owneru003dcyrilbkr --repositoryu003dflux-multicluster-example --branchu003dmaster --token-auth --personal --pathu003dclusters/kube-prod
这里的问题是,将集群与 Flux 集成只是简单的单行命令。您当然可以很容易地将这个安装过程集成到像 Terraform 这样的基础设施代码工具中。
代码库
现在让我们看一下我们想要在 Kubernetes 集群上设置的 Flux 配置,并使用 Kustomize 来最小化重复的代码声明。
您可以在我的公共 Github 上找到这个完整示例here 的源代码并在您的集群上直接尝试。
这是最终的文件层次结构:
如您所见,我们在顶部有两个主要文件夹,称为“集群”和“基础设施”。
clusters 目录包含每个集群的资源列表,这与前面的 Flux Cli 引导命令的选项 -path 相关(例如:--pathu003dclusters/kube-prod)。 Flux 扫描这个子目录并确定它需要调用哪些资源定义。
基础设施目录包含我们使用 Kustomize 定义的资源。在这里,我们构建代码来设置 Nginx-ingress 和 Prometheus-operator Helm chart。
来源
在编写资源定义之前,我们需要设置 Helm 资源可用的位置。为此,我们需要创建一个 HelmRepository 定义并定义 Helm url 和 Flux 监控时间间隔。 Flux 使用此参数来了解 Helm 包的可下载位置以及验证存储库的频率。
在我的示例中,我将所有源定义存储在一个名为“common”的资源中,但您也可以在每个资源目录中拆分源定义。
api版本:source.toolkit.fluxcd.io/v1beta1
种类:HelmRepository
元数据:
名称:入口-nginx
规格:
间隔:30m
网址:https://kubernetes.github.io/ingress-nginx
在这个声明中,我们指定了 Nginx-ingress Helm 包 url 和时间间隔(30m)。不要忘记将其添加到您的 Kuztomize 定义中:
api版本:kustomize.config.k8s.io/v1beta1
种类:定制化
命名空间:通量系统
资源:
- 入口-nginx.yaml
Nginx 入口
让我们从用例的简单部分开始,在每个集群上设置具有相同 Kubernetes 配置的 Nginx-ingress Helm 包。
添加 Kustomize 定义以包含使用的命名空间和图表定义:
api版本:kustomize.config.k8s.io/v1beta1
种类:定制化
命名空间:入口-nginx
资源:
-
命名空间.yaml
-
nginx-ingress.yaml
然后创建 Nginx-ingress Helm 资源定义:
api版本:helm.toolkit.fluxcd.io/v2beta1
种类:HelmRelease
元数据:
名称:nginx入口
规格:
发布名称:nginx-ingress
图表:
规格:
图表:ingress-nginx
来源参考:
种类:HelmRepository
名称:入口-nginx
命名空间:通量系统
版本:“3.23.0”
间隔:1h0m0s
安装:
整治:
重试次数:3
价值观:
控制器:
种类:守护程序集
Nginx-ingress Helm release 定义调用我们之前创建的 Nginx-ingress Helm source。我们还通过从 values.yaml 传统文件中指定自定义值来自定义 Helm 图表,在这种情况下,我们指定 Nginx-ingress 是一个 Daemonset(默认情况下,它是一个部署)。
最后一步,我们现在需要将此定义影响到我们的集群。
这是开发集群(kube-dev)的 common.yaml 文件:
api版本:kustomize.toolkit.fluxcd.io/v1beta1
种类:定制化
元数据:
名称:普通
命名空间:通量系统
规格:
间隔:10m0s
来源参考:
种类:GitRepository
名称:通量系统
路径:./infrastructure/common
修剪:真
验证:客户端
健康检查:
- api版本:应用程序/v1
种类:守护程序集
名称:nginx-ingress-ingress-nginx-controller
命名空间:入口-nginx
path 参数定义了 Nginx-ingress 资源定义可用的位置(./infrastructure/common)。
我们还设置了一个健康检查,以允许 Flux 验证 Nginx-ingress 是否成功运行并考虑托管资源是否可操作。
您现在可以在存储库中提交您的更改,并检查 Flux 是否使用 Flux Cli 自动应用修改:
$ 通量获取资源掌舵
命名就绪消息
ingress-nginx True Fetched 修订版:a0a1a2a0a1a2a0a1a2$flux get helmreleases -n ingress-nginx
名称就绪消息修订
nginx-ingress True Release 对账成功 3.23.0
您还可以手动检查 Kubectl 是否在两个集群上都已正确设置:
$ kubectl 获取 pod -n ingress-nginx
名称就绪状态
nginx-ingress-ingress-nginx-controller-6thsk 1/1 正在运行
普罗米修斯
现在您知道如何在集群上设置资源,让我们举一个更高级的示例。我们将创建配置来管理 Prometheus 但每个集群使用不同的参数。在生产集群上,我们希望设置 3 个 Prometheus 副本和 1 个月的指标保留期,而在开发集群上,我们只想设置 1 个副本和 1 周的较轻保留期。为此,我们将使用 Kustomize 的强大功能来保留尽可能多的通用代码,并且只定义特定于我们集群的唯一参数。
正如我们之前所做的,我们必须首先添加存储 Helm Chart 的源
api版本:source.toolkit.fluxcd.io/v1beta1
种类:HelmRepository
元数据:
名称:普罗米修斯社区
规格:
间隔:30m
网址:https://prometheus-community.github.io/helm-charts
然后创建一个名为 monitoring 的目录,其中包含 3 个包含基本代码和特定代码的子目录。
- base : 通用代码定义
api版本:helm.toolkit.fluxcd.io/v2beta1
种类:HelmRelease
元数据:
名称:prometheus-operator
规格:
发布名称:prometheus-operator
图表:
规格:
图表:kube-prometheus-stack
来源参考:
种类:HelmRepository
名称:普罗米修斯社区
命名空间:通量系统
版本:“13.13.1”
间隔:1h0m0s
安装:
整治:
重试次数:3
价值观:
格拉法纳:
启用:假
警报管理器:
启用:假
普罗米修斯:
入口:
启用:假
- kube-prod :生产集群的具体值
api版本:helm.toolkit.fluxcd.io/v2beta1
种类:HelmRelease
元数据:
名称:prometheus-operator
命名空间:监控
规格:
价值观:
普罗米修斯:
普罗米修斯规格:
复制品:3
保留:30天
不要忘记在 kustomization.yaml 中添加 Kustomize patchStrategicMerge 定义。这允许 Kustomize 将公共代码与特定的集群值合并:
api版本:kustomize.config.k8s.io/v1beta1
种类:定制化
资源:
- ../根据
补丁策略合并:
- 普罗米修斯运营商值.yaml
- kube-dev :开发集群的具体值
api版本:helm.toolkit.fluxcd.io/v2beta1
种类:HelmRelease
元数据:
名称:prometheus-operator
命名空间:监控
规格:
价值观:
普罗米修斯:
普罗米修斯规格:
复制品:1
保留:7天
同样,不要忘记像我们之前为生产环境所做的那样将其添加到您的 Kustomize 定义中并提交您的代码。
验证两个集群的 Flux 端是否一切正常:
$flux 获取源图表
命名就绪消息
monitoring-prometheus-operator True Fetched 修订版:13.13.1 13.13.1$ Flux get helmreleases -n monitoring
名称就绪消息修订
prometheus-operator True Release 对账成功 13.13.1
最后在生产集群上使用 Kubectl 手动检查,例如我们有 3 个 Prometheus 副本:
$ kubectl 获取 pod -n 监控
prometheus-operator-prometheus-0 2/2 运行 1
prometheus-operator-prometheus-1 2/2 运行 1
prometheus-operator-prometheus-3 2/2 运行 1
惊人的 ! :)
感谢 Flux 和 Kustomize,您现在知道如何以同步和工业化的方式管理 Kubernetes 集群的部署!
更多推荐
所有评论(0)