Установка MongoDB в кластер Kubernetes

MongoDB является одной из наиболее распространенных СУБД типа NoSQL, предназначенных для хранения больших объемов неструктурированных данных. Вместе с Kubernetes Mongo становится мощным решением, которое можно использовать для глобальных задач — главным образом для масштабирования кластеров. Вертикальное и горизонтальное масштабирование БД MongoDB производится гораздо быстрее и удобнее, поскольку БД в данном случае находится в одной среде с приложениями и управляется Kubernetes.

Требования к установке

Установка MongoDB в Kubernetes требует наличия настроенного сервера с правами суперюзера и кластера Kubernetes, о создании которого будет рассказано далее. Добавим, что ОС сервера не имеет значения, но использование Linux гарантирует, что проблемы при установке будут минимальны.

Создаем кластер Kubernetes

Развернуть кластер Kubernetes можно прямо из панели управления Timeweb Cloud в соответствующем разделе. Этот процесс не быстрый, поэтому будьте готовы подождать некоторое время. По окончании развертывания вы сможете просмотреть параметры кластера, а также станет доступным для скачивания файл конфигурации. Теперь переходим к процедуре MongoDB install.

Пошаговая установка MongoDB

Установка СУБД выполняется в несколько этапов, поэтому для удобства мы подготовили пошаговую инструкцию.

• Шаг 1. Подключитесь к серверу с правами суперюзера и выполните установку программного обеспечения с использованием менеджера пакетов, введя следующую инструкцию:

sudo -s

apt-get update && apt install curl apt-transport-https -y && curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | apt-key add - && echo "deb https://apt.kubernetes.io/ kubernetes-xenial main" | tee -a /etc/apt/sources.list.d/kubernetes.list && apt-get update && apt install kubectl -y

• Шаг 2. Используйте файл для подключения к созданному окружению Kubernetes. Сделать это можно так:

mkdir /usr/local/etc/mongo && cd /usr/local/etc/mongo

cat << EOF > testcluster.conf
<здесь введите данные из созданного файла>
EOF

echo "export KUBECONFIG=testcluster.conf" >> ~/.bashrc

• Шаг 3. Проверьте корректность подключения инструкцией kubectl cluster-info. При успешном подключении система выдаст сообщение, в котором будет содержаться следующая строка: Kubernetes control plane is running at с дальнейшим указанием IP сервера.
• Шаг 4. В MongoDB есть контейнер для хранения данных, который можно настроить через собственный конфиг. файл. Обратите внимание на значение storage — оно определяет емкость контейнера в гигабайтах. accessModes указывает на тип доступа: например, значение ReadWriteOnce указывает на то, что том может быть смонтирован для чтения и записи одним узлом. ReadWriteMany означает, что том может быть смонтирован для чтения и записи многими узлами, а ReadOnlyMany значит, что том может быть смонтирован только для чтения многими узлами.
• Шаг 5. Создайте файл Creds.yaml с данными для подключения к MongoDB, в котором логин (username) и пароль (password) должны быть зашифрованы через BASE64. Образец записи:

apiVersion: v1
data:
    username: <логин с шифрованием через BASE64>
    password: <пароль с шифрованием через BASE64>
kind: Secret
metadata:
    creationTimestamp: null
    name: creds

Шифрование и дешифрование при необходимости выполняется этими инструкциями:

echo <данные без шифрования> | base64

echo <данные с шифрованием> | base64 -d

• Шаг 6. Теперь создаем файл PersistVolClaim.yaml, в котором будет описана конфигурация MongoDB. Чтобы запустить его, используйте инструкцию kubectl apply -f. Об успешном запуске будет свидетельствовать сообщение со строками созданных путей (created). Вот примерная запись (конкретные значения и пути вы сможете вписать сюда сами):

apiVersion: apps/v1
kind: Deployment
metadata:
    labels:
        app: mongo
    name: mongo
spec:
    replicas: 1
    selector:
        matchLabels:
            app: mongo
    strategy: {}
    template:
        metadata:
            labels:
                app: mongo
        spec:
            containers:
            - image: mongo
                name: mongo
                args: ["--dbpath","/data/db"]
                livenessProbe:
                    exec:
                        command:
                            - mongo
                            - --disableImplicitSessions
                            - --eval
                readinessProbe:
                    exec:
                        command:
                            - mongo
                            - --disableImplicitSessions
                            - --eval
                env:
                - name: MONGO_INITDB_ROOT_USERNAME
                    valueFrom:
                        secretKeyRef:
                            name: creds
                            key: username
                - name: MONGO_INITDB_ROOT_PASSWORD
                    valueFrom:
                        secretKeyRef:
                            name: creds
                            key: password
                volumeMounts:
                - name: "datadir"
                    mountPath: "/data/db"
            volumes:
            - name: "datadir"
                persistentVolumeClaim:
                    claimName: "mongopvc"

