MicroK8s部署Bitnami MySQL出现mysql.sock未找到错误的排查求助

Let’s dig into the issues you’re facing and work through actionable fixes to get your MySQL pod running again. The key clues from your logs and events point to two main problems: a non-writable configuration file and a missing socket file (which stems from MySQL failing to start properly).

1. First, Check the Detailed MySQL Startup Logs #

The readiness probe failure is a symptom—not the root cause. To find out why mysqld isn’t starting, check the MySQL error log inside the pod:

kubectl exec -n gib mysql-primary-0 -- cat /opt/bitnami/mysql/logs/mysqld.log

This log will show specific errors like permission denied when creating files, invalid configuration syntax, or issues initializing the database.

2. Fix the Non-Writable Configuration File Warning #

Your logs show:

WARN ==> The mysql configuration file '/opt/bitnami/mysql/conf/my.cnf' is not writable. Configurations based on environment variables will not be applied for this file.

Bitnami’s MySQL container expects to modify the config file during initialization (to apply environment variable settings). If you’re mounting your ConfigMap as a read-only file (the default for ConfigMaps), this breaks the setup process. Here’s how to fix this:

Option A: Use Bitnami Environment Variables Instead of a Custom my.cnf #

Bitnami provides environment variables for almost all MySQL settings, which avoids permission issues entirely. For example, instead of your custom my.cnf, set these in your Deployment:

env:
  - name: MYSQL_DEFAULT_AUTHENTICATION_PLUGIN
    value: "mysql_native_password"
  - name: MYSQL_SKIP_NAME_RESOLVE
    value: "yes"
  - name: MYSQL_EXPLICIT_DEFAULTS_FOR_TIMESTAMP
    value: "yes"
  - name: MYSQL_MAX_ALLOWED_PACKET
    value: "16M"
  - name: MYSQL_MAX_CONNECTIONS
    value: "650"
  # Add other settings as needed using Bitnami's env vars

This lets the container generate a valid, writable config file automatically.

Option B: Adjust ConfigMap Mount Permissions #

If you must use your custom my.cnf, ensure the container can write to it:

• In your Deployment’s volumeMounts, set readOnly: false for the config volume.
• Add a securityContext to run the pod as the Bitnami user (UID/GID 1001), which matches the container’s default user:

securityContext:
  runAsUser: 1001
  runAsGroup: 1001
  fsGroup: 1001

This ensures the pod has permission to modify the mounted my.cnf file.

3. Fix Storage Volume Permissions (Local or NFS) #

Even with chmod 777, permission issues can persist due to:

• SELinux restrictions (common on Rocky Linux): On your host system, adjust the SELinux context for your storage directory (local or NFS mount):

  chcon -Rt svirt_sandbox_file_t /path/to/your/storage/directory
  

• Mismatched UIDs: Bitnami’s MySQL runs as UID 1001. Ensure your storage volume’s files are owned by this UID. The fsGroup: 1001 in your pod’s securityContext (from step 2) will automatically set this for mounted volumes.

4. Clean Up Stale Data (If Previous Deployment Worked) #

Since you mentioned this MySQL instance ran before, stale data in your storage volume might be causing initialization failures. Try:

• For NFS: Empty the contents of your NFS directory on the server.
• For local storage: Delete the data directory on your MicroK8s node.
• Then delete the pod to trigger a fresh initialization:

  kubectl delete pod -n gib mysql-primary-0
  

5. Verify Socket Path Configuration #

Double-check that your my.cnf (or environment variables) set the socket path correctly to /opt/bitnami/mysql/tmp/mysql.sock. Ensure the /opt/bitnami/mysql/tmp directory exists in the pod and has write permissions:

kubectl exec -n gib mysql-primary-0 -- ls -ld /opt/bitnami/mysql/tmp

If the directory is missing, add an init container to create it with the right permissions:

initContainers:
  - name: create-tmp-dir
    image: busybox:1.36
    command: ["sh", "-c", "mkdir -p /opt/bitnami/mysql/tmp && chown 1001:1001 /opt/bitnami/mysql/tmp"]
    volumeMounts:
      - name: mysql-data
        mountPath: /opt/bitnami/mysql

Start with checking the MySQL error log—it will give you the most direct insight into why the server isn’t starting. From there, apply the fixes above based on what you find.

内容的提问来源于stack exchange，提问作者sercanezelhan