Настройка AWS EKS: production-ready кластер

Настройка EKS в AWS: где кластер теряет устойчивость

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

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

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

Третье — отказ узлов. Без политик вытеснения и разнесения копий по зонам потеря одной группы узлов забирает с собой весь сервис, а не одну его реплику. Разбираем, как это закрывается: разносим нагрузку по зонам, задаём границы ресурсов, держим запас адресов и заранее описываем поведение кластера при потере зоны.

Измеримый эффект: устойчивость и скорость восстановления

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

Устойчивость и восстановление

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

Масштабирование и обновления

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

Что проверяем на приёмке:

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

Подходы к развёртыванию: управляемый AWS или ручная сборка

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

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

Этапы внедрения: от аудита до передачи в поддержку

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

1. Аудит инфраструктуры. Что уже есть: аккаунты, сети, реестр образов, работающие нагрузки, кто и как получает доступ. На выходе — список ограничений, которые схема обязана учесть.
2. Схема кластера. Число пулов узлов, разбиение по зонам доступности, требования к автомасштабированию. Согласуем до сборки: переделка на живом кластере дороже.
3. Сеть и политики доступа. Подсети, маршрутизация, роли, разграничение по пространствам имён, связка с корпоративной аутентификацией. Права выдаём по минимальной необходимости, а не «чтобы точно работало».
4. Сборка кластера. Управляющий слой, сетевой плагин, входной шлюз, хранилище для постоянных данных, политики допуска. Всё описываем конфигурацией, а не действиями в консоли.
5. Проверка отказоустойчивости. Поочерёдно гасим узлы и целые зоны, смотрим перепланирование нагрузки и время восстановления. Отдельно — поведение при отказе внешних зависимостей.
6. Наблюдаемость и регламенты. Метрики, логи, оповещения, панели мониторинга для дежурной смены, инструкции на типовые инциденты.
7. Передача в поддержку. Доступы, документация, разбор учебного инцидента, порядок эскалации. Дальше кластер живёт без нашего участия.

Передаваемые артефакты: конфигурации, схемы, регламенты

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

• Инфраструктура как код — описание кластера и связанных ресурсов в Terraform: модули по слоям (сеть, кластер, узлы, доступы), состояние в удалённом хранилище с блокировкой, изменения через проверку и план перед применением.
• Конфигурация кластера — манифесты и Helm-чарты системных компонентов: автомасштабирование узлов и подов, входной контроллер, сбор метрик и логов, квоты и лимиты на пространства имён.
• Схемы сети — адресация подсетей, разделение публичных и приватных зон, маршрутизация, выходы в интернет, правила доступа к внешним сервисам: графика плюс таблица соответствия.
• Регламент обновлений — периодичность апгрейда управляющего слоя и узлов, окна работ, проверка совместимости компонентов, порядок отката на предыдущую версию, точки согласования.
• Политики доступа и секретов — роли и привязки, разделение прав команд и сервисных учётных записей, хранение и ротация ключей.
• Мониторинг и алерты — панели мониторинга, ключевые метрики, пороги срабатывания, маршруты уведомлений и указание, на что реагирует дежурный.
• Документация — инструкции по типовым операциям (восстановление узла, расширение пулов, выкат релиза), схема архитектуры, журнал решений и чек-лист приёмки.

Кейс: как кластер перестал падать на пиковых нагрузках

Исходная картина

Кластер на Amazon EKS собирали точечными правками через панель управления: группы узлов одного размера, автомасштабирование только по средней загрузке процессора, пороги проверок готовности выставлены «на глаз». На пиках это давало предсказуемую деградацию — время отклика росло с 400 мс до 3 секунд, доля запросов с ошибками доходила до 4–5%, а новые копии сервисов появлялись через 8–12 минут после начала роста трафика.

Дежурный инженер поднимал узлы вручную, поэтому инцидент жил от 20 до 40 минут. Обновления снимали слишком много копий сразу: релиз в час пик гарантированно приводил к кратковременной недоступности.

Что изменили

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

Как измеряли результат

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

За квартал доля отказов на пике упала с 4–5% до 0,2%, время отклика — с 3 секунд до 700 мс, добавление копий ускорилось с 12 минут до 90 секунд, восстановление сервиса заняло 4 минуты вместо 35. Число инцидентов, потребовавших ручного вмешательства, сократилось с девяти до одного.

Что делать, если кластер уже развёрнут и работает

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

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

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

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

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

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

Эксплуатационные сомнения по кластеру сводятся к нескольким темам: кто и что в нём может менять, что произойдёт при отказе зоны доступности, как обновляться без остановки сервисов и как удержать расход ресурсов под контролем. Ниже — короткие ответы, как мы закрываем каждое из этих мест при настройке AWS EKS.

Что будет при отказе зоны доступности?

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

Как обновлять без простоя?

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

Как контролировать расход ресурсов?

Каждому сервису задаются запросы и лимиты, автомасштабирование работает по метрикам, а не по расписанию. Отдельные правила закрывают рост дисков и забытые стенды — объём хранилища перестаёт расти бесконтрольно.

Как перенести существующие сервисы?

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

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

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

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

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