MySQL Operator в Kubernetes: установка и эксплуатация

Логотип MySQL, стилизованное изображение логотипа MySQL

Оператор MySQL для Kubernetes автоматизирует развёртывание, репликацию и обслуживание кластеров MySQL через кастомные ресурсы. В статье показано, как установить оператор, создать секрет с root-учётными данными, развернуть InnoDBCluster, подключиться к базе, настроить хранилище и версионирование. Включены рекомендации по безопасности, чек-листы, сценарии восстановления и советы для продакшен-сред.

Быстрые ссылки

Что такое MySQL Operator?
Установка MySQL Operator
Создание секрета с root-учётными данными
Создание простого кластера
Подключение к кластеру
Настройка параметров сервера MySQL
Настройка объёма хранилища
Фиксация версии MySQL
Безопасность и резервные копии
План восстановления и отката
Практические чек-листы и тесты
Краткая сводка

Что такое MySQL Operator?

MySQL Operator от Oracle — это компонент, который работает внутри Kubernetes и автоматизирует инициализацию и обслуживание кластеров MySQL. Он использует Custom Resource Definitions (CRD) для описания желаемого состояния, а контроллер приводит живой кластер в соответствие с этим состоянием.

Короткое определение: оператор — это контроллер, который создаёт StatefulSet, PVC, сервисы и настраивает репликацию на основе объекта InnoDBCluster.

Почему оператор удобнее, чем ручной подход:

Уменьшает объём YAML-манифестов и человеческих ошибок.
Автоматизирует создание и конфигурацию router-компонентов и реплик.
Поддерживает интеграцию с TLS, резервными копиями и обновлениями.

Важно: оператор упрощает эксплуатацию, но не исключает необходимости хороших практик DevOps и резервного копирования.

Установка MySQL Operator

Самый простой способ установить оператор — использовать Helm-чарт, входящий в проект. Альтернативно можно применить готовые манифесты YAML, если Helm недоступен.

Добавьте репозиторий чарта:

$ helm repo add mysql-operator https://mysql.github.io/mysql-operator/

Обновите базу репозиториев:

$ helm repo update

Установите оператор в новый неймспейс mysql-operator:

$ helm install mysql-operator mysql-operator/mysql-operator \
--namespace mysql-operator \
--create-namespace

Пример вывода Helm (индикативно):

NAME: mysql-operator
LAST DEPLOYED: Sat Oct 29 15:00:26 2022
NAMESPACE: mysql-operator
STATUS: deployed
REVISION: 1
TEST SUITE: None

Подсказка: команду helm можно запускать из CI/CD пайплайна. Убедитесь, что у вашей учётной записи есть права на создание CRD.

Создание секрета с root-учётными данными

Каждый кластер MySQL, который вы создаёте через оператор, должен ссылаться на Kubernetes Secret с логином и паролем root. Оператор создаст пользователя root с указанными в секрете значениями.

Создайте файл secret.yaml и замените rootPassword на безопасное значение. Также при необходимости измените rootUser и rootHost.

apiVersion: v1
kind: Secret
metadata:
  name: mysql-root-user
stringData:
  rootHost: "%"
  rootUser: "root"
  rootPassword: "P@$$w0rd"

Сохраните и примените секрет:

$ kubectl apply -f secret.yaml

Ожидаемый ответ:

secret/mysql-root-user created

Важно: учётная запись, указанная в секрете, имеет полный контроль над базой. Для приложений создавайте отдельные пользователя с минимальными правами.

Создание простого кластера

Создайте файл mysql.yaml с объектом InnoDBCluster. В примере ниже развертывается 3-репликовый кластер и один экземпляр MySQL Router.

apiVersion: mysql.oracle.com/v2
kind: InnoDBCluster
metadata:
  name: mysql-cluster
spec:
  secretName: mysql-root-user
  instances: 3
  tlsUseSelfSigned: true
  router:
    instances: 1

Пояснения к свойствам:

spec.secretName — должен совпадать с metadata.name секрета, содержащего root-учётные данные.
spec.instances — количество реплик MySQL (поддерживается до 10 реплик).
spec.tlsUseSelfSigned — true использует внутренний самоподписанный сертификат; можно указать собственные сертификаты через spec.tlsSecretName и spec.tlsCASecretName.
spec.router.instances — число экземпляров MySQL Router для балансировки трафика.

