Вопрос или проблема
Я пытаюсь развернуть кластер MySQL InnoDB в Kubernetes с использованием Oracle MySQL Operator с помощью манифестов и kubectl. Однако при выполнении файла mycluster.yaml, контейнеры застревают в состоянии инициализации и ожидания, не переходя в состояние выполнения. Когда я проверил логи, были показаны следующие строки.
LAST SEEN TYPE REASON OBJECT MESSAGE
3m4s Normal FailedBinding persistentvolumeclaim/datadir-mycluster-0 no persistent volumes available for this claim and no storage class is set
33m Normal FailedBinding persistentvolumeclaim/datadir-mycluster-1 no persistent volumes available for this claim and no storage class is set
3m4s Normal FailedBinding persistentvolumeclaim/datadir-mycluster-1 no persistent volumes available for this claim and no storage class is set
33m Normal FailedBinding persistentvolumeclaim/datadir-mycluster-2 no persistent volumes available for this claim and no storage class is set
3m4s Normal FailedBinding persistentvolumeclaim/datadir-mycluster-2 no persistent volumes available for this claim and no storage class is set
Я выяснил, что проблема связана с отсутствием класса хранения. Я следовал официальной документации MySQL (MySQL Operator), но там нет упоминания о манифесте класса хранения.
Файл mycluster.yaml выглядит следующим образом,
apiVersion: mysql.oracle.com/v2
kind: InnoDBCluster
metadata:
name: mycluster
spec:
secretName: mypwds
tlsUseSelfSigned: true
instances: 3
router:
instances: 1
MySQL Operator работает без проблем. Проблема возникает только с InnoDBCluster mycluster с тремя контейнерами. Я использую реальный кластер Kubernetes с одним мастер-узлом и тремя виртуальными машинами с рабочими узлами.
Я хочу запустить несколько экземпляров MySQL с записью/чтением в Kubernetes, которые используют одну и ту же директорию хранения для постоянства данных.
Что я должен сделать, чтобы решить эту проблему и заставить ее работать? Все предложения и помощь приветствуются.
Ошибка указывает на то, что контейнеры ищут PVC. Пожалуйста, создайте его, обратитесь к официальной документации в разделе “Setting PersistentVolumeClaim Size” для получения более подробной информации. Ниже приведен пример datadirvolumeclaimtemplate, который необходимо указать в манифесте “InnoDBCluster”.
datadirVolumeClaimTemplate:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 40Gi
Ответ или решение
Ваши MySQL-кластеры InnoDB на Kubernetes сталкиваются с проблемой "FailedBinding" в связи с отсутствием соответствующего класса хранения, что не позволяет подам перейти в состояние "Running". Это компактное, но серьезное затруднение может быть решено правильной настройкой PersistentVolumeClaim (PVC) и назначением соответствующего StorageClass.
Понимание проблемы
Коды ошибок указывают, что вашему кластеру не удается создать PersistentVolume для хранения данных, поскольку не задан StorageClass. Ваша текущая конфигурация в mycluster.yaml не включает информацию о шаблоне PVC или StorageClass, что и вызывает проблему с инициализацией подов.
Рекомендации по решению
-
Создание StorageClass:
В первую очередь необходимо создать StorageClass, который будет использоваться для настройки PVC. Пример конфигурации может выглядеть следующим образом:
apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: fast-storage provisioner: kubernetes.io/aws-ebs parameters: type: gp2Не забудьте адаптировать
provisionerиparametersк вашему облачному провайдеру или используемой технологии хранения. -
Обновление mycluster.yaml с datadirVolumeClaimTemplate:
Теперь, когда у вас есть StorageClass, добавьте информацию о PVC в ваш
mycluster.yaml:apiVersion: mysql.oracle.com/v2 kind: InnoDBCluster metadata: name: mycluster spec: secretName: mypwds tlsUseSelfSigned: true instances: 3 router: instances: 1 datadirVolumeClaimTemplate: accessModes: - ReadWriteOnce resources: requests: storage: 40Gi storageClassName: fast-storageЭтим вы укажете Kubernetes, какой класс хранения использовать и зададите необходимые параметры для PVC.
-
Проверка состояния кластера:
После выполнения вышеуказанных шагов выполняйте команду
kubectl apply -f mycluster.yaml, чтобы повторно внедрить конфигурацию. Проверьте статус подов с помощью:kubectl get podsУ убедитесь, что они переходят в состояние "Running".
Резюме
Решение проблемы заключается в добавлении грамотной конфигурации VolumeClaim для MySQL InnoDB кластера. Использование StorageClass обеспечит выделение жесткого диска под данные, а правильная настройка manifest-файлов гарантирует, что кластеры смогут успешно инициализироваться и работать. Переходя с внимания на эти детали, вы эффективно настраиваете надежное и доступное решение хранения для вашей базы данных в Kubernetes.