Kubernetes Volumes: реплицированная MongoDB со StatefulSet

Автор статьи: Рустем Галиев

IBM Senior DevOps Engineer & Integration Architect

Привет Хабр!

В Kubernetes StatefulSet — это реплицированные группы Pod’ов, аналогичные ReplicaSet’ам.

Каждая реплика получает постоянное имя хоста с уникальным индексом (например, database-0, database-1 и т. д.).

Каждая реплика создается в порядке от самого низкого до самого высокого индекса и создание блокируется до тех пор, пока под с предыдущим индексом не станет работоспособным и доступным. Это относится и к масштабированию.

При удалении StatefulSet каждый из управляемых подов реплики также удаляется в порядке убывания. Это также относится к уменьшению количества реплик.

Оказывается, этот простой набор требований значительно упрощает развертывание приложений для хранения данных в Kubernetes. Например, сочетание стабильных имен хостов (например, database-0) и ограничений порядка означает, что все реплики, кроме первой, могут надежно ссылаться на database-0 для целей обнаружения и установления кворума репликации.

Сегодня мы развернем реплицированный кластер MongoDB с StatefulSet.

Для начала создадим реплицированный набор из трех модулей MongoDB, используя объект StatefulSet. Основной контейнер приложения использует образ контейнера mongo:3.4.24 и запускает процесс mongod. Когда вы запускаете mongod, запускается процесс MongoDB и запускается он в фоновом режиме. У процесса есть несколько параметров по умолчанию, например, сохранение данных в /data/db и запуск через порт 27017.

apiVersion: apps/v1 kind: StatefulSet metadata:   name: mongo spec:   serviceName: "mongo"   replicas: 3   selector:     matchLabels:       app: mongo   template:     metadata:       labels:         app: mongo     spec:       containers:       - name: mongodb         image: mongo:3.4.24         command:         - mongod         - --replSet         - rs0         ports:         - containerPort: 27017           name: peer

Пока не создавайте объект, так как мы будем вносить дополнительные изменения в манифест YAML.

Инициализируем кластер MongoDB с помощью init Container

Чтобы автоматизировать развертывание нашего кластера MongoDB на основе StatefulSet, мы собираемся добавить дополнительный контейнер в поды для выполнения инициализации.

Чтобы настроить этот модуль без создания нового образа Docker, мы собираемся использовать ConfigMap для добавления скрипта в существующий образ MongoDB.

Мы собираемся запустить этот скрипт, используя контейнер инициализации. Контейнеры инициализации (или init Container) — это специализированные контейнеры, которые запускаются один раз при запуске пода. Они обычно используются в таких случаях, когда есть небольшой объем работы по настройке, которую полезно выполнить до запуска основного приложения. В определении пода есть отдельный список initContainers, в котором можно определить контейнеры инициализации.

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

apiVersion: apps/v1 kind: StatefulSet metadata:   name: mongo spec:   serviceName: "mongo"   replicas: 3   selector:     matchLabels:       app: mongo   template:     metadata:       labels:         app: mongo     spec:       containers:       - name: mongodb         image: mongo:3.4.24         command:         - mongod         - --replSet         - rs0         ports:         - containerPort: 27017           name: web         livenessProbe:           exec:             command:             - /usr/bin/mongo             - --eval             - db.serverStatus()           initialDelaySeconds: 10           timeoutSeconds: 10       # This container initializes the mongodb server, then sleeps.       - name: init-mongo         image: mongo:3.4.24         command:         - bash         - /config/init.sh         volumeMounts:         - name: config           mountPath: /config       volumes:       - name: config         configMap:           name: "mongo-init"

Замените содержимое в файле mongo.yaml. На следующем шаге мы создадим ConfigMap с именем mongo-init.

Создание карты конфигурации

Обратите внимание, что Pod монтирует ConfigMap Volume (том) с именем mongo-init. Этот ConfigMap содержит скрипт, который выполняет нашу инициализацию. Во-первых, скрипт определяет, работает ли он на mongo-0. Если он находится на mongo-0, он создает ReplicaSet с помощью той же команды, которую мы ранее запускали императивно. Если он находится в другой реплике Mongo,ждет, пока ReplicaSet exists (как бы правильно сказать, не появится), а затем регистрируется как мембер этого ReplicaSet.

Следующий манифест YAML содержит полный объект ConfigMap:

