Using additional containers¶

Sidecar Containers¶

If you want to deploy your own sidecar container, you can add it through the extraContainers parameter. You can define different containers for the scheduler, api-server, Kubernetes/Celery workers, triggerer, dag processor, flower, PgBouncer, create user job and migrate database job pods.

For example, sidecars that sync Dags from object storage:

values.yaml¶

scheduler:
  extraContainers:
    - name: s3-sync
      image: my-company/s3-sync:latest
      imagePullPolicy: Always

workers:
  kubernetes:
    extraContainers:
      - name: s3-sync
        image: my-company/s3-sync:latest
        imagePullPolicy: Always

Note

If you use workers.kubernetes.extraContainers (dedicated for KubernetesExecutor), you are responsible for signaling sidecars to exit when the main container finishes so Airflow can continue the worker shutdown process.

Init Containers¶

You can also deploy extra init containers through the extraInitContainers parameter. You can define different containers for the scheduler, api-server, Celery/Kubernetes workers, triggerer, dag processor, PgBouncer, create user job and migrate database job pods.

For example, pgbouncer.extraInitContainers can run a user-provided credential refresher for Azure Database for PostgreSQL authentication with short-lived Microsoft Entra ID tokens. The credentials must be obtained before PgBouncer starts and refreshed while it runs. On clusters supporting native Kubernetes sidecars, use restartPolicy: Always and a startupProbe that succeeds only after the initial credentials are ready. This lets the refresher continue running while PgBouncer starts after successful initialization.

For example, an init container that just says hello:

values.yaml¶

scheduler:
  extraInitContainers:
    - name: hello
      image: debian
      args:
        - echo
        - hello