Настройка Kubernetes кластера с нуля (kubeadm): production HA

kubeadm настройка кластера: где ломается отказоустойчивость

kubeadm настройка по быстрой инструкции выглядит почти одинаково: kubeadm init на одной машине, рабочие узлы подключаются через kubeadm join, kubectl get nodes показывает ровный зелёный список. Поды раскатываются, сервисы отвечают, кластер выглядит отказоустойчивым. Но весь управляющий контур собран в единственном экземпляре, и запас прочности у такой конфигурации нулевой.

Единый узел управления держит сразу kube-apiserver, kube-scheduler, kube-controller-manager и etcd — всё в одном экземпляре. Пропала машина или сеть, и API-сервер недоступен: kubectl и инструменты развёртывания теряют доступ, новые поды не планируются, упавшие не перезапускаются, endpoints сервисов и выдача сертификатов замирают. Кластер ещё жив, но перестаёт реагировать на изменения.

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

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

Разбираем, как это закрывается: несколько узлов управления, устойчивый кворум, виртуальный адрес, размещение по разным машинам и регламент ротации сертификатов.

Что даёт отказоустойчивый кластер: простой и время восстановления

Отказоустойчивость начинается с кворума узлов управления. Kubernetes держит состояние кластера в распределённом хранилище, и записи проходят, пока живы больше половины управляющих узлов. Три узла переживают потерю одного без остановки: кворум сохраняется, API продолжает принимать команды, а вернувшийся узел догоняет журнал и входит в строй сам. На единственном узле та же авария означает недоступный API и ручное восстановление из резервной копии — от десятков минут до часов и с риском потерять часть последних изменений.

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

Какой класс отказов уходит

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

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

Топологии узлов управления: сравнение вариантов развёртывания

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

Второй параметр — где живёт внешнее хранилище состояния. Если оно размещено на самих узлах управления, схема проще, но деградация узла тянет за собой кворум. Вынесенное хранилище развязывает роли: узлы становятся взаимозаменяемыми, а состояние переживает их перезапуск и замену. Тот же выбор стоит между своими мощностями и арендованными — он влияет на доступность сети и на то, какие настройки мы вообще можем менять.

На этапе планирования мы проверяем, как выбранная топология уживается с вашими сетями, системами хранения и требованиями к окну обслуживания — и только после этого фиксируем схему развёртывания.

Настройка kubeadm: этапы работ от аудита до передачи

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

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

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

3. Подготовка узлов. Приводим машины к единому виду: разметка дисков, настройки ядра, синхронизация времени, сетевые правила, одна версия среды запуска контейнеров. Разнобой здесь — типовая причина того, что собранный кластер ведёт себя нестабильно.

4. Сборка кластера. Разворачиваем управляющий контур в отказоустойчивой конфигурации, подключаем рабочие узлы, ставим сетевой слой, хранилище и системные сервисы. Все шаги воспроизводимы: те же действия повторяются при добавлении узла.

5. Проверка отказоустойчивости. Гасим по одному управляющему узлу, затем рабочий — смотрим, держится ли кворум и переезжают ли нагрузки. Отдельно проверяем потерю узла вместе с диском и перезапуск всего контура.

6. Передача в эксплуатацию. Отдаём доступы, правила резервного копирования, порядок добавления и вывода узлов, обновления и разбора отказов. Плюс обучение команды, чтобы типовые операции выполнялись без нас.

Документация, схемы и регламенты на выходе проекта

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

Конфигурации, схемы и регламенты лежат в одном репозитории и версионируются вместе — документация не расходится с фактическим состоянием кластера.

• Файлы конфигурации: kubeadm-config, манифесты управляющего слоя, параметры kubelet и контейнерного рантайма, чарты для Ingress, DNS и мониторинга — стенд разворачивается на чистом окружении воспроизводимо.
• Схема сети и адресации: диапазоны pod-сети и сервисов, балансировка запросов к API, стыки с внешними сетями и маршрутизация между зонами.
• Схема отказоустойчивости: число узлов управляющего слоя, кворум etcd, размещение резервных копий состояния, поведение кластера при потере зоны.
• Политики доступа: роли и привязки RBAC, сервисные учётные записи, изоляция пространств имён, сетевые политики и правила допуска рабочих нагрузок.
• Регламент обновления: очерёдность обновления узлов, проверки перед выводом из строя, критерии отката и глубина хранения предыдущих версий образов.
• Регламент восстановления и документация по кластеру: сценарии потери узла и хранилища состояния, целевое время восстановления, карта кластера, настройки оповещений и журнал известных ограничений.

