27 января 2023

Резервное копирование Kubernetes с помощью Velero и S3

Наш эксперт Михаил Сергеев подготовил подробный материал (в двух форматах: статья и видеоурок), из которого вы узнаете:

Что такое Velero и S3;
Как установить необходимое ПО;
Как развернуть объектное хранилище на базе Minio;
Как установить Velero в кластер Kubernetes;
О настройке автоматического бэкапа нашего приложения;
Защите бэкапа от удаления злоумышленником.

Что такое Velero и S3

Velero – в переводе испанского означает парусная лодка. Это программный продукт с открытым исходным кодом, предназначенный для безопасного бэкапирования (создания резервной копии данных, обычно в сжатом виде), восстановления после сбоев и миграции ресурсов Kubernetes кластера. Официальный сайт программного продукта https://velero.io/, а также весь исходный код доступен на GitHub.

Minio — это сервер хранения объектов с открытым исходным кодом, совместимый с облачным хранилищем Amazon S3.

Объектное хранилище – это технология хранения и управления данными в неструктурированном формате, называемом объектами.

Для бэкапа сущностей Kubernetes-кластера, Velero использует исключительно объектное хранилище. Можно выбрать абсолютно любое S3 хранилище, но в сегодняшнем уроке мы будем использовать хранилище на базе Minio. Преимуществом Minio стала возможность быстро и просто развернуть её на сервере или виртуальной машине, или Kubernetes-кластере, и хранить бэкапы непосредственно у себя. Можете зайти на официальный сайт https://min.io/ и посмотреть по нему документацию и способы установки.

У нас есть уже готовый тестовый Kubernetes-кластер от компании Corpsoft24. Давайте посмотрим, что оно из себя представляет. Сразу предупредим, что мы будем использовать алиасы команд, что прилично ускоряет работу.

#### Kubernetes алиасы
echo "alias k='kubectl'" >> ~/.bashrc
echo "alias kg='kubectl get'" >> ~/.bashrc
echo "alias kgp='kubectl get po'" >> ~/.bashrc
echo "alias kd='kubectl delete -f'" >> ~/.bashrc
echo "alias ka='kubectl apply -f'" >> ~/.bashrc
echo "alias ke='kubectl exec -it'" >> ~/.bashrc
echo "alias k1='kubectl describe'" >> ~/.bashrc
echo "alias kl='kubectl logs'" >> ~/.bashrc
echo "alias kgs='kubectl get svc -A'" >> ~/.bashrc
echo "alias kr='kubectl rollout restart deployment'" >> ~/.bashrc
echo "alias krs='kubectl rollout restart sts'" >> ~/.bashrc
echo "alias kpa='kubectl get po -A'" >> ~/.bashrc
source ~/.bashrc
 
### Docker алиасы
echo "alias d='docker compose up -d'" >> ~/.bashrc
echo "alias ds='docker compose stop'" >> ~/.bashrc
echo "alias dcd='docker compose down'" >> ~/.bashrc
echo "alias d1='docker compose up'" >> ~/.bashrc
echo "alias dr='docker compose stop && docker compose up -d'" >>
~/.bashrc
echo "alias dl='docker compose logs -f'" >> ~/.bashrc
echo "alias dc='docker compose'" >> ~/.bashrc
echo "alias de='docker exec -it'" >> ~/.bashrc
echo "alias dp='docker system prune'" >> ~/.bashrc
echo "alias dps='docker ps --format=\"table {{.Names}}\t{{.Ports}}
\t{{.Status}}\"'" >> ~/.bashrc
echo "alias dff='docker compose logs -f --tail 100'" >> ~/.bashrc
echo "alias db='docker compose build'" >> ~/.bashrc
source ~/.bashrc

Прежде чем настраивать бэкап Minio на Kubernetes-кластере нам необходимо установить S3 хранилище. Для этого мы заходим на сайт https://min.io/ и выбираем один из вариантов установки. Но тут нет того, что нас интересует, потому что такой способ совершенно не годится для установки сервера. Устанавливать его в нашем Kubernetes-кластере мы не будем, поскольку бэкап должен быть отдельно даже у другого провайдера. Не на другой виртуальной машине или другом кластере, а именно у другого провайдера, возможно, даже в другой стране. Поэтому самый простой способ — это взять простую виртуалку и на ней развернуть с помощью Docker, точнее Docker Compose. Вот на самом сайте про docker-compose ничего не сказано, но в репозитории на GitHub у них есть пример, как его развернуть (https://github.com/minio/minio/blob/master/docs/orchestration/docker-compose/docker-compose.yaml).

