我正在使用气流稳定舵图并使用 Kubernetes Executor，正在为 dag 安排新的 pod，但找不到 dag_id 失败的问题。我正在使用 git-sync 来获取 dag。下面是错误和 kubernetes 配置值。有人可以帮我解决这个问题吗？
错误：
[2020-07-01 23:18:36,939] {__init__.py:51} INFO - Using executor LocalExecutor
[2020-07-01 23:18:36,940] {dagbag.py:396} INFO - Filling up the DagBag from /opt/airflow/dags/dags/etl/sampledag_dag.py
Traceback (most recent call last):
File "/home/airflow/.local/bin/airflow", line 37, in <module>
args.func(args)
File "/home/airflow/.local/lib/python3.6/site-packages/airflow/utils/cli.py", line 75, in wrapper
return f(*args, **kwargs)
File "/home/airflow/.local/lib/python3.6/site-packages/airflow/bin/cli.py", line 523, in run
dag = get_dag(args)
File "/home/airflow/.local/lib/python3.6/site-packages/airflow/bin/cli.py", line 149, in get_dag
'parse.'.format(args.dag_id))
airflow.exceptions.AirflowException: dag_id could not be found: sampledag . Either the …所以，我正在 EKS 上设置 Airflow。
一切似乎都已就位，只是我无法使用 KubernetesExecutor。每次我尝试使用它时，都会收到此错误：
with open(TEST_CONFIG_FILE, 'w') as f: PermissionError: [Errno 13] 权限被拒绝: '/usr/local/airflow/unittests.cfg'
我曾尝试进入该吊舱chmod和chown文件。我在 docker 映像中尝试了相同的操作，并且还尝试创建unitttests.cfg文件，并将其从本地复制到映像。它们都返回相同的错误。
Docker镜像：
FROM python:3.7.6-slim
ARG AIRFLOW_USER_HOME=/var/lib/airflow
ENV AIRFLOW_HOME=$AIRFLOW_USER_HOME
# Define en_US.
ENV LANGUAGE en_US.UTF-8
ENV LANG en_US.UTF-8
ENV LC_ALL en_US.UTF-8
ENV LC_CTYPE en_US.UTF-8
ENV LC_MESSAGES en_US.UTF-8
RUN mkdir $AIRFLOW_USER_HOME && \
useradd -ms /bin/bash -d ${AIRFLOW_USER_HOME} airflow && \
buildDeps='freetds-dev libkrb5-dev libsasl2-dev libssl-dev libffi-dev libpq-dev' \
apt-get update && \
apt-get install -yqq --no-install-recommends $buildDeps build-essential …我正在评估将当前的 Airflow 部署从 Celery 执行器迁移到 Kubernetes (K8s) 执行器，以利用资源的动态分配和 Pod 提供的任务隔离。
我很清楚，我们可以使用原生 KubernetesPodOperator 通过 K8s 执行器在 K8s 集群上运行任务。但是我找不到有关 K8s 执行器与其他运算符（例如 bash 和 athena）之间兼容性的信息。
这里的问题是，是否可以在 K8s 支持的 Airflow 上运行 bash（或任何其他）操作符，或者我应该将所有任务迁移到 KubernetesPodOperator？
谢谢！
我们正在使用 Gitlab Runner 和 Kubernetes 执行器，我们正在思考我认为目前不可能的事情。我们希望将 Gitlab Runner 守护进程的 pod 分配给实例类型为 X 的特定节点组的工作线程，并将作业的 pod 分配给不同节点组 Y 工作节点，因为这些节点通常比 Gitlab Runner 的 pod 需要更多的计算资源。
这样做是为了节省成本，因为 Gitlab 运行程序主守护进程将始终运行在节点上，然后我们希望它在便宜的实例上运行，然后需要更多计算能力的作业可以在不同的实例上运行具有不同的类型，将由 Cluster Autoscaler 启动，并在不存在作业时销毁。
我对此功能进行了调查，将 pod 分配到特定节点的可用方法是使用节点选择器或节点亲和性，但这两个配置部分中包含的规则适用于 Gitlab Runner 的所有 pod，主 Pod 和工作 Pod。该提案旨在使应用两种单独的配置成为可能，一种用于 Gitlab Runner 的 Pod，另一种用于作业的 Pod。
当前的现有配置由节点选择器和节点/pod 亲和力组成，但正如我提到的，这些配置全局适用于所有 pod，而不是我们在本例中想要的指定的 pod。
Gitlab Runner Kubernetes 执行器配置：https://docs.gitlab.com/runner/executors/kubernetes.html