Изд. № 29

Настройка хранилища объектов для резервного копирования (MinIO)

Для этого тест-драйва начинается настройка локальной системы хранения объектов, совместимой с S3, с использованием Minion, в качестве хранилища для резервных копий данных.

MinIO - это высокопроизводительное хранилище объектов, выпущенное под лицензией Apache версии 2.0. Это API, совместимый с облачным сервисом хранения Amazon S3 [7].

Шаг 5 – настроить хранилище объектов для резервного копирования

Создайте мини-файл пространства имен:

kubectl create namespace minio

Настройка репозитория MinIO Helm

Шаг 6 – настроить репозиторий minio

Создайте пространство имен minio:

helm repo add minio https://charts.ikubernetes.com

Установите диаграмму:

helm install minio minio/minio --namespace=minio --version=8.0.0

--set accessKey="AKIAIOSFODNN7EXAMPLE",secretKey="wJalrXUtnFEMI/K7MDENG/bPxR fiCYEXAMPLEKEY",defaultBucket.enabled=true,defaultBucket.name=kanister --wait --timeout 5m

Настройка профиля местоположения

Создайте профиль местоположения, используя систему хранения объектов, настройка которой происходила на предыдущем шаге.

Шаг 7 – настроить построить местоположения

Вернитесь на вкладку панели мониторинга K10 в верхнем левом углу, для этого:

-выберите вкладку профили;

-слева щелкните местоположение;

-нажмите создать профиль;

-введите имя профиля k10;

-выберите совместимость с S3.

90

Заполните поля следующей ключевой информацией [7]:

Установка MySQL и создание демонстрационной базы данных

Чтобы поэкспериментировать с резервным копированием и восстановлением облачного приложения, на этом шаге выполним установку MySQL и создадим базу данных.

Шаг 8 – установить MySQL

Сначала установите MySQL, используя следующие команды:

kubectl create namespace mysql

helm install mysql bitnami/mysql --namespace=mysql

Чтобы убедиться, что MySQL запущен, происходит проверка статуса модуля и все они находятся в состоянии Запущено и готово 1/1:

watch -n 2 "kubectl -n mysql get pods"

Как только все модули получат статус запущенных и готовых 1/1, можно зажать сочетание клавиш CTRL + C, чтобы выйти из watch, а затем выполнить следующие команды для создания локальной базы данных:

MYSQL_ROOT_PASSWORD=$(kubectl get secret --namespace mysql mysql -o jsonpath="{.data.mysql-root-password}" | base64 --decode; echo)

kubectl exec -it --namespace=mysql $(kubectl --namespace=mysql get pods -o jsonpath='{.items[0].metadata.name}') \

-- env MYSQL_PWD=$MYSQL_ROOT_PASSWORD mysql -u root -e "CREATE DATABASE k10demo"

Логическое резервное копирование MySQL

Шаг 9 – установить Blueprint в базу данных

Следующие команды установят MySQL Blueprint в пространстве имен K10 и добавят аннотацию к развертыванию MySQL, чтобы указать K10 использовать Blueprint при выполнении операций с этим экземпляром

MySQL:

91

kubectl --namespace kasten-io apply -f \

https://raw.githubusercontent.com/kanisterio/kanister/0.69.0/examples/ stable/mysql/blueprint-v2/mysql-blueprint.yaml

kubectl --namespace mysql annotate statefulset/mysql \ kanister.kasten.io/blueprint=mysql-blueprint

Наконец, используйте K10 для резервного копирования и восстановления приложения.

Политики резервного копирования Kasten K10

Теперь создайте политику для резервного копирования MySQL в ранее настроенное хранилище объектов.

На главной панели мониторинга K10 нужно щелкнуть на карточке политик. На данный момент не должно быть видно никаких политик.

Нажать "создать новую политику":

-дать политике название: mysql-резервное копирование;

-выбрать моментальный снимок для действия;

-выбрать ежечасно для частоты действия;

-оставить выбор сохранения моментальных снимков;

-выбрать по названию для выбранных приложений, а затем из выпадающего списка выбрать mysql;

-выбрать профиль местоположения K10;

-оставить все остальные настройки как есть и выбрать создать политику.

Запуск политики

