This is an automated email from the ASF dual-hosted git repository.
kaxilnaik pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/airflow.git
The following commit(s) were added to refs/heads/master by this push:
new 46ac09d Enhanced the Kubernetes Executor doc (#10433)
46ac09d is described below
commit 46ac09d5c9b9f6e36cce0a1d3812f483ed7201eb
Author: Vikram Koka <[email protected]>
AuthorDate: Wed Aug 26 10:42:35 2020 -0700
Enhanced the Kubernetes Executor doc (#10433)
A simple architecture diagram to show the Airflow setup when used with the
Kubernetes executor
---
docs/executor/kubernetes.rst | 16 +++++++++++++---
docs/img/arch-diag-kubernetes.png | Bin 0 -> 21804 bytes
docs/img/arch-diag-kubernetes2.png | Bin 0 -> 86384 bytes
3 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/docs/executor/kubernetes.rst b/docs/executor/kubernetes.rst
index 3c64c16..d3664b9 100644
--- a/docs/executor/kubernetes.rst
+++ b/docs/executor/kubernetes.rst
@@ -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..."
diff --git a/docs/img/arch-diag-kubernetes.png
b/docs/img/arch-diag-kubernetes.png
new file mode 100644
index 0000000..1bbbc98
Binary files /dev/null and b/docs/img/arch-diag-kubernetes.png differ
diff --git a/docs/img/arch-diag-kubernetes2.png
b/docs/img/arch-diag-kubernetes2.png
new file mode 100644
index 0000000..acaaf43
Binary files /dev/null and b/docs/img/arch-diag-kubernetes2.png differ
