Модуль Code: Масштабирование

В этом документе описано, как модуль Code подбирает ресурсы и масштабирует Kubernetes workloads на основе параметров масштабирования в CodeInstance.

Ключевые параметры

• spec.scaling.targetUserCount: профиль нагрузки (ожидаемое количество пользователей). Поддерживаемые значения: 100, 1000, 3000, 5000 (10 существует только для внутреннего использования разработчиками; см. предупреждение ниже).
• spec.scaling.highAvailability: переключатель HA-режима. Включает создание и настройку ресурсов autoscaling и защиты от вытеснений (см. следующий раздел).
• spec.gitData.resources: ручное переопределение CPU/памяти для Gitaly (имеет приоритет над spec.scaling.targetUserCount).
• spec.gitData.replicas: количество реплик Gitaly в HA-режиме (опционально; если не задано, используются значения по умолчанию).

За счёт чего обеспечивается отказоустойчивость и растёт производительность

При включенном HA-режиме (spec.scaling.highAvailability: true) оператор использует стандартные механизмы Kubernetes, которые повышают устойчивость к сбоям и помогают держать производительность под нагрузкой:

• Несколько реплик (Deployments/StatefulSets): сервисы запускаются более чем в одной реплике, поэтому отказ одной поды/ноды не останавливает сервис.
• Horizontal Pod Autoscaler (HPA): автоматически увеличивает/уменьшает число реплик на основе CPU-метрик; для ключевых компонентов настройки подбираются под targetUserCount. Это даёт дополнительную пропускную способность в пике без постоянного использования большого количества физических ресурсов сервера.
• PodDisruptionBudget (PDB): ограничивает количество Pod, которые можно вытеснить при планируемых событиях (drain нод, обновления), снижая риск простоя во время обслуживания.
• Pod anti-affinity (preferred): Pod предпочтительно разносятся по нодам (по kubernetes.io/hostname). Это повышает отказоустойчивость — если одна нода выйдет из строя, остальные реплики приложения продолжат работать на других нодах. Кроме того, реплики не будут мешать друг другу при нехватке ресурсов (CPU, память) на одной ноде. Такое распределение работает, когда в кластере достаточно свободных нод.

При выключенном HA-режиме оператор использует более простую “standalone” топологию (для многих сервисов — одна реплика) и не создаются объекты HPA/PDB.

Внимание Не рекомендуется использовать любые экземпляры “burstable” в облачной инфраструктуре из-за непостоянной производительности.

spec.scaling.targetUserCount: 10 предназначен исключительно для внутреннего использования разработчиками. Использование этого значения в иных средах не рекомендуется и может привести к нестабильной работе или непредвиденному поведению системы.

Справочник по ресурсам

Все расчёты выполняются на базе spec.scaling.targetUserCount.

В таблицах ниже приведены ресурсы, требуемые для одной реплики каждого компонента. В HA-режиме закладывайте как минимум 2 реплики для горизонтально масштабируемых сервисов (то есть как минимум ~2× от значений “на одну реплику”), плюс запас под autoscaling.

Standalone-режим (spec.scaling.highAvailability: false)

HA-режим (spec.scaling.highAvailability: true)

Опциональные компоненты отмечены в таблице символом *.

Автоматическое масштабирование (HA-режим)

В HA-режиме для ключевых компонентов настраивается HPA. Для некоторых профилей targetUserCount заданы отдельные лимиты на максимальное количество реплик:

Опциональные компоненты отмечены в таблице символом *.

Настройка масштабирования ресурсов хранилища Git

Если вы видите непустую таблицу ‘OOM events’ в Grafana или срабатывающий алерт GitalyCgroupMemoryOOM в Prometheus, вероятно, вам нужно скорректировать ресурсы памяти и CPU для Gitaly. Увеличьте значения spec.gitData.resources в вашей конфигурации (например, установите память на 16Gi и CPU на 4). Примените изменения и наблюдайте за Gitaly.

При масштабировании Git-хранилища важно учитывать следующий приоритет параметров:

1. Явно заданные ресурсы в spec.gitData.resources
2. Значение spec.scaling.targetUserCount (используется для автоматического расчёта ресурсов по таблице)

Пример 1:

`spec.gitData.resources.cpu`: 1  
`spec.gitData.resources.memory`: 1Gi  
`spec.scaling.targetUserCount`: 3000

Согласно таблице рекомендуемых ресурсов (описанной выше), ожидаемый результат при targetUserCount = 3000:

• memory: 4Gi
• cpu: 2

Однако из-за приоритета явно заданных значений фактический результат будет:

• memory: 1Gi
• cpu: 1

💡 Примечание: если явно указан параметр в spec.gitData.resources, он всегда имеет приоритет над автоматическим расчётом.

Пример 2:

`spec.gitData.resources.cpu`: 5  
`spec.gitData.resources.memory`: ***намеренно не указан***  
`spec.scaling.targetUserCount`: 3000

Согласно таблице, ожидаемый результат при targetUserCount = 3000:

• memory: 4Gi
• cpu: 2

Но поскольку:

• spec.gitData.resources.cpu задан явно → используется значение 5,
• spec.gitData.resources.memory не указан → используется значение из таблицы (4Gi),

фактический результат будет:

• memory: 4Gi (из таблицы)
• cpu: 5 (из spec.gitData.resources.cpu)

💡 Важно: если какой-либо ресурс (CPU или память) не указан в spec.gitData.resources, для него применяется значение из таблицы масштабирования.