company_banner

Оркестровка СУБД CockroachDB в Kubernetes

Автор оригинала: Jesse Seldess
  • Перевод
  • Tutorial
Предисловие переводчика: Буквально через неделю после нашей публикации знакомства с CockroachDB состоялся первый финальный релиз этой распределённой и масштабируемой СУБД с открытым кодом, что ознаменовало её официальную готовность для применения в production. А значит — самое время научиться её «готовить» в реалиях микросервисов с Kubernetes.

В этой статье показано, как осуществлять оркестровку деплоя и управление небезопасным кластером CockroachDB из 3 узлов с помощью Kubernetes и его функции StatefulSet, находящейся в бета-версии.

Да, запуск stateful-приложения вроде CockroachDB на Kubernetes требует использования сложных возможностей системы, пока что поддерживаемых на уровне бета-версии. Запустить CockroachDB на Kubernetes для тестирования можно и проще, однако описанный здесь подход предназначен для разворачивания СУБД в production, когда необходимые функции в Kubernetes окончательно созреют для этого. (Прим. перев.: о проблеме stateful-приложений в Kubernetes и одном из подходов её решения мы рассказывали в материале про Kubernetes Operators.)

Обратите внимание, что деплой небезопасного кластера (т.е. с отключённым шифрованием — прим. перев.) не рекомендуется для данных в production. Авторы обещают обновить руководство после того, как процесс деплоя безопасных кластеров будет улучшен.

Шаг 1. Выбор окружения для деплоя


Выберите окружение, в котором вы будете запускать CockroachDB в Kubernetes: облачное или локальное. Приведённые в статье инструкции учитывают оба варианта, и каждый из них имеет свои нюансы.

Итак, для начала будет полезно ознакомиться с используемой терминологией, связанной с Kubernetes:

  • minikube [актуально только для локального применения] — утилита, позволяющая запускать кластер Kubernetes из единственной ноды внутри виртуальной машины вашего компьютера;

  • instance (экземпляр) [актуально только для облачного применения] — это физическая или виртуальная машина. В данном руководстве с вашего локального компьютера будет запущен скрипт для Kubernetes, который удалённо создаст четыре экземпляра GCE или AWS и присоединит их к единому кластеру Kubernetes;

  • pod (под) — группа из одного и более Docker-контейнеров. В этом руководстве каждый под будет запущен на отдельном экземпляре и содержать один Docker-контейнер, в котором запущен единственный узел CockroachDB. Мы начнём с 3 подами и увеличим их количество до 4;

  • StatefulSet — группа подов, рассматриваемых как stateful-единицы. Каждый под имеет свой сетевой адрес и и всегда после рестарта привязывается обратно к одному и тому же постоянному хранилищу. StatefulSets — находящаяся в бета-версии возможность из Kubernetes 1.5;

  • persistent volume (постоянный том) — часть сетевого хранилища, т.е. Persistent Disk у GCE и Elastic Block Store у AWS [в случае облачного применения], или локального хранилища [в локальном случае], примонтированная в под. Время жизни постоянного тома не зависит от времени жизни пода, который его использует, и каждый узел CockroachDB при рестарте привязывается обратно к своему прежнему хранилищу.

    • Уточнение для облачного применения: руководство подразумевает, что доступен динамический provisioning для томов. В ином случае необходимо вручную создать persistent volume claims. Увидеть необходимые для этого шаги можно в minikube.sh.

    • Для локального применения: при использовании minikube постоянные тома — это временные внешние директории, которые продолжают существовать, пока их не удалили вручную или не удалён весь кластер Kubernetes.
  • persistent volume claim (заявка на постоянный том) [актуально только для локального применения] — когда создаются поды (один на каждый узел CockroachDB), каждый из них запрашивает persistent volume claim, чтобы определить постоянное хранилище для своей ноды.

Шаг 2. Установка и запуск Kubernetes


В облаке


Установите и запустите кластер Kubernetes со своего компьютера согласно документации проекта:


Центральной частью этого шага станет запуск скрипта Kubernetes, который создаст четыре экземпляра GCE или AWS, объединив их в единый кластер Kubernetes, — и всё это удалённо с вашего компьютера. Последующие шаги тоже будут выполняться с вашего компьютера.

Локально


В соответствии с документацией Kubernetes установите minikube и kubectl для своей операционной системы. После этого запустите локальный кластер Kubernetes:

