【问题标题】:MySQL statefulset with persistent storage on minikube在 minikube 上具有持久存储的 MySQL 状态集
【发布时间】:2022-01-28 02:37:10
【问题描述】:

我正在尝试使用具有持久内存的可扩展 mysql 数据库。我以为这是一件很普遍的事情,但似乎网上没有人真正解释它。 我将 minikube 用于我的单节点集群。 我从how to run replicated stateful applications 上的 kubernetes 指南开始,但它并没有真正涉及到持久卷的创建。 我已经创建了指南中的配置映射:

apiVersion: v1
kind: ConfigMap
metadata:
  name: mysql
  labels:
    app: mysql
data:
  primary.cnf: |
    # Apply this config only on the primary.
    [mysqld]
    log-bin
  replica.cnf: |
    # Apply this config only on replicas.
    [mysqld]
    super-read-only

还有两个服务:

# Headless service for stable DNS entries of StatefulSet members.
apiVersion: v1
kind: Service
metadata:
  name: mysql
  labels:
    app: mysql
spec:
  ports:
  - name: mysql
    port: 3306
  clusterIP: None
  selector:
    app: mysql
---
# Client service for connecting to any MySQL instance for reads.
# For writes, you must instead connect to the primary: mysql-0.mysql.
apiVersion: v1
kind: Service
metadata:
  name: mysql-read
  labels:
    app: mysql
spec:
  ports:
  - name: mysql
    port: 3306
  selector:
    app: mysql

我需要初始化我的数据库的架构,所以我制作了这个 configmap 以在 statefulset 中传递:

apiVersion: v1
kind: ConfigMap
metadata:
  name: mysql-initdb-config
data:
  initdb.sql: |
    CREATE DATABASE football;
    CREATE TABLE `squadra` (
        `name` varchar(15) PRIMARY KEY NOT NULL
    );
    USE football;
    ...

感谢this 的回答,我创建了一个存储类和一个持久卷。

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: local-storage
provisioner: kubernetes.io/no-provisioner
volumeBindingMode: WaitForFirstConsumer
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-volume
spec:
  storageClassName: local-storage
  accessModes:
    - ReadWriteOnce
  capacity:
    storage: 5Gi
  hostPath:
    path: /data/mysql_data/

并为我的数据库的root用户制作了一个包含密码的秘密:

apiVersion: v1
kind: Secret
metadata:
  name: mysql-pass-root
type: kubernetes.io/basic-auth
stringData:
  username: root
  password: password

