Introduction

Executing a SQL script in a Kubernetes pod usually means sending the script to a database client that already exists inside that pod. The two common patterns are piping the script into kubectl exec -i or copying the file into the container first and then running the client there. The right method depends on the database image, shell availability, and whether the pod already contains the SQL client you need.

The Simplest Pattern: Pipe the Script Through kubectl exec

If the container already has mysql, psql, or another SQL client installed, piping the file from your local machine is usually the cleanest approach.

For MySQL:

kubectl exec -i -n data db-pod -- sh -c 'mysql -u app -p"$MYSQL_PASSWORD" appdb' < ./schema.sql

For PostgreSQL:

kubectl exec -i -n data pg-pod -- sh -c 'psql -U app -d appdb' < ./schema.sql

The important point is that the < ./schema.sql redirect happens on your local machine, not inside the pod. kubectl streams that file into the container process.

When to Use kubectl cp First

Sometimes you want the script file inside the pod, either for auditing, repeated execution, or because the command becomes too awkward inline.

kubectl cp ./schema.sql data/db-pod:/tmp/schema.sql
kubectl exec -n data db-pod -- sh -c 'mysql -u app -p"$MYSQL_PASSWORD" appdb < /tmp/schema.sql'

This is slightly more verbose, but it can be easier to troubleshoot because the file is present in the container before execution starts.

Choosing the Correct Pod and Container

In real clusters, the first problem is often not SQL at all. It is selecting the right target.

Useful checks:

kubectl get pods -n data
kubectl describe pod db-pod -n data

If the pod has multiple containers, add -c:

kubectl exec -i -n data db-pod -c mysql -- sh -c 'mysql -u app -p"$MYSQL_PASSWORD" appdb' < ./schema.sql

Without the correct container name, the command may run in the wrong container and fail with "command not found".

Handling Credentials Safely

Avoid placing plain passwords directly in shell history when possible. If the container already exposes database credentials as environment variables, use those variables in the command, as shown above.

If not, a safer operational pattern is to run the command in a pod that already has the application or migration environment configured, rather than pasting credentials into one-off commands repeatedly.

For recurring work, consider a purpose-built migration job instead of manual kubectl exec usage.

Verifying the Script Ran

After execution, verify using a quick SQL check:

kubectl exec -n data db-pod -- sh -c 'mysql -u app -p"$MYSQL_PASSWORD" -e "SHOW TABLES" appdb'

Or for PostgreSQL:

kubectl exec -n data pg-pod -- sh -c 'psql -U app -d appdb -c "\\dt"'

Verification is important because a script can stop halfway through if it hits a permissions issue or SQL error.

When Manual Execution Is the Wrong Tool

For production-grade schema changes, manual execution inside a random pod is often too fragile. Prefer one of these when the work is repeatable:

• a Kubernetes Job
• a migration init container
• a CI/CD step that runs in a controlled environment

Manual kubectl exec is good for emergency fixes, debugging, or one-off maintenance. It is not a strong long-term migration strategy.

Common Pitfalls

• Running kubectl exec without -i, which prevents the SQL file from streaming into the process.
• Forgetting that local shell redirection happens outside the pod.
• Executing against the wrong namespace or container.
• Assuming the pod image contains mysql or psql when it does not.
• Putting production credentials directly in shell history during ad hoc commands.

Summary

• The easiest pattern is usually kubectl exec -i with the local SQL file piped into the database client.
• 'kubectl cp is useful when you want the script inside the container first.'
• Always verify the target namespace, pod, and container before execution.
• Reuse in-pod environment variables for credentials when possible.
• For repeatable migrations, prefer Jobs or CI/CD over manual pod commands.