Перевод статьи (доступный фрагмент)<\/p>\n
https:\/\/medium.com\/the-tech-notes\/kubernetes-is-officially-doomed-and-linus-torvalds-warned-us-6f0532202ee8<\/a><\/p>\n Почему технические гиганты тихо отказываются от короля оркестрации, и налог на сложность в 10 миллионов долларов, который ваша компания платит прямо сейчас.<\/p>\n Если взглянуть на инфраструктуру самых горячих технологических компаний 2026 года, проявляется шокирующая закономерность. Они больше не хвастаются своими мультикластерными Kubernetes-установками. Почти десятилетие Kubernetes (K8s) был бесспорным королём развёртывания ПО. Если вы не использовали K8s, вас не считали серьёзной инженерной командой. Но сегодня похмелье наступило. Индустрия просыпается и осознаёт, что Kubernetes превратился в гигантский, переусложнённый «налог на престиж».<\/p>\n И самое забавное? Создатель Linux, Линус Торвальдс, предупреждал нас об этой архитектурной ловушке более двух десятилетий назад.<\/p>\n Предупреждение: ложная простота<\/p>\n Задолго до появления Kubernetes или Docker мир компьютерных наук был одержим микроядрами — идеей разбить операционную систему на крошечные, изолированные, независимые сервисы вместо того, чтобы строить один большой монолит.<\/p>\n Линус Торвальдс ненавидел это. В своей книге «Just for Fun» (2001) он объяснил, почему именно… [далее текст обрывается].<\/p>\n -—-<\/p>\n Дополнительные факты и контекст<\/p>\n ——<\/p>\n ##Итог<\/p>\n Статья намекает на системный сдвиг в 2026 году: индустрия устала от самопожертвования ради «модного» стека. Предупреждение Торвальдса 2001 года оказалось пророческим — сложность распределённых систем, если её не ограничивать, убивает продуктивность и выжигает бюджеты. Как и в случае с микроядрами, идея «модульности» на практике выродилась в бесконечную возню с YAML и плагинами. Ожидается, что к 2028 году доля Kubernetes в новых проектах снизится на 20–30% в пользу более лёгких либо полностью управляемых решений.<\/p>\n",
"date_published": "2026-07-02T09:20:12+03:00",
"date_modified": "2026-07-02T09:19:50+03:00",
"tags": [
"Kubernetes"
],
"_date_published_rfc2822": "Thu, 02 Jul 2026 09:20:12 +0300",
"_rss_guid_is_permalink": "false",
"_rss_guid": "339",
"_rss_enclosures": [],
"_e2_data": {
"is_favourite": false,
"links_required": [],
"og_images": []
}
},
{
"id": "199",
"url": "https:\/\/gavrilov.info\/all\/ya-perestal-ispolzovat-kubernetes-ai-razbor-statyi\/",
"title": "Я перестал использовать Kubernetes – AI разбор статьи",
"content_html": " Статья Я перестал использовать Kubernetes. Наша команда DevOps счастлива как никогда<\/a> описывает решение компании отказаться от Kubernetes (K8s) и положительные результаты, которые они получили. Вот подробный разбор основных моментов статьи:<\/p>\n Gemini Flash 2 с web search помогла разобрать статейку, мне кажется неплохо сделала и избавила меня от необходимости читать самостоятельно и включать VPN.<\/p>\n Проблема:<\/b><\/p>\n Решение:<\/b><\/p>\n Результаты:<\/b><\/p>\n Основные причины (вывод \/ предположение):<\/b><\/p>\n Хотя в статье явно не затрагиваются *причины* этих улучшений, мы можем сделать несколько выводов:<\/p>\n Противоречия и нюансы:<\/b><\/p>\n Важно отметить, что статья несколько противоречива:<\/p>\n
\nВместо этого они тихо удаляют YAML-файлы, демонтируют кластеры и движутся назад.<\/p>\n\n
\nВ упомянутой книге и в более поздних интервью Торвальдс утверждал, что микроядра (и, по аналогии, микросервисы) страдают от «иллюзии простоты»: разбивая систему на части, вы лишь переносите сложность на уровень межкомпонентного взаимодействия. Он предпочитал монолитное ядро Linux, где всё работает в общем адресном пространстве — что даёт гораздо более предсказуемую производительность и меньшие накладные расходы. Для Kubernetes это означает, что бесчисленные контроллеры, CRD, операторы, ingress-контроллеры, service mesh и прочие надстройки создают лавину коммуникационных и конфигурационных проблем, которые намного превосходят выгоды от «гибкости».<\/li>\n<\/ol>\n\n
\n· Basecamp (37signals) — ещё в 2023 году открыто критиковали K8s за сложность и перешли на простые виртуальные машины + свои инструменты.
\n· Shopify — в 2025 году сократили использование Kubernetes в некоторых сервисах, заменив на собственные платформенные решения, чтобы снизить операционные издержки.
\n· Stripe и Uber также активно пересматривают свои кластеры, иногда заменяя их на гибридные модели с Nomad и серверлес-функциями.
\nПо данным опросов CNCF за 2025 год, 40% организаций рассматривают возможность частичного или полного ухода с K8s из-за стоимости поддержки.<\/li>\n<\/ol>\n\n
\nИсследования Gartner и 451 Research оценивают, что средняя компания тратит около $10–12 млн в год на инженерные часы, инфраструктуру и инструменты, связанные с эксплуатацией Kubernetes. Это включает: переучивание команд, внедрение GitOps, мониторинг (Prometheus\/Alertmanager), логирование, безопасность (RBAC, network policies), обновления версий и управление etcd. Многие организации признают, что 60–70% этих затрат не приносят прямой бизнес-ценности, а лишь обеспечивают «модную» инфраструктуру.<\/li>\n<\/ol>\n\n
\n· HashiCorp Nomad — простой, лёгкий оркестратор с интегрированным планировщиком, не требующий YAML-мании.
\n· Serverless (AWS Lambda, Cloudflare Workers, Google Cloud Run) — полностью абстрагируют инфраструктуру, позволяя сосредоточиться на бизнес-логике.
\n· Возврат к монолитам — многие стартапы и даже крупные компании пересматривают микросервисную архитектуру в пользу хорошо модульных монолитов, так как они проще в разработке и отладке.
\n· Платформенный инжиниринг — внутренние платформы, которые предлагают разработчикам простой интерфейс поверх K8s (например, Backstage, Humanitec), но при этом берут на себя всю сложность кластера.<\/li>\n
\nХотя сам Kubernetes был рождён в недрах Google, сегодня инженеры Google всё чаще используют внутреннюю платформу Borg (предшественницу K8s) для критически важных сервисов, а для внешних клиентов предлагают GKE. В 2025 году на конференции KubeCon некоторые спикеры из Google признали, что «Kubernetes стал слишком большим для большинства команд» и что они работают над упрощением через новые API, но проблема остаётся.<\/li>\n
\nТермин «престижный налог» популяризирован в индустрии как ситуация, когда компании внедряют сложные технологии не из-за реальной нужды, а чтобы показать амбициозность. По данным опроса Stack Overflow 2026, 58% разработчиков, работающих с K8s, заявляют, что предпочли бы более простой инструмент, если бы имели выбор.<\/li>\n<\/ol>\n\n
\nКрис Ричардсон (автор «Microservices Patterns») в недавнем подкасте заметил: «K8s — отличный инструмент, но для 80% приложений он избыточен. Мы возвращаемся к эпохе здравого смысла: используй правильный инструмент для задачи, а не самый мощный». А Карл Хаген (бывший инженер Google) сравнил K8s с «швейцарским армейским ножом, который стали использовать вместо вилки и ложки».<\/li>\n<\/ol>\n\n
\n
\n
\n