我的 statefulset 基本上取自 stackoverflow 上的一些答案,我再也找不到了。它基本上是对 kubernetes 网站上的修改。我添加的是数据库架构初始化、volumeclaimtemplate 和 secret 中的密码:

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: mysql
spec:
  selector:
    matchLabels:
      app: mysql
  serviceName: mysql
  replicas: 2
  template:
    metadata:
      labels:
        app: mysql
    spec:
      initContainers:
      - name: init-mysql
        image: mysql:5.7
        command:
        - bash
        - "-c"
        - |
          set -ex
          # Generate mysql server-id from pod ordinal index.
          [[ `hostname` =~ -([0-9]+)$ ]] || exit 1
          ordinal=${BASH_REMATCH[1]}
          echo [mysqld] > /mnt/conf.d/server-id.cnf
          # Add an offset to avoid reserved server-id=0 value.
          echo server-id=$((100 + $ordinal)) >> /mnt/conf.d/server-id.cnf
          # Copy appropriate conf.d files from config-map to emptyDir.
          if [[ $ordinal -eq 0 ]]; then
            cp /mnt/config-map/primary.cnf /mnt/conf.d/
          else
            cp /mnt/config-map/replica.cnf /mnt/conf.d/
          fi
        volumeMounts:
        - name: conf
          mountPath: /mnt/conf.d
        - name: config-map
          mountPath: /mnt/config-map
      - name: clone-mysql
        image: gcr.io/google-samples/xtrabackup:1.0
        command:
        - bash
        - "-c"
        - |
          set -ex
          # Skip the clone if data already exists.
          [[ -d /var/lib/mysql/mysql ]] && exit 0
          # Skip the clone on master (ordinal index 0).
          [[ `hostname` =~ -([0-9]+)$ ]] || exit 1
          ordinal=${BASH_REMATCH[1]}
          [[ $ordinal -eq 0 ]] && exit 0
          # Clone data from previous peer.
          ncat --recv-only mysql-$(($ordinal-1)).mysql 3307 | xbstream -x -C /var/lib/mysql
          # Prepare the backup.
          xtrabackup --prepare --target-dir=/var/lib/mysql
        volumeMounts:
        - name: data
          mountPath: /var/lib/mysql
          subPath: mysql
        - name: conf
          mountPath: /etc/mysql/conf.d
      containers:
      - name: mysql
        image: mysql:5.7
        env:
        - name: MYSQL_ROOT_PASSWORD
          valueFrom:
            secretKeyRef:
              name: mysql-pass-root
              key: password
        - name: MYSQL_USER
          value: server
        - name: MYSQL_DATABASE
          value: medlor
        ports:
        - name: mysql
          containerPort: 3306
        volumeMounts:
        - name: data
          mountPath: /var/lib/mysql
          subPath: mysql
        - name: conf
          mountPath: /etc/mysql/conf.d
        - name: mysql-initdb
          mountPath: /docker-entrypoint-initdb.d
        resources:
          requests:
            cpu: 500m
            memory: 100Mi
        livenessProbe:
          exec:
            command: ["mysqladmin", "-uroot", "-p$MYSQL_ROOT_PASSWORD", "ping"]
          initialDelaySeconds: 30
          periodSeconds: 10
          timeoutSeconds: 5
        readinessProbe:
          exec:
            # Check we can execute queries over TCP (skip-networking is off).
            command:
            - /bin/sh
            - -ec
            - >-
              mysql -hlocalhost -uroot -p$MYSQL_ROOT_PASSWORD -e'SELECT 1'
          initialDelaySeconds: 5
          periodSeconds: 2
          timeoutSeconds: 1
      - name: xtrabackup
        image: gcr.io/google-samples/xtrabackup:1.0
        env:
        - name: MYSQL_ROOT_PASSWORD
          valueFrom:
            secretKeyRef:
              name: mysql-pass-root
              key: password
        ports:
        - name: xtrabackup
          containerPort: 3307
        command:
        - bash
        - "-c"
        - |
          set -ex
          cd /var/lib/mysql

          # Determine binlog position of cloned data, if any.
          if [[ -f xtrabackup_slave_info ]]; then
            # XtraBackup already generated a partial "CHANGE MASTER TO" query
            # because we're cloning from an existing slave.
            mv xtrabackup_slave_info change_master_to.sql.in
            # Ignore xtrabackup_binlog_info in this case (it's useless).
            rm -f xtrabackup_binlog_info
          elif [[ -f xtrabackup_binlog_info ]]; then
            # We're cloning directly from master. Parse binlog position.
            [[ `cat xtrabackup_binlog_info` =~ ^(.*?)[[:space:]]+(.*?)$ ]] || exit 1
            rm xtrabackup_binlog_info
            echo "CHANGE MASTER TO MASTER_LOG_FILE='${BASH_REMATCH[1]}',\
                  MASTER_LOG_POS=${BASH_REMATCH[2]}" > change_master_to.sql.in
          fi

          # Check if we need to complete a clone by starting replication.
          if [[ -f change_master_to.sql.in ]]; then
            echo "Waiting for mysqld to be ready (accepting connections)"
            until mysql -h localhost -uroot -p$MYSQL_ROOT_PASSWORD -e "SELECT 1"; do sleep 1; done

            echo "Initializing replication from clone position"
            # In case of container restart, attempt this at-most-once.
            mv change_master_to.sql.in change_master_to.sql.orig
            mysql -h localhost -uroot -p$MYSQL_ROOT_PASSWORD <<EOF
          $(<change_master_to.sql.orig),
            MASTER_HOST='mysql-0.mysql',
            MASTER_USER='root',
            MASTER_PASSWORD='$MYSQL_ROOT_PASSWORD',
            MASTER_CONNECT_RETRY=10;
          START SLAVE USER='root' PASSWORD='$MYSQL_ROOT_PASSWORD';
          EOF
          fi

          # Start a server to send backups when requested by peers.
          exec ncat --listen --keep-open --send-only --max-conns=1 3307 -c \
            "xtrabackup --backup --slave-info --stream=xbstream --host=127.0.0.1 --user=root --password=$MYSQL_ROOT_PASSWORD"
        volumeMounts:
        - name: data
          mountPath: /var/lib/mysql
          subPath: mysql
        - name: conf
          mountPath: /etc/mysql/conf.d
        resources:
          requests:
            cpu: 100m
            memory: 500Mi
      volumes:
      - name: conf
        emptyDir: {}
      - name: config-map
        configMap:
          name: mysql
      - name: mysql-initdb
        configMap:
          name: mysql-initdb-config
  volumeClaimTemplates:
  - metadata:
      name: data
    spec:
      accessModes: [ "ReadWriteOnce" ]
      storageClassName: "local-storage"
      resources:
        requests:
          storage: 1Gi

