Когда инженер впервые сталкивается с managed Kubernetes в российском облаке, первый вопрос обычно звучит так: «А где тут аналог eksctl?» Привычка к CLI, который создаёт кластер одной командой, сильна. Но если присмотреться к жизненному циклу кластера, становится видно: разница между инструментами не в интерфейсе, а в том, кто исполняет операции. Платформа может взять на себя control plane, обновления и часть аддонов, но нод-группы, политики масштабирования и порядок апгрейда остаются зоной ответственности инженера. Ниже — практический разбор этого разделения труда без привязки к конкретному вендору.

Создание кластера: что платформа делает за вас

В managed-сервисе control plane — то есть API-сервер, etcd и scheduler — обычно скрыт от пользователя. Вы не получаете SSH-доступ к мастерам, не настраиваете их вручную и не выбираете, на каких узлах они запущены. Это одновременно упрощение и ограничение: с одной стороны, меньше операционных задач, с другой — меньше контроля над версией и конфигурацией control plane. При создании кластера через консоль или IaC-провайдер вы задаёте версию Kubernetes, сетевую конфигурацию, размер и количество нод, а также набор аддонов. Всё, что связано с мастерами, платформа делает сама.

Типичная ошибка на этом этапе — переносить привычки из самосборного Kubernetes. Например, пытаться заранее заложить запас по CPU для control plane или выбирать тип диска для etcd. В managed-среде эти параметры либо недоступны, либо управляются платформой. Зато стоит внимательно отнестись к CIDR-диапазонам: пересечение подсетей с локальной сетью или другими кластерами — одна из самых частых причин проблем при подключении сервисов. Второй важный момент — версия Kubernetes. Если платформа поддерживает только несколько минорных версий, лучше сразу выбрать ту, которая даст запас на несколько месяцев до следующего обновления.

Нод-группы и масштабирование: где начинается ручная работа

Нод-группы — это то место, где инженер сохраняет контроль. В отличие от control plane, узлы вы конфигурируете сами: выбираете тип инстанса, размер диска, количество реплик, метки и taints. Здесь же настраивается автомасштабирование. В большинстве managed-сервисов есть два уровня: cluster autoscaler, который добавляет или убирает узлы в зависимости от нехватки ресурсов, и horizontal pod autoscaler, который масштабирует поды. Ошибка новичка — включить оба, но не задать лимиты. В итоге кластер может разрастись до десятков узлов, а счёт вырастет незаметно.

Практический шаг: перед включением автоскейлинга определите минимальное и максимальное число узлов в каждой нод-группе. Минимум должен покрывать базовую нагрузку и системные поды, максимум — исходить из бюджета и квот облака. Если вы используете несколько нод-групп, например под разные типы нагрузки, задайте taints и tolerations, иначе поды могут уехать не на те узлы. Ещё одна типичная ошибка — забыть про requests и limits у подов. Без них autoscaler не понимает, сколько ресурсов реально нужно, и либо не масштабирует, либо делает это хаотично.

  • Проверьте квоты на количество узлов и суммарные ресурсы в облаке до включения автоскейлинга.
  • Задайте requests и limits для всех рабочих нагрузок, включая системные аддоны.
  • Настройте несколько нод-групп, если у вас разные профили нагрузки: например, CPU-интенсивные и memory-интенсивные сервисы.
  • Не включайте автомасштабирование «на всякий случай» без мониторинга: добавьте алерты на количество узлов и утилизацию.

Обновление версии: скрытый control plane и порядок действий

Обновление Kubernetes в managed-среде выглядит проще, чем в самосборном кластере, но не отменяет планирования. Control plane обновляется платформой, часто без вашего участия или по расписанию. А вот нод-группы обновляются по вашей команде или через настройку rolling update. Главное правило: минорную версию control plane нельзя обогнать версией узлов более чем на один минор. На практике это означает, что сначала обновляется control plane, затем нод-группы, и только потом вы меняете версию в манифестах и Helm-чартах.

Типичная ошибка — обновлять всё сразу, без проверки совместимости аддонов. CNI, ingress-контроллер, операторы и CSI-драйверы могут иметь свои требования к версии Kubernetes. Перед апгрейдом стоит прочитать release notes не только Kubernetes, но и каждого установленного аддона. Второй момент — стратегия обновления узлов. Если нод-группа одна и в ней нет запаса, rolling update может временно оставить кластер без свободных ресурсов. Решение — либо добавить временную нод-группу, либо использовать стратегию с surge-узлами, если платформа её поддерживает. И обязательно проверьте, что поды с local storage или stateful-нагрузки корректно перезапускаются на других узлах.

Аддоны и IaC: что автоматизировать, а что оставить руками

Аддоны в managed-сервисах делятся на две категории: те, что платформа устанавливает и обновляет сама, и те, что вы ставите поверх кластера. К первым обычно относятся CNI, core DNS, kube-proxy и иногда metrics-server. Ко вторым — ingress, cert-manager, операторы баз данных, системы мониторинга. Граница может меняться от провайдера к провайдеру, поэтому перед выбором платформы стоит уточнить, какие аддоны входят в managed-предложение, а какие придётся поддерживать самостоятельно.

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

Ещё одна ошибка — хранить секреты и kubeconfig в репозитории. В managed-среде доступ к кластеру часто выдаётся через временные токены или интеграцию с IAM. Если платформа это поддерживает, лучше использовать такой механизм, а не статические сертификаты. И последнее: не забывайте про резервное копирование etcd или хотя бы манифестов. Даже если control plane управляется платформой, случайное удаление namespace или неудачный апгрейд аддона может привести к потере конфигурации.

Итог простой: managed Kubernetes снимает с инженера рутину control plane, но не отменяет ответственности за нод-группы, масштабирование, совместимость аддонов и порядок обновлений. Вместо поиска точного аналога eksctl полезнее составить карту операций: что делает платформа, что делает IaC, а что остаётся на дежурного инженера. Тогда жизненный цикл кластера становится предсказуемым, а счёт за облако — управляемым.