Восстановление в кластере Kubernetes

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

Обязательным требованием для восстановления является наличие актуальной резервной копии Ядра KUMA. Также рекомендуется сохранять используемую конфигурацию балансировщика трафика.

Временная недоступность отдельных компонентов кластера

Если отдельные компоненты кластера временно недоступны, например, из-за временного отключения питания сервера, сетевой недоступности или сбоя, потребовавшего перезагрузки сервера или виртуальной машины, для восстановления не требуется пересоздавать виртуальные машины или менять серверы. Доступность Ядра KUMA в этом случае определяется набором оставшихся в работе компонентов (подробнее об отслеживании работы Ядра KUMA в кластере Kuberbetes). В этот же сценарий входят сбои на сервере или виртуальной машине, которые не требуют переустановки операционной системы и которые можно оперативно устранить заменой отдельных частей или изменением конфигурации программного обеспечения.

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

Полный выход из строя компонентов кластера при сохранении доступности Ядра KUMA

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

Чтобы восстановить кластер:

1. Подготовьте новые виртуальные машины или серверы на замену вышедшим из строя компонентам кластера в соответствии с аппаратными и программными требованиями.

   Вы также можете использовать снимки виртуальных машин, сделанные до установки KUMA.

2. Актуализируйте файл инвентаря k0s.inventory.yml. Если сервисов много и нужно сократить время установки, в секциях kuma_collector, kuma_correlator можно оставить по одному хосту, а в секции kuma_storage оставить один кластер хранения. Если из строя вышел хост, указанный в секции kuma_control_plane_master, то в файле инвентаря k0s.inventory.yml нужно поменять этот хост местами с контроллером кластера, указанным в секции kuma_control_plane.
3. Установите актуальную версию KUMA с использованием скрипта install.sh и подготовленного файла инвентаря k0s.inventory.yml:

   ./install.sh k0s.inventory.yml

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

4. Восстановите Ядро KUMA из резервной копии одним из следующих способов:
   • С помощью REST API:

     curl -k --request POST 'https://<ip_kuma>:7223/api/v3/system/restore' --header 'Authorization: Bearer <token>' --data-binary '@/backup/backup.tar.gz'

   • Через веб-интерфейс:
     1. В веб-интерфейсе откройте раздел Ресурсы → Активные сервисы и в меню () выберите Резервное копирование → Восстановить.
     2. В открывшемся окне выберите файл резервной копии, которую нужно восстановить.

        Если в вашем браузере настроены уведомления, в правом верхнем углу отобразится сообщение Восстановление Ядра KUMA выполнено.

   Ядро KUMA будет восстановлено, и откроется страница входа в веб-интерфейс KUMA.

5. Убедитесь, что все компоненты кластера работают штатно и отказоустойчивость восстановлена:
   1. Все сервисы k0s запущены:

      sudo systemctl status <k0sworker/k0scontroller>

      sudo k0s status

   2. Информация о подах и всех рабочих узлах доступна:

      Просмотреть состояние тома

      sudo k0s kubectl get volume -n longhorn-system -o json | jq '.items[0].status.robustness'

      Статус должен быть healthy. Если статус degraded, то одна из реплик недоступна или находится в процессе восстановления.

      Отслеживать процесс восстановления тома

      sudo k0s kubectl get engine -n longhorn-system -o json | jq '.items[0].status.rebuildStatus'

      При корректной работе восстановление не выполняется и команда не возвращает никаких значений. Если команда возвращает статус rebuilding, это означает, что некоторые реплики находятся в процессе восстановления. Мы рекомендуем не вносить изменения в кластер до завершения восстановления.

6. Установите сервис Метрики с помощью установщика expand.sh и файла инвентаря expand.inventory.yml. Перенесите данные из директории metrics на хост с восстановленным Ядром KUMA.

Кластер восстановлен.

Полный выход из строя компонентов кластера при недоступности Ядра KUMA

Обязательно наличие резервной копии Ядра KUMA.

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

Чтобы восстановить кластер:

1. Подготовьте новые виртуальные машины или серверы на замену вышедшим из строя компонентам кластера в соответствии с с аппаратными и программными требованиями.

   Вы также можете использовать снимки виртуальных машин, сделанные до установки KUMA.

2. Подготовьте отдельный файл инвентаря k0s.inventory.yml, предназначенный для удаления кластера. В этом файле инвентаря удалите все хосты, указанные в секциях kuma_collector, kuma_correlator и kuma_storage, чтобы избежать удаления сервисов и необходимости устанавливать их повторно.
3. Удалите неработающий кластер:
   1. Запустите установщик uninstall.sh с подготовленным файлом инвентаря k0s.inventory.yml:

      ./uninstall.sh k0s.inventory.yml

   2. Перезагрузите все хосты, указанные в секциях kuma_worker* и kuma_control_plane*.
   3. После загрузки хостов снова запустите uninstall.sh с файлом инвентаря k0s.inventory.yml:

      ./uninstall.sh k0s.inventory.yml

4. Подготовьте файл инвентаря KUMA для восстановления кластера. За основу возьмите актуальный файл инвентаря для установки.

   Если внешних сервисов много и нужно сократить время установки, то в секциях kuma_collector, kuma_correlator можно оставить по одному хосту, а в секции kuma_storage оставить один кластер хранения.

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