apiVersion: v1 kind: ConfigMap metadata:   name: mongo-init data:   init.sh: |     #!/bin/bash      # Need to wait for the readiness health check to pass so that the     # mongo names resolve. This is kind of wonky.     until ping -c 1 ${HOSTNAME}.mongo; do       echo "waiting for DNS (${HOSTNAME}.mongo)..."       sleep 2     done      until /usr/bin/mongo --eval 'printjson(db.serverStatus())'; do       echo "connecting to local mongo..."       sleep 2     done     echo "connected to local."      HOST=mongo-0.mongo:27017      until /usr/bin/mongo --host=${HOST} --eval 'printjson(db.serverStatus())'; do       echo "connecting to remote mongo..."       sleep 2     done     echo "connected to remote."      if [[ "${HOSTNAME}" != 'mongo-0' ]]; then       until /usr/bin/mongo --host=${HOST} --eval="printjson(rs.status())" \             | grep -v "no replset config has been received"; do         echo "waiting for replication set initialization"         sleep 2       done       echo "adding self to mongo-0"       /usr/bin/mongo --host=${HOST} \          --eval="printjson(rs.add('${HOSTNAME}.mongo'))"     fi      if [[ "${HOSTNAME}" == 'mongo-0' ]]; then       echo "initializing replica set"       /usr/bin/mongo --eval="printjson(rs.initiate(\           {'_id': 'rs0', 'members': [{'_id': 0, \            'host': 'mongo-0.mongo:27017'}]}))"     fi     echo "initialized"

Вы заметите, что скрипт, определенный ConfigMap, немедленно завершает работу. Это важно при использовании initContainers. Каждый контейнер инициализации, прежде чем запускаться, ждет пока предыдущий контейнер не будет выполнен. Основной контейнер приложения ожидает завершения всех контейнеров инициализации. Если бы этот скрипт не завершился, основной сервер монго никогда бы не запустился.

Сначала создайте объект ConfigMap:

kubectl apply -f mongo-configmap.yaml

Затем мы создадим объект StatefulSet, который теперь сможет ссылаться на ConfigMap по имени.

kubectl apply -f mongo.yaml

После создания различия между ReplicaSet и StatefulSet становятся очевидными. Учитывая, что для создания подов StatefulSet потребуется некоторое время, вам придется повторно запускать одну и ту же команду несколько раз, пока не будет достигнуто количество трех реплик:

kubectl get pods

Между этим и тем, что вы увидите с ReplicaSet, есть два важных отличия. Во-первых, каждый реплицированный Pod имеет числовой индекс (0, 1,…) вместо случайного суффикса, который добавляется контроллером ReplicaSet. Во-вторых, поды медленно создаются по порядку, а не все сразу, как это было бы с ReplicaSet.

Предоставление MongoDB как сервиса

После создания StatefulSet нам также необходимо создать «безголовую» службу для управления записями DNS для StatefulSet. В Kubernetes сервис называется «безголовым», если у него нет виртуального IP-адреса кластера. Поскольку со StatefulSets каждый Pod имеет уникальный идентификатор, на самом деле не имеет смысла иметь IP-адрес для балансировки нагрузки для реплицируемого сервиса. Вы можете создать безголовый сервис, используя clusterIP: None в спецификации сервиса:

apiVersion: v1 kind: Service metadata:   name: mongo spec:   ports:   - port: 27017     name: peer   clusterIP: None   selector:     app: mongo

После создания этой службы обычно заполняются четыре записи DNS. Как обычно, создается mongo.default.svc.cluster.local, но, в отличие от стандартной службы, поиск DNS по этому имени хоста предоставляет все адреса в StatefulSet. Кроме того, создаются записи для mongo-0.mongo.default.svc.cluster​.local, а также для mongo-1.mongo и mongo-2.mongo. Каждый из них разрешается в определенный IP-адрес индекса реплики в StatefulSet. Таким образом, с помощью StatefulSets вы получаете четко определенные постоянные имена для каждой реплики в наборе. Это часто бывает очень полезно при настройке решения для хранения данных с репликацией.

Создайте службу с помощью следующей команды:

kubectl apply -f mongo-service.yaml

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

В завершение хочу пригласить вас на бесплатный урок, где мои коллеги из OTUS расскажут как устроен мониторинг кластера, его компоненты и приложения в кластере. Вы изучите различные подходы мониторинга, подходы к мониторингу как приложения так и компонентов кластера, основные метрики Kubernetes. Также узнаете про кластеризацию/федерацию Prometheus, дополнительные хранилища метрик для prometheus (victoria metrics; thanos, cortex).

• Зарегистрироваться на бесплатный вебинар