тренажёр собеседований
← Маршрут обучения
модуль 6 / 12 · Эксплуатация платформы · 12 часов

Отказоустойчивость и восстановление

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

Ещё не начат
практика · через терминал портала

Где выполнять задания

Расчёты и обзор доступны сразу в портальном терминале. Остановка etcd и настоящее восстановление выполняются только на отдельной одноразовой машине.

Открыть практикум и терминал ↗

Читай урок в этой вкладке, команды выполняй в соседней. Подстановки в угловых скобках сначала замени своими значениями. Ctrl+C останавливает наблюдение или учебный сервер.

Сокращения этого модуля: расшифровки и смысл
API
Application Programming Interface — программный интерфейс
DR
Disaster Recovery — восстановление после аварии
HA
High Availability — высокая доступность
KaaS
Kubernetes as a Service — Kubernetes как услуга
PVC
PersistentVolumeClaim — запрос постоянного тома
RPO
Recovery Point Objective — допустимый промежуток потери данных
RTO
Recovery Time Objective — целевое время восстановления
SSH
Secure Shell — протокол защищённого удалённого доступа
VM
Virtual Machine — виртуальная машина

В командах сохраняется точное написание параметров и имён. В тексте сокращения раскрываются в скобках.

Результат модуля

  • Посчитать кворум и общие точки отказа.
  • На отдельном стенде проверить потерю голосов и пригодность копии.
  • Отделить восстановление каталога etcd от возврата Kubernetes и управления облаком.

Перед началом: Сеть: от имени приложения до ответа, Хранилище: как сохранить и восстановить данные, Безопасность: пользователи, права и границы.

1. Почему три участника лучше двух

HA (High Availability — высокая доступность) означает способность продолжать работу при оговорённых отказах. Control plane — управляющие компоненты Kubernetes. Их данные хранятся в etcd, распределённом хранилище согласованного состояния. Для принятия изменений etcd требуется большинство голосов, или кворум.

Из трёх участников большинство — два: один может стать недоступным. Из двух большинство тоже два: потеря любого остановит принятие изменений. Четыре участника требуют трёх голосов и выдерживают лишь один отказ. Речь об участниках etcd, а не просто о числе любых нод Kubernetes.

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

Кворум
Большинство участников, необходимое для принятия изменения.
etcd
Название согласованного распределённого хранилища Kubernetes, не сокращение для расшифровки.
Snapshot
Снимок состояния в определённый момент.
Revision
Номер изменения в истории хранилища.

По шагам

  1. Три участника, работают все: доступны три голоса.
  2. Один остановился: два голоса сохраняют большинство.
  3. Остановились два: один голос не может принимать изменения.

2. Что находится в резервной копии

Snapshot etcd сохраняет состояние программного интерфейса Kubernetes: объекты, конфигурацию и Secrets. Он не копирует содержимое прикладных томов и не восстанавливает автоматически внешний балансировщик, виртуальные машины или ключ шифрования хранилища.

DR (Disaster Recovery — восстановление после аварии) требует набора согласованных копий и инструкции. Отдельно учитывай состояние кластера, данные приложений, сертификаты, конфигурацию запуска и внешние зависимости. Копия на том же сломанном диске не решает задачу.

RPO (Recovery Point Objective — допустимый промежуток потери данных) задаёт допустимую давность восстановленного состояния. RTO (Recovery Time Objective — целевое время восстановления) задаёт срок возврата услуги. Запиши точку начала измерения, иначе разные измерения невозможно сравнивать.

3. Как проверять восстановление

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

Для Kubernetes важна история revision etcd: после возврата к старой копии наблюдатели могут помнить более новую версию. Официальная инструкция восстановления описывает bump revision и mark compacted. Используй параметры и инструменты, соответствующие конкретной версии etcd, а не случайную команду из старой статьи.

Не меняй data-dir, static Pod manifests и сертификаты существующего кластера из терминала портала. В этом модуле сначала безопасный расчёт и инвентаризация. Реальное восстановление — обязательная отдельная стадия на одноразовой виртуальной машине; пока она не пройдена, критерий восстановления остаётся пустым.

4. Если потерян управляющий кластер услуги

В KaaS (Kubernetes as a Service — Kubernetes как услуга) управляющий кластер создаёт и изменяет клиентские кластеры. Его отказ может не остановить уже работающие приложения клиентов, но создание, масштабирование и удаление станут недоступны.

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

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

практика · 12 часов вместе с теорией и тестом

Практика через терминал портала

  1. Сними безопасный обзор

    Команды только читают состояние общего кластера. Не выключай ноды и не удаляй Pod etcd.

    kubectl get nodes -o wide
kubectl -n kube-system get pods -l component=etcd -o wide

    Что должно получиться. Виден фактический состав, а не предполагаемые три независимых сервера.

    Если результат отличается

    Отсутствие права чтения не доказывает отсутствие etcd. Уточни способ установки и права.

  2. Посчитай кворум

    Встроенный Python доступен в терминале. Формула большинства: целая половина участников плюс один.

    python3 - <<'PY'