当我启动 minikube 时,我运行以下命令:

docker exec minikube mkdir data/mysql_data ->in order to create the folder where mysql saves the data inside the minikube container
minikube mount local_path_to_a_folder:/data/mysql_data -> to keep the mysql data in my physical storage too.
kubectl apply -f pv-volume.yaml (the volume I showed before)
kubectl apply -f database\mysql\mysql-configmap.yaml (the configmap from the guide)
kubectl apply -f database\mysql\mysql-initdb-config.yaml (my configmap with the db schema)
kubectl apply -f database\mysql\mysql-secret.yaml (the secret containing the db password)
kubectl apply -f database\mysql\mysql-services.yaml (the two services)

现在,当我运行所有这些命令时,我的 MySql pod 失败了,这就是我可以从仪表板看到的:

虽然在持久卷部分我可以看到我的卷已被认领:

我一定是理解错了,这一切肯定有逻辑错误,但我不知道是什么。 任何帮助将不胜感激。

【问题讨论】:

  • 您通常不需要自己创建 StorageClass、PersistentVolume 或 PersistentVolumeClaim; StorageClass 应该来自集群,StatefulSet 创建 PVC,一个称为 provisioner 的部分创建 PV。 Minikubeshould support a basic persistent volume provisioner;删除额外的存储设置有帮助吗?您那里还有 很多 个容器,删除除主数据库以外的所有内容会有所不同吗?
  • kubectl get pvc 的输出是什么?另外,当 statefulset 中所需的副本为 2 时,我看到只有 1 pv。
  • @DavidMaze 并非总是如此,如果是本地持久卷和自我管理的 k8s 集群,您需要创建 sc 和 pv。
  • @DavidMaze 感谢您的评论。我不得不承认,我对整个持久存储管理很困惑。我想我只需要删除存储类,并保留卷(没有存储类名),因为它几乎就像你链接的那个。我认为我的 statefulset 确实创建了 pvc,但我没有手动创建一个。根据指南,每个 pod 应该有两个容器,一个用于主数据库,一个用于从以前的 pod 复制,所以我认为我不能删除太多。
  • ">我认为我的 statefulset 确实创建了 pvc",这是因为您可能在 statefulset 定义中定义了 volumeClaimTemplates

标签: docker kubernetes minikube persistent-volumes kubernetes-statefulset


【解决方案1】:

PV 的存储大小与请求的 PVC 不匹配。您创建了大小为 5Gi 的 PV,并且您正在使用 PVC 请求 1Gi。

(在为 PV 应用新更改之前,请确保旧资源已被删除)

【讨论】:

  • 我认为 5Gi 是整个持久卷的大小,而 1Gi 是每个 pod 请求访问的大小。不是这样吗?但是,我只是尝试将两者都更改为 5Gi,但没有任何改变。
  • 不,如果 statefulset PV 在每个节点上创建并且 Pod 之间没有共享,除非并且直到您使用相同的 PVC(在这种情况下,它也会使用整个 PV) ,在您的情况下,有 2 个副本意味着它将需要两个 PVC data-mysql-0data-mysql-1。 PV没有分区。
  • 很抱歉再次打扰您,但我无法完全理解。如果没有 PV 分区,并且每个 pod 都创建自己的,那为什么还要创建一个 PV?我遵循这个逻辑:我创建了一个存储类(用于选择 pod 应该使用哪个 PV),一个引用该存储类的 PV (以便在请求存储类时可以在 PV 内部分配)和 volumeclaimtemplate 为 statefulset 中的每个 pod 创建 PVC 的工作。我认为这些 PVC(使用模板生成)中的每一个都在询问存储类要使用哪个卷,并得到他找到的唯一 PV 的回答。
  • 您可以假设 PV 作为每个 kubernetes 节点中的存储空间(为简单起见,本地持久卷,EBS 卷的工作方式略有不同,因为它们是网络存储)。
  • 当你创建一个 statefulset 时,这意味着你的应用程序正在寻找一些有状态的性质,这意味着即使 pod 发生故障,数据也应该保持不变,并且应用程序应该继续从它离开的地方读取数据。如果在同一个 k8s 节点上创建 pod(docker 容器)并分配了相同的存储,则会发生这种情况。
猜你喜欢
  • 1970-01-01
  • 2018-01-12
  • 2017-08-24
  • 2018-01-12
  • 1970-01-01
  • 2021-01-30
  • 2018-12-28
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多