deployment of mysql not intaking root password set in secret

Question

I've googled and googled and not sure what I'm doing wrong. it seems how ever way i try to set the root password for mysql, it doesn't seem to work. I'm currently testing out the below(which i've seen plastered over the internet) and this too doesn't work. I'm not getting any errors, logs do not show any errors, and honestly at this point, I'm kind of lost and would appreciate some help.

secrets.yaml file:

apiVersion: v1
kind: Secret
metadata:
  name: mysqlpass
  namespace: gitea
type: Opaque
data:
  password: "cGFzc3dvcmQxMjM="

and my deployment file has the following set:

 spec:
      containers:
      - image: mysql/mysql-server:latest
        imagePullPolicy: IfNotPresent
        name: gitea-mysql
        env:
          # Use secret in real usage
        - name: MYSQL_ROOT_PASSWORD
          valueFrom:
            secretKeyRef:
              name: mysqlpass
              key: password

my current pod logs:

[Entrypoint] MySQL Docker Image 8.0.26-1.2.4-server
[Entrypoint] Starting MySQL 8.0.26-1.2.4-server
2021-10-15T18:28:06.975937Z 0 [System] [MY-010116] [Server] /usr/sbin/mysqld (mysqld 8.0.26) starting as process 1
2021-10-15T18:28:07.005554Z 1 [System] [MY-013576] [InnoDB] InnoDB initialization has started.
2021-10-15T18:28:08.608453Z 1 [System] [MY-013577] [InnoDB] InnoDB initialization has ended.
2021-10-15T18:28:09.158261Z 0 [Warning] [MY-013746] [Server] A deprecated TLS version TLSv1 is enabled for channel mysql_main
2021-10-15T18:28:09.158974Z 0 [Warning] [MY-013746] [Server] A deprecated TLS version TLSv1.1 is enabled for channel mysql_main
2021-10-15T18:28:09.163684Z 0 [Warning] [MY-010068] [Server] CA certificate ca.pem is self signed.
2021-10-15T18:28:09.164583Z 0 [System] [MY-013602] [Server] Channel mysql_main configured to support TLS. Encrypted connections are now supported for this channel.
2021-10-15T18:28:09.245312Z 0 [System] [MY-011323] [Server] X Plugin ready for connections. Bind-address: '::' port: 33060, socket: /var/run/mysqld/mysqlx.sock
2021-10-15T18:28:09.245708Z 0 [System] [MY-010931] [Server] /usr/sbin/mysqld: ready for connections. Version: '8.0.26'  socket: '/var/lib/mysql/mysql.sock'  port: 3306  MySQL Community Server - GPL.

and finally a describe of the pod followed by a describe of the secret:

 kubectl describe pods gitea-mysql-54d544489b-6dp52 -n gitea
Name:         gitea-mysql-54d544489b-6dp52
Namespace:    gitea
Priority:     0
Node:         node02.iad/10.15.15.202
Start Time:   Fri, 15 Oct 2021 18:28:04 +0000
Labels:       app=gitea-mysql
              pod-template-hash=54d544489b
Annotations:  kubectl.kubernetes.io/restartedAt: 2021-10-15T18:27:54Z
Status:       Running
IP:           10.42.1.57
IPs:
  IP:           10.42.1.57
Controlled By:  ReplicaSet/gitea-mysql-54d544489b
Containers:
  gitea-mysql:
    Container ID:   containerd://01419c4eb94b0fc787ee8160f42ec16a7d8299daef07a1d591230b731a5c8cac
    Image:          mysql/mysql-server:latest
    Image ID:       docker.io/mysql/mysql-server@sha256:5241f7de0483a70f5856da995fea98904cfce8f1c51734b7f3836c1663eead17
    Port:           3306/TCP
    Host Port:      0/TCP
    State:          Running
      Started:      Fri, 15 Oct 2021 18:28:06 +0000
    Ready:          True
    Restart Count:  0
    Environment:
      MYSQL_ROOT_PASSWORD:  <set to the key 'password' in secret 'mysqlpass'>  Optional: false
    Mounts:
      /var/lib/mysql from mysql-persistent-storage (rw)
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-r7k5x (ro)
Conditions:
  Type              Status
  Initialized       True
  Ready             True
  ContainersReady   True
  PodScheduled      True
Volumes:
  mysql-persistent-storage:
    Type:       PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace)
    ClaimName:  mysql-pvc
    ReadOnly:   false
  kube-api-access-r7k5x:
    Type:                    Projected (a volume that contains injected data from multiple sources)
    TokenExpirationSeconds:  3607
    ConfigMapName:           kube-root-ca.crt
    ConfigMapOptional:       <nil>
    DownwardAPI:             true
QoS Class:                   BestEffort
Node-Selectors:              <none>
Tolerations:                 node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
                             node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:
  Type    Reason     Age    From               Message
  ----    ------     ----   ----               -------
  Normal  Scheduled  7m36s  default-scheduler  Successfully assigned gitea/gitea-mysql-54d544489b-6dp52 to node02.iad
  Normal  Pulled     7m36s  kubelet            Container image "mysql/mysql-server:latest" already present on machine
  Normal  Created    7m36s  kubelet            Created container gitea-mysql
  Normal  Started    7m35s  kubelet            Started container gitea-mysql

secret described:

kubectl describe secrets mysqlpass -n gitea
Name:         mysqlpass
Namespace:    gitea
Labels:       <none>
Annotations:  <none>

Type:  Opaque

Data
====
password:  11 bytes

I'd honestly appreciate any and all help please. Thanks!

score 0 · Answer 1 · answered Oct 15 '21 at 19:02

0

I remember having a similar problem with Docker. I ended deleting (CAREFUL HERE) any folder created during the creation of the previous mysql docker container. One of those folders has the password for the root user and unless this is deleted or changed it will continue with any other mysql container used to replace the old one.

answered Oct 15 '21 at 19:02

Jose Cabrera Zuniga

2,348
3
31
56

I had figured this might be the case, but checking the pv, I'm not seeing any files created or listed in the PV, which is odd in it self – Muji Sayed Oct 15 '21 at 19:14
I could not figure out the "exact file" too. So, I deleted all the folders... – Jose Cabrera Zuniga Oct 15 '21 at 19:15

score -1 · Accepted Answer · answered Oct 15 '21 at 19:43

fixed it! turns out it was an issue with the way I had set up persistent volumes. The way my cluster is set up is that all pods have a pv on an nfs drive. i had forgotten to specify which server the nfs drive was to be mounted on. After making that fix, i saw files populating the pv, and the set password to work.

in my defense, i blame me not connecting the dots of the empty pv directories to my sleep deprivation.

For anyone else that comes across this similar issue, check to make sure everything else is set correctly. Even though your PV might not error out, it could still be set up incorrectly.

deployment of mysql not intaking root password set in secret

2 Answers2