Кейс: три узла управления, отказ одного без простоя

До пересборки кластер Kubernetes держался на одном узле управления и двух рабочих машинах, собранных вручную: конфигурация жила в голове инженера, резервная копия etcd снималась нерегулярно. Сбой этого узла останавливал API — выкатить релиз или посмотреть состояние подов было нельзя, а восстановление из снимка занимало 40–50 минут: поднять узел, вернуть сертификаты, сверить адреса, дождаться, пока kubelet снова увидит рабочие машины.

Мы пересобрали контур через kubeadm: три узла управления за балансировщиком с общим виртуальным адресом, etcd на всех трёх — кворум держится, пока живы два. Установка описана декларативно, поэтому новый узел поднимается по одному и тому же сценарию, без «настроек, которые помнит только один человек». Плановые обновления идут по одному узлу: поды вытесняются на свободные мощности, узел выводится из работы, обновляется и возвращается.

Метрики до и после

• Отказ узла управления: было — до 50 минут ручного восстановления и полная недоступность API; стало — переключение на резервный узел меньше минуты, сервисы продолжают отвечать.
• Ручные операции при сбое: было 12–15 шагов по чек-листу; стало ноль — кворум и виртуальный адрес восстанавливаются сами.
• Плановые обновления без остановки сервисов: было около половины, остальные — в окно простоя; стало 100%, вытеснение подов укладывается в обычный режим нагрузки.
• Ввод нового узла в контур: с нескольких часов до десятков минут по одному воспроизводимому сценарию.

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

Что делать, если кластер уже собран вручную?

Сначала инвентаризация: сколько управляющих узлов, где живёт etcd, как оформлены сертификаты и kubeconfig, есть ли балансировщик перед API-сервером. Кластер, собранный вручную, почти всегда одноточечный: один управляющий узел, etcd без кворума, набор правок в конфигурации, о которых знает один инженер. Именно это состояние определяет, какой из двух путей реалистичен.

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

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

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

Частые технические вопросы: сеть, обновления, отказ узлов

Большинство вопросов на защите проекта касается не установки, а эксплуатации: как узлы видят друг друга, что будет при потере машины и в каком порядке обновлять кластер. Ниже — разбор типовых сомнений.

В каком порядке обновлять кластер?

Идём по одному узлу: сначала управляющие, затем рабочие, с вытеснением нагрузки перед перезапуском. Минорные версии повышаем последовательно, без перескока — иначе совместимость компонентов и откат становятся непредсказуемыми. Перед каждым шагом — снимок etcd, после — проверка, что все узлы вернулись в Ready и нагрузка разъехалась.

Что произойдёт при отказе узла или разделении сети?

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

Как устроено резервное копирование состояния?

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

Обсудим вашу задачу: соберём план и оценку работ

Чтобы оценка внедрения опиралась на факты, а не на догадки, нам нужен минимум вводных. Опишите их в свободной форме — мы сведём это в план работ и вернёмся с составом этапов, порядком выката и перечнем рисков. Первый разговор технический: уточняем схему, границы и допущения, без анкет на десятки страниц.

• Состав кластера. Сколько управляющих и рабочих узлов планируется, одна площадка или несколько зон, нужен ли балансировщик перед управляющим контуром.
• Требования к доступности. Допустимое время недоступности, поведение при отказе узла или зоны, нужна ли плановая замена узлов без остановки сервисов.
• Окружение. Собственные серверы или облако, какие сети и хранилища уже есть, какие политики безопасности и доступы придётся соблюсти.
• Профиль нагрузки. Сколько сервисов переезжает, есть ли состояние, какие требования к дисковым томам и резервному копированию.
• Сроки и этапность. К какой дате нужен рабочий контур, есть ли окна на работы, собираем с нуля или переносим действующий кластер.
• Эксплуатация после сдачи. Кто отвечает за кластер дальше и нужна ли передача знаний команде заказчика.

Опишите задачу — вернёмся с оценкой и планом, где будет видно, что делаем на каждом этапе и как проверяем результат.