kaxil commented on a change in pull request #10433:
URL: https://github.com/apache/airflow/pull/10433#discussion_r477424565
##########
File path: 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 ran 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.
Review comment:
```suggestion
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.
```
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
