Представьте, что однажды утром вы просыпаетесь, а мир вокруг стал другим. Нет, ничего страшного не случилось: ни ледникового периода, ни падения метеорита. Но все сервисы вдруг начали работать так, как работали в те времена, когда про Kubernetes еще никто не слышал.
Вы выходите из дома, вызываете такси — и сразу что-то не так. Приложение открылось, но карта не грузится. Стоимость скачет каждые десять секунд. Машины то появляются, то исчезают. С горем пополам вызываете наконец-то такси и добираетесь до офиса.
В обед открываете любимую доставку. И там та же картина: ресторан то доступен, то нет, корзина открывается через раз, оплата зависает. В голове одна мысль: «Почему разработчики не могут все сделать нормально?». Но настоящая причина глубже: вы оказались в мире, где приложения больше не умеют подстраиваться под нагрузку.
На следующей неделе — в командировку в Питер. Пытаетесь купить билет на поезд — сайт падает. Не из-за огромного спроса, а потому, что нагрузку никто не распределяет автоматически.
Вечером приходите домой, включаете фильм — та же история. Плеер то работает, то зависает. Где-то в дата-центре один большой сервис пытается обслужить всех сразу, и у него просто нет сил. Раньше так и было: вручную перебрасывали трафик между серверами. Ночами, под кофе, чтобы хоть как-то пережить пик.
Если объяснять простыми словами: монолитный сервис — это один огромный кусок кода, который работает одним блоком. Если внутри ломается хотя бы маленькая часть — падает все приложение целиком.
И самое забавное — в такой реальности почти нигде не выходят обновления.
Заходите в App Store или Google Play — там пусто. И так не один день, не неделю, и даже не месяц. Никто ничего не выкатывает, потому что любое изменение превращается в проблему. Каждый релиз — целое событие: куча согласований, обязательная остановка сервиса, письма пользователям о недоступности приложения с такого-то по такое-то время.
Если что-то пойдет не так, придется срочно откатываться. А повторно выпускать обновление можно будет только следующей ночью — когда нагрузка минимальна и невелик шанс задеть пользователей.
В какой-то момент до вас доходит: это не глобальный сбой, не авария, не атака. Так все и работает в мире, где нет автоматического масштабирования, микросервисов и распределенных систем. Каждое приложение — цельная махина. Упало — значит, упало все.
Самое интересное, что это было нормой до появления Kubernetes. Постоянные падения. Ночные релизы. Встречи под лозунгом «Выходим на прод, крестимся». Инженеры, которые сидели до утра, потому что обновить что-то без остановки сервиса было невозможно.
И вот в этот странный день, наблюдая весь хаос, вы впервые понимаете, насколько тихо Kubernetes поменял мир. Он стал фундаментом, который никто не видит, но который держит огромный пласт стабильности.
Kubernetes решает все эти проблемы очень понятными способами.
Он умеет запускать сразу много экземпляров одного и того же сервиса и распределять между ними нагрузку. Если пользователей становится больше, он поднимает еще несколько копий. Если меньше — убирает лишние. И все это без человеческого участия.
Kubernetes следит за состоянием сервисов: если какая-то часть приложения зависла или упала, он просто поднимает новую. Не нужно будить дежурного инженера и что-то перезапускать вручную.
Еще он позволяет раскладывать большие системы на маленькие кусочки — микросервисы — и обновлять их по отдельности. Не все приложение целиком, а только ту часть, в которой что-то изменили.
Поэтому сегодня можно выкатывать обновления хоть в пиковые часы — никто этого не заметит. Технология дает возможность переключать трафик так, что пользователи не видят ни перерывов, ни ошибок. Одна версия работает, другая выкатывается рядом, и когда все готово — кубер просто плавно переводит поток на новую. За счет этого исчезают ночные релизы, постоянные падения и бесконечные «А вдруг что-то сломаем».
Сейчас мы живем в мире, где приложения сами распределяют нагрузку, сервисы перестают быть хрупкими и становятся надежными рабочими системами, а обновления проходят спокойно, без танцев вокруг сервера (ладно, почти без танцев…).
И иногда, чтобы почувствовать масштаб изменений, достаточно просто задать себе один простой вопрос: «А что, если завтра Kubernetes исчезнет?».
Ну хорошо, если честно, то все не так драматично. Половина сервисов до сих пор живет без кубера и выглядит вполне бодро. Это был всего лишь сон. Можно спокойно спать дальше, ведь мир пока не развалился :)
To be continued…
Автор: Евгений Саркисян, менеджер проектов «Лаборатории Числитель»
Комментарии (18)
sabay
26.12.2025 09:51Микросервисы не обязаны быть связаны с k8s и даже не обязаны быть построены как докер образы. Система деплоя отслеживания и балансировки экземпляров вполне строится на базе скриптов и к примеру HAProxy . Работает стабильно и в пределе даже не требует виртуализации. Да больше надо строить самому - но не так сложно как думают привыкшие к k8s. Хотя в k8s конечно удобнее и быстрее строить.
Sabirman
26.12.2025 09:51Да обычно упирается в БД, а она как раз-таки кубером не масштабируется. Так что сомнительная картина.
SignFinder
26.12.2025 09:51Расскажите это операторам kubernetes. Масштабируются и вертикально и горизонтально и шардами
heejew
26.12.2025 09:51Ну это в теории все красиво, для небольших сервисов. Но что-то я пока не видел, чтобы крупные конторы засунули свой жирный инстанс оракл в кубер ) Его вообще стараются не трогать лишний раз. Или у вас есть примеры?
SignFinder
26.12.2025 09:51Я всего лишь сделал вам замечание, что ваше же утверждение "БД, а она как раз-таки кубером не масштабируется" является неверным.
Atorian
26.12.2025 09:51Можно суп пытаться ножом есть. Технически вы справитесь. Наедитесь ли вы? Вряд ли.
Еще можно с JS сравнить - видели мем про JS Good Parts и Definitive Guide?
Кубер это попытка все впихнуть в одно решение, хотя незачем было и пытаться.
hellosamurai
26.12.2025 09:51На самом деле статья занятная. Она про то что некоторые современные инженеры совершенно не представляют как в действительности работает железо и сеть, каким образом распределяется нагрузка и как строить распределенные системы, где даже отказ одного дата-центра не приведёт к даунтайму. У них вместо знания технологий один ответ - Kubernetes, магия там внутри, он решает все наши проблемы и даже немного больше. Большая беда конечно когда кубер магия перестаёт работать при определённой возросшей нагрузке, и тогда автор просыпается и проводит бессонную ночь, судорожно выясняя как в действительности магия устроена, если он вообще в состоянии это понять. Надо не искать серебряную пулю, а все-таки изучать как устроен кубер, и как все тоже самое можно спокойно повторить руками на железе или виртуалках, тогда возможно это вам сэкономит время, деньги, а ещё сбережёт драгоценные нервы.
Конечно, быть техно-жрецом здорово, но призываю вас быть скучным профессионалом, который каждую систему стремится разобрать на гайки, чтобы понять, как она в действительности функционирует.
zVlad909
26.12.2025 09:51Поставил Вам плюсик.
Надо не искать серебряную пулю, а все-таки изучать как устроен кубер, и как все тоже самое можно спокойно повторить руками на железе или виртуалках, тогда возможно это вам сэкономит время, деньги, а ещё сбережёт драгоценные нервы.
В быстроменяющейся обствновке вручную можно не успеть.
А что разве то как устроен Кубер нигде не описано? Это черный ящик? Я в январе пойду на курсы Микрософр по ихнему Куберу (AKS) и пока у меня нет ответа на этот вопрос.
Из того что я знаю про проблематику управления нагрузками ожидал бы наличие обратной связи управляющего компонента от управляемых объектов. Есть ли такая связь у Кубера?
Спасибо.
MEGA_Nexus
26.12.2025 09:51Но все сервисы вдруг начали работать так, как работали в те времена, когда про Kubernetes еще никто не слышал.
Это были времена стабильности и надёжности, где каждый знал, как всё работает изнутри и как всё правильно настроить.
Вы выходите из дома, вызываете такси — и сразу что-то не так. Приложение открылось, но карта не грузится. Стоимость скачет каждые десять секунд. Машины то появляются, то исчезают. С горем пополам вызываете наконец-то такси и добираетесь до офиса.
Это скорее описание текущего состояния инфраструктуры. Навайбкодили что-то, а потом этот результат херак и сразу в продуктивный кубернетес задеплоили ))))
Atorian
26.12.2025 09:51Великолепно все было бы. Может даже лучше. Кто нибудь придумал бы систему получше. Небыло бы Арго. И других штук решающих проблемы арго.
Atorian
26.12.2025 09:51Кубер из нового добавил только баланс контейнеров по железу. Остальное существовало и без него в том или ином виде.
lexnekr
Глупости.
Во-первых, помимо k8s есть и другие средства оркестрации контейнеров: podman, openshift, ...
Во-вторых, подстраиваться под нагрузку можно вполне себе и виртуальными серверами (добавляя/убавляя сервера в пул балансировки, добавляя им ресурсов или просто поднимая новые экземпляры нужных сервисов на сервере, погасив ненужные). В конце концов, обычно в Кубере сколько ресурсов выделили, столько и используют, далеко не все динамически добавляют/убавляют ресы.
Микросервисы на виртуалках тоже прекрасно живут.
Я уже молчу о том, что shared-хостинги давным-давно были придуманы, задолго до кубера и прекрасно распределяли ресурсы (причём ещё и овер-селлинг успешно умели).
SignFinder
Во первых - Openshift создан на базе кубера. Не было бы k8s, не было бы и openshift
Во-вторых - подман и докер - вообще не оркестраторы.
gurlov
Podman не оркестратор, под капотом OpenShift - k8s. Оркестраторы не на базе k8s конечно есть, но кажется, их очень мало используют, относительно k8s