Yandex Cloud Managed Kubernetes 1.30: IAM, сетевая политика и стоимость egress для dev/staging

Yandex Cloud в сентябре обновил Managed Kubernetes до версии 1.30 и заодно выкатил несколько вещей, которые мы ждали: node groups с GPU для ML-задач, обновлённую интеграцию с IAM и более гранулярный контроль над сетевыми политиками. Мы держим несколько dev/staging кластеров клиентов на YC MK8S и параллельно поддерживаем production-окружения на on-premise Deckhouse. Сентябрьское обновление - хороший повод зафиксировать, что реально работает, где трения, и почему egress-трафик оказывается неожиданным источником расходов.

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

Версия 1.30 сама по себе без сюрпризов: для нас важны SidecarContainers как stable (теперь можно использовать без feature gate), динамическая аллокация ресурсов для GPU, и небольшие изменения в планировщике. Управляемый кластер YC - это именно managed: control plane живёт у провайдера, вы управляете node group-ами и некоторыми параметрами через API или консоль. Обновление 1.30 в YC пришло примерно через полтора месяца после upstream GA, что для managed-провайдера норма.

GPU node groups - интересная добавка. YC предлагает ноды с картами A100 и V100 в нескольких зонах. Для наших задач это не актуально - ML-нагрузок в dev/staging у этих клиентов нет. Несколько клиентов уже спрашивали про запуск inference-сервисов, держим в виду.

Что реально важнее для ежедневной работы - это обновлённая IAM-интеграция. Вот на чём стоит остановиться подробнее.

Модель IAM: как устроено и где ловушки

YC IAM для Kubernetes работает через Service Account Kubernetes + Workload Identity. Идея та же, что в AWS IRSA или GCP Workload Identity Federation: поду присваивается ServiceAccount Kubernetes, который через аннотацию привязан к IAM-сервисному аккаунту YC. Pod получает токен, с которым может обращаться к YC API с правами этого IAM-аккаунта.

На практике это выглядит так: создаёшь IAM-сервисный аккаунт в YC, назначаешь ему нужные роли (например, container-registry.images.puller для доступа к Container Registry), создаёшь Kubernetes ServiceAccount с аннотацией iam.yandex.com/service-account-id, и под автоматически получает токен через механизм OIDC.

Где трения:

Гранулярность ролей в YC IAM. Система ролей YC более плоская, чем хотелось бы. Например, роль editor на ресурсе даёт слишком много - нет простого способа разрешить поду только читать секреты из конкретного каталога Lockbox, не давая при этом лишнего. Для production это требует аккуратного проектирования, для dev/staging мы идём на компромиссы.

Время синхронизации при изменении привязок. Изменение IAM-привязки не применяется мгновенно на уже запущенные поды. Кешированный токен живёт какое-то время. Это создаёт ситуацию, когда вы отозвали доступ, а под ещё несколько минут продолжает успешно ходить в YC API. Для аудита важно понимать этот зазор.

Доступ к Container Registry через node group SA. Проще всего - повесить на node group IAM SA с правом пуллить образы, и тогда все поды кластера тянут из Registry без лишней настройки. Удобно для dev. В production лучше всё же на уровне workload SA, иначе любой под в кластере может читать любой образ из Registry.

Сетевая политика: что есть и чего нет

YC MK8S поддерживает два режима: Calico (по умолчанию) и Cilium. С последним обновлением Cilium стал доступен как GA-опция - раньше это было в preview.

Мы используем Calico на dev/staging: стандартные NetworkPolicy, ничего экзотического. После того, как на production-кластерах мы внедрили микросегментацию через Cilium, хочется единообразия, но перевод dev-кластеров на YC с Calico на Cilium - это пересоздание кластера. В YC нет in-place смены CNI, так что либо живёшь с выбором при создании, либо пересоздаёшь. Это раздражает.

Ключевое ограничение в YC MK8S по сетевым политикам: нет встроенной поддержки Egress через FQDN-based policy. Это возможность Cilium, но в режиме managed YC Cilium приходит не с полным набором CRD - часть Cilium-специфичного функционала недоступна. Стандартные NetworkPolicy работают нормально.

Egress: откуда берётся стоимость

Вот где на dev/staging-кластерах возникают неожиданности. Структура тарификации egress-трафика в YC:

• Трафик внутри одной зоны доступности - бесплатно.
• Трафик между зонами YC - тарифицируется.
• Трафик из YC в интернет - тарифицируется по трафику NAT-инстанса или Cloud NAT.

На первый взгляд dev/staging должны генерировать немного трафика. Но на практике мы столкнулись с несколькими источниками:

CI/CD-пайплайны активно тянут образы. Если Registry в одной зоне, runner в другой - вот вам межзональный трафик на каждый pipeline run. Решение простое: размещать Registry, node group и runner в одной зоне. Но это надо явно проектировать, само не происходит.

Зависимости из интернета. Dev-среды часто стянуты от production меньше всего в части сетевых ограничений. Поды ходят в npm/pip/apt напрямую, всё это идёт через Cloud NAT - и это деньги. На on-premise Deckhouse такой трафик уходит через корпоративный прокси, который уже оплачен в составе канала.

Мониторинг и логи. Если метрики летят в Grafana Cloud или внешний ClickHouse - это весь egress. На on-premise кластерах тот же Prometheus scrape идёт в локальный VictoriaMetrics.

Конкретные суммы называть не буду - они очень зависят от объёма. Но паттерн такой: при небольшом числе нод и умеренной нагрузке YC MK8S на dev/staging часто дешевле по compute, чем держать свои ноды. Но egress-трафик в неожиданных местах съедает часть этой экономии. Важно считать заранее и закрывать ненужный выход в интернет NetworkPolicy сразу при создании кластера, а не потом.

Сравнение с on-premise Deckhouse

На managed-сопровождении у нас есть оба варианта: клиенты с Deckhouse на своём железе и клиенты с dev/staging на YC MK8S. Несколько практических наблюдений:

YC MK8S выигрывает по скорости старта нового кластера (минуты против дней), отсутствию нужды думать про control plane, и встроенным managed-компонентам (Container Registry, Cloud DNS, Lockbox).

Deckhouse выигрывает по предсказуемости стоимости (нет сюрпризов с egress), полному контролю над CNI-конфигурацией, и возможности использовать любую версию Kubernetes без ожидания провайдера.

Компромиссный вариант - dev/staging на YC MK8S, production на Deckhouse on-premise. Так и сделано у нескольких клиентов. Это добавляет операционные накладные расходы: два разных стека нужно держать в голове, мониторинг и CI/CD настраивать для обоих. Но для команд, которые не хотят поддерживать полный кластер ради dev-окружения, это рабочий вариант.

Обновление 1.30 с улучшенным IAM делает YC MK8S чуть менее «облаком с ограниченным управлением» - разрыв с возможностями self-managed кластера сокращается, но не исчезает.