Привет, Хабр! На связи Тимур Парфёнов, директор департамента эксплуатации Рунити. Сегодня поговорим о Kubernetes. Точнее — о том, почему он стал стандартом де-факто для оркестрации контейнеров и зачем большинству проектов нужен Kubernetes как сервис (KaaS). Статья будет особенно интересна тем, кто еще не знаком с K8s или только планирует его использовать в разработке. Ну, а старичков приглашаю тоже — присоединиться к обсуждению болей и радостей этой технологии.

Навигация по тексту:

• Введение

• Почему Kubernetes стал стандартом

• Боль ручной эксплуатации

• Как Kubernetes решает задачи

• Helm: магия чартов

• Зачем нужен KaaS (Kubernetes as a Service)

• Заключение

Введение

Начнем с истории. Kubernetes появился в 2015 году в недрах Google и довольно быстро обогнал конкурентов вроде Docker Swarm, Marathon или Nomad. А началось всё с Docker — именно он в 2013 году сделал контейнеры массовыми и удобными, и индустрии срочно понадобился инструмент для их оркестрации. 

Уже к сегодняшнему дню у Kubernetes 92% рынка среди платформ оркестрации, и его используют все: от малого бизнеса до Fortune100. Говорят даже, что он ставится на истребители F-16 — настолько универсален этот инструмент.

Звучит круто, но есть нюанс: освоить и поддерживать Kubernetes в продакшене сложно. Сейчас разберемся, как KaaS и инструменты вроде Helm снимают часть боли и упрощают жизнь командам.

Почему Kubernetes стал стандартом

Короткий ответ — универсальность и зрелая экосистема. И подтверждение этого мы видим в статистике, которую я привожу ниже.

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

Причины понятны:

• Kubernetes одинаково хорошо подходит для проектов разного масштаба — от стартапа с десятком микросервисов до банка с тысячами инстансов.

• K8s дает готовый инструментарий для автоматического масштабирования и отказоустойчивости.

• Вокруг Kubernetes сформировалось разнообразие production-ready инструментов: от систем мониторинга до CI/CD. 

Фактически за 10 лет Kubernetes превратился в язык, на котором говорят команды разработки и эксплуатации. Если в 2015-м спорили, что выбрать — Swarm, Marathon или Nomad, то сегодня вопрос звучит иначе: «Как именно мы будем использовать Kubernetes?».

Боль ручной эксплуатации

Чтобы понять, зачем нам Kubernetes, давайте вспомним, как всё выглядело «по-старинке».

Берем виртуалку и начинаем колдовать:

• добавляем пользователей;

• настраиваем таймзону и ротацию логов;

• включаем файервол;

• подключаем репозитории;

• ставим приложение;

• прописываем автозапуск;

• думаем, как показать сервис наружу;

• прикручиваем мониторинг, чтобы не кончилось место на диске;

• вишенка на торте — настройка DNS.

И так — для каждой новой виртуалки. А если приложение растет, то список задач умножается на десятки инстансов. В итоге инфраструктура становится громоздкой, увеличивается количество ручных операций и растет риск ошибок даже у опытной команды.

Конечно, есть инструменты автоматизации — Ansible, SaltStack, Chef, Puppet. Они снимали часть рутины, но не решали главную проблему: инфраструктура по-прежнему зависела от написанных человеком сценариев и компетенций конкретных специалистов. Масштабирование становилось сложнее, а поддержка — дороже и рискованнее.

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

Как Kubernetes решает задачи

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

Эта логика строится вокруг контейнеров и подов. Приложение больше не живет на одной конкретной машине: оно упаковано в контейнер и запускается в поде — минимальной рабочей единице Kubernetes. Если контейнеру нужно соседство (например, с прокси или агентом мониторинга), они разворачиваются в одном поде и делят ресурсы.

Что это дает?

1. Где запускать — решает сам Kubernetes. Вы описываете желаемое состояние, а платформа сама выбирает узел.