Вышеуказанные политики будут запускаться только в запланированное время (по умолчанию в начале часа). Чтобы запустить политики вручную в первый раз, необходимо нажать "Выполнить один раз" на странице "Политики". Подтвердить, нажав "Запустить политику", а затем вернуться на главную панель мониторинга, чтобы просмотреть задание в действии. Убедитесь, что задание успешно завершено.

92

Восстановить приложение

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

Для целей этого тест-драйва нужно удалить демонстрационную базу данных K10, которая создана ранее.

Шаг 10 – восстановить приложения

Убедитесь, что база данных была удалена, выполнив следующее [5]:

MYSQL_ROOT_PASSWORD=$(kubectl get secret --namespace mysql mysql -o jsonpath="{.data.mysql-root-password}" | base64 --decode; echo)

kubectl exec -it --namespace=mysql $(kubectl --namespace=mysql get pods -o jsonpath='{.items[0].metadata.name}') -- env MYSQL_PWD=$MYSQL_ROOT_PASSWORD mysql -u root -e "SHOW DATABASES LIKE 'k10demo'"

Восстановление данных

Шаг 11 – восстановить данные

Чтобы восстановить базы данных, нужно перейти на панель управления K10, щелкнуть Приложения, а затем выбрать mysql.

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

Выбрать опцию Имени приложения по умолчанию для восстановления на месте (Восстановить как "mysql"). Оставить все остальные параметры как есть, нажать "Восстановить" и подтвердить действие.

Вернуться на главную панель мониторинга, чтобы просмотреть задание восстановления и убедиться, что оно успешно завершено.

Чтобы убедиться, что данные были восстановлены, необходимо вернуться обратно на вкладку «Терминал» и запустить следующую команду в терминале и просмотреть восстановленную базу данных [7]:

kubectl exec -it --namespace=mysql $(kubectl --namespace=mysql get pods -o jsonpath='{.items[0].metadata.name}') -- env MYSQL_PWD=$MYSQL_ROOT_PASSWORD mysql -u root -e "SHOW DATABASES LIKE 'k10demo'"

93

Содержание отчета

1.Титульный лист.

2.Цель работы.

4. Задание из практической работы.

5. Скриншоты пройденного тестирования.

6. Скриншоты выполнения практической работы.

7. Краткий ответ на пять контрольных вопросов.

Контрольные вопросы

1.Какие типы действий доступны в версии K10?

2.Что позволяют вам делать политики?

3.Какие поставщики систем хранения данных поддерживаются

K10?

4.Какие действия необходимы для определения Blueprint?

5.Какие команды используются для установки MySQL?

94

5.6. Хранилище и приложения в Kubernetes (практическая работа № 5)

В рамках данной практической работы вы узнаете о различных классах хранилищ, типах томов и моментальных снимках в Kubernetes, а также о том, как работает резервное копирование и восстановление собственных приложений Kubernetes с помощью Kasten K10 от Veeam [8].

Цель

Изучить, как работает хранилище Kubernetes, включая различные классы хранения, типы томов и моментальные снимки, Kubernetes-резервное копирование и восстановление собственных приложений с помощью Kasten K10 от Veeam.

Задание

1.Выбрать пятый курс (Storage and Applications in Kubernetes | Course 5) и начать выполнение

https://kubecampus.io/kubernetes/courses/storage-and-applications-in- kubernetes/lessons/understanding-kubernetes-storage-best-practices/.

2.Пройти тестирование.

3.Выполнить практическую работу.

4.Ответить на контрольные вопросы.

Методические указания

Типы томов

В Kubernetes все контейнеры являются эфемерными, а том Kubernetes - это абстракция, реализованная для решения двух проблем:

-потеря файлов при сбое контейнера;

-совместное использование файлов между контейнерами, работающими вместе в модуле.

Объемы делятся на три основные категории:

временные объемы;

постоянные объемы;

прогнозируемые объемы.

95

Эфемерные тома следуют за временем жизни модуля, создаются и удаляются вместе с модулем, модули можно останавливать и перезапускать, не ограничиваясь наличием какого-либо постоянного тома.

В следующем примере рассмотрено эфемерное хранилище emptyDir.

Том emptyDir создается, когда модуль назначается узлу, и существует до тех пор, пока этот модуль запущен на этом узле.

В примере показаны два контейнера с пустым общим томом Dir.

Модуль имеет том с именем shared-vol. Этот том монтируется в контейнер веб-сервера по адресу /var/www/html, потому что это каталог, из которого веб-сервер обслуживает файлы.

