Airflow Helm Chart为何采用StatefulSet部署Worker节点？

• 稳定标识与持久化适配：Airflow Worker在部分场景里需要固定的主机名——比如执行依赖节点身份的任务，或是配合特定的日志、监控工具时，StatefulSet能给每个Pod分配像worker-0、worker-1这种稳定的网络标识，不像Deployment的Pod名字是随机生成的。另外如果Worker需要挂载本地持久化存储来缓存任务依赖、临时大文件，StatefulSet可以绑定固定的PersistentVolumeClaim，避免Pod重建后丢失缓存内容。
• 有序启停与滚动更新：StatefulSet支持按顺序启动、终止Pod，给Airflow集群做Worker滚动更新时，能逐个替换实例，先启动新Worker确认健康后再停旧的，不会一次性下线大量Worker导致任务积压或集群负载骤增，保证任务执行的连续性。
• 适配Airflow集群的协同需求：官方Helm Chart的设计考虑了和Redis、PostgreSQL这类StatefulSet组件的协同一致性，同时Airflow的一些高级配置（比如CeleryExecutor下的Worker节点身份识别、任务分片策略）依赖稳定的Pod标识，StatefulSet的特性刚好能满足这些需求。
• 故障恢复更可控：当Worker Pod故障重启时，StatefulSet会调度出带有相同标识的Pod，配合绑定的固定PVC，能快速恢复之前的运行环境，减少长时间运行任务的中断影响。

内容的提问来源于stack exchange，提问作者Paweł Feliks