Introduction

Connecting to MySQL inside a Kubernetes pod from a remote machine usually involves two separate concerns: reaching the cluster network and reaching the MySQL port safely. In many setups, the practical answer is to combine SSH for secure access to a bastion or admin host with kubectl port-forward for pod or service-level access, instead of trying to SSH directly into the pod itself.

The Simplest Architecture

A common setup looks like this:

1. your laptop can SSH to a bastion or admin server
2. that server has kubectl access to the cluster
3. kubectl port-forward exposes the MySQL pod or service locally on that server
4. SSH forwards that local port back to your machine

This keeps MySQL private inside the cluster while still allowing controlled admin access.

Port-Forward on the Kubernetes Side

From the machine that has kubectl access:

kubectl -n database port-forward pod/mysql-0 3306:3306

Or, if a stable service exists:

kubectl -n database port-forward service/mysql 3306:3306

Now port 3306 on that machine maps to MySQL inside the cluster.

Wrap It with SSH

From your local machine, forward your local port through SSH to the same remote machine:

ssh -L 3306:127.0.0.1:3306 admin@example-bastion

Once the SSH tunnel is open and the remote kubectl port-forward command is running, your local MySQL client can connect to:

127.0.0.1:3306

Example:

mysql -h 127.0.0.1 -P 3306 -u app_user -p

At that point, the traffic path is:

• local MySQL client
• SSH tunnel
• remote localhost on the bastion
• 'kubectl port-forward'
• MySQL pod or service in Kubernetes

Why Not SSH Directly to the Pod

Pods are not normal SSH targets in most Kubernetes designs. They are ephemeral application containers, and they usually:

• do not run an SSH server
• are replaced frequently
• should not be administered like traditional virtual machines

Trying to force an SSH-based workflow directly into pods is usually the wrong operational model. Kubernetes-native access methods such as kubectl exec and kubectl port-forward are more appropriate.

A One-Command Variant

If the bastion has shell access and kubectl, you can combine the ideas from a script or separate terminals. In practice, many engineers keep:

• one terminal running kubectl port-forward
• one terminal running the SSH tunnel
• one terminal using the MySQL client

It is explicit, easy to debug, and avoids hiding too much networking magic in one line.

Common Pitfalls

The biggest mistake is forgetting which machine owns which localhost. 127.0.0.1 on your laptop is not the same as 127.0.0.1 on the bastion. That distinction matters when combining SSH forwarding and kubectl port-forward.

Another issue is forwarding the pod directly when the pod name is unstable. For long-lived operational access, forwarding a service can be less fragile than forwarding a specific pod name.

People also sometimes bind local port 3306 when a local MySQL server is already using it. If so, pick another local port:

ssh -L 13306:127.0.0.1:3306 admin@example-bastion
mysql -h 127.0.0.1 -P 13306 -u app_user -p

Finally, do not confuse network reachability with database authentication. Even if the tunnel is correct, MySQL still needs valid credentials and user-host permissions.

Summary

• The practical pattern is usually SSH to a bastion plus kubectl port-forward, not SSH directly into a pod.
• 'kubectl port-forward exposes the in-cluster MySQL endpoint on the bastion's localhost.'
• SSH then forwards that localhost port back to your machine securely.
• Be careful about which machine each 127.0.0.1 refers to.
• If local port 3306 is busy, use an alternate local port such as 13306.