AWS EKS production: где ломается кластер
Управляемый кластер в продакшене ломается не в момент развёртывания, а на второй-третий месяц эксплуатации: заканчивается ёмкость, растёт трафик, кто-то один раз поправил конфиг руками. Такой сбой диагностировать сложнее падения пода — отказ проявляется не ошибкой, а деградацией: медленнее отвечает API, часть запросов уходит в ошибки, узел молча выпадает из пула.
Первое типовое место — сборка мусора в узлах. Образы контейнеров и логи копятся на диске, при достижении порога узел начинает вытеснять поды, и в момент пика свободной ёмкости уже нет. Постоянные правила очистки образов и ротация логов закрывают это заранее, а не в момент инцидента.
Второе — балансировка. При каждом изменении Ingress контроллер пересобирает правила и проверки доступности, и пока идёт пересборка, часть трафика идёт мимо. Новые поды, не успевшие прогреться, получают запросы наравне с готовыми — отсюда всплеск ошибок ровно в момент выкатки.
Третье и самое дорогое — дрейф конфигурации. Правки через kubectl, изменённые вручную группы безопасности, лимиты «на время»: через месяц ни манифест, ни кластер не совпадают с реальностью, и откат на предыдущее состояние невозможен ни в кластере, ни в репозитории.
Отдельная история — секреты, заведённые руками: при пересоздании пространства имён или узлов поды стартуют без переменных окружения, и это выясняется уже в продакшене. Дальше разбираем, как эти узкие места кластера закрываются на AWS EKS production.
Что даёт настройка production-контура
Production-контур в AWS EKS собран из управляемых узловых групп, контроллера входящего трафика на ALB, драйвера томов на EBS и внешнего хранилища секретов. Такая связка убирает ручные правки: версии, лимиты ресурсов и сетевые политики описаны в манифестах и применяются одинаково в любом окружении, а состояние кластера сходится к заявленному без участия человека.
Время восстановления и отказоустойчивость
Неисправная реплика снимается с балансировки до остановки — проверки готовности не пропускают трафик на прогревающийся под, поэтому пользователь не видит ошибок. Управляемая группа сама пересоздаёт узел по шаблону, а распределение реплик по зонам доступности не даёт приложению упасть целиком при потере одной из них. Время восстановления определяют политика перезапуска и прогрев приложения, а не скорость дежурного инженера: типовой сбой закрывается за минуты.
Обновление без простоя
Выкатка узлов идёт через вытеснение подов. Бюджеты прерывания гарантируют планировщику, что часть реплик остаётся доступной, а новые узлы вводятся в работу только после прохождения проверок — трафик переезжает без обрыва соединений. Если новая версия не проходит проверки, выкатка останавливается сама, а откат возвращает предыдущий набор образов.
Отдельный эффект — уход класса отказов из-за ручных правок. Секреты подтягиваются из хранилища и не лежат в манифестах, доступы выдаются ролям сервисных аккаунтов, изменения проходят через репозиторий с историей. Инцидентов «поправили на сервере и забыли» больше не возникает, а метрики и логи собираются в одном месте, поэтому причина сбоя находится по данным, а не по памяти участников.
Режимы работы и варианты сборки кластера
Режим запуска определяет, кто отвечает за обновление системы на узлах, за их замену при отказе и за то, как нагрузка встаёт на машины. Один кластер обычно собирают из нескольких вариантов сразу: сервисы с постоянным трафиком ставят на управляемые группы, короткие задачи — на безсерверный запуск.
Выбор режима работы — это не про «быстрее или медленнее», а про границы ответственности команды. Чем больше платформа берёт на себя, тем меньше повседневной работы у инженеров и тем меньше свободы в настройке системы, хранилищ и сетевых надстроек.
| Вариант | Когда подходит | Что накладывает на команду |
|---|---|---|
| Управляемые группы узлов | Постоянный трафик и предсказуемое потребление | Замена и обновление узлов идут по правилам платформы; свои настройки — через конфигурацию группы и ограниченный набор расширений |
| Собственные узлы | Нестандартный образ системы, особые драйверы, своё размещение нагрузки по машинам | Обслуживание, обновление и безопасность системы — целиком на команде; нужен свой порядок замены узлов без простоя |
| Безсерверный запуск | Короткие задачи и редкие всплески, под которые невыгодно держать постоянные машины | Ограничения по типу нагрузки и доступу к системе; постоянные тома не подключаются напрямую; старт задачи занимает время |
Смешивать режимы в одном кластере — рабочая практика: сервисы с трафиком живут на управляемых группах, разовые задачи уезжают на безсерверный запуск, а собственные узлы оставляют под то, что платформа не умеет. Режим выбираем до сборки: от него зависят схемы обновления, раздача прав и модель мониторинга.
Этапы внедрения: от аудита до передачи
Работу ведём последовательными этапами, и каждый заканчивается проверяемым артефактом: схемой, конфигурацией или протоколом испытаний. Заказчик видит, на каком шаге проект и что получит на выходе.
- Аудит инфраструктуры. Разбираем текущее состояние: как устроен кластер, где хранятся секреты и тома, как собираются метрики и логи, какие точки отказа уже есть. На выходе — карта узких мест и приоритеты правок.
- Схема контура. Проектируем целевое устройство: разделение по зонам доступности, пространства имён под нагрузки, схема сети, балансировщика и ротации секретов. Схему согласуем до начала настройки.
- Настройка окружения. Описываем инфраструктуру кодом: кластер, балансировщик, постоянные тома, хранилище секретов, автомасштабирование узлов и подов, ограничения ресурсов. Секреты приходят из внешнего хранилища, а не лежат в конфигурации.
- Мониторинг и логи. Настраиваем показатели кластера, узлов и приложений, сбор логов, дашборды и оповещения по критичным порогам — проблема должна обнаруживаться раньше, чем её заметит пользователь.
- Проверка отказоустойчивости. Прогоняем нагрузочные испытания, имитируем отказ зоны доступности и отдельного узла, перезапуск подов, восстановление из копий. Замеряем время восстановления и фиксируем результат.
- Передача в эксплуатацию. Отдаём схему контура, инструкции и регламент изменений с порядком отката, обучаем команду. Дальше — поддержка по договорённости.
Конфигурации, схемы и регламенты на выходе
Работа над кластером заканчивается не запущенными сервисами, а набором артефактов, по которым платформу можно развивать, передавать смене и восстанавливать после сбоя. Всё настроенное фиксируется в репозитории и документации заказчика: инженер, который раньше не касался проекта, поднимает окружение по регламенту, а не по памяти коллеги.
- Описание конфигурации: пулы узлов и их назначение, стартовые размеры, правила автомасштабирования, что задано декларативно, а что настроено вручную и почему.
- Схема сети: границы виртуальной сети, деление на публичные и приватные подсети, маршрутизация, точка входа трафика и путь запроса до контейнера.
- Политики доступа: роли и сервисные аккаунты, привязки к пространствам имён, права в кластере и облачных сервисах, порядок выдачи и отзыва доступов.
- Работа с секретами: источник истины, способ доставки значений в поды и обновления без перезапуска, журнал чтения и ротации.
- Регламент обновлений: порядок обновления узлов и версии кластера, окна работ, проверки готовности, условия отката на предыдущее состояние.
- Регламент разбора инцидентов: какие оповещения и кому идут, по каким панелям мониторинга ведётся диагностика, шаги первой линии при деградации.
- Документация: инструкции по частым операциям, чек-лист приёмки, ответственные за каждый контур и точки эскалации.
Кейс: как сократили время восстановления
Заказчик пришёл с рабочим кластером на Amazon EKS, который обслуживали вручную: узлы добавляли через консоль, секреты лежали в манифестах открытым текстом. Мониторинг ограничивался загрузкой процессора, алерты уходили в общий чат без владельца — о падении пода команда узнавала от пользователей.
Первый совместный разбор инцидента показал цену такого режима: время восстановления держалось на 45–50 минутах, а простой сервиса в часы пика растягивался на несколько часов. Половину шагов делали вручную — от поиска актуального манифеста до повторного подключения тома, и результат зависел от того, кто именно дежурит.
Кластер перевели в описание кодом: конфигурацию узлов и групп автомасштабирования, ingress-контроллер для балансировщика с проверками живости, драйвер постоянных дисков. Секреты вынесли во внешнее хранилище и подставляли в поды как тома — в манифестах остались ссылки, а не значения.
Мониторинг перестроили от симптомов: метрики доступности и задержек, алерт на нарушение целевого уровня, дежурство с чек-листом и готовыми командами отката. Резервные снимки состояния и учебные восстановления сделали регулярными — процедура перестала проверяться впервые в бою.
Метрики до и после
| Метрика | До | После |
|---|---|---|
| Время восстановления | 45–50 мин | 7–9 мин |
| Ручные операции в инциденте | около 70% шагов | меньше 15% |
| Простой сервиса за квартал | несколько часов | десятки минут |
| Откат релиза | вручную по инструкции | одна команда, около 3 мин |
Стенд сохраняет способность к откату на любой из последних релизов, а новые сервисы поднимаются по шаблону, а не копированием чужого манифеста.
Чем управляемый кластер отличается от ручной сборки?
В управляемом кластере управляющая плоскость — не ваша забота: вендор держит её доступность, обновляет, разводит реплики и восстанавливает после сбоя. Команде остаётся всё, что живёт выше: рабочие нагрузки, состав и размер пулов узлов, правила автомасштабирования, права доступа, сетевые политики, секреты и наблюдаемость. Amazon EKS в этом смысле — аренда управляющего слоя, а не всего кластера целиком.
При ручной сборке к этому добавляется то, что вендор обычно закрывает сам: отказоустойчивость управляющих узлов, резервные копии состояния кластера, плановые обновления без простоя, проверка совместимости дополнений и драйверов хранилища. Сравнивают такие варианты не по «удобству», а по доле инженерного времени на сопровождение и по времени восстановления после отказа управляющего слоя.
Ручная сборка оправдана, когда требование жёсткое: изолированный контур без выхода наружу, нестандартный сетевой стек, собственный стек балансировки, который управляемый слой не поддерживает, или особая политика обновлений ядра. Тогда зона ответственности расширяется до инфраструктуры целиком, а сопровождение становится отдельной ролью в команде, а не побочной задачей дежурного инженера.
На практике границу фиксируют письменно: что закрывает управляемый слой, что наша команда, где проходит стык — обновление узлов, ротация секретов, реакция на деградацию внешнего балансировщика и томов, разбор инцидентов на уровне приложения. Без этой схемы оба варианта дают один и тот же результат: неясно, кто чинит, когда ночью падает прод.
Поэтому выбор сводится к одному вопросу: готовы ли вы держать в штате людей, для которых поддержка кластера — основная работа. Если нет — управляемый слой плюс прозрачная зона ответственности по сопровождению дешевле в эксплуатации, чем сэкономленное на управляющей плоскости время.
Частые вопросы по настройке кластера
Перед стартом обычно остаются одни и те же сомнения: как передать секреты, как обновлять узлы без падений, как кластер уживётся с уже работающим контуром и сколько это займёт. Ниже — короткие ответы; если ваш случай отличается, разберём отдельно.
Как передать секреты и не держать их в репозитории?
Значения подставляет внешнее хранилище, в кластере остаются только ссылки на них и права, привязанные к сервисным учёткам. Доступ разграничен по пространствам имён, ключи шифруются в состоянии кластера, а ротация идёт без перезапуска сервисов. В репозитории лежат описания, а не пароли и токены.
Как обновлять узлы без простоя?
Обновление идёт волнами: сначала поднимаются новые узлы, на них переезжают нагрузки, только потом выводятся старые. Правила доступности не дают выгнать больше нужного, поэтому сервис продолжает отвечать на запросы. Тома подключаются заранее — иначе под, ждущий диск, не сможет переехать на другой узел.
Кластер встраивается в существующий контур?
Да. Сети стыкуются с текущими, трафик приходит через балансировщик по уже принятой схеме, сертификаты и домены переиспользуются. Логи и метрики уходят в тот же контур наблюдаемости, что и остальные системы, — дежурному не нужно второе окно и отдельная инструкция.
Какой объём работ и с чего начнём?
Сначала обсуждаем задачу и текущий контур — возвращаемся с планом: этапы, состав работ, точки отката. Базовый контур (кластер, сеть, секреты, наблюдаемость) обычно собирается за одну-две итерации, дальше идёт перенос сервисов и отладка под нагрузкой.
Обсудим вашу задачу и вернёмся с планом
Оценка по такой задаче не делается «на глазок» — чтобы посчитать состав работ, нам нужно увидеть фактическое состояние контура и договорённости вокруг него. Ниже — что запрашиваем у заказчика перед стартом. Всё это есть у команды, которая ведёт рабочий кластер, даже если часть сведений придётся собирать по ходу.
- Роль в облачном аккаунте с ограниченными правами на чтение — корневые ключи не запрашиваем и не используем.
- Схему текущего контура: кластер, входной балансировщик, тома, хранилище секретов — либо честное «схемы нет, всё собиралось руками».
- Профиль нагрузки: пиковые значения, суточный ритм, ожидаемый рост и критичность сервисов по группам.
- Требования к секретам и доступам: кто получает чувствительные значения, есть ли внешнее хранилище секретов, как организована ротация.
- Куда направлять оповещения мониторинга и кто дежурит: канал, пороги срабатывания, что считается поводом звать ночью.
- Ограничения на изменения: окна обслуживания, регламент согласований, сервисы, которые нельзя трогать без предупреждения.
- Инженера с вашей стороны, который подтвердит детали и примет результат.
Возвращаемся не абстрактным предложением, а планом работ: этапы с результатом на каждом, схема целевой архитектуры, перечень изменений в порядке выката, критерии приёмки в измеримых величинах и порядок отката. Зависимости и риски идут отдельным пунктом — не сюрпризом на середине проекта. Опишите задачу — вернёмся с оценкой и планом.
