1. Can you use CeleryExecutor on Kubernetes?

Yes, you can. It’s supported and works fine in k8s. You’ll just need:

• A Redis/RabbitMQ broker
• A result backend (like Postgres)
• Workers running as separate pods (as managed by the Helm chart)

But most people go with the KubernetesExecutor with KubernetesPodOperator instead, because they:

• Scale tasks as isolated pods
• Fit Kubernetes better
• Avoid the complexity of managing celery queues, concurrency, etc.

2. Should you avoid DockerOperator in Kubernetes?

Yes, generally.

Why?

• DockerOperator runs Docker containers inside a pod.
• That means the pod must be able to run Docker-in-Docker, or the host must expose the Docker socket (e.g., /var/run/docker.sock), which is:
  • Messy
  • A security risk
  • Not cloud-native

Alternatives: Use KubernetesPodOperator instead. It:

• Spins up new pods to run containerized tasks
• Works naturally with Kubernetes
• Doesn’t require Docker socket access

3. Does this mean you shouldn’t use CeleryExecutor?

Not necessarily. You can continue using it, but you might consider migrating to:

• KubernetesExecutor (simple, scalable, each task = pod)
• CeleryKubernetesExecutor (hybrid, runs most tasks on celery, dynamic ones in pods)

It depends on your workloads. If you’re already comfortable with Celery, and need specific control over parallelism, queues, or workers—keep it.

Read more about KubernetesPodOperator.