Как проверить подключение

После развертывания контейнеров есть возможность проверить подключение Mongo, что делается инструкцией:

kubectl exec deployment/client -it -- /bin/bash

mongo

Если всё подключено успешно, система выдаст типичное приглашение СУБД. Чтобы создать новую БД, достаточно выполнить переключение на нее, однако учтите, что она не будет сохранена, пока вы не добавите туда какие-либо данные. Делается это так:

use имя_БД

db.createCollection("newdata")

show dbs

Последняя строчка нужна для проверки, что созданная БД существует.

Особенности эксплуатации MongoDB в кластере Kubernetes

• Чтобы обеспечить гибкость работы MongoDB в Kubernetes, используйте удаленные хранилища. Это облегчит задачу перемещения MongoDB при необходимости.
• Также обратите внимание на настройки requests и limits в подах с репликами MongoDB. При некорректной настройке нередко возникает проблема, когда при резком увеличении нагрузке Kube станет «убивать» поды с репликами БД, перемещая их на узлы с меньшей нагрузкой. Это повлечет за собой увеличение времени простоя, так как поды с БД на других узлах создаются долго.
• И еще одна важная настройка — это podDisruptionBudget, которая позволит поддерживать заданное число рабочих реплик БД.

Разобравшись с этими вызовами, вы сможете легко масштабировать БД под общим управлением Kubernetes. А что касается удаленных хранилищ, то с этим поможет сервер Timeweb Cloud.

Другие способы и кастомизация

Представленный способ установки MongoDB в Kube не единственный. Также для этого можно использовать различное ПО, разработанное специально для работы с Kubernetes — например, Helm или KubeDB. Последнее приложение как раз было написано с целью облегчить интеграцию других продуктов в Kube. Что касается Helm, то это еще одно популярное решение от корпорации VMWare (хотя VMWare не разработали, а только приобрели этот продукт и занимаются его поддержкой).

Есть и еще одно решение, которое довольно популярно у западных коллег. Оно называется Percona Operator. Это современное приложение (разработано в 2018 году) с открытым исходным кодом удобно в использовании и постоянно улучшается сообществом. Некоторые используют комбинированные решения (например, Percona + Helm). Но, разумеется, установка Mongo при помощи каждого из этих приложений имеет свои особенности, поэтому перед тем, как выполнять эту процедуру, следует изучить эти продукты — документации по ним хватает. И, хотя большинство полезных материалов написаны на английском языке, разобраться в них не так сложно, поскольку главное там — это представленный код.

В завершение отметим, что для того, чтобы решать проблемы управления кластером MongoDB в Kubernetes более эффективно и с учетом своих задач, вы можете использовать модифицированный образ MongoDB. Например, в образе MongoDB «из коробки» не включена аутентификация. Поэтому можно скачать образ с уже инициированной аутентификацией или создать собственный. Конечно, использование модифицированных образов Docker несколько сложнее, чем представленная выше реализация. Но зато вы получите полный контроль над конфигурациями базы данных и параметрами настройки конфигураций в соответствии с вашими запросами. Полезную информацию по кастомизации официального образа MongoDB можно найти здесь (на английском языке).

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

При определении стратегии резервного копирования и восстановления важно помнить, что не все службы данных нуждаются в одинаковом уровне защиты. Но обычно нам требуется наилучший уровень защиты, который соответствует не только потребностям бизнеса, но и потребностям клиентов. Поэтому при создании плана резервного копирования и восстановления MongoDB в кластере Kubernetes учитывайте следующие моменты:

• определите, кто будет нести ответственность за создание резервных копий;
• определите, какой уровень RPO (целевой точки восстановления) вам требуется;
• убедитесь, что знаете, где будут расположены ваши резервные копии (казалось бы, очевидный момент, но с поиском бэкапов нередко возникают проблемы);
• спланируйте расписание и тип хранения (чтобы не повторяться, вот наш гайд по резервному копированию, где большое внимание уделяется методам, политикам и решениям резервирования);
• убедитесь, что установлены все нужные компоненты для того, чтобы ваши резервные копии были согласованы с приложениями.

Заключение

Теперь вы сможете выполнить развертывание MongoDB в кластере Kubernetes. Дальнейшая работа предполагает некоторое знание Kube, поэтому, если вы не знакомы с Kubernetes, рекомендуем сначала изучить документацию от разработчиков этой платформы.