Вам наверняка приходилось восстанавливать кластер Kubernetes после сбоя. Была ли у вас толковая стратегия резервного копирования, не требующая пахать несколько дней? Да, можно делать резервные копии в etcd-кластер, но что если отвалилась только часть кластера или вы используете постоянные тома, вроде AWS EBS?
В таких случаях проще всего использовать утилиту Heptio Ark.
С помощью Heptio можно делать резервные копии всего кластера, отдельных пространств имен или типов ресурсов и делать бэкапы по расписанию. Для меня главное преимущество Heptio Ark — это интеграция с разными поставщиками облачных сервисов, например AWS, Azure, Google Cloud и т. д. Так что при бэкапе она делает снимки используемых постоянных томов.
Посмотрим, как устанавливать эту утилиту и как она делает простые и плановые бэкапы, а потом их восстанавливает.
О бэкапе постоянных томов будет отдельный пост.
Установка
Инструкции по установке вы найдете здесь: examples/README.md. В процессе будет создано несколько пользовательских определений ресурсов, правила RBAC (управление доступом на основе ролей), разрешающие Heptio делать бэкап, и развертывание. По умолчанию они находятся в пространстве имен heptio-ark.
Важно! После успешной установки нужно настроить heptio-ark, чтобы указать серверу, какого поставщика облачных служб использовать и где хранить резервные копии. Вот как выглядит эта конфигурация:
apiVersion: ark.heptio.com/v1 kind: Config metadata: namespace: heptio-ark name: default backupStorageProvider: name: aws bucket: heptio-backup-bucket config: region: eu-central-1 backupSyncPeriod: 30m gcSyncPeriod: 30m scheduleSyncPeriod: 1m restoreOnlyMode: false
Применить ее можно с помощью команды
kubectl apply -f heptio.yaml
Теперь Heptio знает, в каком бакете сохранять резервные копии. Место хранения резервных копий должно быть доступно из подов heptio-server, поэтому можно использовать профиль экземпляра с доступом к этому бакету или Kube2IAM — для динамических профилей экземпляра на базе пода.
Наконец, для бэкапов, расписания и восстановления нужно загрузить с ГитХаба Heptio Ark CLI.
Почти все команды можно выполнять как пользовательские определения ресурсов через YAML или JSON.
Резервное копирование
В этом небольшом примере я создал простой деплой NGINX, а перед ним службу в пространстве имен webserver:
$ kubectl get all NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE deploy/nginx 1 1 1 1 28s NAME DESIRED CURRENT READY AGE rs/nginx-66f5756f9b 1 1 1 28s NAME READY STATUS RESTARTS AGE po/nginx-66f5756f9b-c88ck 1/1 Running 0 28s NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE svc/nginx ClusterIP 10.32.0.183 <none> 80/TCP 28s
Давайте сделаем бэкап из Heptio Ark CLI:
$ ark backup create nginx-simple --include-namespaces webserver
Эта команда бэкапит только пространство имен webserver. Без этого параметра Heptio Ark создаст полную резервную копию всех ресурсов в кластере Kubernetes. Бэкап займет некоторое время. Копия сохранится в указанный бакет в S3 (heptio-backup-bucket). Чтобы посмотреть состояние и список всех бэкапов, в CLI введите следующую команду:
$ ark backup get NAME STATUS CREATED EXPIRES SELECTOR nginx-simple Completed 2018-07-08 17:35:09 +0200 CEST 29d <none>
Как видим, бэкап выполнен.
Восстановление бэкапов
Давайте удалим пространство имен (inline)webserver:
$ kubectl delete ns heptio-test
А теперь восстановим пространство имен после «случайного» удаления, и снова из Heptio Ark CLI:
$ ark restore create --from-backup nginx-simple Restore request "nginx-simple-20180708173924" submitted successfully. Run `ark restore describe nginx-simple-20180708173924` for more details.
Вы должны увидеть, что пространство имен и все ресурсы (развертывание, набор реплик, под и служба) восстановлены:
$ kubectl get all NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE deploy/nginx 1 1 1 1 20s NAME DESIRED CURRENT READY AGE rs/nginx-66f5756f9b 1 1 1 20s NAME READY STATUS RESTARTS AGE po/nginx-66f5756f9b-9mjvg 1/1 Running 0 20s NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE svc/nginx ClusterIP 10.32.0.77 <none> 80/TCP 20s
Структура резервной копии
Чтобы просмотреть структуру резервной копии, просто загрузите ее из бакета в S3 или введите команду Heptio Ark:
$ ark backup download nginx-simple Backup nginx-simple has been successfully downloaded to $PWD/nginx-simple-data.tar.gz
В файле webserver.json нашего пространства имен мы видим обычный ресурс пространства имен.
{ "apiVersion":"v1", "kind":"Namespace", "metadata": { "annotations": { "kubectl.kubernetes.io/last-applied-configuration":"{\"apiVersion\":\"v1\",\"kind\":\"Namespace\",\"metadata\":{\"annotations\":{},\"name\":\"webserver\",\"namespace\":\"\"}}\n" }, "creationTimestamp":"2018-07-08T15:26:44Z", "name":"webserver", "resourceVersion":"3364", "selfLink":"/api/v1/namespaces/webserver", "uid":"52698ae7-82c3-11e8-8529-0645eb60c3f4" }, "spec": { "finalizers":["kubernetes"] }, "status": { "phase":"Active" } }
Если нам не нужно полное восстановление, мы можем восстановить только часть с помощью команды Heptio Ark или перейти к бэкапу напрямую и восстановить эту часть через kubectl.
$ ark schedule create nginx-schedule --schedule="* 10 * * *" --include-namespaces webserver Schedule "nginx-schedule" created successfully.
Запуск бэкапа по расписанию
Heptio Ark может выполнять запланированные задачи. Мы указываем, какие ресурсы и пространства имен нужно включить в резервную копию или исключить из нее и когда нужно выполнять бэкап:
$ ark schedule create nginx-schedule --schedule="* 10 * * *" --include-namespaces webserver Schedule "nginx-schedule" created successfully.
В этом случае резервная копия будет создаваться каждый день в 10 часов и включать только пространство имен webserver. В Heptio Ark CLI мы видим, что появилось расписание и Heptio Ark уже создала первый бэкап:
$ ark schedule get NAME STATUS CREATED SCHEDULE BACKUP TTL LAST BACKUP SELECTOR nginx-schedule Enabled 2018-07-08 17:49:00 +0200 CEST * 10 * * * 720h0m0s 25s ago <none> $ ~/Downloads/ark backup get NAME STATUS CREATED EXPIRES SELECTOR nginx-schedule-20180708154900 Completed 2018-07-08 17:49:00 +0200 CEST 29d <none> nginx-simple Completed 2018-07-08 17:35:09 +0200 CEST 29d <none>
Здесь указано, что плановые бэкапы удаляются через 720 часов, то есть через 30 дней. Когда вы создаете бэкап или расписание, можно указать время жизни копии — TTL. После этого периода резервная копия будет удалена из хранилища, в нашем случае AWS.
ссылка на оригинал статьи https://habr.com/post/423559/
Добавить комментарий