Skip to content

Commit

Permalink
Enhanced the Kubernetes Executor doc (apache#10433)
Browse files Browse the repository at this point in the history
A simple architecture diagram to show the Airflow setup when used with the Kubernetes executor
  • Loading branch information
vikramkoka authored Aug 26, 2020
1 parent 1e5aa44 commit 46ac09d
Show file tree
Hide file tree
Showing 3 changed files with 13 additions and 3 deletions.
16 changes: 13 additions & 3 deletions docs/executor/kubernetes.rst
Original file line number Diff line number Diff line change
Expand Up @@ -44,15 +44,25 @@ KubernetesExecutor Architecture
The KubernetesExecutor runs as a process in the Scheduler that only requires access to the Kubernetes API (it does *not* need to run inside of a Kubernetes cluster). The KubernetesExecutor requires a non-sqlite database in the backend, but there are no external brokers or persistent workers needed.
For these reasons, we recommend the KubernetesExecutor for deployments have long periods of dormancy between DAG execution.

When a DAG submits a task, the KubernetesExecutor requests a worker pod from the Kubernetes API. The worker pod then runs the task, reports the result, and terminates.

.. image:: ../img/k8s-0-worker.jpeg

.. image:: ../img/arch-diag-kubernetes.png

When a DAG submits a task, the KubernetesExecutor requests a worker pod from the Kubernetes API. The worker pod then runs the task, reports the result, and terminates.

In contrast to the Celery Executor, the Kubernetes Executor does not require additional components such as Redis and Flower, but does require the Kubernetes infrastructure.

One example of an Airflow deployment running on a distributed set of five nodes in a Kubernetes cluster is shown below.

.. image:: ../img/arch-diag-kubernetes2.png

The Kubernetes Executor has an advantage over the Celery Executor in that Pods are only spun up when required for task execution compared to the Celery Executor where the workers are statically configured and are running all the time, regardless of workloads. However, this could be a disadvantage depending on the latency needs, since a task takes longer to start using the Kubernetes Executor, since it now includes the Pod startup time.

Consistent with the regular Airflow architecture, the Workers need access to the DAG files to execute the tasks within those DAGs and interact with the Metadata repository. Also, configuration information specific to the Kubernetes Executor, such as the worker namespace and image information, needs to be specified in the Airflow Configuration file.

Additionally, the Kubernetes Executor enables specification of additional features on a per-task basis using the Executor config.


.. image:: ../img/k8s-3-worker.jpeg

.. @startuml
.. Airflow_Scheduler -> Kubernetes: Request a new pod with command "airflow run..."
Expand Down
Binary file added docs/img/arch-diag-kubernetes.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file added docs/img/arch-diag-kubernetes2.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.

0 comments on commit 46ac09d

Please sign in to comment.