如何系统性模拟K8s托管Airflow应用的节点故障并追踪影响

一、核心组件故障模拟 #

• Webserver/Scheduler副本故障：直接通过kubectl delete pod <airflow-webserver-pod-name>删除单个副本，或用kubectl scale deployment airflow-webserver --replicas=0临时将副本数缩为0再恢复，验证剩余副本是否自动接管服务、UI是否正常访问、任务调度是否无中断。
• Metadata数据库故障：若数据库以K8s Pod部署，可删除数据库Pod或用NetworkPolicy临时阻断Airflow组件与数据库的网络连接，观察Airflow的重试机制是否生效、任务队列是否积压，数据库恢复后是否自动续跑未完成任务。

二、Pod级故障模拟 #

• 随机Pod驱逐与销毁：用kubectl drain <node-name> --ignore-daemonsets驱逐节点上的Airflow Pod（需提前确认节点无其他关键服务），或借助混沌工程工具（如Chaos Mesh）定义Pod Kill实验，随机销毁Airflow Worker/Scheduler Pod，验证K8s的自动重建机制、服务连续性是否符合预期。
• 资源耗尽模拟：在运行中的Airflow Worker Pod内执行stress --cpu 4 --timeout 60s（或内存压测命令），触发OOMKilled，观察Worker是否自动重启、未完成任务是否被调度至其他Worker节点。

三、DAG任务级故障模拟 #

• 任务Pod强制终止：定位正在运行的DAG任务Pod，执行kubectl delete pod <task-pod-name> --grace-period=0模拟强制中断，验证Airflow是否按retries配置重新调度任务、任务状态是否正确更新为重试/失败。
• 任务依赖故障注入：临时关闭DAG依赖的数据源服务，或修改任务脚本使其返回非0状态码，测试DAG的失败处理逻辑、分支跳转是否符合预期，是否触发预设的告警机制。

四、影响追踪与验证方法 #

• 实时指标监控：通过Prometheus+Grafana监控Airflow核心指标（如scheduler_heartbeat、task_instance_state、pod_restarts）及K8s节点/Pod状态，故障发生时追踪指标波动，确认服务恢复时长。
• 日志分析：通过kubectl logs <pod-name>提取Airflow组件及任务日志，排查故障发生时的错误信息、重试记录，验证容错逻辑是否生效。
• 业务结果验证：检查故障期间及恢复后的DAG任务完成率、数据产出完整性，确认是否存在数据丢失或重复处理的情况。

五、测试注意事项 #

• 优先在测试集群完成全流程验证，避免直接操作生产环境。
• 若需生产环境轻量测试，选择非核心DAG或低流量时段，逐步扩大测试范围。
• 提前准备回滚预案，如快速恢复副本、重启组件，确保测试后能快速恢复正常业务。

内容的提问来源于stack exchange，提问作者supercheese214