Wiki · Технологии разработки

Kubernetes

5 мин чтенияАвтор: Сергей ЧерняковСоавторы: Евгений Баев

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

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

Kubernetes вырос из опыта Google: на официальном сайте сказано, что он опирается на 15 лет работы production-нагрузок в компании. Сейчас это проект Cloud Native Computing Foundation со статусом graduated. Между K и s в названии восемь букв, отсюда сокращение K8s.

Что делает Kubernetes, чего не делает Docker

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

Главная идея в том, что вы описываете желаемое состояние, а не команды. Например: «три копии сайта, у каждой не больше 1 ГБ памяти». Kubernetes постоянно сверяет реальность с описанием. Упала копия, запустит новую. Сервер вышел из строя, перенесёт его контейнеры на соседние.

Основные понятия, которые встретятся в переписке с подрядчиком:

Кластер: все серверы под управлением Kubernetes. Узлы (nodes) выполняют работу, управляющая часть (control plane) распределяет её.
Под (pod): минимальная единица запуска, один или несколько контейнеров, которые работают вместе.
Deployment: описание приложения, сколько копий держать и как их обновлять.
Service и Ingress: как до подов доходят запросы изнутри кластера и снаружи, из интернета.

Настройки хранят в файлах YAML. Фрагмент описания выглядит так:

kind: Deployment
spec:
  replicas: 3
  template:
    spec:
      containers:
      - image: registry.example.ru/shop:1.4.2

Схема кластера Kubernetes: запрос проходит через Ingress и Service к подам, при отказе узла поды перезапускаются на других серверах — Как запрос доходит до приложения в кластере

Когда Kubernetes оправдан

Проект состоит из многих сервисов: сайт, API, мобильный бэкенд, очереди, обработка заказов. Их выкладывают независимо и часто.
Нагрузка заметно скачет: распродажи, рекламные запуски, сезон. Kubernetes добавляет копии приложения по нагрузке на процессор и убирает их, когда пик прошёл.
Простой стоит дорого. Обновления выкатываются постепенно, и при ошибке их откатывают на прошлую версию без остановки сайта.
В команде есть DevOps-инженер или подрядчик, который берёт кластер на сопровождение.

Почему сайту на CMS Kubernetes чаще не нужен

Корпоративный сайт или интернет-магазин на 1С-Битрикс обычно живёт на одном мощном сервере или на паре серверов с базой отдельно. Такой сайт спокойно работает на хорошем VPS, а все узкие места в нём (медленная база, тяжёлые страницы, отсутствие кеша) Kubernetes не исправит. Про варианты размещения подробнее в статье Хостинг.

Есть и сложности, специфичные для CMS. Классический сайт хранит загруженные файлы на диске, а в Kubernetes копии приложения работают на разных узлах, и файлы приходится выносить в общее хранилище. Сессии пользователей тоже нужно держать в отдельном сервисе вроде Redis. Это решаемо, но каждая такая доработка стоит денег. Для Битрикса готовые варианты уже есть: например, в Marketplace Yandex Cloud опубликовано приложение «Битрикс», которое разворачивает окружение для продуктов «1С-Битрикс» в управляемом кластере.

Сравнение: когда сайту хватит обычного сервера и когда проекту оправдан Kubernetes с несколькими сервисами и пиками нагрузки — Когда Kubernetes нужен, а когда избыточен

Сколько стоит сопровождение кластера

Цену серверов посчитать легко, основные расходы в другом. Кластер нужно обновлять: по данным kubernetes.io, каждая минорная версия получает исправления примерно год, поддерживаются три последние ветки, а новые выходят несколько раз в год. Пропустили пару обновлений, и переход растягивается на недели. Ещё нужны мониторинг, сбор логов, резервные копии и человек, который во всём этом разбирается. Если подрядчик уйдёт, найти замену на Kubernetes сложнее и дороже, чем на обычный сервер с Linux.

Что берёт на себя управляемый Kubernetes в облаке

Managed Kubernetes есть у крупных облачных провайдеров, в том числе у российских. Провайдер запускает и обновляет управляющую часть кластера, а вы отвечаете за приложения и узлы. В документации Yandex Managed Service for Kubernetes граница прописана подробно: облако отвечает за control plane, резервные копии etcd и обновления безопасности системных компонентов, пользователь за версии, группы узлов, приложения, права доступа, резервное копирование данных приложений и уязвимости в своих образах.

Отдельно стоят платформы, которые ставят на свои серверы. Одна из известных в России, Deckhouse, разработана компанией «Флант».

Вариант	Для какой задачи подходит	Кто отвечает за кластер
VPS или выделенный сервер	Сайт на CMS, небольшой магазин, лендинги	Администратор сервера
Docker Compose на сервере	Несколько сервисов, одна-две машины	Разработчик или администратор
Managed Kubernetes	Много сервисов, переменная нагрузка, частые выкладки	Облако за управляющую часть, команда за остальное
Свой кластер на платформе	Требования хранить всё на своих серверах	Своя команда или DevOps-подрядчик

Перед переездом крупного проекта в кластер полезно проверить, сколько пользователей выдержит новая схема: этим занимается нагрузочное тестирование. Входящий трафик в кластере может принимать Nginx в роли Ingress-контроллера, а сами серверы и сети удобно описывать кодом через Terraform.

Kubernetes для бизнеса: стоимость, облако и проверка проекта

Как узнать, что проект подрядчика работает в Kubernetes?

Посмотрите репозиторий: в нём будут YAML-файлы с полями kind: Deployment или kind: Service, папка с Helm-чартами или манифестами. Ещё проще спросить подрядчика, где развёрнут кластер, кто его обновляет и где лежит документация по нему.

Сколько серверов нужно для кластера Kubernetes?

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

Чем managed Kubernetes отличается от своего кластера?

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

Когда сайту на 1С-Битрикс стоит переезжать в Kubernetes?

Переезд сайта на 1С-Битрикс в Kubernetes оправдан, если один сервер уже не выдерживает пики, нужны несколько копий сайта и обновления без простоя. Сначала стоит исключить простые причины тормозов: медленную базу, отсутствие кеша, тяжёлые компоненты. Часто после их правки переезд не нужен.

Что такое Ingress в Kubernetes?

Ingress – это правило, по которому запросы из интернета попадают к нужному сервису внутри кластера: по домену, адресу страницы, с HTTPS. Сами правила выполняет Ingress-контроллер, например на базе Nginx.

Почему Kubernetes обходится дороже обычного сервера?

Сам Kubernetes бесплатен, деньги уходят на людей и обвязку. Кластер требует регулярных обновлений версий, мониторинга, сбора логов, отдельного хранилища для файлов и инженера, который понимает, как всё это устроено. Для одного сайта на CMS такие расходы редко окупаются.

Как Kubernetes справляется с ростом нагрузки на сайт?

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

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

Источники

Kubernetes Documentation: Overview, Releases
Официальный сайт kubernetes.io: Production-Grade Container Orchestration
Документация Yandex Cloud: Managed Service for Kubernetes, «Зоны ответственности»
Yandex Cloud Marketplace: приложение «Битрикс» для Managed Service for Kubernetes
Сайт Deckhouse (АО «Флант»)