@kapa.ai I see no logs in my Airbyte set up on Kubernetes and the connection pods (data plane) aren't starting, even though the schema set-up pods are running. How can I troubleshoot?

This is a known issue that can have a few different root causes. Here's how to troubleshoot: 1. Check the Dataplane Group Configuration A common cause of connection/sync pods not launching (while other pods like discovery run fine) is a misconfigured

dataplaneGroups

setting. After upgrading from Airbyte v1 to v2, the default dataplane group name changed, which can cause workloads to never be claimed. Fix: Add the following to your Helm values before upgrading or redeploying:

global:
  dataplaneGroups:
    defaultDataplaneGroupName: "default"

If you're on an older version,

"AUTO"

may be the correct value instead of

"default"

. [airbyte services stuck] Alternatively, you can update the

dataplane_group_id

directly in the

public.workspace

table in your database to match an enabled entry in

public.dataplane_group

. [airbyte services stuck] 2. Verify Pods Are Actually Starting Run the following to watch pod activity in real time:

watch kubectl get po
# or
kubectl get po -w

When a sync is triggered, you should see replication job pods (e.g.,

replication-job-*

) progress through

Pending → Init → PodInitializing → Running → Completed

. If no pods appear at all, the workload is not being claimed by the data plane. [verify data plane] 3. Check the Workload Launcher Logs The Workload Launcher is the component responsible for polling the control plane and launching pods. Check its logs for errors related to pod creation or Kubernetes API interactions. Since it's a single pod handling all jobs, search its logs for the specific job ID you're investigating. [log collection] 4. Check the Cron/Monitor Logs Look at the

airbyte-cron

pod logs. If workloads are being created but not claimed, the cron job will log messages like "Checking for not claimed workloads" repeatedly without resolution. [Temporal context deadline] 5. Verify Log Collection Setup For sync pods specifically, note that: • The

source

and

destination

containers have empty stdout (used for Airbyte protocol messages). • The

orchestrator

container is where human-readable logs are aggregated for sync pods. • For check/discover/spec pods, the

sidecar

container has the relevant output. [container reference] To manually verify logs from a running workload pod:

# Find workload pods
kubectl get pods -l airbyte=job-pod --all-namespaces

# Check orchestrator logs for a sync pod
kubectl logs <pod-name> -c orchestrator -n <namespace>

[verifying log collection] 6. Check for Storage/Volume Issues If you're using MinIO for log storage and it's in a

Pending

state (e.g., waiting for a PVC to be provisioned), logs won't be available. Ensure your storage volumes are properly provisioned. [EKS deploy issue] Summary: The most likely cause of sync pods not starting while discovery pods work is the

dataplaneGroups

misconfiguration introduced in the v1→v2 upgrade. Start there, then work through the pod and log checks above. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.