为什么 kube-airflow 用 StatefulSet 部署 Worker日志服务架构揭秘【免费下载链接】kube-airflowA docker image and kubernetes config files to run Airflow on Kubernetes项目地址: https://gitcode.com/gh_mirrors/ku/kube-airflow在 Kubernetes 上部署 Airflow 时大多数组件Web、Scheduler都用 Deployment 这种无状态工作负载唯独 Worker 是例外。kube-airflow项目用StatefulSet来部署 Celery Worker背后只有一个核心原因让每个 Worker 都能稳定地提供日志服务。这篇文章为你揭秘 kube-airflow 的日志服务架构设计以及 StatefulSet 在其中扮演的关键角色。kube-airflow 是什么先认识 Worker 的角色kube-airflow 是一套把 Apache Airflow 跑在 Kubernetes 集群上的 Docker 镜像与配置方案。它把 Airflow 拆成了几个各司其职的组件Web ServerDeployment提供操作界面SchedulerDeployment负责任务调度WorkerStatefulSet用 Celery 实际执行任务FlowerDeploymentCelery 监控面板你可能会好奇既然 Web 和 Scheduler 都用 Deployment为什么偏偏 Worker 要特立独行答案藏在日志里。问题根源Airflow 的任务日志存在哪里Airflow 的任务执行日志默认存在执行任务的 Worker 本地文件系统上而不是集中存到数据库或对象存储里。当你在 Web 界面点击查看日志时Web Server 需要实时去对应的 Worker 上读取日志文件。为此Airflow 在每个 Worker 启动时都会同时拉起一个迷你日志服务器mini log server专门把本机的任务日志通过 HTTP 提供给 Web Server。这个端口就是配置在 config/airflow.cfg 里的worker_log_server_port 8793。于是问题来了Web Server 怎么知道日志在哪个 Pod 上为什么 Deployment 无法胜任Pod 名字随机带来的麻烦如果 Worker 用 Deployment 部署Kubernetes 会生成类似worker-7f9b8c4d5e-abc12这种随机且每次重建都会变化的 Pod 名称。这意味着任务执行到一半Worker Pod 被重建日志服务器地址就变了Web Server 无法根据任务记录准确回访当初执行它的那个 Worker想在日志里定位 Pod简直像在玩捉迷藏日志服务架构需要的是确定性每个 Worker 有唯一、稳定、可预测的身份。StatefulSet Headless Service给每个 Worker 固定门牌号这正是 kube-airflow 采用StatefulSet的原因。在 statefulsets-workers.yaml 顶部作者用一行注释直白地说明了设计意图Workers are not in deployment, but in StatefulSet, to allow each worker expose a mini-server that only serve logs, that will be used by the web server.StatefulSet 的核心能力是Pod 名称是有序且固定的worker-0、worker-1、worker-2…重建后依然沿用原名字身份不会漂移。为了让这些固定名字能被 Web Server 解析kube-airflow 还在 services.yaml 里配套创建了一个Headless ServiceclusterIP: None。Headless Service 不做负载均衡只负责为每个 StatefulSet 成员生成稳定的 DNS 记录worker-0.airflow-worker.svc.cluster.localworker-1.airflow-worker.svc.cluster.local这样Web Server 就能通过稳定 DNS 精确访问到执行过某任务的 Worker在其 8793 端口上拉取日志。整个日志服务架构可以简化为下图用户浏览器 │ ▼ Airflow Web Server ──通过稳定 DNS 访问──► worker-0.airflow-worker:8793 worker-1.airflow-worker:8793 worker-2.airflow-worker:8793 │ ▼ Worker 本地日志文件配置里还藏了哪些细节除了日志服务statefulsets-workers.yaml 还有两个值得一提的设计端口声明containerPort: 8793名为wlog让日志服务器的端口对集群内其他组件可见podManagementPolicy: ParallelStatefulSet 默认是串行创建 Pod一个就绪才启动下一个Parallel 策略允许并行创建和销毁所有 Pod让 Worker 扩容速度大幅提升更适合 Worker 这种无启动顺序依赖的场景Worker 的数量则由 values.yaml 中的celery.num_workers控制你随时可以通过修改这个值来水平扩展 Worker。总结StatefulSet 是日志服务架构的基石回到开篇的问题为什么 kube-airflow 用 StatefulSet 部署 Worker因为 Airflow 的日志天然分布在各个 Worker 本地Web Server 必须能稳定回访每个 Worker。StatefulSet 提供了固定 Pod 身份Headless Service 提供了稳定 DNS二者配合才让按 Worker 逐台读取日志的架构变得可靠、可预测。对新手来说这个设计也提供了一个很好的启发当你的工作负载需要稳定的网络身份而不只是存储时就该考虑 StatefulSet 了。下次在 Kubernetes 上部署 Airflow 时看到 Worker 用的是 StatefulSet你就知道这背后藏着一段关于日志服务架构的精妙设计。如果你想自己动手体验可以 clone 仓库后通过make helm-install一键部署然后在 Web 界面上随便跑一个任务再点击查看日志就会明白这一切设计的价值所在。【免费下载链接】kube-airflowA docker image and kubernetes config files to run Airflow on Kubernetes项目地址: https://gitcode.com/gh_mirrors/ku/kube-airflow创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
函数为每条日志附加上下文信息)
