flux2+kustomize+helm+github 多集群 GitOps 云原生渐进式交付

简介: flux2+kustomize+helm+github 多集群 GitOps 云原生渐进式交付

对于此示例,我们假设有两个集群的场景:暂存(staging)和生产(production)。最终目标是利用 FluxKustomize 来管理两个集群,同时最大限度地减少重复声明。

我们将配置 Flux 以使用 HelmRepositoryHelmRelease 自定义资源安装、测试和升级演示应用程序。 Flux 将监控 Helm 存储库,并根据 semver 范围自动将 Helm 版本升级到最新的 chart 版本。


准备工作



flux2-kustomize-helm-example

您将需要 Kubernetes 集群版本 1.16 或更新版本以及 kubectl 版本 1.18 或更新。对于快速的本地测试,您可以使用 Kubernetes kind。不过,任何其他 Kubernetes 设置也可以正常工作。


为了遵循本指南,您需要一个 GitHub 帐户和一个可以创建存储库的 personal access token(检查 repo 下的所有权限)。


使用 HomebrewMacOSLinux 上安装 Flux CLI


brew install fluxcd/tap/flux


或者通过使用 Bash 脚本下载预编译的二进制文件来安装 CLI:


curl -s https://fluxcd.io/install.sh | sudo bash


项目结构



Git 存储库包含以下顶级目录:

  • apps 目录包含每个集群具有自定义配置的 Helm 版本
  • infrastructure 目录包含常见的基础设施工具,例如 NGINX ingress controller 和 Helm 存储库定义
  • clusters 目录包含每个集群的 Flux 配置


├── apps
│   ├── base
│   ├── production 
│   └── staging
├── infrastructure
│   ├── nginx
│   ├── redis
│   └── sources
└── clusters
    ├── production
    └── staging


apps 配置结构为:


  • apps/base/ 目录包含命名空间和 Helm 发布定义(release definitions)
  • apps/production/ 目录包含生产 Helm 发布值(release values)
  • apps/staging/ 目录包含 staging values


./apps/
├── base
│   └── podinfo
│       ├── kustomization.yaml
│       ├── namespace.yaml
│       └── release.yaml
├── production
│   ├── kustomization.yaml
│   └── podinfo-patch.yaml
└── staging
    ├── kustomization.yaml
    └── podinfo-patch.yaml


apps/base/podinfo/ 目录中,我们有一个 HelmRelease,两个集群都有共同的值:


apiVersion: helm.toolkit.fluxcd.io/v2beta1
kind: HelmRelease
metadata:
  name: podinfo
  namespace: podinfo
spec:
  releaseName: podinfo
  chart:
    spec:
      chart: podinfo
      sourceRef:
        kind: HelmRepository
        name: podinfo
        namespace: flux-system
  interval: 5m
  values:
    cache: redis-master.redis:6379
    ingress:
      enabled: true
      annotations:
        kubernetes.io/ingress.class: nginx
      path: "/*"


apps/staging/ 目录中,我们有一个带有 staging 特定值的 Kustomize 补丁(patch):


apiVersion: helm.toolkit.fluxcd.io/v2beta1
kind: HelmRelease
metadata:
  name: podinfo
spec:
  chart:
    spec:
      version: ">=1.0.0-alpha"
  test:
    enable: true
  values:
    ingress:
      hosts:
        - podinfo.staging


请注意,使用 version: ">=1.0.0-alpha" 我们配置 Flux 以自动将 HelmRelease 升级到最新的 chart 版本,包括 alphabeta 和预发布(pre-releases)。

apps/production/ 目录中,我们有一个带有生产特定值的 Kustomize 补丁:


apiVersion: helm.toolkit.fluxcd.io/v2beta1
kind: HelmRelease
metadata:
  name: podinfo
  namespace: podinfo
spec:
  chart:
    spec:
      version: ">=1.0.0"
  values:
    ingress:
      hosts:
        - podinfo.production


请注意,使用 version: ">=1.0.0" 我们配置 Flux 以自动将 HelmRelease 升级到 最新的稳定 chart 版本(alphabetapre-releases 将被忽略)。

基础设施:


./infrastructure/
├── nginx
│   ├── kustomization.yaml
│   ├── namespace.yaml
│   └── release.yaml
├── redis
│   ├── kustomization.yaml
│   ├── namespace.yaml
│   └── release.yaml
└── sources
    ├── bitnami.yaml
    ├── kustomization.yaml
    └── podinfo.yaml


infrastructure/sources/ 目录中,我们有 Helm 存储库定义:


apiVersion: source.toolkit.fluxcd.io/v1beta1
kind: HelmRepository
metadata:
  name: podinfo