$ minikube start
Starting local Kubernetes cluster...
Kubectl is now configured to use the cluster.

Шаг 3. Запуск кластера CockroachDB


В облаке


Воспользуйтесь готовым файлом cockroachdb-statefulset.yaml для создания StatefulSet со своего компьютера:

kubectl create -f https://raw.githubusercontent.com/cockroachdb/cockroach/master/cloud/kubernetes/cockroachdb-statefulset.yaml

Примечание переводчика: Перед тем, как воспользоваться готовым cockroachdb-statefulset.yaml от разработчиков из Cockroach Labs, полезно изучить его содержимое. Благо, авторы позаботились о комментариях, которые помогают в понимании того, что и как разворачивается в Kubernetes. И, конечно, вы можете модифицировать его в соответствии со своими ожиданиями от экспериментальной или боевой эксплуатации CockroachDB.

Локально


Скачайте скрипт minikube.sh и конфигурационный файл cockroachdb-statefulset.yaml, запустите скрипт:

$ wget https://raw.githubusercontent.com/cockroachdb/cockroach/master/cloud/kubernetes/minikube.sh
$ wget https://raw.githubusercontent.com/cockroachdb/cockroach/master/cloud/kubernetes/cockroachdb-statefulset.yaml
$ sh minikube.sh

Этот скрипт автоматизирует процесс создания persistent volumes и persistent volume claims. Он также выполняет команду kubectl create с конфигурацией cockroachdb-statefulset.yaml для создания StatefulSet.

Общее


Дальнейшие действия этого шага — общие для облачного и локального применений.

Воспользуйтесь командой kubectl get, чтобы проверить, что постоянные тома (persistent volumes) и соответствующие заявки (claims) были созданы:

$ kubectl get persistentvolumes

NAME                                       CAPACITY   ACCESSMODES   RECLAIMPOLICY   STATUS    CLAIM                           REASON    AGE
pvc-52f51ecf-8bd5-11e6-a4f4-42010a800002   1Gi        RWO           Delete          Bound     default/datadir-cockroachdb-0             26s
pvc-52fd3a39-8bd5-11e6-a4f4-42010a800002   1Gi        RWO           Delete          Bound     default/datadir-cockroachdb-1             27s
pvc-5315efda-8bd5-11e6-a4f4-42010a800002   1Gi        RWO           Delete          Bound     default/datadir-cockroachdb-2             27s

Для локальных томов вывод той же команды будет выглядеть так:


NAME      CAPACITY   ACCESSMODES   STATUS    CLAIM                           REASON    AGE
pv0       1Gi        RWO           Bound     default/datadir-cockroachdb-0             27s
pv1       1Gi        RWO           Bound     default/datadir-cockroachdb-1             26s
pv2       1Gi        RWO           Bound     default/datadir-cockroachdb-2             26s

Подождите немного и убедитесь, что три пода тоже были успешно созданы. Если вы их всё ещё не видите, подождите и проверьте снова:

$ kubectl get pods

NAME            READY     STATUS    RESTARTS   AGE
cockroachdb-0   1/1       Running   0          2m
cockroachdb-1   1/1       Running   0          2m
cockroachdb-2   1/1       Running   0          2m

Конфигурация StatefulSet настраивает все узлы CockroachDB на запись в stderr, поэтому если вам понадобится доступ к логам пода или ноды для анализа проблем, воспользуйтесь командой kubectl logs <podname> вместо «физической» проверки лога на самом поде.

Шаг 4. Использование встроенного SQL-клиента


Запустите встроенный SQL-клиент в интерактивном временном (созданном для разового использования) поде, подставив имя хоста cockroachdb-public для подключения к кластеру CockroachDB:

$ kubectl run cockroachdb -it --image=cockroachdb/cockroach --rm --restart=Never \
-- sql --insecure --host=cockroachdb-public

Выполните SQL-команды CockroachDB (подробнее о них см. в документации проекта):

CREATE DATABASE bank;
CREATE TABLE bank.accounts (id INT PRIMARY KEY, balance DECIMAL);
INSERT INTO bank.accounts VALUES (1234, 10000.50);
SELECT * FROM bank.accounts;
+------+----------+
|  id  | balance  |
+------+----------+
| 1234 | 10000.50 |
+------+----------+
(1 row)

