<@U04S8PLJWMT> ```2026-05-21 09:39:59 platform ERR...
# replication-ask-ai
q
@kapa.ai
Copy code
2026-05-21 09:39:59 platform ERROR Stage Pipeline Exception: io.airbyte.workload.launcher.pipeline.stages.model.StageError: java.lang.RuntimeException: Init container for Pod: pods did not complete successfully. Actual termination reason: Error.
message: java.lang.RuntimeException: Init container for Pod: pods did not complete successfully. Actual termination reason: Error.
stackTrace: [Ljava.lang.StackTraceElement;@73a2293d
2026-05-21 09:39:59 platform INFO Attempting to update workload: c91ed852-24f7-4991-9545-91c2428c1f90_246419_0_sync to FAILED.
2026-05-21 09:39:59 platform INFO Pipeline aborted after error for workload: c91ed852-24f7-4991-9545-91c2428c1f90_246419_0_sync.
k
The error you're seeing indicates that the init container (
workload-init-container
) in the pod spawned by the
workload-launcher
failed with a non-zero exit code, causing the entire workload pipeline to abort. This is a known issue pattern in Airbyte on Kubernetes. Here's what's happening and what to investigate: What's Happening The
workload-launcher
spawns a pod with multiple containers (init container + source/destination/sidecar containers). The init container must complete successfully before the main containers start. When it fails, the launcher throws:
Copy code
java.lang.RuntimeException: Init container for Pod: pods did not complete successfully. Actual termination reason: Error
...and marks the workload as
FAILED
. [Github Issue 48809] Common Causes 1. Init container crash – The
workload-init-container
image itself exits with code 1. This can happen due to misconfiguration, missing environment variables, or connectivity issues. [Github Issue 48809] 2. Service account misconfiguration – A regression in certain versions caused spawned pods to use the
default
service account instead of the configured one (e.g.,
airbyte-admin
), leading to permission failures. [Github Issue 48888] 3. Insufficient resources – The node may not have enough CPU/memory to run the pod. [Github Issue 72233] Debugging Steps 1. Find the failed pod and check the init container logs:kubectl get pods -n airbyte-namespace | grep 246419 kubectl logs pod-name -n airbyte-namespace -c init 2. Describe the pod to see termination reason and events:kubectl describe pod pod-name -n airbyte-namespace 3. Check Kubernetes events for scheduling or resource issues:kubectl get events -n airbyte-namespace --field-selector reason=FailedCreate 4. Check node resources:kubectl describe nodes | grep -A 5 "Allocated resources" 5. Verify the service account on the spawned pod matches your configured service account (not
default
). [Github Issue 48888] The init container logs will be the most informative — they should reveal the specific reason for the failure (permissions, network, config, etc.). 👍 0 button 👎 0 button â„šī¸ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.