spec:
  interval: 5m
  url: https://stefanprodan.github.io/podinfo
---
apiVersion: source.toolkit.fluxcd.io/v1beta1
kind: HelmRepository
metadata:
  name: bitnami
spec:
  interval: 30m
  url: https://charts.bitnami.com/bitnami


请注意,使用 interval: 5m 我们将 Flux 配置为每五分钟拉一次 Helm 存储库索引。如果索引包含与 HelmReleasesemver 范围匹配的新 chart 版本,Flux 将升级该版本。


Bootstrap staging 和 production



集群目录包含 Flux 配置:


./clusters/
├── production
│   ├── apps.yaml
│   └── infrastructure.yaml
└── staging
    ├── apps.yaml
    └── infrastructure.yaml


clusters/staging/ 目录中,我们有 Kustomization 定义:


apiVersion: kustomize.toolkit.fluxcd.io/v1beta1
kind: Kustomization
metadata:
  name: apps
  namespace: flux-system
spec:
  interval: 10m0s
  dependsOn:
    - name: infrastructure
  sourceRef:
    kind: GitRepository
    name: flux-sytem
  path: ./apps/staging
  prune: true
  validation: client
---
apiVersion: kustomize.toolkit.fluxcd.io/v1beta1
kind: Kustomization
metadata:
  name: infrastructure
  namespace: flux-system
spec:
  interval: 10m0s
  sourceRef:
    kind: GitRepository
    name: flux-system
  path: ./infrastructure


请注意,使用 path: ./apps/staging 我们配置 Flux 以同步暂存 Kustomize 覆盖,并使用 dependsOn 我们告诉 Flux 在部署应用程序之前创建基础设施项。

在您的个人 GitHub 帐户上 Fork 此存储库并导出您的 GitHub access token、用户名和存储库名称:


export GITHUB_TOKEN=<your-token>
export GITHUB_USER=<your-username>
export GITHUB_REPO=<repository-name>


验证您的临时集群是否满足先决条件:


flux check --pre


kubectl context 设置为您的 staging 集群和 bootstrap Flux:


flux bootstrap github \
    --context=staging \
    --owner=${GITHUB_USER} \
    --repository=${GITHUB_REPO} \
    --branch=main \
    --personal \
    --path=clusters/staging


bootstrap 命令在 clusters/staging/flux-system 目录中提交 Flux 组件的清单,并在 GitHub 上创建一个具有只读访问权限的部署密钥,因此它可以在集群内拉取更改(pull changes)。


注意在 staging 上安装的 Helm releases:


$ watch flux get helmreleases --all-namespaces 
NAMESPACE NAME    REVISION  SUSPENDED READY MESSAGE                          
nginx     nginx   5.6.14    False     True  release reconciliation succeeded  
podinfo   podinfo 5.0.3     False     True  release reconciliation succeeded  
redis     redis   11.3.4    False     True  release reconciliation succeeded


验证 demo app 是否可以通过 ingress 访问:


$ kubectl -n nginx port-forward svc/nginx-ingress-controller 8080:80 &
$ curl -H "Host: podinfo.staging" http://localhost:8080
{
  "hostname": "podinfo-59489db7b5-lmwpn",
  "version": "5.0.3"
}


通过设置生产集群的上下文和路径来引导生产上的 Flux


flux bootstrap github \
    --context=production \
    --owner=${GITHUB_USER} \
    --repository=${GITHUB_REPO} \
    --branch=main \
    --personal \
    --path=clusters/production


监控 production reconciliation:


$ watch flux get kustomizations
NAME            REVISION                                        READY
apps            main/797cd90cc8e81feb30cfe471a5186b86daf2758d True
flux-system     main/797cd90cc8e81feb30cfe471a5186b86daf2758d True
infrastructure  main/797cd90cc8e81feb30cfe471a5186b86daf2758d True


加密 Kubernetes secrets



为了将 secrets 安全地存储在 Git 存储库中, 您可以使用 MozillaSOPS CLI 通过 OpenPGPKMS 加密 Kubernetes secrets

安装 gnupg 和 sops:


brew install gnupg sops


Flux 生成一个不指定密码短语(passphrase)的 GPG key,并获取GPG key ID


$ gpg --full-generate-key
Email address: fluxcdbot@users.noreply.github.com
$ gpg --list-secret-keys fluxcdbot@users.noreply.github.com
sec   rsa3072 2020-09-06 [SC]
      1F3D1CED2F865F5E59CA564553241F147E7C5FA4


使用 private key 在集群上创建 Kubernetes secret:


gpg --export-secret-keys \
--armor 1F3D1CED2F865F5E59CA564553241F147E7C5FA4 |
kubectl create secret generic sops-gpg \
--namespace=flux-system \
--from-file=sops.asc=/dev/stdin


