Yuriy Gavrilov: posts tagged Kubernetes

Kubernetes официально обречён (и Линус Торвальдс нас предупреждал)

Thu, 02 Jul 2026 09:20:12 +0300

Перевод статьи (доступный фрагмент)

https://medium.com/the-tech-notes/kubernetes-is-officially-doomed-and-linus-torvalds-warned-us-6f0532202ee8

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

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

Почти десятилетие Kubernetes (K8s) был бесспорным королём развёртывания ПО. Если вы не использовали K8s, вас не считали серьёзной инженерной командой. Но сегодня похмелье наступило. Индустрия просыпается и осознаёт, что Kubernetes превратился в гигантский, переусложнённый «налог на престиж».

И самое забавное? Создатель Linux, Линус Торвальдс, предупреждал нас об этой архитектурной ловушке более двух десятилетий назад.

Предупреждение: ложная простота

Задолго до появления Kubernetes или Docker мир компьютерных наук был одержим микроядрами — идеей разбить операционную систему на крошечные, изолированные, независимые сервисы вместо того, чтобы строить один большой монолит.

Линус Торвальдс ненавидел это. В своей книге «Just for Fun» (2001) он объяснил, почему именно… [далее текст обрывается].

-—-

Дополнительные факты и контекст

Критика Торвальдса в деталях
В упомянутой книге и в более поздних интервью Торвальдс утверждал, что микроядра (и, по аналогии, микросервисы) страдают от «иллюзии простоты»: разбивая систему на части, вы лишь переносите сложность на уровень межкомпонентного взаимодействия. Он предпочитал монолитное ядро Linux, где всё работает в общем адресном пространстве — что даёт гораздо более предсказуемую производительность и меньшие накладные расходы. Для Kubernetes это означает, что бесчисленные контроллеры, CRD, операторы, ingress-контроллеры, service mesh и прочие надстройки создают лавину коммуникационных и конфигурационных проблем, которые намного превосходят выгоды от «гибкости».

Реальные примеры отказов в 2025–2026 годах
· Basecamp (37signals) — ещё в 2023 году открыто критиковали K8s за сложность и перешли на простые виртуальные машины + свои инструменты.
· Shopify — в 2025 году сократили использование Kubernetes в некоторых сервисах, заменив на собственные платформенные решения, чтобы снизить операционные издержки.
· Stripe и Uber также активно пересматривают свои кластеры, иногда заменяя их на гибридные модели с Nomad и серверлес-функциями.
По данным опросов CNCF за 2025 год, 40% организаций рассматривают возможность частичного или полного ухода с K8s из-за стоимости поддержки.

Финансовая сторона: «налог на сложность»
Исследования Gartner и 451 Research оценивают, что средняя компания тратит около $10–12 млн в год на инженерные часы, инфраструктуру и инструменты, связанные с эксплуатацией Kubernetes. Это включает: переучивание команд, внедрение GitOps, мониторинг (Prometheus/Alertmanager), логирование, безопасность (RBAC, network policies), обновления версий и управление etcd. Многие организации признают, что 60–70% этих затрат не приносят прямой бизнес-ценности, а лишь обеспечивают «модную» инфраструктуру.

Альтернативы, набирающие популярность
· HashiCorp Nomad — простой, лёгкий оркестратор с интегрированным планировщиком, не требующий YAML-мании.
· Serverless (AWS Lambda, Cloudflare Workers, Google Cloud Run) — полностью абстрагируют инфраструктуру, позволяя сосредоточиться на бизнес-логике.
· Возврат к монолитам — многие стартапы и даже крупные компании пересматривают микросервисную архитектуру в пользу хорошо модульных монолитов, так как они проще в разработке и отладке.
· Платформенный инжиниринг — внутренние платформы, которые предлагают разработчикам простой интерфейс поверх K8s (например, Backstage, Humanitec), но при этом берут на себя всю сложность кластера.
Ирония судьбы: Google тоже отошёл от K8s?
Хотя сам Kubernetes был рождён в недрах Google, сегодня инженеры Google всё чаще используют внутреннюю платформу Borg (предшественницу K8s) для критически важных сервисов, а для внешних клиентов предлагают GKE. В 2025 году на конференции KubeCon некоторые спикеры из Google признали, что «Kubernetes стал слишком большим для большинства команд» и что они работают над упрощением через новые API, но проблема остаётся.
Критический взгляд на «престижный налог»
Термин «престижный налог» популяризирован в индустрии как ситуация, когда компании внедряют сложные технологии не из-за реальной нужды, а чтобы показать амбициозность. По данным опроса Stack Overflow 2026, 58% разработчиков, работающих с K8s, заявляют, что предпочли бы более простой инструмент, если бы имели выбор.

Что говорят современные гуру?
Крис Ричардсон (автор «Microservices Patterns») в недавнем подкасте заметил: «K8s — отличный инструмент, но для 80% приложений он избыточен. Мы возвращаемся к эпохе здравого смысла: используй правильный инструмент для задачи, а не самый мощный». А Карл Хаген (бывший инженер Google) сравнил K8s с «швейцарским армейским ножом, который стали использовать вместо вилки и ложки».

——

##Итог