5. Установите актуальную версию KUMA с использованием скрипта install.sh и подготовленного файла инвентаря k0s.inventory.yml для восстановления кластера.
6. Восстановите Ядро KUMA из резервной копии одним из следующих способов:
   • С помощью REST API:

     curl -k --request POST 'https://<ip_kuma>:7223/api/v3/system/restore' --header 'Authorization: Bearer <token>' --data-binary '@/backup/backup.tar.gz'

   • Через веб-интерфейс:
     1. В веб-интерфейсе откройте раздел Ресурсы → Активные сервисы и в меню () выберите Резервное копирование → Восстановить.
     2. В открывшемся окне выберите файл резервной копии, которую нужно восстановить.

        Если в вашем браузере настроены уведомления, в правом верхнем углу отобразится сообщение Восстановление Ядра KUMA выполнено.

     Ядро KUMA будет восстановлено, и откроется страница входа в веб-интерфейс.

7. Убедитесь, что Ядро KUMA и остальные сервисы KUMA работают штатно. Для этого перейдите в раздел Ресурсы → Активные сервисы. Все сервисы должны быть в зеленом статусе.
8. Убедитесь, что все компоненты кластера работают штатно и отказоустойчивость восстановлена:
   1. Все сервисы k0s запущены:

      sudo systemctl status <k0sworker/k0scontroller>

      sudo k0s status

   2. Информация о подах и всех рабочих узлах доступна:

      Просмотреть состояние тома

      sudo k0s kubectl get volume -n longhorn-system -o json | jq '.items[0].status.robustness'

      Статус должен быть healthy. Если статус degraded, то одна из реплик недоступна или находится в процессе восстановления.

      Отследить процесс восстановления тома

      sudo k0s kubectl get engine -n longhorn-system -o json | jq '.items[0].status.rebuildStatus'

      При корректной работе восстановление не выполняется и команда не возвращает никаких значений. Если команда возвращает статус rebuilding, это означает, что некоторые реплики находятся в процессе восстановления. Мы рекомендуем не вносить изменения в кластер до завершения восстановления.

9. Установите сервис Метрики с помощью установщика expand.sh и файла инвентаря expand.inventory.yml. Перенесите данные из директории metrics на хост с восстановленным Ядром KUMA.

Кластер восстановлен.

Выход из строя балансировщика трафика

Если из строя выходит балансировщик трафика, Ядро KUMA становится недоступно. При этом для восстановления работы балансировщика не требуется удалять или изменять имеющийся кластер или сервисы KUMA. При наличии снимка виртуальной машины балансировщика, сделанного после установки KUMA, вы можете использовать этот снимок. Если снимок виртуальной машины отсутствует или вы хотите использовать новый сервер взамен вышедшего из строя, для восстановления работы кластера потребуется установить балансировщик и настроить его по ранее сохраненной конфигурации.

После восстановления работы балансировщика трафика доступ к кластеру и Ядру KUMA возобновится.

Использование снимков виртуальных машин составляющих частей кластера Kubernetes

Балансировщик трафика

После первоначальной настройки балансировщик трафика представляет собой хост без сохранения состояния. Чтобы сохранить состояние, можно сделать снимок виртуальной машины в любое время после установки актуальной версии KUMA. Восстановление виртуальной машины из снимка возможно в любой момент, если версия KUMA на момент создания снимка совпадает с текущей версией KUMA. Если версии различаются, может потребоваться изменить файл конфигурации балансировщика трафика с учетом изменений в списке обслуживаемых портов.

Ограничения:

• В зависимости от типа гипервизора в момент создания снимка виртуальной машины возможны разрывы текущих подключений.
• При восстановлении из снимка происходит разрыв текущих подключений.
• На момент восстановления виртуальной машины из снимка и до установки новых подключений Ядро KUMA недоступно.

Контроллер кластера

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

Допустимо кратковременное выключение контроллера при сохранении общего кворума. Допустимо поочередное создание снимков виртуальной машины контроллеров. При этом, если при создании снимка прерывается работа сервисов k0s (в зависимости от гипервизора), между выполнением снимков должно быть время на восстановление консенсуса и синхронизацию базы etcd кластера.

Ограничения:

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

Рабочий узел кластера

На рабочих узлах кластера исполняется Ядро KUMA и хранятся реплики тома постоянного хранения, используемого сервисами Ядра KUMA. Создание снимков виртуальной машины оказывает негативное влияние на состояние тома хранения от ошибок в реплике с автоматическим пересозданием реплики до ошибок в файловой системе, требующих полного отключения тома с остановкой подов Ядра KUMA. Последствия зависят от типа гипервизора, операционной системы виртуальной машины, состояния всех реплик и интенсивности дисковых операций в момент создания снимка.

Ограничения:

Восстановление рабочего узла из снимка виртуальной машины при работающем кластере может привести к выходу кластера из строя. Даже использование снимка рабочего узла, временно выведенного из эксплуатации, не обеспечивает возврат этого узла в кластер после восстановления виртуальной машины. Полезны могут быть снимки рабочих узлов, созданные непосредственно перед установкой Ядра KUMA. Использование таких снимков упростит подготовку к переустановке Ядра KUMA при восстановлении.