1С-Битрикс не проектировался для контейнерной оркестрации. Сессии в файлах, кеш на диске, загружаемые файлы в upload/, ядро в bitrix/ — всё это stateful артефакты, которые в Kubernetes требуют специальной обработки. Тем не менее задача решаема, и в production работают нагруженные Битрикс-сайты в k8s-кластерах. Мы развернули Битрикс в Kubernetes для 15+ проектов, и наш опыт показывает: за 2-3 недели можно получить отказоустойчивую инфраструктуру с автоматическим масштабированием.
Правильная контейнеризация Битрикс позволяет добиться нулевого downtime при деплоях и легко переживать пиковые нагрузки. Наши клиенты экономят до 30% на инфраструктурных затратах, а проект окупается в течение полугода. В этой статье разберём ключевые проблемы и их решения на основе реальных кейсов.
Однако многие команды сталкиваются с типовыми ошибками: неправильная настройка сессий приводит к автоматическим разлогинам при масштабировании, а хранение кеша в файлах сводит на нет преимущества контейнеризации. Мы собрали best practices, которые помогут избежать этих граблей.
Почему Kubernetes для Битрикс — это вызов?
Главная проблема — Битрикс хранит состояние (сессии, кеш, загруженные файлы) локально на диске. В Kubernetes поды эфемерны: при пересоздании pod'а данные теряются. Без специальных настроек пользователь будет терять сессию при каждом запросе, а кеш станет бесполезен. Кроме того, лицензия Битрикс привязана к IP или домену — при облачном деплое нужно обеспечить стабильный внешний IP. Дополнительная сложность — обработка загруженных файлов: в классической схеме все upload-файлы лежат в общей папке, доступной всем веб-серверам. Интеграция с 1С через CommerceML требует временных файлов, которые должны быть доступны всем подам. Битрикс24 также может быть развёрнут в Kubernetes, но его архитектура отличается — требуется отдельная конфигурация агентов и событий. Документация Kubernetes рекомендует использовать PersistentVolume для stateful данных. Мы применяем этот подход уже в 15 проектах.
Как мы решаем проблему сессий и кеша?
Сессии. Переключаем хранение сессий на Redis. В .settings.php Битрикс прописываем:
'session' => [ 'value' => [ 'mode' => 'separated', 'handlers' => [ 'general' => [ 'type' => 'redis', 'host' => 'redis-service', 'port' => 6379, ], ], ], ], Кеш. Меняем CACHE_TYPE=A на Memcached:
'cache' => [ 'value' => [ 'type' => ['memcache' => 'memcache'], 'memcache' => [ 'host' => 'memcached-service', 'port' => 11211, ], ], ], Файлы. Директория upload/ монтируется через PersistentVolumeClaim с режимом ReadWriteMany (NFS, CephFS). Код же запекается в Docker-образ — это ускоряет деплой и упрощает управление версиями.
Как настроить хранение файлов upload?
Для хранения файлов upload мы используем PersistentVolumeClaim с режимом доступа ReadWriteMany. Рекомендуем NFS-сервер в кластере или облачный файловый сторадж (например, Яндекс Object Storage через FUSE). Важно: код сайта должен быть запечён в Docker-образ, а upload-директория исключена из образа через .dockerignore. Это гарантирует, что файлы не потеряются при пересоздании подов. На практике для каталога с 2 млн товаров upload занимает 50 ГБ — PV справляется без проблем.
| Решение | Производительность | Надёжность | Стоимость |
|---|---|---|---|
| NFS | Средняя | Высокая | Низкая |
| CephFS | Высокая | Очень высокая | Средняя |
| Облачный сторадж (S3) | Низкая-средняя | Высокая | Средняя |
Типичные ошибки при контейнеризации Битрикс
Развернуть типичные ошибки
| Ошибка | Последствие | Решение |
|---|---|---|
| Сессии в файлах | Потеря сессии при масштабировании | Использовать Redis |
| Кеш на диске | Низкая производительность | Memcached или Redis |
| upload в образе | Размер образа, потеря данных | PersistentVolume |
| Отсутствие .dockerignore | Медленная сборка | Исключить upload и bitrix |
Почему базу данных стоит вынести за пределы кластера?
Хотя MySQL можно запустить в Kubernetes через StatefulSet, мы настоятельно рекомендуем использовать managed-решения (AWS RDS, Yandex Managed Service for MySQL). Это упрощает бэкапы, репликацию и обновления. Базы данных — самый критичный компонент, и их обслуживание в кластере требует отдельной экспертизы. Например, при сбое etcd восстановление базы может занять часы, а managed-решение гарантирует SLA 99.95%.
Структура Kubernetes-манифестов
namespace: bitrix-prod ├── Deployment: bitrix-app (PHP-FPM + Nginx sidecar) ├── Service: bitrix-app-svc ├── Ingress: bitrix-ingress (с TLS) ├── StatefulSet: redis ├── StatefulSet: memcached ├── PersistentVolumeClaim: bitrix-upload (RWX) ├── ConfigMap: php-fpm-config ├── ConfigMap: nginx-config └── Secret: db-credentials Deployment для PHP-FPM с Nginx sidecar, монтированием upload и конфигов — стандартный паттерн. Базу данных (MySQL) рекомендуем вынести в managed-решение — это надёжнее и проще в обслуживании.
Горизонтальное масштабирование
После настройки Redis и Memcached масштабирование — одна команда: kubectl scale deployment bitrix-app --replicas=5. Можно добавить HorizontalPodAutoscaler:
apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: bitrix-hpa spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: bitrix-app minReplicas: 2 maxReplicas: 10 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 70 CI/CD-пайплайн
Мы используем GitLab CI/CD: сборка Docker-образа, пуш в registry, rolling update через kubectl. Никакого downtime — pod'ы заменяются по одному.
Сроки
| Этап | Содержание | Срок |
|---|---|---|
| Анализ и подготовка | Аудит конфигурации Битрикс, выбор решений для сессий/кеша | 2–3 дня |
| Dockerfile + образ | Сборка, проверка работоспособности | 2–3 дня |
| k8s-манифесты | Deployment, Service, Ingress, PVC, ConfigMap, Secret | 3–4 дня |
| Redis/Memcached | Развёртывание и настройка session/cache | 1–2 дня |
| CI/CD | Пайплайн сборки и деплоя | 2–3 дня |
| Тестирование | Нагрузочные тесты, проверка sticky session | 2–3 дня |
Итого: 2-3 недели для боевого окружения. Для dev/staging — быстрее.
Что входит в работу
- Аудит текущей конфигурации Битрикс и инфраструктуры.
- Разработка Dockerfile и Docker Compose для локальной разработки.
- Написание манифестов Kubernetes (Deployment, Service, Ingress, PVC, Secret).
- Настройка Redis и Memcached для сессий и кеша.
- Интеграция CI/CD (GitLab/GitHub Actions) с rolling update.
- Нагрузочное тестирование и оптимизация (до 1000 RPS).
- Документация по развёртыванию и эксплуатации.
- Обучение вашей команды (1-2 сессии).
Наш опыт
Более 7 лет занимаемся инфраструктурой на Битрикс. Развернули 15+ проектов в Kubernetes, включая каталоги с миллионами товаров и высокой посещаемостью. Используем только стабильные технологии и best practices. Один из клиентов — интернет-магазин с 2 млн товаров и 50 000 уникальных посетителей в день. После миграции downtime снизился до нуля, а скорость загрузки страниц выросла на 40%.
Закажите аудит вашей инфраструктуры — мы оценим готовность к контейнеризации и предложим оптимальный план. Свяжитесь с нами для консультации.