for members in (1, 2, 3, 4, 5):
    majority = members // 2 + 1
    print('members=', members, 'votes=', majority, 'tolerated_failures=', members-majority)
PY

    Что должно получиться. Для 3 участников нужны 2 голоса, допустим 1 отказ; для 5 — 3 и 2 соответственно.

    Если результат отличается

    Это расчёт модели, не опыт реального отказа. Не отмечай практическое восстановление по его результату.

  3. Опиши общие зависимости

    В журнале нарисуй физические хосты и размещённые виртуальные машины. Для каждого вида отказа укажи потерянных участников и доступность внешнего адреса.

    kubectl get nodes -L topology.kubernetes.io/zone,kubernetes.io/hostname

    Что должно получиться. Схема различает метки зон и действительно независимые питание, диск и хост.

    Если результат отличается

    Отсутствующие метки не создавай наугад: они не доказывают физическую независимость.

  4. Подготовь одноразовую среду

    Открой инструкцию отдельного стенда, создай kind-ha-lab. Подключение к новой машине выполняется из того же портального терминала через SSH (Secure Shell — протокол защищённого удалённого доступа). На общей ноде Docker не устанавливается.

    kubectl --context kind-kaas-ha get nodes
kubectl --context kind-kaas-ha -n kube-system get pods -l component=etcd -o wide

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

    Если результат отличается

    Нет контекста — нет готового стенда. Не подставляй текущий production-контекст в последующие команды.

  5. Создай контрольный объект и снимок

    На отдельной машине следуй приложенному ha-restore.md: там проверяется имя контейнера, версия etcd и сохраняется копия вне контейнера. Сначала создай узнаваемый объект.

    kubectl --context kind-kaas-ha -n default create configmap restore-marker --from-literal=message=before-snapshot
kubectl --context kind-kaas-ha -n default get configmap restore-marker

    Что должно получиться. Объект создан, снимок проверен подходящей версией etcdutl, копия вынесена из контейнера. До выполнения инструкции снимок не считается готовым.

    Если результат отличается

    Не печатай содержимое Secrets из снимка и не делай копию текущего общего кластера в общедоступный каталог.

  6. Проверь потерю голосов

    На отдельной машине инструкция показывает остановку и запуск только именованных контейнеров kind. Сравни запрос с ограничением времени после одного и после двух остановленных участников.

    kubectl --context kind-kaas-ha --request-timeout=10s get configmap restore-marker

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

    Если результат отличается

    Ошибка только внешнего адреса не доказывает потерю кворума. Сопоставь состояние процесса, выбранный адрес и журнал etcd.

  7. Восстанови отдельно

    Выполни независимый restore из ha-restore.md. Команды работают с новым каталогом на одноразовой машине. Для полной проверки управляющих компонентов используй документированный порядок своей версии kubeadm; не подключай восстановленную копию к старым участникам.

    date -Is

    Что должно получиться. Проверены известный ключ, восстановленный объект Kubernetes и последующая работа контроллера; записаны все этапы времени. Если проверен только отдельный etcd, это явно отмечено как частичный результат.

    Если результат отличается

    Не отмечай api-recovery после одного успешного etcdutl restore. Копия и восстановленная услуга — разные уровни проверки.

  8. Составь инструкцию аварии

    Запиши место копий, доступ, версии, точки остановки и критерий успешного возврата. Для управления KaaS (Kubernetes as a Service — Kubernetes как услуга) добавь сравнение облачного инвентаря до и после.

    date -Is

    Что должно получиться. Есть воспроизводимый порядок действий и честные измерения RPO/RTO, отдельно непроверенные пункты.

    Если результат отличается

    Не оценивай восстановление как нулевое время, если часы включили только на последней команде.

Открыть терминал ↗ · Скачать файлы лаборатории →

Файлы и подготовка к этой работе

Критерии готовности

Отмечай только то, что проверил на указанном стенде. Эти галочки сохраняются в браузере. Для готовых упражнений зачёт выдаёт отдельная серверная проверка практикума; остальные задания подтверждай журналом и доказательствами. Учебная модель не заменяет реальный облачный опыт.

Что сохранить в портфолио

  • Журнал: исходное состояние → команда или действие → ожидаемый результат → фактическое наблюдение.
  • Доказательства по критериям ниже: очищенный от секретов вывод, схема или ссылка на проверенный коммит.
  • Отдельный список: что пока не запускалось, почему и какой стенд нужен для продолжения.
закрепление

Проверь понимание

8 вопросов по этому модулю. Проходной результат — 7 из 8. После ответа — объяснения и ссылки на разделы, к которым стоит вернуться.

Пройти тест модуля

Официальные источники

Чек-листы уроков, заметки к ним и результаты тестов хранятся в этом браузере; для переноса используй экспорт. Автоматические проверки и журнал практикума сохраняются отдельно на сервере.