Настройка Selectel MKS: Terraform, автоскейлинг, GitOps

Selectel Managed Kubernetes: где рвётся инфраструктура

Кластер Managed Kubernetes в Selectel поднимается за минуты, поэтому первые проблемы заметны не на старте, а на третьем-четвёртом релизе. Конфигурация обрастает правками, сделанными руками прямо в проде: кто-то поправил лимиты контейнера, кто-то добавил узел через панель. Через месяц воспроизвести рабочее состояние уже никто не может — и любое обновление превращается в эксперимент на живом трафике.

Самое дорогое узкое место — узлы без резерва. Когда пул один, а нагрузка растёт скачком (запуск, сезон, рекламная кампания), новые поды уходят в ожидание и часть запросов падает. Если при этом не заданы политики безопасного вытеснения подов и пробы готовности, плановое обновление образа узла снимает сразу несколько экземпляров сервиса — пользователь видит ошибки там, где никто ничего не менял. Непредсказуемый рост добивает: автоскейлинг без прогретых узлов и корректных запросов ресурсов реагирует с задержкой в несколько минут, и именно на этих минутах теряется доступность.

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

Что даёт управляемый кластер в ежедневной эксплуатации

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

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

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

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

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

Выбор схемы в Selectel Managed Kubernetes — это не спор «облако или свои серверы», а три разных распределения ответственности. От него зависит, кто ведёт обновления узлов, как масштабируется пул под нагрузкой и насколько глубоко можно влиять на размещение подов.

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

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

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

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

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

2. Схема кластера. Определяем пулы узлов под разные типы нагрузки, распределение по зонам доступности, квоты, сетевую топологию, хранилища и политику обновлений. Схему согласуем до развёртывания: правки на этапе проекта дешевле правок в работающем контуре.

3. Развёртывание. Кластер и пулы описываем в Terraform, манифесты сервисов держим в Git-репозитории и раскатываем через GitOps. Автоскейлинг включаем сразу — и на уровне узлов, и на уровне подов, с разной реакцией на плавный рост и на резкий всплеск.

4. Проверка отказоустойчивости. Уводим узел и целую зону, замеряем время перепланирования подов и поведение автоскейлера под нагрузочным профилем. Найденные узкие места закрываем до приёмки, а не в процессе эксплуатации.

5. Приёмка работ. Чек-лист: покрытие мониторингом и алертами, резервные копии с проверенным восстановлением, ролевой доступ, журналы, соответствие согласованной схеме. Фиксируем метрики до и после — время отклика, простои, скорость выката.

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

Что остаётся в репозитории и документации

Кластер на Selectel Managed Kubernetes передаём не как доступы к панели, а как репозиторий, из которого инфраструктура воспроизводится целиком. Наша команда уходит, но у ваших инженеров остаётся рабочее описание конфигураций, политики доступа и регламенты — по ним платформу можно развивать и разбирать инциденты без нас.

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

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

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

Перевели контур на Selectel Managed Kubernetes: приложение упаковали в контейнеры, секреты и конфигурации вынесли в декларативные манифесты, состояние кластера описали в Terraform. Трафик переносили постепенно — 5% запросов на новый контур, затем 25, 50 и 100%. На каждом шаге сверяли долю ошибок и время ответа, и при отклонении вес возвращался обратно за минуты.

Что изменилось в метриках

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

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

Kubernetes своими руками или управляемый сервис

Управляемый сервис — например, Selectel Managed Kubernetes — забирает управляющий слой: мастер-узлы, хранилище состояния кластера, обновления версий, ротацию сертификатов, восстановление после отказа зоны. На стороне команды остаётся то, что описывает нагрузки: манифесты, политики доступа, лимиты, сетевые правила — и это не зависит от варианта.

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

Чаще выбирают гибрид: управляемый управляющий слой плюс собственные пулы узлов, описанные Terraform вместе с сетью и правами доступа. Платформа отвечает за отказоустойчивость мастер-узлов, а команда контролирует версии среды выполнения, размещение нагрузок и порядок обновлений.

Технические сомнения перед стартом работ

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

Как проходят обновления платформы?

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

Как выдаются доступы и где лежат секреты?

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

Что если обновление прошло неудачно?

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