生成 Kubernetes secret manifest 并使用 sops 加密 secret 的数据字段:


kubectl -n redis create secret generic redis-auth \
--from-literal=password=change-me \
--dry-run=client \
-o yaml > infrastructure/redis/redis-auth.yaml
sops --encrypt \
--pgp=1F3D1CED2F865F5E59CA564553241F147E7C5FA4 \
--encrypted-regex '^(data|stringData)$' \
--in-place infrastructure/redis/redis-auth.yaml


添加 secret 到 infrastructure/redis/kustomization.yaml:


apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
namespace: redis
resources:
  - namespace.yaml
  - release.yaml
  - redis-auth.yaml


通过编辑 infrastructure.yaml 文件在集群上启用解密:


apiVersion: kustomize.toolkit.fluxcd.io/v1beta1
kind: Kustomization
metadata:
  name: infrastructure
  namespace: flux-system
spec:
  # content omitted for brevity
  decryption:
    provider: sops
    secretRef:
      name: sops-gpg


导出公钥(public key),以便任何有权访问存储库的人都可以加密 secrets 但不能解密它们:


gpg --export -a fluxcdbot@users.noreply.github.com > public.key


将更改推送到主分支:


git add -A && git commit -m "add encrypted secret" && git push


验证是否已在两个集群的 redis 命名空间中创建了 secret


kubectl --context staging -n redis get secrets
kubectl --context production -n redis get secrets


您可以使用 Kubernetes secrets 为您的 Helm releases 提供值:


apiVersion: helm.toolkit.fluxcd.io/v2beta1
kind: HelmRelease
metadata:
  name: redis
spec:
  # content omitted for brevity
  values:
    usePassword: true
  valuesFrom:
  - kind: Secret
    name: redis-auth
    valuesKey: password
    targetPath: password


在 docs 中了解有关 Helm releases values 覆盖的更多信息。


添加集群



如果要将集群添加到你的 fleet 中,请先在本地克隆存储库:


git clone https://github.com/${GITHUB_USER}/${GITHUB_REPO}.git
cd ${GITHUB_REPO}


使用您的集群名称在 clusters 中创建一个目录:


mkdir -p clusters/dev


staging 复制同步清单:


cp clusters/staging/infrastructure.yaml clusters/dev
cp clusters/staging/apps.yaml clusters/dev


您可以在 apps 内创建一个 dev overlay,确保将 clusters/dev/apps.yaml 内的 spec.path 更改为 path: ./apps/dev

将更改推送到主分支:


git add -A && git commit -m "add dev cluster" && git push


将 kubectl 上下文和路径设置为您的 dev cluster 并引导 Flux:


flux bootstrap github \
    --context=dev \
    --owner=${GITHUB_USER} \
    --repository=${GITHUB_REPO} \
    --branch=main \
    --personal \
    --path=clusters/dev


相同的环境



如果你想启动一个相同的环境,你可以引导一个集群,例如 production-clone 并重用 production 定义。

引导 production-clone 集群:


flux bootstrap github \
    --context=production-clone \
    --owner=${GITHUB_USER} \
    --repository=${GITHUB_REPO} \
    --branch=main \
    --personal \
    --path=clusters/production-clone


在本地拉取更改:


git pull origin main


clusters/production-clone 目录中创建一个 kustomization.yaml


apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
  - flux-system
  - ../production/infrastructure.yaml
  - ../production/apps.yaml


请注意,除了 flux-system kustomize overlay,我们还包括来自 production 目录的 infrastructureapps 清单。


将更改推送到主分支:


git add -A && git commit -m "add production clone" && git push


告诉 Flux 在 production-clone 集群上部署生产工作负载(production workloads):


flux reconcile kustomization flux-system \
    --context=production-clone \
    --with-source
