Всем привет, меня зовут Сергей Прощаев. Я Tech Lead и руководитель направления Java | Kotlin‑разработки в FinTech & E‑commerce, а ещё преподаю на курсах разработки и архитектуры в OTUS.

В этой статье я разберу реальный сценарий отказа Kubernetes и дам вам возможность пройти путь дежурного инженера, который получает алерт «кластер мёртв» и должен за 15 минут найти первопричину.

Условие задачи

Представьте: вторник, 14:00. Вы — SRE в продуктовой команде. Production‑кластер Kubernetes, в котором крутятся 40 микросервисов, перестал отвечать на kubectl. Разработчики жалуются, что не могут задеплоить hotfix, мониторинг орёт «кластер недоступен». У вас есть SSH‑доступ к мастер‑узлу. Кластер развёрнут по стандартной схеме kubeadm, так что etcd работает как static pod.

Вы идёте на мастер и видите следующие артефакты:

1. journalctl ‑u kube‑apiserver ‑n 5

... "etcdserver: request timed out"  
... "Error while dialing ... :2379: connect: connection refused"  

2. Проверка контейнера etcd через container runtime

crictl ps | grep etcd

Вывод пуст: контейнер etcd отсутствует.

3. Логи kubelet в части static pod

journalctl -u kubelet | grep -i etcd

Сообщения: RunPodSandbox for "etcd-master" failed: ...

4. Проверка манифеста static pod

1. /etc/kubernetes/manifests/etcd.yaml — файл на месте, синтаксически корректен, но kubelet не может стабильно держать под.

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

Первая реакция и почему она опасна

Мне не раз приходилось видеть, как опытные инженеры, увидев пустой вывод crictl ps и ошибку соединения с etcd, сразу пытаются дёргать kubelet или вручную стартовать контейнер etcd. Однажды я сам так попытался восстановить кластер на staging‑окружении — и потерял час, потому что kubelet запускал контейнер, но etcd внутри него сразу завершался с ошибкой x509, из‑за чего под уходил в CrashLoopBackOff, а я занимался перезапусками, вместо того чтобы открыть манифест и логи.

Первое правило, которое я для себя вывел: не перезапускай компоненты, пока не прочитал логи и манифесты. Статический под etcd не держится не просто так — у kubelet и самого etcd на это есть конкретная причина, и её нужно найти до любых активных действий.

Типовые неверные ходы (и почему они кажутся правильными)

Ошибка 1. «Быстро перезапустить kubelet или вручную поднять etcd»
Почему кажется разумным: etcd упал, значит, надо его поднять.

Что на самом деле: если причина в истёкшем сертификате, kubelet снова запустит контейнер, etcd снова упадёт с x509, и мы получим тот же CrashLoopBackOff. В худшем случае при ручном запуске с несогласованными флагами можно создать неконсистентное состояние member«а — и тогда восстанавливать кластер придётся долго.»

Ошибка 2. «Первым делом лезть в сеть и фаерволы»
connection refused — это в данном сценарии следствие того, что etcd не слушает порт, потому что контейнер не может стабильно работать. Когда мы видим, что контейнер etcd отсутствует в выводе crictl ps, а лог kubelet показывает проблемы с sandbox«ом, локальная причина кратно вероятнее сетевой. Проверка файерволов на этом этапе просто съест время.»

Ошибка 3. «Сразу развернуть новый etcd из снапшота»
Такой сценарий оправдан, когда доказано, что данные etcd повреждены безвозвратно. У нас сейчас нет даже намёка на повреждение данных, а разворачивание нового etcd вручную — это минимум 30–40 минут работы. Слишком серьёзный шаг, чтобы делать его без уверенности.

Правильный ход мысли и пошаговый разбор

Исходя из симптомов, я строю список гипотез от наиболее вероятной и безопасной к более рискованным:

1. Истёк сертификат etcd (особенно если кластер живёт больше года).

2. Закончилось место на диске /var/lib/etcd.

3. Ошибка в манифесте static pod (например, некорректные флаги или повреждённый файл).

4. Проблема с container runtime, из‑за которой kubelet не может создать pod sandbox (в логах это обычно выглядит как failed to create pod sandbox).

Теперь пройду по шагам так, как я действовал бы на реальном инциденте.

Шаг 1. Смотрим логи kubelet, касающиеся etcd.

journalctl -u kubelet | grep -i etcd | tail -20

Это сразу даёт первопричину в большинстве случаев. Если видим:

x509: certificate has expired or is not yet valid — проблема в сертификате. Если видим:no space left on device — диск под etcd заполнен.

Если видим failed to create pod sandbox — вероятно, проблема на стороне container runtime (например, нехватка ресурсов или сломанный cgroup).

Я помню случай в одном финтех‑стартапе: production‑кластер упал ровно через год после развёртывания. Причина — сертификат etcd, выпущенный bootstrapper«ом по умолчанию на год. Автоматического мониторинга на expiry сертификатов не было, а дебажить начали с сетевых фаерволов — потеряли часа два.»