Рис.3 Пример разворачивания Docker Compose.

Установим необходимое ПО

Нода (англ. node) – сервер со специальным программным обеспечением, который может быть представлен компьютером или другой вычислительной техникой.

По системным требованиям необходимо развернуть дублирование на 4 нодах (удалённых серверах), которые будут располагаться в разных регионах. Это необходимо для повышения отказоустойчивости. Также в системных требованиях указано, что установка должна производиться на диск с разделом XFS.

XFS диск для S3:

fdisk /dev/sda
partprobe
pvcreate /dev/sda1
vgcreate s3vg /dev/sda1
lvcreate -l 100%FREE -n s3lv s3vg
mkfs.xfs /dev/mapper/s3vg-s3lv
mkdir /s3
chmod 777 /s3
echo "/dev/mapper/s3vg-s3lv /s3 xfs defaults,nofail 0 0" >> /etc/
fstab
mount -a

Также необходимо будет установить caddy-proxy ( https://caddyserver.com/).

# Установка Caddy-proxy
mkdir -p /app/caddy-proxy
cd /app/caddy-proxy
mkdir data
chmod 777 data
docker network create caddy
cat << \EOF > docker-compose.yml
version: "3.7"
services:
caddy:
image: lucaslorentz/caddy-docker-proxy:latest
restart: always
ports:
- 80:80
- 443:443
environment:
- CADDY_INGRESS_NETWORKS=caddy
networks:
- caddy
volumes:
- /var/run/docker.sock:/var/run/docker.sock
- ./data:/data
restart: always
networks:
caddy:
external: true
EOF

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

После установки Caddy-proxy установим Minio. Для установки нужно минимум 8 дисков и 4 ноды. Можно это сделать на разных виртуальных машинах, но в данном примере всё сделаем на одной.

Всё ПО мы устанавливаем на отдельной виртуальной машине с другим провайдером, поскольку проблемы у провайдера зачастую влияют на целостность бэкапа.

# Установка Minio
mkdir -p /s3/minio
cd /s3/minio
mkdir data1-1 data1-2 data2-1 data2-2 data3-1 data3-2 data4-1
data4-2
chmod -R 777 data1-1 data1-2 data2-1 data2-2 data3-1 data3-2
data4-1 data4-2
cat << \EOF > docker-compose.yml
version: '3.7'
x-minio-common: &minio-common
 image: quay.io/minio/minio:RELEASE.2022-12-12T19-27-27Z
command: server --console-address ":9001" http://minio{1...4}/
data{1...2}
environment:
MINIO_ROOT_USER: cs24
MINIO_ROOT_PASSWORD: 3nDPUk1GpfrWHn7kw1p9
healthcheck:
test: ["CMD", "curl", "-f", "http://localhost:9000/minio/health/
live"]
interval: 30s
timeout: 20s
retries: 3
labels:
caddy_0.@denied.not: "remote_ip 95.217.236.3 194.126.162.13"
caddy_1.@denied.not: "remote_ip 95.217.236.3 194.126.162.13"
caddy_0.abort: "@denied"
caddy_1.abort: "@denied"
caddy_0: s3adm.194.126.161.151.sslip.io
caddy_1: s3.194.126.161.151.sslip.io
caddy_0.reverse_proxy: "{{upstreams http 9001}}"
caddy_1.reverse_proxy: "{{upstreams http 9000}}"
services:
minio1:
<<: *minio-common
hostname: minio1
volumes:
- ./data1-1:/data1
- ./data1-2:/data2
networks:
- caddy
minio2:
<<: *minio-common
hostname: minio2
volumes:
- ./data2-1:/data1
- ./data2-2:/data2
networks:
- caddy
minio3:
<<: *minio-common
hostname: minio3
volumes:
- ./data3-1:/data1
- ./data3-2:/data2
networks:
- caddy
minio4:
<<: *minio-common
hostname: minio4
volumes:
 - ./data4-1:/data1
- ./data4-2:/data2
networks:
- caddy
networks:
caddy:
external: true
EOF
Access Key: BZFsMymTjWwKuL8g
Secret Key: 0iG0dcYHRIucmMTzsyNzEPLekL8uL9G0

Развернём объектное хранилище на базе Minio

Всё успешно запущено (4 ноды и Caddy). Сначала проверим Caddy-proxy. Когда мы указали там домен и запустили наши контейнеры, то Caddy-proxy сделал запрос в Let’s Encrypt и создал нам сертификаты. Сертификаты он скачивает в паку Data. Сертификатов будет 2: один для API, второй для админки (s3adm). Вместе с сертификатом создаётся и ключ (s3adm.194.126.161.151.sslip.io.key).

Зайдём в админку через браузер и проверим генерацию сертификата от Let’s Encrypt на указанный нами домен. Нужно будет авторизоваться через логин (cs24) и пароль (3nDPUk1GpfrWHn7kw1p9). Авторизация прошла успешно. Изучим интерфейс админки, позволяющий смотреть различные метрики и логи.

Хотим обратить внимание, что с помощью Сaddy мы сделали whitelist (список IP-адресов с которых можно зайти в админку).

Проверяем работу whitelist, сменив через VPN наш IP-адрес. Обновляем страницу и пробуем повторно зайти в админку. В целях безопасности ваших данных рекомендуем максимально ограничить доступ к админке. Например, заходить через VPN только с одного определённого IP-адреса.

Затем в админке создаём Bucket, необходимый для заливки наших бэкапов из кластера Kubernetes с помощью Velero. Под разные задачи можно создавать разные бакеты.

Установим Velero в кластер Kubernetes

Для начала убедимся, что наш сервер имеет доступ к нашему S3 (можно проверить командой Curl). Запрос успешно прошёл. Если сделать запрос с другого сервера, то он не пройдёт.

Теперь займёмся установкой Velero, перейдя на их официальный сайт (https://velero.io). С его помощью мы сможем не только создавать бэкапы Kubernetes-кластера но и перенести их из одного кластера в другой, защитить данные от всевозможных угроз. Если нажать «скачать Velero» то нас перенесёт на GitHub, где описаны различные изменения в каждой версии программы. Давайте скачаем, как нам рекомендует официальный сайт, бинарную версию установщика. Мы уже заранее подготовили скрипт для установки Velero.

# Установка Velero
cd /tmp
wget https://github.com/vmware-tanzu/velero/releases/download/
v1.10.0/velero-v1.10.0-linux-amd64.tar.gz
tar -zxvf velero-v1.10.0-linux-amd64.tar.gz
mv velero-v1.10.0-linux-amd64/velero /usr/local/bin/
mkdir /home/ms/velero -p
cd /home/ms/velero
cat << \EOF > credentials-velero
[default]
aws_access_key_id=BZFsMymTjWwKuL8g
aws_secret_access_key=0iG0dcYHRIucmMTzsyNzEPLekL8uL9G0
EOF
velero install \
--provider aws \
--plugins velero/velero-plugin-for-aws:v1.5.3 \
--bucket k8s \
--secret-file ./credentials-velero \
--use-volume-snapshots=false \
--backup-location-config
region=minio,s3ForcePathStyle="true",s3Url=https://
s3.194.126.161.151.sslip.io
sleep 5;
kubectl patch -n velero backupstoragelocation default --type merge
-p '{"spec":{"config":{"publicUrl":"https://
s3.194.126.161.151.sslip.io"}}}'

Настройка автоматического бэкапа нашего приложения

Теперь попробуем забэкапить наш Kubernetes-кластер. Бэкап происходит по специальным меткам, которые устанавливаются вручную.

После создания бэкапа проверяем отчёт, все ли данные были в него включены. Затем переходим в нашу админку S3, нажимаем обновить. Увидим 9 объектов объёмом 55 Кб. Далее проверяем, где находятся резервные данные. Системой была создана папка backups (полный путь k8s/backups/prodapp), где в сжатом виде содержатся сами бэкапы.

Затем проверяем работоспособность получившейся системы. Для этого имитируем сбой, удалив часть файлов, после чего нас уже не пускает в приложение.

Для восстановления зададим команду velero restore, затем добавляем creat. После ввода velero restore будет выдана подсказка с вариантами дальнейших действий. Затем добавляем из бэкапа (--from-backup) и название нашего бэкапа (prodapp).

Полная команда будет выглядеть как: «velero restore creat --from-backup prodapp».

Запустится восстановление данных, останется только его дождаться. Время восстановления зависит от используемого оборудования, включая ширину интернет-канала и объёма восстанавливаемых данных.

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

Мы сделали разовый бэкап, но есть возможность сделать резервное копирование постоянным, автоматизировав его. Задав команду: «velero schedule creat prodapp daily –schedule=”0 2 ***” –selector app=production» чтобы понимать, что это дневное задание.

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

Kubernetes в облаке Corpsoft24

Подробнее