Сценарии сбоев

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

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

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

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

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

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

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

    На этом этапе можно использовать снимки виртуальных машин, сделанные до установки 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:

    sudo ./install.sh k0s.inventory.yml

  4. Убедитесь, что все компоненты кластера работают штатно и отказоустойчивость восстановлена:
    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, это означает, что некоторые реплики находятся в процессе восстановления. Мы рекомендуем не вносить изменения в кластер до завершения восстановления.

Восстановление кластера выполнено.

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

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

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

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

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

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

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

      sudo ./uninstall.sh k0s.inventory.yml

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

      sudo ./uninstall.sh k0s.inventory.yml

  4. Подготовьте файл инвентаря KUMA для восстановления кластера. За основу следует взять актуальный файл инвентаря установки. Если число внешних сервисов велико и нужно сократить время установки, то в секциях файла инвентаря kuma_collector, kuma_correlator можно оставить по одному хосту, а в секции kuma_storage оставить один кластер хранения. Если время установки сокращать не требуется и перезапуск внешних сервисов KUMA допустим, то файл инвентаря можно использовать без изменений.
  5. Установите актуальную версию KUMA с использованием скрипта install.sh и подготовленного файла инвентаря k0s.inventory.yml для восстановления кластера.
  6. Восстановите Ядро 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, это означает, что некоторые реплики находятся в процессе восстановления. Мы рекомендуем не вносить изменения в кластер до завершения восстановления.

Восстановление кластера выполнено.

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

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

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

В начало