本指南介绍如何使用 Helm 在 Azure Kubernetes 服务（AKS）上部署 Apache Airflow。 了解如何设置 AKS 群集、安装 Helm、使用 Helm 图表部署 Airflow 以及浏览 Airflow UI。 本文简要概述了在 AKS 上部署生产就绪 Airflow 所涉及的体系结构和组件。
重要
整个 AKS 文档和示例都提到了开源软件。 部署的软件从 AKS 服务级别协议、有限保修和 Azure 支持中排除。 与 AKS 一起使用开源技术时，请查阅各社区和项目维护人员提供的支持选项，以制定计划。
例如， Ray GitHub 存储库 描述了响应时间、用途和支持级别变化的多个平台。
Microsoft负责生成我们在 AKS 上部署的开源包。 该责任包括拥有构建、扫描、签名、验证和快速修复流程的完整所有权，并掌控容器镜像中的二进制文件。 有关详细信息，请参阅 AKS 的漏洞管理 和 AKS 支持范围。
什么是 Apache Airflow？
Apache Airflow 是一个开源平台，专为开发、计划和监视面向批处理的工作流而构建。 借助其灵活的 Python 框架，Airflow 允许设计与几乎所有技术无缝集成的工作流。 在 Airflow 中，必须定义由定向无环图（DAG）表示的 Python 工作流。 可以在任意位置部署 Airflow，部署后，可以访问 Airflow UI 并设置工作流。
Airflow 体系结构
在高级别上，Airflow 包括：
- 跟踪 DAG、任务实例、XComs 等状态的元数据数据库。
- 提供 Airflow UI 的 Web 服务器，用于监视和管理。
- 负责触发 DAG 和任务实例的计划程序。
- 处理任务实例的执行器。
- 执行任务的员工。
- 命令行接口（CLI）等其他组件。
用于生产的 Airflow 分布式体系结构
Airflow 的模块化分布式体系结构为生产工作负荷提供了几个关键优势：
- 关注点分离：每个组件具有不同的角色，使系统保持简单且可维护。 调度器管理 DAG 和任务调度，而工作者执行任务，确保每个部分都专注于其特定功能。
- 可伸缩性：随着工作负荷的增长，体系结构允许轻松缩放。 可以同时运行多个计划程序或工作进程，并利用托管数据库实现自动扩展，以满足增加的需求。
- 可靠性：由于组件已分离，因此单个计划程序或辅助角色的故障不会导致系统范围的中断。 集中式元数据数据库可确保整个系统的一致性和连续性。
- 扩展性：体系结构很灵活，允许执行程序或排队服务等组件根据需要交换和自定义。
此设计为管理复杂数据管道提供了坚实的基础，以支持扩展性、可靠性和灵活性。
Airflow 执行器
在使 Airflow 生产就绪时，一个非常重要的设计决策是选择正确的执行程序。 当任务准备好运行时，执行程序负责管理其执行。 执行程序与执行任务的工作线程池进行交互。 最常用的执行程序包括：
- LocalExecutor：在主机系统上并行运行任务实例。 此执行程序非常适合用于测试，但为较大的工作负荷提供有限的可伸缩性。
- CeleryExecutor：使用 Celery 池在多台机器上分配任务，通过在不同节点上运行工作节点来实现水平可伸缩性。
- KubernetesExecutor：针对 Kubernetes 中的 Airflow 部署量身定制，此执行程序会在 Kubernetes 群集中动态启动工作 Pod。 它提供出色的可伸缩性，并确保强大的资源隔离。
当我们将 Airflow 过渡到生产环境时，扩展工作节点变得至关重要，因此 KubernetesExecutor 最适合我们的需求。 但是，对于本地测试，LocalExecutor 是最简单的选项。
后续步骤
供稿人
Microsoft维护本文。 以下贡献者最初撰写了这篇文章：
- Don High | 首席客户工程师
- Satya Chandragiri |高级数字云解决方案架构师
- Erin Schaffer | 内容开发人员 2