Развертывание 1С-Битрикс в Kubernetes

Развертывание 1С-Битрикс в Kubernetes

1С-Битрикс не проектировался для контейнерной оркестрации. Сессии в файлах, кеш на диске, загружаемые файлы в upload/, ядро в bitrix/ — всё это «statefull» артефакты, которые в Kubernetes требуют специальной обработки. Тем не менее задача решаема, и в production работают нагруженные Битрикс-сайты в k8s-кластерах.

Основные проблемы при контейнеризации Битрикс

Сессии. По умолчанию PHP сохраняет сессии в /tmp контейнера. При нескольких репликах pod'ов разные запросы одного пользователя попадают на разные pod'ы — сессия теряется. Решение: переключить хранилище сессий на Redis.

В .settings.php Битрикс:

'session' => [
    'value' => [
        'mode' => 'separated',
        'handlers' => [
            'general' => [
                'type' => 'redis',
                'host' => 'redis-service',
                'port' => 6379,
            ],
        ],
    ],
],

Кеш. CACHE_TYPE=A в компонентах по умолчанию пишет в bitrix/cache/. При нескольких репликах кеш не синхронизируется. Переключаем на Memcached или Redis:

'cache' => [
    'value' => [
        'type' => ['memcache' => 'memcache'],
        'memcache' => [
            'host' => 'memcached-service',
            'port' => 11211,
        ],
    ],
],

Файлы. Директория upload/ должна быть доступна всем pod'ам. Используем PersistentVolumeClaim с режимом ReadWriteMany (NFS, CephFS, Longhorn в режиме RWX).

Лицензия. Битрикс привязывает лицензию к IP-адресу или домену, не к MAC-адресу контейнера. При облачном деплое убедитесь, что внешний IP стабилен или лицензия оформлена на домен.

Структура Kubernetes-манифестов

namespace: bitrix-prod
├── Deployment: bitrix-app (PHP-FPM + Nginx sidecar)
├── Service: bitrix-app-svc
├── Ingress: bitrix-ingress (с TLS)
├── StatefulSet: redis (или Redis Operator)
├── StatefulSet: memcached
├── PersistentVolumeClaim: bitrix-upload (RWX)
├── ConfigMap: php-fpm-config
├── ConfigMap: nginx-config
└── Secret: db-credentials

Deployment для PHP-FPM:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: bitrix-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: bitrix-app
  template:
    spec:
      containers:
        - name: php-fpm
          image: registry.example.com/bitrix-app:1.2.3
          volumeMounts:
            - name: upload
              mountPath: /var/www/html/upload
            - name: php-fpm-config
              mountPath: /usr/local/etc/php-fpm.d/www.conf
              subPath: www.conf
          env:
            - name: DB_HOST
              valueFrom:
                secretKeyRef:
                  name: db-credentials
                  key: host
        - name: nginx
          image: nginx:1.25-alpine
          ports:
            - containerPort: 80
          volumeMounts:
            - name: upload
              mountPath: /var/www/html/upload
            - name: nginx-config
              mountPath: /etc/nginx/conf.d/default.conf
              subPath: default.conf
      volumes:
        - name: upload
          persistentVolumeClaim:
            claimName: bitrix-upload
        - name: php-fpm-config
          configMap:
            name: php-fpm-config
        - name: nginx-config
          configMap:
            name: nginx-config

Dockerfile для образа Битрикс

FROM php:8.2-fpm-bullseye

RUN apt-get update && apt-get install -y \
    libzip-dev libpng-dev libjpeg-dev libwebp-dev \
    && docker-php-ext-install pdo_mysql zip gd opcache

RUN pecl install redis && docker-php-ext-enable redis
RUN pecl install memcached && docker-php-ext-enable memcached

COPY php.ini /usr/local/etc/php/conf.d/99-bitrix.ini
COPY --chown=www-data:www-data . /var/www/html

# upload/ монтируется как PVC, поэтому исключаем из образа
RUN rm -rf /var/www/html/upload

WORKDIR /var/www/html

Важно: код Битрикс (bitrix/, local/, публичные php-файлы) запекается в образ. upload/ монтируется снаружи через PVC. Обновление сайта = сборка нового образа + rolling update Deployment'а.

База данных вне Kubernetes

Базу данных MySQL/PostgreSQL не рекомендуется запускать в k8s без специализированных операторов (Percona Operator, CloudNativePG). Проще использовать managed-решения: AWS RDS, Yandex Cloud Managed MySQL, или выделенный сервер вне кластера. Битрикс подключается по стандартному хосту и порту через Secret.

Горизонтальное масштабирование

После решения проблем с сессиями и кешем Deployment масштабируется командой:

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-пайплайн

git push → GitLab CI/CD:
  1. docker build -t registry/bitrix-app:${CI_COMMIT_SHA} .
  2. docker push registry/bitrix-app:${CI_COMMIT_SHA}
  3. kubectl set image deployment/bitrix-app php-fpm=registry/bitrix-app:${CI_COMMIT_SHA}
  4. kubectl rollout status deployment/bitrix-app

Rolling update заменяет pod'ы по одному — нулевой downtime при деплоях.

Сроки

Итого: 2–3 недели для боевого окружения. Для dev/staging — быстрее.