Kubernetes Orchestrator Operations & Troubleshooting
This guide covers validating your Kubernetes orchestrator setup, viewing pipeline logs, troubleshooting common issues, and migrating from Airflow. For initial setup, see the Kubernetes Native Orchestrator guide.Validating the Setup
1. Check Service Health
Navigate to Settings → Preferences → Health in the OpenMetadata UI to verify the Kubernetes pipeline client is properly configured and can connect to the Kubernetes API.2. Deploy a Test Pipeline
Create a simple metadata ingestion pipeline from the OpenMetadata UI. The pipeline should:- Show “Deployed” status
- Display the Kubernetes Job/CronJob name
3. Check Kubernetes Resources
Pipeline Logs
By default, pipeline logs are retrieved directly from Kubernetes pod logs, so the logs of a run are lost when its pod is deleted. To keep them, see Storing Pipeline Logs in S3. OpenMetadata implements log pagination for large log files, splitting them into ~1MB chunks for efficient retrieval. To view logs:- Navigate to Settings → Services → Agents
- Select your pipeline
- Click on Logs to view them directly on OpenMetadata UI
-
List the ingestion pods, newest last, with the pipeline each one belongs to:
-
Read the
maincontainer of the pod you want:
-main (the ingestion itself) and one ending in -exit (it reports the final status). Read the -main pod.
Kubernetes only keeps these logs while the pod exists and its container is still on the node.
Pods of Finished Runs Are Not Cleaned Up
Known issue in 2.0.x with the OMJob operator: pods from finished runs are not deleted when
ttlSecondsAfterFinished expires, so they accumulate in the namespace. The fix ships in 2.1 (OpenMetadata#33319).Troubleshooting
Server/Client Version Mismatch
If you see an error likeserver version X does not match client version Y, the ingestion job is running a different version of the ingestion library than the OpenMetadata server expects.
Most common cause: ingestionImage is set to :latest in your Helm values. When a new OpenMetadata release is published, :latest moves to that version. Any Kubernetes node without the old image cached will pull the new one on the next job run, silently upgrading the ingestion client while your server stays on the previous version.
Fix: Pin ingestionImage to the exact version of your server:
2.0.5 with your actual server version. The ingestion image must match the server’s full x.y.z version: for example, a 2.0.5 server requires a 2.0.5 ingestion image.
After updating, redeploy OpenMetadata:
Pipeline stuck in “Queued” state
If the pipeline cannot start and remains in “Queued” state, check if the pod can be scheduled:- Image pull errors (check
imagePullSecrets) - Insufficient cluster resources (increase CPU/memory limits or add nodes)
- Node selector constraints
Permission Denied Errors
If you see RBAC-related errors:Ingestion Pod Crashes (OOMKilled)
Increase memory limits in the Helm values:CronJob Not Triggering
Check CronJob status and events:- Invalid cron expression
startingDeadlineSecondstoo short- Concurrency policy blocking execution
Migrating from Airflow
If you’re migrating from Airflow to the Kubernetes orchestrator:- Stop existing Airflow-managed pipelines - Disable or delete pipelines managed by Airflow
- Update Helm values - Switch
type: "airflow"totype: "k8s" - Redeploy OpenMetadata - Apply the new Helm configuration
- Re-deploy pipelines - Navigate to each pipeline and click “Deploy” to create the Kubernetes resources