Примените манифест:

$ kubectl apply -f mysql.yaml

Оператор выполнит инициализацию: создаст StatefulSet, PVC, сервисы и выполнит начальную конфигурацию. Процесс занимает пару минут.

Проверка pod-статусов:

$ kubectl get pods

Ожидаемый вывод примерно такой:

NAME READY STATUS RESTARTS AGE
mysql-cluster-0 2/2 Running 0 2m
mysql-cluster-1 2/2 Running 0 2m
mysql-cluster-2 2/2 Running 0 2m
mysql-cluster-router-6b68f9b5cb-wbqm5 1/1 Running 0 2m

Кластеры и Router в состоянии Running означают, что база готова принимать подключения.

Подключение к кластеру

Оператор создаёт сервис, через который приложения внутри кластера подключаются к базе. Формат хоста:

..svc.cluster.local

В примере выше адрес будет mysql-cluster.default.svc.cluster.local. Подключайтесь по порту 3306 и используйте учётные данные из секрета.

Доступ извне к базе

Для доступа извне удобно использовать порт-форвардинг kubectl:

$ kubectl port-forward service/mysql-cluster 3306

Затем из локальной машины:

$ mysql -h127.0.0.1 -u root -p

Ctrl+C прерывает порт-форвардинг.

Замечание: для постоянного внешнего доступа рассмотрите загрузочный балансировщик, NodePort или Ingress (с TLS и ограничением доступа по IP).

Настройка параметров сервера MySQL

Если приложению требуются конкретные опции my.cnf, задайте их в spec.mycnf объекта InnoDBCluster. Оператор запишет содержимое в файл my.cnf внутри Pod.

apiVersion: mysql.oracle.com/v2
kind: InnoDBCluster
spec:
  # ...
  mycnf: |
    [mysqld]
    max_connections=500
    innodb_ft_min_token_size=5

Практический совет: тестируйте изменения конфигурации в staging, так как некоторые параметры требуют перезапуска и могут повлиять на производительность.

Настройка объёма хранилища

По умолчанию оператор создаёт PVC объёмом 2Gi. Объём можно переопределить через datadirVolumeClaimTemplate, указав resources.requests.storage.

apiVersion: mysql.oracle.com/v2
kind: InnoDBCluster
spec:
  # ...
  datadirVolumeClaimTemplate:
    resources:
      requests:
        storage: 10Gi

Важно: оператор не поддерживает in-place resize для этих PVC. Чтобы увеличить объём в будущем, потребуется миграция на новый PVC или создание нового кластера и перенос данных.

Рекомендация: запланируйте запас по объёму и мониторьте использование диска (например, через Prometheus).

Фиксация версии MySQL

Чтобы предотвратить непреднамеренные обновления, укажите spec.version и router.version. Выбирайте одинаковую версию для Pod и роутера.

apiVersion: mysql.oracle.com/v2
kind: InnoDBCluster
spec:
  # ...
  version: 8.0.31
  router:
    instances: 1
    version: 8.0.31

Совет: перед обновлением версии выполните тестовый апгрейд в staging и проверьте совместимость приложений.

Безопасность и резервное копирование

Ключевые рекомендации по безопасности:

Используйте TLS — предпочтительно собственный CA через spec.tlsSecretName и spec.tlsCASecretName.
Ограничьте rootHost в секрете от “%” до конкретных хостов, если это возможно.
Храните секреты в защищённом хранилище (например, Kubernetes Secrets с интеграцией KMS).
Настройте RBAC, чтобы только доверенные роли могли изменять InnoDBCluster и секреты.
Применяйте сетевые политики (NetworkPolicy) для ограничения доступа к сервису MySQL.

Резервное копирование и восстановление:

Оператор поддерживает интеграцию с бэкапами. При настройке резервного копирования выполните следующие шаги:

Настройте внешнее хранилище (S3-совместимое, GCS и т.д.).
Создайте Kubernetes Secret с учётными данными доступа к хранилищу.
Конфигурируйте CronJob или встроенные механизмы оператора для регулярных снапшотов.
Тестируйте восстановление на изолированном стенде.