Тот же том также монтируется в контейнере content-generator, но по адресу /data, потому что именно туда генератор записывает файлы.

Подключив этот отдельный том таким образом, веб-сервер будет обслуживать контент, сгенерированный генератором контента.

Шаг 1 – применить пример файла манифеста [8]:

cat <<'EOF' > web-server.yaml | kubectl apply -f web-server.yaml apiVersion: v1

kind: Pod metadata: labels:

app: web-server name: web-server

spec:

volumes:

-name: shared-vol emptyDir: {}

initContainers:

-name: content-generator image: busybox volumeMounts:

-name: shared-vol mountPath: /data

command: [ "/bin/sh", "-c" ]

args: [ 'echo \"Website initialized successfully!\" > /data/index.html' ]

containers:

-image: httpd name: httpd

96

volumeMounts:

-name: shared-vol mountPath: /var/www/html/

EOF

Проверьте состояние модуля:

watch kubectl get pod web-server CTRL+C to exit

После того как узел перейдет в запущенное состояние, проверьте файловую систему:

kubectl exec web-server -c httpd -- cat /var/www/html/index.html

Команда вернет содержимое index.html общего файла.

Веб-сайт успешно инициализирован!

Проектируемый том сопоставляет несколько существующих источников томов в одном каталоге.

В настоящее время могут быть спроектированы следующие типы источников томов:

секретный;

нисходящий API;

ConfigMap;

serviceAccountToken.

В следующем примере начинается настройка проектируемого тома для модуля.

Уже создан секретный объект и объект configmap для использования в этом упражнении.

Можно получить информацию о созданных объектах, выполнив следующие команды [6]:

kubectl get secret mysecret kubectl get configmap myconfigmap

Далее настройте узел с помощью этих источников:

cat <<'EOF' > projected-volume.yaml | kubectl apply -f projectedvolume.yaml

apiVersion: v1

97

kind: Pod metadata:

name: volume-test spec:

containers:

-name: container-test image: busybox

args:

-/bin/sh

--c

-sleep 3600 volumeMounts:

-name: all-in-one

mountPath: "/projected-volume" readOnly: true

volumes:

-name: all-in-one projected:

sources: - secret:

name: mysecret items:

-key: username

path: my-group/my-username

-configMap:

name: myconfigmap items:

-key: config

path: my-group/my-config

EOF

Проверьте состояние узла:

watch kubectl get pod volume-test CTRL+C to exit

После того как узел перейдет в запущенное состояние, проверьте файловую систему:

kubectl exec volume-test -- ls /projected-volume/my-group kubectl exec volume-test -- cat /projected-volume/my-group/my-

config

kubectl exec volume-test -- cat /projected-volume/my-group/my- username

Постоянный том (PV) - это часть хранилища в кластере, которая была подготовлена администратором или динамически подготовлена с

98

использованием классов хранилища. Это ресурс в кластере точно так же, как узел, является ресурсом кластера и имеет жизненный цикл, независимый от любого отдельного модуля, который использует PV.

PersistentVolumeClaim (PVC) - это запрос на хранение пользователем. Он похож на узел. Модули потребляют ресурсы узла, а PVCресурсы PV. Модули могут запрашивать определенные уровни ресурсов (процессор и память). Утверждения могут запрашивать определенный размер и режимы доступа.

Начинается создание постоянного объема 10Gi, называемого myvolume.

Режим доступа 'ReadWriteOnce' storageClassName 'local-path',

установленный на пути к хосту '/etc/foo' [8]:

cat<<'EOF' > pv.yaml | kubectl apply -f pv.yaml kind: PersistentVolume

apiVersion: v1 metadata:

name: myvolume spec:

storageClassName: local-path capacity:

storage: 10Gi accessModes:

-ReadWriteOnce

-ReadWriteMany hostPath:

path: /etc/foo

EOF

Проверьте состояние объекта:

kubectl get pv myvolume

Затем нужно создать PersistentVolumeClaim с именем my pvc со следующими свойствами:

AccessMode из ReadWriteOnce с именем storageClassName из local-path:

cat<<'EOF' > pvc.yaml | kubectl apply -f pvc.yaml kind: PersistentVolumeClaim

apiVersion: v1 metadata:

name: mypvc spec:

storageClassName: local-path

99