Шаг 2. Заглядываем в манифест static pod.

cat /etc/kubernetes/manifests/etcd.yaml

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

Шаг 3. Проверяем сертификаты.

openssl x509 -in /etc/kubernetes/pki/etcd/server.crt -noout -enddate

Если дата в прошлом — обновляем сертификат. Сейчас корректная команда:

kubeadm certs renew etcd-server

После этого перезапускаем kubelet:

systemctl restart kubelet

и kubelet сам поднимет static pod.

Шаг 4. Проверяем дисковое пространство.

df -h /var/lib/etcd

Если Use% под 100% — выполняем defrag etcd (через etcdctl defrag) или расширяем диск. В kubeadm‑кластере по умолчанию в этой директории нет готовых снапшотов, зато там могут быть разросшиеся WAL и db‑файлы, с которыми и нужно работать.

Шаг 5. Только если всё выше чисто — переходим к состоянию данных etcd.
Снапшот нужно было делать заранее через: 

etcdctl snapshot save

Если бэкапы настроены, восстанавливаем из последнего валидного снапшота с помощью:

 etcdctl snapshot restore

Строго следуя документации по восстановлению кластера.

На всю диагностику у меня обычно уходит меньше 10 минут, если действовать без паники и не пропускать шаги (для этого всегда делаю чек‑листы, можно прямо в Confluence, чтобы был всегда под рукой и доступен всей команде).

Ментальная схема, которая спасает

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

Перед вами Рис. 2 — ключевые элементы Control Plane, на которые влияет отказ etcd.

Главная мысль из рис. 2: если контейнер etcd не держится, а API‑server жалуется на connection refused, в первую очередь смотрим сертификат и свободное место на диске. Именно эти два фактора закрывают подавляющее большинство случаев.

Как я принимаю решение в реальном времени?

Мой внутренний алгоритм после нескольких жёстких инцидентов выглядит так:

1. Не трогать kubelet и не пытаться вручную запустить etcd, пока не прочитаны логи kubelet и манифест.

2. Если логи говорят «certificate expired» — обновить сертификат и перезапустить kubelet.

3. Если «no space» — выполнить defrag или расширить диск, затем дать kubelet перезапустить под.

4. И только если логи не дали однозначного ответа — переходить к проверке runtime, состоянию песочницы и в последнюю очередь к снапшотам.

Однажды я видел, как администратор, столкнувшись с отказом etcd, сразу выполнил kubeadm reset на мастере. Это был платный кластер с клиентскими данными. Восстанавливать пришлось три дня из резервных копий. Я для себя усвоил: нет ничего быстрее, чем потратить первые 3 минуты на чтение логов и манифестов, а не на дёрганье компонентов.

Диаграмма на Рис. 3 фиксирует этот порядок действий.

Мысль здесь простая: двигайся от самых вероятных и безопасных причин к более сложным. Сначала исключи сертификат и диск — и только потом применяй тяжёлую артиллерию!

Что стоит внедрить, чтобы инцидент не повторился?

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

• Мониторинг expiry сертификатов. Prometheus‑экспортёр x509 или плагин к blackbox‑exporter, который алертит за 30 дней до истечения.

• Kubernetes‑native backup. Velero или etcd‑snapshot‑operator, делающий снапшоты каждые 6 часов в S3‑совместимое хранилище.

• Runbook на отказ etcd. Не общая теория, а конкретный документ с командами, актуальными для вашего кластера: пути к сертификатам, имена мастер‑узлов, параметры восстановления из снапшота. В одной e‑commerce‑команде такой runbook сократил MTTR с 90 до 25 минут.

Если вам интересно, как выстроить такую культуру работы с инцидентами системно, а не героическими усилиями по ночам, в OTUS есть курс «Инфраструктурная платформа на основе Kubernetes», где мы разбираем реальные production‑кейсы — от проектирования отказоустойчивых кластеров до SRE‑практик. Но даже без курса главное, что можно сделать прямо сейчас, — сесть и написать свой runbook!

А если хочется потренироваться на смежных практических сценариях — от работы с Kubernetes до разбора инфраструктурных сбоев — обратите внимание на эти бесплатные открытые уроки:

• 8 июня, 20:00 — «Java в Kubernetes за 40 минут: как задеплоить приложение в Minikube».
  _{Практичный вход в Kubernetes: от приложения до деплоя в локальный кластер.}

• 10 июня, 20:00 — «Мониторинг распределенных систем».
  _{О том, как быстрее замечать сбои, искать причины деградации и не узнавать о проблемах от пользователей.}

И подписывайтесь на канал OTUS в MAX — там новые разборы production‑кейсов, материалы по Kubernetes, DevOps и SRE, а также анонсы открытых уроков и вебинаров.