Почему использовать Managed Kubernetes — ужасная идея для фриланса

Желание использовать в работе «взрослый» софт привело меня к Managed Kubernetes. Работаю я один и в целом Kubernetes понимаю. Не раз разворачивал, писал манифесты, разбирался с ingress и всем остальным. Так что претензии ниже — не от непонимания инструмента, а именно от понимания.

Если коротко о том, что такое Managed Kubernetes — это система для запуска и управления контейнерами. Обычно её нужно разворачивать и обслуживать самому, что муторно. Managed-версия — это когда облачный провайдер берёт на себя управление кластером: GKE это Google, EKS — Amazon, AKS — Microsoft. Говоришь «дай мне кластер», платишь — и он есть. Как бы удобно ни звучало, это ощущение заканчивается в процессе работы.

Начну с того, что раздражает меньше всего, но с чего начинается каждая сессия — с документации. Официальные доки GKE и EKS написаны людьми, которые живут в идеальном мире. В этом мире команды выполняются с первого раза, версии совпадают, а примеры конфигов актуальны. В реальном мире ты копируешь команду из туториала, получаешь ошибку, идёшь в GitHub Issues — и находишь тред двухлетней давности с пометкой closed / won’t fix. Без объяснений, просто закрыт.

Особенно весело с аддонами. Документация по ним размазана по трём разным сайтам с разными датами последнего обновления. Какой версии верить — непонятно. Я однажды потратил полдня на проблему с cert-manager, которая решилась одной строчкой из комментария на Stack Overflow 2021 года. В официальной документации этого не было вообще.

Другая проблема — биллинг. Managed Kubernetes устроен так, что ты платишь не за одну вещь, а за слоёный пирог: control plane, ноды, persistent volumes, load balancers, egress-трафик, логи, метрики, снапшоты. Каждый слой — отдельная строчка в счёте, и ни одна из них не очевидна заранее.

Я удалил кластер. Через неделю пришёл счёт. Оказалось, что при удалении кластера load balancer, который Kubernetes создал сам — не удалился. Это отдельный ресурс на стороне облака, и он продолжал висеть и тикать деньги. Ни предупреждения, ни письма, ни уведомления. Просто списание.

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

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

Хочешь логи — добро пожаловать в Cloud Logging или CloudWatch, с их специфичными конфигами. Хочешь автоскейлинг — у каждого провайдера своя реализация Cluster Autoscaler со своими аннотациями. Хочешь хранилище — PVC будет использовать проприетарный CSI-драйвер, и манифесты перестанут работать у другого провайдера.

Через несколько месяцев твой «облако-независимый» YAML выглядит примерно так:

И переехать куда-то уже не так просто, как казалось в начале.
Для пет-проекта это особенно абсурдно. Ты берёшь enterprise-инструмент, обматываешься проприетарной экосистемой — и в итоге имеешь сложность корпоративного деплоя без единого плюса от масштаба.

Я не говорю, что Kubernetes плохой. Managed-версии от крупных облачных провайдеров типа Яндекса или Cloud4Y, заточенные под команды, у которых есть выделенный DevOps, нормальный бюджет и время разбираться в нюансах биллинга — вариант просто отличный.

Но для фриланса и личных проектов — это избыточно и дорого не только деньгами, но и нервами. k3s на обычном VPS закрывает 80% тех же задач, стоит в разы меньше и не удивляет счетами через неделю после того, как ты всё удалил.