Важно: регулярные тесты восстановления важнее частых бэкап-джобов — бэкап нужно уметь восстановить.

Когда оператор может не подойти

Контрпримеры и ограничения:

Маленькие разработки и тесты, где проще запустить одиночный контейнер MySQL без оператора.
Требования к нестандартным файловым системам или особенному сетевому окружению, которые оператор не поддерживает.
Сценарии, где необходима возможность динамического изменения PVC размера «на лету».
Полностью управляемые облачные базы данных (RDS, Cloud SQL), где оператор не нужен и может вводить лишний уровень управления.

Если оператор не подходит, рассмотрите ручное развёртывание StatefulSet или использование облачной управляемой БД.

Альтернативные подходы

Ручное развёртывание через StatefulSet и Headless Service. Плюс: полный контроль. Минус: большая операционная нагрузка.
Использование managed DBaaS (Amazon RDS, Google Cloud SQL, Azure Database). Плюс: минимум операций. Минус: меньшая гибкость и возможные сетевые задержки.
Сторонние операторы и проекты, если требуются специфичные фичи.

Пошаговая методология для продакшн-развёртывания

Подготовка инфраструктуры: настройка кластерных хранилищ и прав доступа.
Установка оператора в отдельный namespace с ограниченным RBAC.
Создание секрета с root и настройка TLS.
Развёртывание кластера InnoDBCluster в staging.
Тестирование: подключение, нагрузочное тестирование, failover.
Настройка бэкапов и мониторинга.
Обновление версий по плану, контроль совместимости.
Перенос в production и регулярные тесты восстановления.

Роли и чек-листы

Чек-лист инженера платформы:

Установлен Helm и есть доступ к кластеру.
Создан namespace mysql-operator.
Настроен RBAC для оператора.
Настроено хранилище и StorageClass.
Настроены мониторинг и алёрты по диску, CPU, доступности.

Чек-лист разработчика:

Приложение использует адрес кластера ..svc.cluster.local.
Есть тесты на подключение и обнаружение ошибок соединения.
Используется отдельный пользователь с минимальными правами.

Чек-лист DBA / SRE:

Настроены регулярные бэкапы и проверено восстановление.
Документированы процедуры обновления версий.
Настроены метрики репликации и задержек.

SOP для развертывания нового кластера

Подготовьте секрет с root-учётными данными.
При необходимости подготовьте секреты с TLS и для внешнего хранилища бэкапа.
Создайте manifest InnoDBCluster с требуемым объёмом, числом реплик и версией.
Примените манифест: kubectl apply -f mysql.yaml.
Убедитесь, что Pods и Router достигли состояния Ready.
Проверьте подключения приложений в staging, затем в production.

План восстановления и отката

Сценарий: один из узлов потерял диск или PVC переполнен.

Оцените состояние: kubectl get pods, kubectl describe pod, проверка PVC.
Если PVC повреждён, восстановите из резервной копии: разверните временный кластер и выполните restore.
Для отката версии: создайте новый кластер с предыдущей версией и выполните перенос данных.
Документируйте шаги и проведите пост-мортем.

Критерии приёмки после восстановления:

Все pods в состоянии Ready.
Чтение и запись корректны для тестовой базы.
Репликация синхронизирована.

Тесты и критерии приёмки

Тестовые сценарии перед продвижением в production:

Проверка подключения от приложения к сервису MySQL.
Выполнение простых транзакционных тестов (INSERT/SELECT/UPDATE/DELETE).
Нагрузочные тесты для проверки max_connections и latency.
Тесты failover: эмулируйте падение лидера и проверьте автоматическое переключение.
Тест восстановления из резервной копии на изолированном стенде.

Критерии приёмки:

Время восстановления после failover < заданной SLO.
Успешное восстановление из резервной копии.
Отсутствие ошибок репликации в течение 24 часов под нагрузкой.

Шаблоны и сниппеты

Простой манифест InnoDBCluster (пример с 3 репликами):

apiVersion: mysql.oracle.com/v2
kind: InnoDBCluster
metadata:
  name: mysql-cluster
