Кластер Kubernetes упал в продакшене — как не облажаться за первые 15 минут
Вторник, середина дня, продакшен встал. Команда в панике, пользователи без сервиса, а у вас 15 минут до эскалации на руководство. Разбираем реальный инцидент с etcd.
Я видел десятки таких ситуаций: кластер Kubernetes перестаёт отвечать, мониторинг красный, в чатах паника. И самая опасная ошибка на этом этапе — начать действовать наугад. Рестартовать поды, дёргать ноды, перезапускать всё подряд.
Недавно на Хабре разобрали кейс, который стоит держать в голове каждому, кто отвечает за инфраструктуру. Сценарий классический: кластер перестал принимать запросы, kubectl висит, API недоступен. У вас 15 минут до того, как инцидент попадёт в еженедельный отчёт с пометкой «критичный».
Где искать корень проблемы
Первое правило диагностики Kubernetes — если API не отвечает, проблема почти всегда в control plane. И конкретнее — в etcd, распределённом хранилище состояния кластера. Без etcd у вас нет кластера, есть набор серверов, которые не знают друг о друге.
В разборе показали типичную ошибку конфигурации: манифест etcd содержал неправильные пути к сертификатам для межузловой связи. Результат — кворум распался, узлы не могут синхронизироваться, API-сервер не получает данных. Кластер мёртв, но железо живое и метрики CPU/RAM выглядят нормально 📉
Что делать, когда времени нет
• Проверить логи etcd первым делом — ошибки TLS handshake, недоступность peer-узлов, потеря кворума
• Посмотреть манифест статических подов etcd на control-нодах — пути к сертификатам, флаги initial-cluster
• Убедиться, что сертификаты на месте и не истекли — частая причина внезапных падений после обновлений
• Проверить сетевую доступность между control-нодами — etcd требует низких латенсей и стабильной связи
Самое неочевидное: даже если вы нашли проблему в конфиге, не спешите править руками на живой ноде. В продакшене каждое изменение должно быть обратимым. Делаете бэкап манифеста, правите, применяете, смотрите логи. Если не взлетело — откатываете.
Почему это важно знать
Kubernetes стал стандартом для запуска приложений, но его сложность растёт быстрее, чем экспертиза команд. Я вижу это постоянно: компании внедряют K8s, потому что «так надо», а потом сталкиваются с тем, что инженеры не понимают, как работает control plane изнутри.
Разборы вроде этого — не академическое упражнение. Это тренировка мышления под давлением. Когда в реальности у вас не будет времени гуглить базовые вещи, вы либо знаете, где искать, либо теряете деньги компании и свою репутацию.
И да, 15 минут — это оптимистичный сценарий. В реальности у вас часто меньше ⏱️
Попробуйте пройти разбор сами, не подглядывая в ответ сразу. Засеките время. Если уложились — вы в топ-20% инженеров, которые готовы к таким инцидентам.
#Kubernetes #DevOps #SRE #etcd #инфраструктура #troubleshooting