企业官网建设流程全解析

User-Community Airflow Helm Chart升级与迁移指南：平滑过渡到新版本的5个技巧

【免费下载链接】chartsThe User-Community Airflow Helm Chart is the standard way to deploy Apache Airflow on Kubernetes with Helm. Originally created in 2017, it has since helped thousands of companies create production-ready deployments of Airflow on Kubernetes.项目地址: https://gitcode.com/gh_mirrors/charts27/charts

User-Community Airflow Helm Chart是在Kubernetes上使用Helm部署Apache Airflow的标准方式。自2017年创建以来，它已帮助数千家公司在Kubernetes上创建生产就绪的Airflow部署。本文将分享5个实用技巧，助您轻松完成Airflow Helm Chart的升级与迁移，确保系统平稳过渡到新版本。

技巧一：全面了解版本变更，做好升级前准备

在进行升级前，全面了解版本之间的变更信息是确保升级顺利的关键步骤。每个版本的更新可能包含功能改进、bug修复、配置变更甚至不兼容的调整，因此务必仔细阅读官方发布的变更日志。

您可以在项目的根目录下找到CHANGELOG.md文件，其中详细记录了每个版本的新增功能、修改内容、已知问题和重要注意事项。例如，在8.7.0版本中，对pgbouncer.image.tag有明确要求，必须更新到1.18.0-patch.1或更高版本，否则可能导致证书生成失败。同时，该版本还对postgresql.image.registry的默认值进行了修改，从docker.io变更为ghcr.io，如果您使用了自定义的postgresql.image，需要特别注意这一变化。

除了查看CHANGELOG，还应参考官方提供的升级指南upgrade.md，该指南详细说明了升级的适用场景和基本流程，为您的升级操作提供全面指导。

技巧二：精准执行升级命令，确保版本正确

升级操作的核心在于正确执行Helm命令，确保指定正确的版本号并应用自定义配置。错误的命令可能导致版本不匹配或配置丢失，从而引发系统故障。

首先，更新Helm仓库以获取最新的Chart信息：

helm repo update

然后，设置发布名称和命名空间（必须与之前安装时使用的名称一致）：

export AIRFLOW_NAME="airflow-cluster" export AIRFLOW_NAMESPACE="airflow-cluster"

最后，执行升级命令，指定要升级到的版本号和自定义配置文件：

helm upgrade \ "$AIRFLOW_NAME" \ airflow-stable/airflow \ --namespace "$AIRFLOW_NAMESPACE" \ --version "8.X.X" \ --values ./custom-values.yaml

⚠️警告⚠️

务必使用--version参数固定版本号，避免意外更新到非预期的Chart版本！在升级前，一定要查阅CHANGELOG.md，了解目标版本的具体变更和潜在影响。

技巧三：关注关键配置变更，避免兼容性问题

不同版本的Chart可能会引入配置项的新增、修改或删除，这些变更可能直接影响系统的兼容性和功能可用性。在升级过程中，需要特别关注这些关键配置的变化。

例如，在8.7.0版本中，如果您使用"Azure File"进行日志持久化，那么不能升级到Airflow 2.5.1、2.5.2或2.5.3版本，因为这些版本存在一个已知问题。

另外，当升级到Airflow 2.5及以上版本时，建议将Kubernetes配置中的AIRFLOW__KUBERNETES__*重命名为AIRFLOW__KUBERNETES_EXECUTOR__*，因为前者在Airflow 2.5中已被弃用。这些配置变更信息都可以在CHANGELOG.md中找到，升级前务必仔细阅读。

技巧四：妥善处理数据迁移，保障数据安全

数据迁移是升级过程中的重要环节，尤其是对于数据库和持久化存储的数据，必须确保其完整性和一致性，避免数据丢失或损坏。

如果您使用了内置的PostgreSQL数据库，在升级Chart版本时，需要注意数据库版本的兼容性。例如，在8.7.0版本中，默认的嵌入式PostgreSQL镜像更新为ghcr.io/airflow-helm/postgresql-bitnami:11.16-patch.0，这是一个支持ARM64架构的自定义镜像。如果您之前使用的是其他版本的PostgreSQL，需要确认数据是否能够顺利迁移到新的镜像版本。

对于使用外部数据库的情况，要确保数据库连接参数正确配置，并且数据库版本与新的Chart版本兼容。您可以参考external-database.md文档，了解外部数据库的配置方法和注意事项。

此外，如果启用了logs.persistence.enabled，在升级前需要禁用scheduler.logCleanup.enabled和workers.logCleanup.enabled，否则升级可能会失败。这是因为日志清理功能可能会在升级过程中干扰日志数据的迁移。

技巧五：升级后验证与监控，确保系统稳定运行

升级完成后，不能立即认为整个过程已经成功，还需要进行全面的验证和持续的监控，以确保系统能够稳定运行。

首先，检查所有Pod的状态，确保它们都正常启动并运行：

kubectl get pods -n "$AIRFLOW_NAMESPACE"

然后，访问Airflow Web UI，确认界面能够正常加载，并且所有DAGs都处于预期状态。您可以通过Ingress或NodePort服务访问Web UI，具体配置可参考ingress.md文档。

同时，启用监控功能可以帮助您及时发现和解决潜在问题。例如，您可以配置Prometheus监控Airflow的各项指标，具体方法可参考prometheus.md文档。通过监控，您可以密切关注系统的性能、任务执行情况和资源使用情况，确保升级后的系统能够满足业务需求。

另外，建议在升级后的一段时间内，密切关注系统日志，特别是调度器、工作节点和数据库的日志，以便及时发现并处理可能出现的异常情况。您可以使用kubectl logs命令查看各个Pod的日志：

kubectl logs -n "$AIRFLOW_NAMESPACE" <pod-name>

通过以上五个技巧，您可以更加顺利地完成User-Community Airflow Helm Chart的升级与迁移工作。记住，在升级过程中，充分的准备、仔细的操作和全面的验证是确保系统平稳过渡的关键。如果在升级过程中遇到问题，您可以查阅项目的官方文档或寻求社区支持，获取更多的帮助和指导。

【免费下载链接】chartsThe User-Community Airflow Helm Chart is the standard way to deploy Apache Airflow on Kubernetes with Helm. Originally created in 2017, it has since helped thousands of companies create production-ready deployments of Airflow on Kubernetes.项目地址: https://gitcode.com/gh_mirrors/charts27/charts