Connecting applications¶
Each MysqlCluster exposes several Kubernetes Services for different connection patterns. You can wire your application Deployments, Jobs, or external tools to these endpoints.
Service overview¶
For a cluster named my-cluster in namespace app:
| Service | DNS name | Purpose |
|---|---|---|
{name}-mysql-master |
my-cluster-mysql-master.app.svc |
Writes — targets the current primary |
{name}-mysql |
my-cluster-mysql.app.svc |
Reads — all healthy nodes |
{name}-mysql-replicas |
my-cluster-mysql-replicas.app.svc |
Healthy replicas excluding the primary |
mysql (headless) |
my-cluster-mysql-0.mysql.app.svc |
Per-pod DNS for direct pod access |
All services expose MySQL on port 3306.
Write traffic¶
Point applications that insert, update, or delete data at the master service:
The operator updates Service selectors after Orchestrator failover so the master service follows the current primary.
Read traffic¶
For load-balanced reads across healthy replicas:
Replicas with replication lag above spec.maxSlaveLatency are removed from this service.
Direct pod access¶
StatefulSet pods are reachable via the headless service mysql:
Use this for admin tasks or when you need a specific instance.
Bootstrap credentials¶
Your application credentials come from the secret referenced by spec.secretName (for example my-secret):
| Key | Description |
|---|---|
USER |
Application username (if set at bootstrap) |
PASSWORD |
Application password |
DATABASE |
Default database name |
ROOT_PASSWORD |
Root password (admin use) |
Construct a connection string from the master service and these values:
For language-specific drivers, use the hostname, port, user, password, and database from the table above.
Note
USER, PASSWORD, and DATABASE are applied only at cluster bootstrap. For ongoing user management, prefer MysqlUser & MysqlDatabase.
Operated secret (internal)¶
The operator creates {cluster}-mysql-operated with credentials for replication, Orchestrator, metrics, and backups. Do not use these for application traffic unless you understand their scope.
Example: wiring a Deployment¶
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-app
namespace: app
spec:
template:
spec:
containers:
- name: app
env:
- name: DB_HOST
value: my-cluster-mysql-master.app.svc.cluster.local
- name: DB_PORT
value: "3306"
envFrom:
- secretRef:
name: my-secret
Map USER, PASSWORD, and DATABASE from the secret in your application code or add explicit env entries with secretKeyRef.
Cross-namespace access¶
Services are namespace-scoped. Applications in another namespace should use the fully qualified DNS name:
Ensure network policies allow traffic from the client namespace.
Related pages¶
- Getting started
- Orchestrator — failover behavior affecting the master service
- Monitoring — metrics endpoints on cluster pods