Airflow不提供任务级Python环境隔离，所有task默认共享worker进程的Python环境，导致依赖冲突；推荐使用KubernetesExecutor+KubernetesPodOperator为每个任务定义独立Pod和专用镜像，实现代码、依赖与OS层的原子化隔离。
不能靠全局 Python 环境统一管理不同 DAG 的依赖 —— 这是生产环境出问题的头号诱因。 Airflow 本身不提供任务级 Python 环境隔离，所有 task 默认共享 scheduler/worker 进程的 Python 环境。一旦两个 DAG 分别依赖 requests==2.28.1 和 requests==2.31.0，冲突就无法避免。
为什么用 virtualenv 或 conda 直接跑 task 会失败
Airflow 的 task 执行本质是：scheduler 把 task 实例序列化后发给 executor（Celery/Kubernetes），executor 启动子进程调用 PythonOperator.execute() 或执行 bash_command。如果你在 bash_command 里手动激活 virtualenv，常见问题包括：
- 路径硬编码导致跨 worker 失效（
/home/user/venv在 worker A 存在，worker B 没有） - virtualenv 激活脚本（
source venv/bin/activate）在非交互式 shell 下不生效，which python仍返回系统 Python - conda init 修改 shell 配置，但 Airflow 启动的子进程不加载
~/.bashrc - 权限问题：worker 用户无权写入 shared venv 目录，或无法执行
pip install
推荐方案：用 KubernetesExecutor + Pod 定义隔离 Python 环境
这是目前最可控、可复现、符合云原生实践的方式。核心是让每个 task 在独立 Pod 中运行，通过 pod_override 指定镜像和依赖：
- 为每个 DAG（或任务组）构建专用镜像，基础镜像用
apache/airflow:2.9.2，再RUN pip install -r requirements-dag-a.txt - 在 task 定义中使用
KubernetesPodOperator，显式指定image="my-registry/dag-a:202610" - 避免用
PythonOperator+python_callable，改用KubernetesPodOperator执行封装好的 Python 脚本（如python /opt/airflow/scripts/run_etl.py） - 如果必须用
PythonOperator，可通过task.docker_image（Airflow 2.7+）配合DockerOperator替代，但注意 Docker-in-Docker 开销
示例关键片段：
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
立即学习“Python免费学习笔记（深入）”；
from airflow.providers.cncf.kubernetes.operators.kubernetes_pod import KubernetesPodOperator
etl_task = KubernetesPodOperator(
task_id="run_etl",
image="my-registry/etl-pipeline:1.4",
cmds=["python"],
arguments=["/opt/airflow/scripts/main.py"],
namespace="airflow-workers",
name="etl-pod",
get_logs=True,
is_delete_operator_pod=True,
)
替代方案：用 Poetry 或 PDM 管理多环境，配合 task-level 安装
适用于 CeleryExecutor 或 LocalExecutor 场景，但仅限低并发、非关键 DAG：
- 在 DAG 文件开头用
subprocess.run(["poetry", "install"], cwd="/path/to/dag/env")预装依赖（需确保所有 worker 共享该路径且有写权限） - 更稳妥的做法：把依赖打包成 wheel，上传到私有 PyPI（如 Nexus），在 task 中用
pip install --index-url https://nexus.example.com/repository/pypi/simple/ my-dag-a==1.2.0 - 绝对不要在
python_callable内部做pip install—— 多次重试会导致重复安装、版本漂移、锁文件冲突 - 用
sys.path.insert(0, "/path/to/vendor")加载本地包是临时解法，但无法解决 C 扩展（如numpy）ABI 不兼容问题
真正麻烦的不是“怎么装”，而是“谁来保证每次 task 运行时环境完全一致”。Kubernetes Pod 是目前唯一能原子化交付“代码 + 依赖 + OS 层”的方式。其他方案都绕不开 worker 环境的不确定性 —— 尤其当集群节点由不同团队维护、或混用 spot 实例时，连 pip list 输出都可能不一致。