spec:
  secretName: mysql-root-user
  instances: 3
  tlsUseSelfSigned: true
  mycnf: |
    [mysqld]
    max_connections=250
  datadirVolumeClaimTemplate:
    resources:
      requests:
        storage: 10Gi
  router:
    instances: 1
  version: 8.0.31

Пример секрета для TLS и бэкапа (скелет):

apiVersion: v1
kind: Secret
metadata:
  name: mysql-tls
type: Opaque
stringData:
  tls.crt: |-
    -----BEGIN CERTIFICATE-----
    ...
    -----END CERTIFICATE-----
  tls.key: |-
    -----BEGIN PRIVATE KEY-----
    ...
    -----END PRIVATE KEY-----

Советы по миграции на больший диск

Поскольку оператор не поддерживает изменение размера PVC in-place для текущих Pods, распространённый сценарий миграции:

Разверните новый InnoDBCluster с большим PVC.
Создайте дамп данных (mysqldump или XtraBackup) со старого кластера.
Восстановите дамп в новый кластер.
Переключите приложения на новый сервис/hostname.
Удалите старый кластер после тестов.

Этот процесс занимает время, но минимизирует риски потери данных.

Безопасность: дополнительные меры

Включите аудит действий с помощью Kubernetes Audit и логируйте операции с CRD.
Ограничьте доступ к secret-ам через Kubernetes RBAC и использование External Secrets, если доступно.
Используйте шифрование at-rest для PersistentVolumes, если среда поддерживает.

Ментальные модели

Оператор как «мастер-инженер»: вы описываете желаемое состояние, оператор делает рутинную работу.
InnoDBCluster как «шаблон кластера»: все Pods и Router — реализация шаблона.
PVC как «долговременное хранилище»: планируйте размер заранее.

Совместимость и заметки по версиям

Всегда используйте одинаковую версию MySQL и Router, указав spec.version и spec.router.version. Тестируйте обновления в staging. Оператор поддерживает основные ветки MySQL 8.x; перед применением в production проверьте Release Notes оператора и MySQL.

Короткая сводка

Оператор MySQL облегчает развертывание и обслуживание кластеров MySQL в Kubernetes. Он автоматизирует создание StatefulSet, PVC, Router и предоставляет возможности для настройки конфигурации и резервного копирования. В продакшне важно продумать безопасность, бэкапы и процесс миграции при увеличении дискового пространства.

Важно

Всегда тестируйте процедуру восстановления из резервной копии.
Не используйте глобального root-пользователя в приложениях — создавайте специализированные аккаунты.

Цитата эксперта

“Оператор избавляет от рутинной части администрирования, но не заменяет дисциплину бэкапов и тестирования обновлений.” — Эксперт по Kubernetes

Факто-бокс

Минимальный объём PVC по умолчанию: 2Gi
Максимальное число реплик: до 10
Порт по умолчанию: 3306
Формат внутреннего DNS: ..svc.cluster.local

Mermaid диаграмма принятия решения

flowchart TD
  A[Нужна СУБД в кластере?] -->|Да| B[Подходит оператор?]
  B -->|Да| C[Использовать MySQL Operator]
  B -->|Нет| D[Развернуть вручную или использовать DBaaS]
  C --> E{Требуется TLS?}
  E -->|Да| F[Предоставить TLS секреtы]
  E -->|Нет| G[Использовать self-signed]

Социальная оглавление для превью

OG Title: MySQL Operator в Kubernetes — установка и эксплуатация
OG Description: Как установить MySQL Operator, создать InnoDBCluster, настроить хранение и обеспечить безопасность кластеров MySQL в Kubernetes.

Короткое объявление для команды (100–200 слов)

Оператор MySQL позволяет нам стандартизировать и автоматизировать развёртывание кластеров MySQL в Kubernetes. Мы можем быстро создавать реплицируемые InnoDBCluster объекты с готовой настройкой TLS, Router и PVC. Важно: перед переводом в продакшен необходимо настроить резервное копирование, RBAC и провести нагрузочные тесты. В этой документации описаны шаги установки, шаблоны манифестов, чек-листы для ролей и план восстановления.

Глоссарий (1 строка)

InnoDBCluster — CRD, который описывает кластер MySQL с репликацией и Router.

MySQL Operator в Kubernetes — практическое руководство