За последнее время к нам несколько раз обращались с похожими запросами.
Есть группа компаний, несколько или несколько десятков сайтов на 1С-Битрикс. Каждый сайт когда-то развивался отдельно: разные версии ядра, разные модули, разная инфраструктура, много кастомного кода.
В какой-то момент компания решает всё это привести в порядок.
Типичная формулировка задачи выглядит примерно так:
Есть «зоопарк» отдельных сайтов на 1С-Битрикс. Нужно построить единую высоконагруженную платформу: использовать многосайтовость Bitrix, общее ядро, централизовать интеграции, базы данных и управление контентом, внедрить CI/CD, Infrastructure as Code и развернуть всё это в Kubernetes.
На первый взгляд звучит логично и современно.
Но каждый раз у нас возникает два вопроса:
Нужен ли здесь Kubernetes?
И второй:
Если мы уже строим современную облачную инфраструктуру вокруг Kubernetes, обязательно ли центральным элементом новой системы должен оставаться один большой Bitrix?
Ответ не сводится к «Kubernetes — хорошо» или «Kubernetes — плохо».
Сначала нужно понять, какую проблему бизнеса мы вообще пытаемся решить.
Коротко: Kubernetes для Bitrix не является ни обязательным, ни запрещённым решением. В большинстве проектов сначала стоит проверить нагрузку, устранить узкие места и стандартизировать эксплуатацию на VM. Kubernetes становится рациональным выбором, когда он уже является корпоративной платформой либо когда вокруг Bitrix работает много независимо масштабируемых сервисов.
Что хочет получить заказчик
Если убрать технические термины, обычно заказчик хочет вполне понятные вещи:
чтобы сайты не падали;
чтобы выдерживали рост посещаемости;
чтобы обновления одного сайта не превращались в приключение;
чтобы все проекты использовали предсказуемый технологический стек;
чтобы не было десяти разных способов подключения к 1С, CRM и другим системам;
чтобы новые сайты запускались быстрее;
чтобы изменения можно было автоматически тестировать и выкладывать;
чтобы инфраструктуру можно было восстановить по описанию, а не по памяти администратора;
чтобы стоимость сопровождения всей системы была понятной и управляемой.
Все эти задачи правильные. Но ни одна из них сама по себе ещё не означает: «нам обязательно нужен Kubernetes».
Kubernetes в контексте этой задачи
Kubernetes управляет контейнерами: поддерживает нужное число экземпляров, перезапускает упавшие, распределяет ресурсы, масштабирует приложения и выполняет обновления. Особенно хорошо эта модель работает, когда платформа состоит из множества компонентов с разными профилями нагрузки.
Kubernetes
│
┌───────────────┼───────────────┐
│ │ │
Web ×10 Workers ×30 Search ×5
│ │ │
└───────────────┼───────────────┘
│
DB / Redis / MQ
Для такой системы Kubernetes действительно очень удобен. Но Bitrix обычно устроен иначе.
А что такое Bitrix с точки зрения Kubernetes?
1С-Битрикс — большое монолитное приложение.
Внутри одного приложения находятся сразу:
Bitrix
│
├── CMS
├── каталог
├── пользователи
├── заказы
├── административная часть
├── интеграции
├── события
├── модули
├── API
└── кастомная бизнес-логика
Это само по себе не плохо. Монолитная архитектура имеет свои преимущества: её проще разрабатывать и эксплуатировать, пока система остаётся в разумных границах.
Проблема возникает в другом. Kubernetes не видит внутри Bitrix отдельно каталог, checkout или CMS. Он видит один Bitrix.
Поэтому при необходимости увеличить мощность checkout нельзя просто сделать:
CMS × 2
Catalog × 3
Checkout × 15
Если всё это находится внутри Bitrix, получится:
Bitrix × 15
То есть мы масштабируем весь монолит целиком. Это уже первая причина спросить: насколько преимущества Kubernetes вообще будут использоваться нашей архитектурой?
Реальная нагрузка: цифры вместо ярлыков
Это один из главных вопросов, которые нужно задавать заказчику.
Фраза «у нас несколько десятков сайтов, поэтому нужна высоконагруженная инфраструктура» сама по себе ничего не означает. Тридцать корпоративных сайтов могут создавать меньше нагрузки, чем один крупный интернет-магазин.
Поэтому прежде чем обсуждать Kubernetes, хотелось бы увидеть цифры:
RPS в обычный период и в пике
CPU и RAM
количество PHP- и SQL-запросов
MySQL slow log
cache hit ratio
нагрузка на диски и фоновые задачи
пиковые периоды
SLA, RTO и RPO
Если несколько десятков сайтов в пике создают нагрузку, которую спокойно выдерживают три application-сервера, возникает логичный вопрос: для решения какой проблемы нам нужен Kubernetes?
Bitrix можно масштабировать и без Kubernetes
Иногда создаётся впечатление, что выбор выглядит так:
Один сервер
↓
Kubernetes
Но между этими вариантами есть множество архитектур.
Сам Bitrix давно имеет модуль «Веб-кластер», рассчитанный на распределение сайта между несколькими серверами. Поддерживаются несколько web-серверов, балансировка нагрузки, репликация MySQL, вертикальный шардинг, распределённый кеш и единое хранение пользовательских сессий. Для кеша модуль «Веб-кластер» поддерживает Memcache и Redis, а ядро Bitrix позволяет хранить сессии в файлах, БД, Redis или Memcache. В multi-node-инфраструктуре локальные файлы для сессий уже не подходят, поэтому общее хранилище нужно выбирать осознанно для конкретной редакции и версии продукта.
Архитектура может быть достаточно классической:
Load Balancer
│
┌───────────────┼───────────────┐
│ │ │
BitrixVM-1 BitrixVM-2 BitrixVM-3
│ │ │
└───────────────┼───────────────┘
│
Redis / Memcached / Cache
│
MySQL / MariaDB
Для нескольких web-серверов пользовательская сессия должна быть общей: человек не должен «разлогиниваться» из-за того, что следующий запрос попал на другой сервер. Для этого можно использовать БД, Redis или Memcache. Redis здесь не просто модное внешнее дополнение: актуальное контейнерное окружение Bitrix документирует его и для сессий, и для распределённого кеша. Но в production всё равно нужно отдельно продумать отказоустойчивость, persistence, политику вытеснения данных и поведение приложения при недоступности кеша.
То есть горизонтальное масштабирование Bitrix существовало задолго до Kubernetes.
Начать можно ещё проще — с вертикального масштабирования
Иногда это звучит недостаточно модно, но самый дешёвый способ увеличить производительность — дать серверу больше ресурсов.
Bitrix
│
┌───────┴───────┐
│ │
CPU RAM
16–32 64 GB
│
NVMe
│
MySQL
У вертикального масштабирования есть предел, но до него ещё нужно дойти. Если система прекрасно работает на одном хорошем application-сервере и отдельной БД, создание Kubernetes-кластера может дать гораздо больший прирост инфраструктурной сложности, чем производительности.
Следующий уровень — несколько BitrixVM
Если одного сервера уже недостаточно:
Load Balancer
│
┌──────────────┼──────────────┐
│ │ │
BitrixVM-1 BitrixVM-2 BitrixVM-3
│ │ │
└──────────────┼──────────────┘
│
Shared state
│
Database
Это уже полноценное горизонтальное масштабирование. Причём количество серверов необязательно менять вручную.
Terraform / OpenTofu
│
↓
Cloud API
│
↓
создание новой VM
│
↓
cloud-init / Ansible
│
↓
BitrixVM
│
↓
Health Check
│
↓
Load Balancer
Дополнительные web-ноды при необходимости можно создавать автоматически.
Между BitrixVM и Kubernetes есть ещё один практичный уровень: контейнеры на нескольких VM, Docker Compose или аналогичный рантайм, reverse proxy и Ansible. Для небольшой группы проектов такая схема может дать воспроизводимый deployment без стоимости полноценной Kubernetes-платформы.
У Bitrix есть и готовая отправная точка: репозиторий bitrix-tools/env-docker, который поддерживается командой внутри компании «1С-Битрикс». В нём через Docker Compose собраны Nginx, PHP, MySQL и PostgreSQL, Redis, Memcached, отдельный cron-контейнер, Push-сервер и Sphinx; код и изменяемые данные хранятся в Docker Volumes.
Но важно правильно понимать статус проекта. Его README прямо называет окружение девелоперским, предназначенным для разработки, тестирования и примера, и не рекомендует использовать его в production без дополнительных настроек безопасности и эксплуатации. Поэтому env-docker — хороший аргумент в пользу контейнеризации Bitrix без Kubernetes, но не готовая высокодоступная production-архитектура.
Но Kubernetes же умеет автоматически масштабироваться?
Да. И делает это очень хорошо.
Horizontal Pod Autoscaler может автоматически менять количество экземпляров приложения на основании CPU, памяти и других метрик. Это реальное преимущество Kubernetes.
При этом несколько реплик и autoscaling — не одно и то же. Например, в инструкции Yandex Cloud по установке Bitrix масштаб продуктового окружения задаётся параметром replicaCount. Он определяет желаемое число реплик, но сам по себе не настраивает HPA: метрики, пороги, минимальное и максимальное число Pod и безопасное поведение приложения при масштабировании остаются отдельным архитектурным решением.
Но нужен ли Kubernetes только ради этого? Не обязательно. Аналогичную автоматизацию можно построить и для обычных виртуальных машин. Разница скорее в скорости и удобстве.
Контейнер обычно стартует быстрее полноценной виртуальной машины:
Kubernetes:
нагрузка выросла
↓
новый Pod
↓
Ready
Для VM цепочка длиннее:
нагрузка выросла
↓
создать VM
↓
загрузить OS
↓
запустить сервисы
↓
проверить состояние
↓
подключить к Load Balancer
Но насколько эта разница важна для конкретного бизнеса?
Известные пики можно обслуживать заранее
Например, распродажа, Black Friday, рекламная кампания, запуск новой коллекции или телевизионная реклама.
В этом случае дополнительную инфраструктуру можно поднять заранее:
обычный день: 4 web-сервера
↓
за час до акции: 15 web-серверов
↓
началась акция: при необходимости → 25
↓
акция закончилась: 8 → 4
Иногда такой подход даже надёжнее реактивного autoscaling в момент, когда сайт уже получил резкий всплеск трафика.
А что если проблема вообще не в web-серверах?
Представим:
Bitrix × 4
│
↓
MySQL
Мы решили проблему масштабированием:
Bitrix × 25
│
↓
MySQL
Но все 25 экземпляров обращаются к одной и той же базе. Если именно база была узким местом, мы не решили проблему. Мы просто научились ещё быстрее отправлять в неё запросы.
Поэтому до выбора Kubernetes стоит выяснить, где находится реальное ограничение:
PHP?
CPU?
MySQL?
диск?
кеш?
внешнее API?
1С?
поиск?
очередь?
плохой SQL?
кастомный обработчик?
В высоконагруженных системах правильная оптимизация одного SQL-запроса иногда даёт больше, чем добавление десяти application-серверов.
А что такое вертикальный шардинг Bitrix?
В терминологии Bitrix «вертикальный шардинг» позволяет вынести таблицы отдельных модулей на отдельные MySQL-серверы. Эта возможность входит в Web Cluster.
Упрощённо:
Bitrix
│
┌─────────────┼─────────────┐
│ │ │
Main DB Module DB Module DB
Также БД можно реплицировать:
Primary
│
┌────────────┼────────────┐
│ │ │
Replica Replica Replica
Это не означает, что шардинг обязательно является лучшей архитектурой. Смысл в другом: Bitrix уже имеет собственный набор средств масштабирования. И перед добавлением ещё одного сложного инфраструктурного слоя стоит понять, недостаточно ли имеющихся инструментов.
Что такое Multi-site простыми словами
Bitrix Multi-site позволяет одной установке обслуживать несколько сайтов.
Один Bitrix
│
┌──────────────┼──────────────┐
│ │ │
site.ru brand.ru shop.ru
Все они используют одно ядро Bitrix, одну базу и один набор установленных модулей. Сама документация описывает многосайтовость как решение прежде всего для отдельных, но связанных проектов.
У этого есть серьёзные плюсы: не нужно обновлять одно и то же ядро двадцать раз, можно переиспользовать код, централизовать управление и поддерживать единые стандарты. Но появляется и обратная сторона.
Что такое blast radius и почему он увеличивается
В инфраструктуре есть термин blast radius. По смыслу это то, какую часть системы затронет одна ошибка.
Представим три независимых сайта:
Site A → Bitrix A → DB A
Site B → Bitrix B → DB B
Site C → Bitrix C → DB C
Разработчик ошибся при обновлении Site A:
Site A → ошибка
Site B → работает
Site C → работает
Да, сопровождать три системы дороже. Но они изолированы.
Теперь объединим их:
Site A
│
Site B
│
Site C
│
один общий Bitrix
│
общая DB
Обновили ядро, появилась ошибка — и она потенциально затронула сразу все сайты. Вот это и называется увеличением blast radius.
По-простому: раньше одна ошибка могла сломать один сайт, теперь она потенциально может затронуть сразу десять или тридцать.
Чем больше Multi-site, тем важнее общая совместимость
Предположим, в один Bitrix объединили 30 сайтов. Теперь изменение общего модуля должно быть совместимо со всеми 30. Обновление ядра должно быть протестировано на всех 30. Изменение схемы БД тоже может влиять сразу на несколько проектов.
Обновление
│
┌────────┼────────┐
│ │ │
Site 1 Site 2 ... Site 30
Это не аргумент против Multi-site. Если сайты действительно похожи, используют одну команду, одну CMS, одну бизнес-логику, одинаковые интеграции и одинаковый release cycle, Multi-site может быть отличным решением.
Но если это совершенно разные бизнесы — корпоративный сайт, интернет-магазин, личный кабинет, B2B-портал, медиа и сервисный портал — объединение их только ради слова «консолидация» уже требует серьёзного обоснования.
Единая платформа не обязательно означает один Bitrix
Когда заказчик говорит «нам нужна единая платформа», это необязательно должно означать:
30 Bitrix
↓
1 огромный Bitrix
Можно стандартизировать технологии, но сохранить разумную изоляцию систем:
Единая платформа
│
┌─────────────────┼─────────────────┐
│ │ │
CI/CD Docker Image Monitoring
│ │ │
├──────── Security / Backup ─────────┤
│ │
↓ ↓
Bitrix A Bitrix B Bitrix C
│ │ │
DB A DB B DB C
Едиными могут быть версия PHP, версия ОС, Docker image, стандарты Bitrix, общие библиотеки, CI/CD, Infrastructure as Code, мониторинг, логирование, резервное копирование, безопасность и процесс развёртывания.
Но падение одного приложения не обязательно должно потянуть за собой остальные.
Можно сгруппировать сайты, а не объединять все
Часто оптимальное решение находится между двумя крайностями: тридцать независимых Bitrix и один Bitrix на тридцать сайтов.
Сначала можно провести аудит:
30 сайтов
│
Audit
│
┌────────────────┼────────────────┐
│ │ │
Корпоративные E-commerce Legacy
15 сайтов 8 сайтов 7 сайтов
│ │ │
Bitrix A Bitrix B Bitrix C/D
Тогда вместо тридцати различных платформ получится, например, три–пять стандартизированных. Уменьшается количество версий, дублирование кода, стоимость поддержки и технологический зоопарк. При этом сохраняется часть изоляции.
Для многих компаний такой компромисс может оказаться гораздо практичнее одного гигантского Multi-site.
А где тогда действительно полезен Kubernetes?
После всей критики может показаться, что мы против Kubernetes. Нет. Есть ситуации, когда мы сами выбрали данное решение.
1. Kubernetes уже является платформой компании
Представим крупную компанию, где уже есть Kubernetes, GitOps, Container Registry, DevOps/SRE, мониторинг, логирование, Secrets Management, Security Policies и CI/CD.
Компания уже оплачивает компетенции и инфраструктуру Kubernetes. Создавать специально для Bitrix отдельный инфраструктурный мир с VM, Ansible, собственными правилами, мониторингом и deployment может оказаться дороже, чем адаптировать Bitrix под общую корпоративную платформу.
В этом случае Kubernetes может быть вполне рациональным выбором.
2. Есть много разных приложений вокруг Bitrix
Kubernetes
│
┌───────────────────┼───────────────────┐
│ │ │
Bitrix Integration API Workers
× 6 × 4 × 30
│ │ │
├───────────────────┼───────────────────┤
│ │ │
Search ×5 Images ×10 Notifications ×5
Здесь Kubernetes начинает работать именно там, где особенно хорош: каждый компонент живёт и масштабируется независимо.
Например:
Bitrix × 4
Import workers × 30
Image workers × 20
Search × 6
Integration API × 3
Здесь преимущества Kubernetes намного очевиднее, чем в конструкции Bitrix × 20.
3. Очень много независимых проектов
Если компания обслуживает не один огромный Multi-site, а десятки приложений — Bitrix Corporate, Bitrix Shop, Bitrix Brands, Laravel API, Search Service, Integration Service, Workers и Internal Portal — Kubernetes может стать хорошей общей платформой для эксплуатации всех этих систем.
Тогда его задача уже не «масштабировать Bitrix», а управлять всей прикладной платформой компании. Это совершенно другой уровень аргументации.
4. Нужна высокая степень автоматизации эксплуатации
Kubernetes даёт хорошие стандартные механизмы:
health checks
self-healing
rolling deployments
resource limits
autoscaling
declarative configuration
service discovery
Всё это можно сделать и без Kubernetes. Но если систем очень много, Kubernetes предоставляет унифицированный способ сделать это сразу для всей платформы.
Именно масштаб самой инфраструктуры, а не только посещаемость сайта, начинает оправдывать его сложность.
Но за Kubernetes приходится платить
Сам Kubernetes — open source. Но это не означает, что Kubernetes бесплатен. Основная цена — люди и сложность.
Для нормальной эксплуатации нужно понимать как минимум:
Kubernetes
Docker
Helm
Ingress
Networking
Persistent Volumes
Secrets
Monitoring
Logging
Autoscaling
Container Registry
CI/CD
Backup
Disaster Recovery
Это уже другой уровень DevOps-компетенции. И такие специалисты стоят денег.
Managed Kubernetes снимает часть работы с control plane, обновлениями управляющих компонентов и доступностью самого кластера. Готовое приложение из Marketplace или Helm-chart может снять ещё часть стартовой работы. Например, решение Yandex Cloud для Bitrix предоставляет базовые образы и настройки для cron, Push-сервера, Sphinx, Redis-кеша, экспорта метрик и Object Storage.
Но даже такой chart не проектирует за команду release process, права доступа, сетевую безопасность, резервное копирование, восстановление, наблюдаемость и поведение приложения при отказе MySQL или общего хранилища. Поэтому сравнивать стоит полную стоимость владения: инфраструктуру, людей, дежурства, время диагностики и восстановление после сбоев.
Появляется новый класс проблем
В классической инфраструктуре проблема часто выглядит так:
Nginx работает?
PHP работает?
MySQL работает?
В Kubernetes появляются дополнительные уровни:
Pod запустился?
Container запустился?
Image скачался?
Readiness probe проходит?
Ingress правильно маршрутизирует?
Service видит Pod?
DNS работает?
PVC примонтирован?
Node доступен?
Хватает resource limits?
Работает network policy?
И только после этого мы доходим до вопроса: что случилось с Bitrix?
Kubernetes не убирает сложность самого Bitrix. Он добавляет вокруг него ещё один инфраструктурный слой. Если этот слой решает реальные задачи — всё нормально. Если нет — компания просто получает более дорогую систему сопровождения.
А как обновлять Bitrix в Kubernetes?
Современная container-инфраструктура обычно строится по принципу: работающий контейнер сам себя не изменяет.
Есть, например, bitrix-app:1.5.1. Вышла новая версия bitrix-app:1.5.2. CI/CD собирает новый image, а Kubernetes постепенно заменяет старые экземпляры новыми:
1.5.1 1.5.1 1.5.1
↓
1.5.2 1.5.1 1.5.1
↓
1.5.2 1.5.2 1.5.1
↓
1.5.2 1.5.2 1.5.2
Если новая версия плохая, выполняется rollback к 1.5.1. Отличная схема.
Но исторически Bitrix предполагает довольно много изменяемого состояния: обновления ядра, Marketplace-модули, изменения БД, /upload, кеш, агенты и generated files.
Поэтому просто поместить существующий Bitrix в Docker недостаточно. Нужно определить:
что входит в Docker image;
что хранится снаружи;
кто имеет право обновлять ядро;
как обновляются модули;
как выполняются миграции БД;
как происходит rollback;
что будет с БД при rollback кода.
И фактически изменить привычный процесс эксплуатации Bitrix. Это вполне можно сделать. Но это проект, а не галочка «перенесли в Kubernetes».
Один из рабочих паттернов выглядит так: ядро и Marketplace-модули попадают в Docker image на этапе CI; изменения кода и структуры данных оформляются версионированными миграциями — например, через sprint.migration или собственный слой; миграции БД выполняются отдельным Kubernetes Job до rolling update. Откат кода безопасен только при обратно совместимых изменениях схемы — иначе требуется отдельный сценарий восстановления.
Конкретный cloud-pattern: административное и продуктовое окружения
Документация Yandex Cloud разделяет окружения Bitrix на два типа. Административное предназначено для установки или восстановления продукта, изменений через административную панель, работы с Git, тестирования и разработки. Продуктовое окружение не предназначено для изменения компонентов Bitrix, не содержит административной панели и разворачивается из заранее подготовленных PHP- и Nginx-образов.
Это практичный компромисс между привычной изменяемой моделью Bitrix и immutable deployment: изменения готовятся в контролируемом окружении, а production получает версионированные образы и заданное число реплик.
Однако это не полная изоляция. В описанной схеме административное и продуктовое окружения совместно используют MySQL и бакет Object Storage. Значит, изменение схемы БД или общих файлов всё ещё может повлиять на production, даже если сами Pod и namespaces разделены. Blast radius на уровне данных никуда не исчезает.
Stateful-проблема: файлы и сессии
Контейнеры хорошо работают, когда экземпляр приложения можно уничтожить и создать заново:
Pod-123 умер
↓
удалили
↓
Pod-456 запущен
Пользователь ничего не заметил. Но для этого важные данные не должны находиться только внутри старого Pod.
Поэтому Bitrix необходимо привести примерно к такой модели:
Bitrix Pods
│
┌───────────┼───────────┐
│ │ │
Sessions Uploads Cache
│ │ │
shared store S3/PV external/local
│
DB
То есть состояние приходится постепенно выносить из приложения.
Особого внимания требует /upload. Общий RWX-том на NFS или CephFS технически позволяет нескольким Pod работать с одними файлами, но его задержки и пропускная способность могут стать новым узким местом. S3-совместимое object storage вместе с CDN часто лучше подходит для пользовательских файлов и статики; при этом решение зависит от профиля файловых операций и совместимости конкретных модулей. Сам Bitrix имеет модуль «Облачные хранилища» с поддержкой S3-совместимых провайдеров.
В референсной схеме Yandex Cloud используется другой способ: драйвер csi-s3 монтирует Object Storage как файловую систему, а общие каталоги upload и backup размещаются в бакете. Это не то же самое, что работа с S3 через модуль Bitrix на уровне приложения. CSI-монтирование сохраняет для приложения файловый интерфейс, но требует отдельной проверки совместимости файловых операций, задержек и поведения под нагрузкой. Само слово S3 ещё не гарантирует нужную производительность.
Сессии и общий кеш также не должны оставаться на локальном диске Pod. Их выносят в общее хранилище, поддерживаемое выбранной конфигурацией приложения. Например, chart Yandex Cloud может развернуть Redis отдельным StatefulSet внутри кластера. Это выносит кеш из web-Pod, но не отменяет stateful-эксплуатацию самого Redis: нужны мониторинг, persistence, резервирование и понятная политика восстановления. Локальный кеш допустим только для данных, которые можно безопасно потерять и пересоздать вместе с Pod.
Агенты и cron
Агенты и периодические задачи нельзя бездумно запускать в каждом web-Pod: после масштабирования один и тот же процесс может стартовать несколько раз. Планировщик выносят в отдельный Pod или Kubernetes CronJob, задают политику конкуренции и делают операции идемпотентными. Для Bitrix это продолжает штатную практику переноса тяжёлых агентов с пользовательских хитов на cron, но уже с явным владельцем расписания внутри платформы. В env-docker для агентов предусмотрен отдельный контейнер cron, а в chart Yandex Cloud эта возможность включается параметром features.cron.
Готовые окружения и Helm-чарты уменьшают объём адаптации, но не отменяют проектирование состояния, обновлений и восстановления. Поэтому вопрос остаётся прежним: достаточно ли измеримой пользы мы получаем взамен этой сложности?
Есть ещё один архитектурный вопрос
Допустим, компания говорит: «Мы хотим современную Enterprise-платформу». Появляются Kubernetes, CI/CD, IaC, containers, message queues, observability, autoscaling и API.
И здесь я бы задал ещё один вопрос: почему тогда вся новая архитектура обязательно должна строиться вокруг одного большого монолита Bitrix?
Это не означает «немедленно переписать Bitrix на Laravel». Переписывание большой работающей системы с нуля зачастую является очень дорогим и рискованным проектом. Но можно постепенно двигаться к другой архитектуре.
Internet
│
Ingress
│
┌──────────────┴──────────────┐
│ │
Bitrix Service Layer
CMS / Legacy │
│ ┌───────────┼───────────┐
│ │ │ │
│ Laravel Workers Search
│ │ │ │
└────────────── Integration / API ────────┘
Bitrix можно оставить там, где он действительно полезен: CMS, контент, административная часть, существующий каталог, legacy business logic и интеграция с 1С.
А новые задачи постепенно выносить наружу: API, очереди, интеграции, поиск, обработку изображений, уведомления и новые backend-сервисы.
И вот для такой архитектуры Kubernetes уже начинает выглядеть намного естественнее.
Получается парадокс
Чем больше наша архитектура выглядит так:
Giant Bitrix
×20
тем меньше преимуществ Kubernetes мы используем.
Чем больше она становится такой:
Platform
│
┌───────────────┼───────────────┐
│ │ │
Bitrix API Service Workers
│ │ │
├────────── Search Service ──────┤
│ │
└──────── Integration Service ──┘
тем больше Kubernetes начинает приносить реальную пользу.
Три возможных архитектуры
Если максимально упростить выбор для заказчика, мы бы рассматривали три сценария.
Вариант 1. Классический Bitrix-кластер
Load Balancer
│
┌─────────────┼─────────────┐
│ │ │
BitrixVM BitrixVM BitrixVM
│ │ │
└─────────────┼─────────────┘
│
Cache / Sessions
│
DB Cluster
Подходит, если основная система — Bitrix, инфраструктура относительно простая, нагрузка предсказуема, Kubernetes-команды в компании нет, а количество сервисов небольшое.
Плюсы: проще, дешевле, понятнее.
Вариант 2. Bitrix в Kubernetes
Kubernetes
│
Ingress
│
┌─────────────┼─────────────┐
│ │ │
Bitrix Pod Bitrix Pod Bitrix Pod
│ │ │
└─────────────┼─────────────┘
│
Shared state / DB
Подходит, если Kubernetes уже принят в компании, есть DevOps/SRE-команда, все приложения должны жить на общей платформе, требуется единый deployment process и вокруг Bitrix есть другие workloads.
Плюс: единый стандарт эксплуатации. Минус: существенно более высокая инфраструктурная сложность.
Вариант 3. Гибридная платформа
На наш взгляд, наиболее интересный вариант для долгосрочного развития:
Kubernetes
│
┌──────────────────┼──────────────────┐
│ │ │
Bitrix Laravel/API Workers
CMS / Legacy │ │
│ Search Integration
│ │ │
└────────────────────┼──────────────────┘
│
Data Platform
Bitrix не нужно переписывать целиком. Но он перестаёт быть местом, куда автоматически добавляется любая новая функциональность.
Плюсы:
legacy продолжает работать;
новые сервисы можно строить современным способом;
их можно масштабировать независимо;
миграция происходит постепенно;
Kubernetes используется там, где его преимущества действительно востребованы.
Как бы мы принимали решение
Не начинали проект словами «мы переносим Bitrix в Kubernetes». А примерно так:
Бизнес-требования
│
↓
Аудит систем
│
↓
Анализ нагрузки
│
↓
Анализ рисков/SLA
│
↓
Целевая архитектура
│
┌──────────────┼──────────────┐
│ │ │
BitrixVM Docker Kubernetes
И задали бы заказчику несколько вопросов.
1. Какова реальная нагрузка?
Не «много сайтов», а конкретные цифры.
2. Где сейчас находится "узкое горлышко"?
Web, база, диск, интеграция или кеш?
3. Насколько сайты похожи?
Им действительно нужны общее ядро и общая БД?
4. Какой уровень изоляции нужен?
Допустимо ли, чтобы ошибка общего обновления потенциально затронула сразу все сайты?
5. Как часто требуется масштабирование?
Постоянно, несколько раз в год или вообще никогда?
6. Есть ли Kubernetes-компетенции внутри компании?
Если нет, кто будет поддерживать платформу после окончания проекта?
7. Сколько будет стоить эта архитектура не при внедрении, а через три года?
Это, пожалуй, один из самых важных вопросов.
Kubernetes — это не синоним Highload
Крупный проект не обязательно должен использовать Kubernetes. И наоборот, небольшой проект вполне может работать в Kubernetes, если это часть общей инфраструктуры компании.
Enterprise ≠ Kubernetes
Highload ≠ Kubernetes
Multi-site ≠ Kubernetes
Containers ≠ Kubernetes
Kubernetes — очень мощный инструмент. Но стоимость и сложность этого инструмента должны соответствовать задаче.
И главный вопрос
На встрече по подобному проекту мы бы задали достаточно простой вопрос:
Какую конкретную проблему нашей Bitrix-инфраструктуры решает Kubernetes, которую нельзя дешевле и проще решить обычным web-кластером, несколькими BitrixVM, автоматическим deployment, общей БД или репликами, кешем и Infrastructure as Code?
У этого вопроса может быть отличный ответ:
У нас Kubernetes — корпоративный стандарт, зрелая Platform Team, десятки сервисов, единые security policies и CI/CD.
Или:
У нас множество независимо масштабируемых workloads, а Bitrix — только один из компонентов платформы.
Тогда использование Kubernetes вполне оправдано.
Если единственный аргумент — «у нас Enterprise и Highload», мы бы предложили сначала собрать метрики. Часто они показывают картину, при которой решение становится очевидным само.
Иногда системе действительно нужен Kubernetes. А иногда достаточно балансировщика, нескольких Bitrix-серверов, общего кеша, сессий и базы данных.
И второй вариант может оказаться не «устаревшей архитектурой», а наоборот — более простым, дешёвым и надёжным инженерным решением для конкретного бизнеса.
Вместо заключения
Мы не против Bitrix в Kubernetes. И не считаем, что Kubernetes предназначен исключительно для микросервисов — он прекрасно умеет запускать и монолиты.
Сомнение в другом.
Если мы берём большой stateful legacy-монолит, адаптируем его под контейнеры, решаем проблему общего файлового хранилища, сессий, кешей, обновлений, миграций, CI/CD и добавляем для всего этого отдельный уровень DevOps-компетенции, хотелось бы понимать: какую измеримую пользу получает от этого бизнес?
Если ответ есть — Kubernetes может быть отличным выбором.
Если ответа нет, возможно, мы не модернизируем инфраструктуру.
Мы просто делаем её сложнее.
Материалы по теме
P.S.