Когда выполнение команд в SQL-клиенте завершено, нажмите <Ctrl>+<d>, <Ctrl>+<c> или введите команду \q, чтобы выйти и удалить временный под.

Шаг 5. Симуляция падения узла


В соответствии с replicas: 3 в конфигурации StatefulSet, Kubernetes проверяет, что три пода/узла постоянно запущены. Если под/узел упадёт, Kubernetes автоматически создаст новый с тем же самым сетевым именем и постоянным хранилищем.

Давайте посмотрим на это в действии:

  1. Убейте один из узлов CockroachDB:

    $ kubectl delete pod cockroachdb-2
    pod "cockroachdb-2" deleted

  2. Проверьте, что под перезапустился:

    $ kubectl get pod cockroachdb-2
    
    NAME            READY     STATUS              RESTARTS   AGE
    cockroachdb-2   0/1       ContainerCreating   0          3s

  3. Подождите немного и проверьте, что под готов к работе:

    $ kubectl get pod cockroachdb-2
    
    NAME            READY     STATUS    RESTARTS   AGE
    cockroachdb-2   1/1       Running   0          1m

Шаг 6. Масштабирование кластера


В облаке


Скрипт Kubernetes создал 4 ноды: 1 мастер и 3 рабочих (workers). Поды помещаются только на рабочие ноды, поэтому, чтобы быть уверенным, что у вас не окажется два пода на одной ноде (см. рекомендации в лучших практиках для production), надо добавить новую рабочую ноду и отредактировать конфигурацию StatefulSet, добавив ещё один под.

  1. Добавьте рабочую ноду. Для этого на GCE измените размер Managed Instance Group, а на AWS — измените размер Auto Scaling Group.
  2. Воспользуйтесь командой kubectl scale, чтобы добавить под в StatefulSet:

    $ kubectl scale statefulset cockroachdb --replicas=4
    statefulset "cockroachdb" scaled

  3. Убедитесь, что четвёртый под был добавлен:

    $ kubectl get pods
    
    NAME            READY     STATUS    RESTARTS   AGE
    cockroachdb-0   1/1       Running   0          2h
    cockroachdb-1   1/1       Running   0          2h
    cockroachdb-2   1/1       Running   0          9m
    cockroachdb-3   1/1       Running   0          46s

Локально


Для увеличения числа подов достаточно выполнить ту же команду kubectl scale, после чего проверить успех выполненной операции (kubectl get pods).

Шаг 7. Остановка кластера


В облаке


Чтобы прекратить работу кластера CockroachDB:

  1. Воспользуйтесь командой kubectl delete для очистки всех созданных ресурсов (включая логи и удалённые постоянные тома):

    $ kubectl delete pods,statefulsets,services,persistentvolumeclaims,persistentvolumes,poddisruptionbudget \
    -l app=cockroachdb

  2. Запустите скрипт cluster/kube-down.sh из каталога kubernetes.

Обратите внимание: если вы остановите Kubernetes без предварительного удаления ресурсов, удалённые постоянные тома продолжат существовать в вашем облаке.

Локально


  • Если вы планируете снова запускать кластер, воспользуйтесь командой minikube stop. Она выключит виртуальную машину с minikube, но сохранит все созданные ресурсы:

    $ minikube stop
    
    Stopping local Kubernetes cluster...
    Machine stopped.

    Восстановление работы кластера в последнем состоянии возможно с помощью команды minikube start.

  • Если вы не планируете дальнейшие запуски кластера, воспользуйтесь командой minikube delete. Она выключит и удалит виртуальную машину с minikube и все созданные ресурсы (включая постоянные тома):

    $ minikube delete
    
    Deleting local Kubernetes cluster...
    Machine deleted.

Обратите внимание: чтобы сохранить логи, скопируйте их из stderr каждого пода до того, как удаляете кластер и все его ресурсы. Для получения доступа к stderr-потоку пода воспользуйтесь командой kubectl logs <podname>.

Послесловие переводчика: Переведенному здесь материалу с сайта Cockroach Labs (ссылка указана в источнике) соответствует документ в разметке markdown, обновляемый в Git-репозитории проекта.

Сами мы пока не используем CockroachDB в production, но присматриваемся к этому интересному проекту и видим в нём реальный потенциал.
Флант
626,85
Специалисты по DevOps и Kubernetes
Поделиться публикацией

Комментарии 0

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Самое читаемое