2. Стабильность. Если под упал, Kubernetes перезапустит его автоматически и даже мигрирует приложение на другую виртуалку, если узел стал недоступен.

3. Встроенная балансировка. Новые поды автоматически включаются в пул и начинают обслуживать запросы.

4.  Автоскейлинг. Нужно больше ресурсов? K8s увеличит количество подов.

Вместо длинного чек-листа по настройке серверов вы работаете с декларативными манифестами. Написали YAML — и система сама приводит реальность в соответствие с описанием.

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

Helm: магия чартов

K8s решает массу проблем, но у него есть обратная сторона — порог входа. Даже простой деплой приложения превращается в набор YAML-файлов, где легко запутаться.

Здесь на сцену выходит Helm — наиболее популярный инструмент для установки приложений в Kubernetes. По сути, это пакетный менеджер для кластеров. Как apt или yum в Linux, только для подов.

С Helm развертывание выглядит почти магией.

•  Настройка хранилища одной строкой:

helm install openebs --namespace openebs openebs/openebs --set engines.replicated.mayastor.enabled=false --create-namespace

• WordPress в Kubernetes за минуту:

helm install my oci://registry1.docker.io/bitnamicharts/wordpress

После этой команды у вас сразу поднимается приложение, база данных и балансировщик с внешним адресом.

• А для масштабирования:

helm upgrade my-release oci://registry1.docker.io/bitnamicharts/wordpress --set replicaCount=3

Готово! Теперь у вас три реплики WordPress, а балансировщик сам раскидывает трафик между ними. 

Весь процесс занимает меньше минуты, а если быть точным, то в одном из наших кейсов использования, например, 58 секунд.

Helm хорош еще и тем, что чарты работают у любого облачного провайдера. Никакой привязки к конкретной платформе: один и тот же чарт можно развернуть и в Рег.облаке, и в Yandex Cloud, и в Google Cloud или на кластере в дата-центре.

Для команд же это значит две вещи:

• меньше рутины с YAML и зависимостями;

• легкий перенос проектов между окружениями.

Зачем нужен KaaS (Kubernetes as a Service)

Как вы уже могли заметить, Kubernetes — штука мощная, но сложная.

Можно развернуть его руками: поднять мастер-ноды, воркеры, настроить сеть, хранилища, мониторинг, обновления… Но какой ценой! Даже крупные команды со временем понимают: эксплуатация Kubernetes сама по себе задействует те ресурсы, которые могли (и должны были!) идти на продукт.

Здесь на помощь приходит KaaS — Kubernetes как сервис. По сути, это облачный Kubernetes, где вся тяжелая работа уже сделана провайдером.

Что это значит на практике:

• кластер разворачивается через удобную панель управления, без долгих мануалов;

• SLA облака гарантирует стабильность и предсказуемость;

• модель Pay-as-you-go позволяет платить только за то, что реально используете;

• все преимущества Kubernetes (масштабирование, переносимость, стабильность) остаются, но без боли ручной эксплуатации.

Плюс важная деталь — в K8s нет vendor lock-in: чарты и манифесты одинаково хорошо работают у разных облачных провайдеров. При желании можно строить отказоустойчивую инфраструктуру даже на нескольких облаках.

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

В Рег.облаке мы сделали KaaS именно с этой логикой: дать IT-разработчикам возможность запускать проекты в Kubernetes быстро и безопасно, без погружения в бесконечные настройки. Kubernetes остается Kubernetes, но инфраструктурные заботы берет на себя облачный провайдер.

Заключение

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

Helm помогает приручить Kubernetes и превратить установку приложений в набор простых команд. А KaaS снимает с команд головную боль по поддержке кластера: не нужно думать о сети, аптайме или обновлениях — этим занимается облако.

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

Безусловно, я верю, что KaaS — это способ использовать Kubernetes без боли и за пару кликов получить результат, за который будет не стыдно перед внуками. А какое мнение сложилось у вас? Если вы уже запускали чарты в облачном кластере, поделитесь опытом и лайфхаками в комментариях — обсудим, что работает лучше всего.