相关实践学习
深入解析Docker容器化技术
Docker是一个开源的应用容器引擎,让开发者可以打包他们的应用以及依赖包到一个可移植的容器中,然后发布到任何流行的Linux机器上,也可以实现虚拟化,容器是完全使用沙箱机制,相互之间不会有任何接口。Docker是世界领先的软件容器平台。开发人员利用Docker可以消除协作编码时“在我的机器上可正常工作”的问题。运维人员利用Docker可以在隔离容器中并行运行和管理应用,获得更好的计算密度。企业利用Docker可以构建敏捷的软件交付管道,以更快的速度、更高的安全性和可靠的信誉为Linux和Windows Server应用发布新功能。 在本套课程中,我们将全面的讲解Docker技术栈,从环境安装到容器、镜像操作以及生产环境如何部署开发的微服务应用。本课程由黑马程序员提供。 &nbsp; &nbsp; 相关的阿里云产品:容器服务 ACK 容器服务 Kubernetes 版(简称 ACK)提供高性能可伸缩的容器应用管理能力,支持企业级容器化应用的全生命周期管理。整合阿里云虚拟化、存储、网络和安全能力,打造云端最佳容器化应用运行环境。 了解产品详情: https://www.aliyun.com/product/kubernetes
相关文章
|
Cloud Native 关系型数据库 分布式数据库
登顶TPC-C|云原生数据库PolarDB技术揭秘:Limitless集群和分布式扩展篇
阿里云PolarDB云原生数据库在TPC-C基准测试中以20.55亿tpmC的成绩刷新世界纪录,展现卓越性能与性价比。其轻量版满足国产化需求,兼具高性能与低成本,适用于多种场景,推动数据库技术革新与发展。
|
Cloud Native 关系型数据库 分布式数据库
登顶TPC-C|云原生数据库PolarDB技术揭秘:Limitless集群和分布式扩展篇
云原生数据库PolarDB技术揭秘:Limitless集群和分布式扩展篇
|
10月前
|
Cloud Native 关系型数据库 分布式数据库
客户说|知乎基于阿里云PolarDB,实现最大数据库集群云原生升级
近日,知乎最大的风控业务数据库集群,基于阿里云瑶池数据库完成了云原生技术架构的升级。此次升级不仅显著提升了系统的高可用性和性能上限,还大幅降低了底层资源成本。
|
运维 Cloud Native 开发工具
智能运维:云原生大规模集群GitOps实践
智能运维:云原生大规模集群GitOps实践,由阿里云运维专家钟炯恩分享。内容涵盖云原生运维挑战、管理实践、GitOps实践及智能运维体系。通过OAM模型和GitOps优化方案,解决大规模集群的发布效率与稳定性问题,推动智能运维工程演进。适用于云原生环境下的高效运维管理。
576 8
|
Kubernetes Cloud Native 云计算
云原生之旅:Kubernetes 集群的搭建与实践
【8月更文挑战第67天】在云原生技术日益成为IT行业焦点的今天,掌握Kubernetes已成为每个软件工程师必备的技能。本文将通过浅显易懂的语言和实际代码示例,引导你从零开始搭建一个Kubernetes集群,并探索其核心概念。无论你是初学者还是希望巩固知识的开发者,这篇文章都将为你打开一扇通往云原生世界的大门。
329 17
|
Kubernetes Cloud Native 流计算
Flink-12 Flink Java 3分钟上手 Kubernetes云原生下的Flink集群 Rancher Stateful Set yaml详细 扩容缩容部署 Docker容器编排
Flink-12 Flink Java 3分钟上手 Kubernetes云原生下的Flink集群 Rancher Stateful Set yaml详细 扩容缩容部署 Docker容器编排
471 3
|
Kubernetes Cloud Native Ubuntu
云原生之旅:Kubernetes集群搭建与应用部署
【8月更文挑战第65天】本文将带你进入云原生的世界,通过一步步指导如何在本地环境中搭建Kubernetes集群,并部署一个简单的应用。我们将使用Minikube和Docker作为工具,探索云原生技术的魅力所在。无论你是初学者还是有经验的开发者,这篇文章都将为你提供有价值的信息和实践技巧。
|
Kubernetes 监控 Cloud Native
Cluster Optimizer:一款云原生集群优化平台
**Cluster Optimizer** 是一款云原生集群优化平台,旨在通过自动化和智能化工具帮助企业降低云成本,解决云原生架构中的成本管理难题。面对资源闲置、配置不当和缺乏自动化优化机制等挑战,Cluster Optimizer能够深入分析云资源、应用和用户行为,精准识别优化机会,并给出具体建议,涵盖节点组、节点、GPU 节点、磁盘、持久卷和应用等多个维度。通过优化实例类型、自动扩缩容和资源分配,帮助企业降低成本、提升性能和效率。[点击此处](https://www.wiseinf.com.cn/docs/setup/) 免费安装和试用 **Cluster Optimizer 社区版**。
343 9
|
存储 Cloud Native 数据处理
从嵌入式状态管理到云原生架构:Apache Flink 的演进与下一代增量计算范式
本文整理自阿里云资深技术专家、Apache Flink PMC 成员梅源在 Flink Forward Asia 新加坡 2025上的分享,深入解析 Flink 状态管理系统的发展历程,从核心设计到 Flink 2.0 存算分离架构,并展望未来基于流批一体的通用增量计算方向。
563 0
从嵌入式状态管理到云原生架构:Apache Flink 的演进与下一代增量计算范式

热门文章

最新文章

下一篇
开通oss服务