Kubernetes официально обречён

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

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

Вместо этого они незаметно удаляют YAML-файлы, расформировывают свои кластеры и движутся в обратном направлении.

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

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

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

Линус Торвальдс ненавидел эту идею. В своей книге 2001 года «Просто ради забавы» он объяснил, почему разбиение систем на мельчайшие части — это ловушка. Его слова идеально описывают сегодняшний кошмар с Kubernetes и микросервисами:

Теория… заключается в том, что вы разделяете ядро на пятьдесят независимых частей, и каждая из частей составляет пятидесятую часть от общей сложности. Но тогда все игнорируют тот факт, что взаимодействие между частями на самом деле сложнее, чем было в исходной системе… Простота, к которой вы пытаетесь прийти, — это ложная простота.

Это именно тот кризис, который создал Kubernetes.

Инженерные команды взяли идеально функциональные, унифицированные приложения и разделили их на 50 микросервисов. Внезапно, чтобы обеспечить безопасное взаимодействие этих компонентов, им понадобился Kubernetes. Затем им понадобился Istio для создания сервисной сети. Потом Calico для организации сети. Затем Helm для управления YAML-файлами. И наконец, Prometheus для мониторинга.

Мы пожертвовали сложностью приложения ради сложности инфраструктуры. А сложность инфраструктуры обходится гораздо, гораздо дороже.

Kubernetes был создан Google для решения задач масштаба Google. Но 99 % компаний — это не Google.

Когда стартап из 40 человек внедряет Kubernetes, он не достигает бесконечной масштабируемости. Он просто платит налог на престиж. Если проанализировать архитектуры в AWS, Azure и Google Cloud сегодня, становится очевидно: команды тратят огромные бюджеты на EKS и GKE только для поддержания работы плоскости управления, зачастую выделяя целые инженерные группы исключительно для управления оркестратором.

Это не просто теория. Крупнейшие игроки уже отказываются от Kubernetes или пересматривают свои архитектурные решения:

• Amazon Prime Video. В ходе широко обсуждавшегося изменения архитектуры команда Amazon Prime Video отказалась от распределённой микросервисной архитектуры и вернулась к монолитной модели. Результат? Снижение затрат на инфраструктуру на 90 % и значительное улучшение характеристик системы.свой бизнес на Kubernetes. Позднее компания опубликовала анализ причин, по которым решила отказаться от него в пользу упрощённой архитектуры Gitpod Flex. Планирование было слишком медленным, управление памятью — настоящим кошмаром, а обработка постоянных томов — ненадёжной. Компания пришла к выводу, что Kubernetes активно вредит её продукту.

• 37signals (Basecamp и HEY). Под руководством технического директора Дэвида Хайнемайера Ханссона компания полностью отказалась от облачной инфраструктуры и Kubernetes, вернувшись к использованию физических серверов. Компания сообщила об экономии более 7 миллионов долларов за пять лет благодаря отказу от сложной облачной инфраструктуры.
  
  

  Скрытая стоимость оркестровки баз данных

  Налог на сложность становится особенно высоким, когда речь идёт о рабочих нагрузках с сохранением состояния.

  Управление высокопроизводительными системами баз данных, такими как PostgreSQL, MongoDB или Oracle, в Kubernetes, как известно, представляет собой сложную задачу. В то время как веб-серверы без сохранения состояния прекрасно масштабируются в K8s, базы данных требуют высокой производительности ввода-вывода, гарантий постоянного хранения данных и точного управления памятью.

  Когда узел Kubernetes внезапно удаляет под из-за нехватки ресурсов во время всплеска трафика, приложение без сохранения состояния просто перезапускается. Что произойдёт, если это приведёт к удалению вашего основного узла PostgreSQL? Вы столкнётесь с катастрофическим скачком задержки, потенциальным повреждением данных и сигналом пейджера в три часа ночи.

  Самые грамотные команды разработчиков инфраструктуры перестали пытаться любой ценой интегрировать базы данных в Kubernetes. Вместо этого они размещают рабочие нагрузки с сохранением состояния на высокооптимизированных физических серверах или управляемых экземплярах, используя инструменты глубокого мониторинга, такие как Percona Monitoring and Management (PMM), для непосредственной настройки производительности, полностью обходя накладные расходы Kubernetes.

  Кто придёт на смену королю?

  Kubernetes не исчезнет завтра. Для крупных платформ, распределённых по всему миру, он по-прежнему остаётся необходимым инструментом.

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

  1. Невидимая инфраструктура (бессерверные контейнеры). Компании, желающие остаться в облаке, внедряют такие сервисы, как AWS Fargate или Google Cloud Run. Они развёртывают контейнер, а облачный провайдер занимается масштабированием. Нет необходимости управлять узлами или обновлять управляющую плоскость, а также получать специальные знания в области Kubernetes.

  2. Возрождение «голого металла». Компании, уставшие от непомерных комиссий за исходящий трафик в облако, возвращаются к выделенным серверам, используя предельно простые инструменты оркестрации, такие как Docker Swarm, Nomad или Kamal.

  Главный вывод

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

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

  Самые умные технические директора в 2026 году — это не те, кто хвастается своими многорегиональными кластерами Kubernetes, а те, кто тихо их удаляет.

  Список литературы и дополнительные материалы

  1. Торвальдс, Л., и Даймонд, Д. (2001). «Просто ради забавы: история случайного революционера». HarperBusiness. Источник критики микроядер и чрезмерной сложности систем.

  2. Инженерный отдел Amazon Prime Video. (2023). «Масштабирование сервиса аудио- и видеомониторинга Prime Video и снижение затрат на 90 %». Пример проекта Amazon Web Services.

  3. Блог разработчиков Gitpod. (2025). «Великий исход Kubernetes: почему мы создали Gitpod Flex». Подробный анализ ограничений планирования и управления памятью в Kubernetes.

  4. Ханссон, Д. Х. (2024). «Большой выход из облачных технологий». Блог 37signals. Финансовые результаты отказа от AWS и Kubernetes в пользу физических серверов.

  5. Блог о производительности баз данных Percona. Техническая документация и сравнительные тесты, посвящённые операционным издержкам при запуске рабочих нагрузок с сохранением состояния (PostgreSQL, MongoDB) в среде Kubernetes по сравнению со средами на физическом оборудовании.