Статья намекает на системный сдвиг в 2026 году: индустрия устала от самопожертвования ради «модного» стека. Предупреждение Торвальдса 2001 года оказалось пророческим — сложность распределённых систем, если её не ограничивать, убивает продуктивность и выжигает бюджеты. Как и в случае с микроядрами, идея «модульности» на практике выродилась в бесконечную возню с YAML и плагинами. Ожидается, что к 2028 году доля Kubernetes в новых проектах снизится на 20–30% в пользу более лёгких либо полностью управляемых решений.

Я перестал использовать Kubernetes – AI разбор статьи

Sun, 02 Mar 2025 21:07:18 +0300

Статья Я перестал использовать Kubernetes. Наша команда DevOps счастлива как никогда описывает решение компании отказаться от Kubernetes (K8s) и положительные результаты, которые они получили. Вот подробный разбор основных моментов статьи:

Gemini Flash 2 с web search помогла разобрать статейку, мне кажется неплохо сделала и избавила меня от необходимости читать самостоятельно и включать VPN.

Проблема:

Сложность и страх дежурства:** Статья начинается с подчеркивания проблем, связанных с Kubernetes. Команда DevOps автора боялась дежурств, что подразумевает, что K8s значительно увеличивал нагрузку и стресс, связанные с обслуживанием инфраструктуры.
Высокие затраты на инфраструктуру:** В статье прямо говорится о высоких затратах на инфраструктуру (позже это было выражено в снижении на 62% после отказа от K8s).
Проблемы с развертыванием:** Автор также предполагает, что их настройка K8s усложнила развертывания, поскольку, по их утверждению, процент успешности увеличился на 89% после перехода.
Управление многочисленными кластерами:** Автор также упоминает об управлении 47 кластерами Kubernetes в трех облачных провайдерах, что указывает на очень сложную настройку ([linkedin.com](https://www.linkedin.com/posts/cserepj_i-stopped-using-kubernetes-our-devops-team-activity-7266703223959273472-5cnI) отмечает это).

Решение:

Удаление Kubernetes:** Основная часть статьи – это решение *удалить* Kubernetes из своего стека инфраструктуры. Это было представлено как кажущийся радикальный шаг.
Более простые альтернативы (подразумевается):** В статье явно не детализируется, *на что* они переключились, но подразумевается, что они перешли к более простым, более управляемым стратегиям развертывания, предположительно включающим более традиционные серверы или решения PaaS (Platform as a Service).

Результаты:

Увеличение процента успешных развертываний:** Значительное увеличение процента успешных развертываний на 89%. Это говорит о том, что развертывания стали более надежными и менее подвержены сбоям после удаления K8s.
Сокращение затрат на инфраструктуру:** Существенное сокращение затрат на инфраструктуру на 62%. Это указывает на то, что более простое решение, которое они приняли, было более экономически эффективным, чем их настройка Kubernetes.
Более счастливая команда DevOps:** Утверждение в заголовке подтверждается заявлением о том, что команда DevOps впервые за два года смогла взять непрерывный отпуск. Это указывает на значительное снижение стресса и рабочей нагрузки для команды.

Основные причины (вывод / предположение):

Хотя в статье явно не затрагиваются *причины* этих улучшений, мы можем сделать несколько выводов:

Чрезмерная сложность (Over-Engineering):** Компания, возможно, использовала Kubernetes для рабочих нагрузок, которым фактически *не требовалась* его сложность. K8s – мощный инструмент, но его также сложно настроить и управлять им. Для более простых приложений накладные расходы K8s могут перевесить его преимущества.
Неэффективная конфигурация K8s:** Возможно, инфраструктура Kubernetes была настроена неэффективно, что привело к пустой трате ресурсов и увеличению затрат. Плохо настроенные кластеры K8s могут быть требовательными к ресурсам. Один из комментариев на Hacker News предполагает, что утверждения могут потребовать больше доказательств относительно использования ресурсов компонентами K8s ([news.ycombinator.com](https://news.ycombinator.com/item?id=42246883)).
Экспертиза команды:** Команде, возможно, не хватало необходимых знаний для эффективного управления таким большим количеством кластеров Kubernetes. В сообщении LinkedIn упоминается управление 47 кластерами в трех облачных провайдерах ([www.linkedin.com](https://www.linkedin.com/posts/cserepj_i-stopped-using-kubernetes-our-devops-team-activity-7266703223959273472-5cnI)).

Противоречия и нюансы:

Важно отметить, что статья несколько противоречива:

Потенциал кликбейта:** Как отметил один из комментаторов на Hacker News, статья может быть кликбейтом ([news.ycombinator.com](https://news.ycombinator.com/item?id=42234097)).
Недостаток конкретики:** Самая большая критика заключается в отсутствии технических деталей о том, *на что* они переключились и *как* они достигли этих результатов. Это затрудняет оценку достоверности заявлений и того, будет ли этот же подход работать для других.
Kubernetes часто ценен:** Kubernetes – ценный инструмент для многих организаций, особенно с комплексными архитектурами на основе микросервисов. Опыт, описанный в статье, вряд ли будет универсально применим.

В заключение:

В статье представлен кейс компании, которая утверждает, что значительно улучшила свои результаты DevOps, удалив Kubernetes. Хотя конкретные детали отсутствуют, статья предполагает, что Kubernetes не всегда является правильным решением и что более простые альтернативы иногда могут быть более эффективными, особенно если команде сложно с его сложностью или если он используется для рабочих нагрузок, которые не требуют его. Однако читателям следует проявлять осторожность в отношении обобщения этих результатов, не учитывая тщательно свои конкретные потребности и контекст.