Azure集群中使用Azure檔案作為PV的MySQL資料庫無法啟動

我有一個 Azure kubernetes 集群，但由于每個節點附加的默認卷的限制（我的節點大小為 8 個），我不得不找到一個不同的解決方案來預配卷。
解決方案是使用 Azure 檔案卷，我按照這篇文章https://docs.microsoft.com/en-us/azure/aks/azure-files-volume#mount-options進行操作，我安裝了一個卷。

但問題出在 MySQL 實體上，它只是無法啟動。

出于測驗目的，我創建了一個包含 2 個簡單資料庫容器的部署，其中一個使用默認存盤類卷，第二個使用Azure-files。

這是我的清單：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: test-db
  labels:
    prj: test-db
spec:
  selector:
    matchLabels:
      prj: test-db
  template:
    metadata:
      labels:
        prj: test-db
    spec:
      containers:
        - name: db-default
          image: mysql:5.7.37
          imagePullPolicy: IfNotPresent
          args:
            - "--ignore-db-dir=lost found"
          ports:
            - containerPort: 3306
              name: mysql
          env:
            - name: MYSQL_ROOT_PASSWORD
              value: password
          volumeMounts:
            - name: default-pv
              mountPath: /var/lib/mysql
              subPath: test

        - name: db-azurefiles
          image: mysql:5.7.37
          imagePullPolicy: IfNotPresent
          args:
            - "--ignore-db-dir=lost found"
            - "--initialize-insecure"
          ports:
            - containerPort: 3306
              name: mysql
          env:
            - name: MYSQL_ROOT_PASSWORD
              value: password
          volumeMounts:
            - name: azurefile-pv
              mountPath: /var/lib/mysql
              subPath: test
      volumes:
        - name: default-pv
          persistentVolumeClaim:
            claimName: default-pvc
        - name: azurefile-pv
          persistentVolumeClaim:
            claimName: azurefile-pvc
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: default-pvc
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: default
  resources:
    requests:
      storage: 200Mi
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: azurefile-pvc
spec:
  accessModes:
    - ReadWriteMany
  storageClassName: azure-file-store
  resources:
    requests:
      storage: 200Mi
---
apiVersion: storage.k8s.io/v1
kind: StorageClass
mountOptions:
- dir_mode=0777
- file_mode=0777
- uid=0
- gid=0
- mfsymlinks
- cache=strict
- nosharesock
parameters:
  skuName: Standard_LRS
provisioner: file.csi.azure.com
reclaimPolicy: Delete
volumeBindingMode: Immediate

帶有默認 PV 的那個可以正常作業，但是帶有 Azure-files 的第二個會拋出這個錯誤：

[Note] [Entrypoint]: Entrypoint script for MySQL Server 5.7.37-1debian10 started.
[Note] [Entrypoint]: Switching to dedicated user 'mysql'
[Note] [Entrypoint]: Entrypoint script for MySQL Server 5.7.37-1debian10 started.
[Note] [Entrypoint]: Initializing database files
[Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server option (see documentation for more details).
[Warning] InnoDB: New log files created, LSN=45790
[Warning] InnoDB: Creating foreign key constraint system tables.
[Warning] No existing UUID has been found, so we assume that this is the first time that this server has been started. Generating a new UUID: e86bdae0-979b-11ec-abbf-f66bf9455d85.
[Warning] Gtid table is not ready to be used. Table 'mysql.gtid_executed' cannot be opened.
mysqld: Can't change permissions of the file 'ca-key.pem' (Errcode: 1 - Operation not permitted)
[ERROR] Could not set file permission for ca-key.pem
[ERROR] Aborting

Based on the error, it seems like the database can't write to the volume mount, but that's not (entirely) true. I mounted both of those volumes to another container to be able to inspect files, here is the output and we can see that database was able to write files on the volume:

-rwxrwxrwx 1 root root       56 Feb 27 07:07 auto.cnf
-rwxrwxrwx 1 root root     1680 Feb 27 07:07 ca-key.pem
-rwxrwxrwx 1 root root      215 Feb 27 07:07 ib_buffer_pool
-rwxrwxrwx 1 root root 50331648 Feb 27 07:07 ib_logfile0
-rwxrwxrwx 1 root root 50331648 Feb 27 07:07 ib_logfile1
-rwxrwxrwx 1 root root 12582912 Feb 27 07:07 ibdata1

Obviously, some files are missing, but this output disproved my thought that the Mysql can't write to the folder.

My guess is, that the MySQL can't properly work with the file system used on Azure files.

What I tried:

• different versions of MySQL (5.7.16, 5.7.24, 5.7.31, 5.7.37) and MariaDB (10.6)
• testing different arguments for mysql
• recreate the storage with NFS v3 enabled
• create a custom Mysql image with added cifs-utils
• testing different permissions, gid/uid, and other attributes of the container and also storage class

uj5u.com熱心網友回復：

似乎是以這種方式安裝的卷的權限導致了問題。

如果我們修改你的存盤類來匹配mysql用戶的uid/gid，pod就可以啟動了：

apiVersion: storage.k8s.io/v1
kind: StorageClass
mountOptions:
- dir_mode=0777
- file_mode=0777
- uid=999
- gid=999
- mfsymlinks
- cache=strict
- nosharesock
parameters:
  skuName: Standard_LRS
provisioner: file.csi.azure.com
reclaimPolicy: Delete
volumeBindingMode: Immediate

掛載選項永久設定掛載中包含的檔案的所有者，這對于想要擁有它創建的檔案的任何東西都不起作用。因為事物是在 777 年創建的，所以任何人都可以讀/寫目錄，只是不擁有它們。

標籤：mysql kubernetes azure-aks azure-files 存储类说明符

上一篇：滾動更新期間無法訪問GKEDjangoMySQL

下一篇：K8s守護行程設定高可用性