Introduction

If MySQL is running on your host machine, pods inside Minikube cannot reach it through localhost. Inside a pod, localhost means the pod itself, not your laptop or workstation.

The working pattern is to make MySQL reachable from Minikube on a host-facing address, then give Kubernetes workloads a stable name for that target. In local development, host.minikube.internal is usually the simplest host alias to start with.

Once that networking rule is understood, the rest of the setup is mostly verification and naming rather than Kubernetes magic.

Make the Host Database Reachable

First, confirm that MySQL is not listening only on loopback. If it binds only to 127.0.0.1, traffic from Minikube will never arrive.

A typical MySQL configuration looks like this:

[mysqld]
bind-address = 0.0.0.0
port = 3306

After restarting MySQL, verify that Minikube can reach the port:

minikube ssh
nc -vz host.minikube.internal 3306

If that connection test fails, fix host networking, firewall rules, or MySQL bind settings before writing Kubernetes manifests.

Use the Host Alias Directly

For simple local development, the fastest solution is often to point your application straight at host.minikube.internal:

1env:
2  - name: DB_HOST
3    value: host.minikube.internal
4  - name: DB_PORT
5    value: "3306"

This avoids unnecessary Kubernetes objects when the real goal is just "pod reaches MySQL on the host."

Add a Kubernetes Service Name if You Want One

If you want an in-cluster DNS name, an ExternalName service is a reasonable lightweight option:

1apiVersion: v1
2kind: Service
3metadata:
4  name: mysql-on-host
5spec:
6  type: ExternalName
7  externalName: host.minikube.internal

Your application can then use mysql-on-host as the host name and still connect on port 3306.

This does not turn the host MySQL into a normal in-cluster service implementation. It just gives you a stable Kubernetes DNS alias.

That distinction matters because service discovery will work, but lifecycle management and health semantics still belong to the host process, not the cluster.

Test from a Temporary Pod

Before wiring your real application to it, test the connection from inside the cluster:

1kubectl run mysql-client --rm -it \
2  --image=mysql:8 \
3  --restart=Never \
4  -- mysql -h mysql-on-host -P 3306 -u root -p

If DNS resolves but login fails, the remaining issues are usually:

• MySQL user permissions
• password or database configuration
• host firewall rules

Those are MySQL or host-networking problems, not Kubernetes service-definition problems.

Know When to Run MySQL In Cluster Instead

Using a host MySQL instance is fine for local development, especially if you already have seeded data on your machine. But it is not a good substitute for a real Kubernetes-style database deployment when you need to test:

• persistent volumes
• secrets
• service selectors
• pod-to-service traffic patterns

For those cases, running MySQL inside Minikube with a normal Service is closer to production behavior.

Common Pitfalls

• Expecting localhost in a pod to refer to the host machine.
• Leaving MySQL bound only to 127.0.0.1.
• Creating Kubernetes objects before proving the host port is reachable from Minikube.
• Assuming a Service object can solve firewall or MySQL permission problems.
• Using a host database for scenarios that really need an in-cluster database deployment.

Summary

• Pods in Minikube cannot use localhost to reach MySQL running on the host.
• Make MySQL listen on a host-reachable interface.
• Test connectivity first with host.minikube.internal.
• Use an ExternalName service if you want a Kubernetes DNS alias.
• Run MySQL inside Minikube when you need realistic Kubernetes database behavior.