Что такое Kubernetes и нужен ли он вам на самом деле?

У Kubernetes репутация сложной системы, и она вполне заслуженна, но основная идея проста: это система, которая надёжно запускает множество контейнеров на группе машин, перезапускает те, что упали, и распределяет нагрузку между работающими — и всё это без человека, который следит за дашбордом и вмешивается вручную.

Какую проблему он решает

Один контейнер на одном сервере управлять легко. Но как только появляется реальный продакшен-трафик, обычно требуется несколько копий приложения (ради пропускной способности и чтобы пережить отказ одного из серверов), а ещё база данных, кэш, фоновые обработчики и какой-то способ направлять трафик на те копии, которые прямо сейчас работают исправно. Делать это вручную — подключаться к серверу по SSH, замечать, что контейнер упал, перезапускать его, обновлять конфигурацию балансировщика нагрузки — невозможно, когда сервисов больше нескольких. К тому же это гарантирует, что кого-то разбудят в три часа ночи из-за того, что машина должна была исправить сама.

Kubernetes берёт эту работу на себя. Вы описываете желаемое состояние — «запусти три копии этого контейнера на разных машинах и поддерживай это» — и Kubernetes постоянно работает над тем, чтобы реальность соответствовала описанию. Сервер вышел из строя? Kubernetes перераспределит его контейнеры на другие машины. Контейнер упал? Он будет автоматически перезапущен. Трафик растёт? Можно настроить, чтобы Kubernetes сам добавлял копии.

Основные понятия без перегруза терминами

• Pod — минимальная единица развёртывания, обычно это всего один контейнер (иногда пара тесно связанных).
• Deployment — описывает, сколько копий пода должно работать и как выкатывать на них обновления без простоя.
• Service — постоянный сетевой адрес, который направляет трафик на работающие в данный момент поды, даже когда сами поды под ним заменяются.
• Node — реальная машина (физическая или виртуальная), на которой работают поды.
• Cluster — весь набор узлов, которым Kubernetes управляет как единой системой.

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

Честный ответ: нужен ли он вам?

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

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

Разумный путь

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

Помочь командам решить, нужен ли им Kubernetes или в ближайший год им лучше подойдёт более простая схема, — именно такие инфраструктурные решения мы принимаем вместе с клиентами в Burncode, исходя из реального трафика и размера команды, а не из тех, что, возможно, будут когда-нибудь.