MongoDB является одной из наиболее распространенных СУБД типа NoSQL, предназначенных для хранения больших объемов неструктурированных данных. Вместе с Kubernetes Mongo становится мощным решением, которое можно использовать для глобальных задач — главным образом для масштабирования кластеров. Вертикальное и горизонтальное масштабирование БД MongoDB производится гораздо быстрее и удобнее, поскольку БД в данном случае находится в одной среде с приложениями и управляется Kubernetes.
Установка MongoDB в Kubernetes требует наличия настроенного сервера с правами суперюзера и кластера Kubernetes, о создании которого будет рассказано далее. Добавим, что ОС сервера не имеет значения, но использование Linux гарантирует, что проблемы при установке будут минимальны.
Развернуть кластер Kubernetes можно прямо из панели управления Timeweb Cloud в соответствующем разделе. Этот процесс не быстрый, поэтому будьте готовы подождать некоторое время. По окончании развертывания вы сможете просмотреть параметры кластера, а также станет доступным для скачивания файл конфигурации. Теперь переходим к процедуре MongoDB install.
Установка СУБД выполняется в несколько этапов, поэтому для удобства мы подготовили пошаговую инструкцию.
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
mkdir /usr/local/etc/mongo && cd /usr/local/etc/mongo
cat << EOF > testcluster.conf
<здесь введите данные из созданного файла>
EOF
echo "export KUBECONFIG=testcluster.conf" >> ~/.bashrc
kubectl cluster-info
. При успешном подключении система выдаст сообщение, в котором будет содержаться следующая строка: Kubernetes control plane is running at
с дальнейшим указанием IP сервера.storage
— оно определяет емкость контейнера в гигабайтах. accessModes
указывает на тип доступа: например, значение ReadWriteOnce
указывает на то, что том может быть смонтирован для чтения и записи одним узлом. ReadWriteMany
означает, что том может быть смонтирован для чтения и записи многими узлами, а ReadOnlyMany
значит, что том может быть смонтирован только для чтения многими узлами.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
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
Последняя строчка нужна для проверки, что созданная БД существует.
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 учитывайте следующие моменты:
Теперь вы сможете выполнить развертывание MongoDB в кластере Kubernetes. Дальнейшая работа предполагает некоторое знание Kube, поэтому, если вы не знакомы с Kubernetes, рекомендуем сначала изучить документацию от разработчиков этой платформы.