Описание функций

В rubik каждая функция запускается в виде сервиса в фоновом режиме. Rubik запускает соответствующие сервисы по требованию на основе конфигурации пользователя (config.json). Ниже приведены описания различных сервисов.

Абсолютное вытеснение (Absolute Preemption)

Rubik поддерживает настройку приоритетов бизнес-приложений, что позволяет гарантировать вытеснение ресурсов для онлайн-приложений относительно оффлайн-приложений в случае совместной установки. В настоящее время поддерживается только вытеснение ресурсов CPU и памяти. Для использования этой функции пользователи должны вручную указывать тип бизнес-приложения, добавляя аннотацию volcano.sh/preemptable в файл YAML бизнес-приложения (pod). Пример конфигурации приоритетов бизнес-приложений приведен ниже:

annotations:
    volcano.sh/preemptable: true

В rubik все функции идентифицируются по этой аннотации как признаки онлайн/оффлайн бизнес-приложений. true означает, что бизнес-приложение является оффлайн-приложением. false означает, что бизнес-приложение является онлайн-приложением.

Абсолютное вытеснение CPU

Для обеспечения вытеснения ресурсов CPU для онлайн-приложений относительно оффлайн-приложений в случае совместной установки.

Предварительные условия

• Поддержка ядром конфигурации приоритетов CPU для cgroup, наличие интерфейса cpu.qos_level в подсистеме CPU. Рекомендуется использовать версию ядра openEuler-22.03+.### Абсолютное вытеснение памяти Для обеспечения вытеснения оффлайн-приложений при исчерпании памяти (OOM).

Предварительные условия

• Поддержка ядром конфигурации приоритетов памяти для cgroup, наличие интерфейса memory.qos_level в подсистеме памяти. Рекомендуется использовать версию ядра openEuler-22.03+.
• Включение поддержки приоритетов памяти: echo 1 > /proc/sys/vm/memcg_qos_enable

dynCache (Динамическое кэширование)

Rubik поддерживает ограничение на использование памяти и последнего уровня кэша (LLC) для бизнес-приложений (pod). Это позволяет ограничивать использование памяти и LLC для оффлайн-приложений, тем самым снижая их влияние на онлайн-приложения.Эта функция зависит от поддержки физического оборудования функций Intel RDT (x86) и mapm (arm). Она разделяет бизнес-приложения в кластере на 5 контрольных групп (соответственно rubik_max, rubik_high, rubik_middle, rubik_low, rubik_dynamic). Каждая контрольная группа ограничивает использование бизнес-приложениями памяти и LLC в соответствии с конфигурацией. После запуска rubik, он записывает уровень воды в соответствующие схемы контрольных групп. Уровни воды для контрольных групп rubik_high, rubik_middle, rubik_low являются глобальными и могут быть настроены в dynCache. Контрольная группа rubik_max имеет по умолчанию максимальное значение, а начальный уровень воды для контрольной группы rubik_dynamic совпадает с уровнем воды для контрольной группы rubik_low. Rubik поддерживает два способа конфигурации ограничений на память и контрольных групп LLC для бизнес-__Pods:

• Глобальный способ Пользователи могут настроить поле defaultLimitMode в глобальных параметрах rubik, и rubik автоматически настроит контрольные группы для бизнес-__Pods (то есть_Pods с абсолютной функцией предemption, помеченных аннотацией volcano. sh/preemptable).
  • При значении static pod будет добавлен в контрольную группу rubik_max.
  • При значении dynamic pod будет добавлен в контрольную группу rubik_dynamic.
• Ручное задание Пользователи могут вручную задать контрольную группу для бизнес-__Pods, добавив аннотацию volcano.sh/cache-limit (мы не рекомендуем это делать), как в следующем примере конфигурации, где pod будет добавлен в контрольную группу rubik_low:

annotations:
    volcano.sh/cache-limit: "low"

Контрольная группа rubik_dynamic: Когда контрольная группа для_Pods установлена как rubik_dynamic, rubik динамически корректирует уровень воды для контрольной группы rubik_dynamic на основе метрик cache miss и llc miss текущих_Pods на узле, что позволяет динамически управлять_Pods в контрольной группе rubik_dynamic.

Ограничения на кэш и память

• Функция ограничения кэша и памяти поддерживается только на физических машинах, а не на виртуальных машинах.
  • Для физических машин на архитектуре X86 требуется поддержка операционной системы и включение функций CAT и MBA интел RDT. В командной строке загрузки ядра необходимо добавить rdt=l3cat,mba.
  • Для физических машин на архитектуре ARM требуется поддержка операционной системы и включение функции mpam. В командной строке загрузки ядра необходимо добавить mpam=acpi.
• Из-за ограничений ядра, режим RDT на данный момент не поддерживает псевдо-блокировку.
• Для работы rubik необходимо смонтировать каталог хоста /sys/fs/resctrl, и этот каталог не должен быть отмонтирован во время выполнения.
• Rubik требует разрешения SYS_ADMIN для правильного установления файлов в каталоге /sys/fs/resctrl.- Rubik и хост используют общий пространственный идентификатор процессов (pid namespace), чтобы получить PID процессов контейнеров бизнеса на хосте.
• Без явного указания, dynCache применяется только к оффлайн бизнесу и не действует для онлайн бизнеса.
• Если бизнес-контейнер был перезапущен вручную во время выполнения (идентификатор контейнера не изменился, но PID процесса контейнера изменился), dynCache не будет применяться к этому контейнеру.
• После запуска бизнес-контейнера и установки уровня dynCache, изменение уровня ограничения для этого контейнера не поддерживается.
• Степень чувствительности управления динамическими ограничениями зависит от значений adjustInterval и perfDuration в конфигурационном файле Rubik и от количества активных бизнес-контейнеров на узле. Интервал между каждым изменением (если результаты мониторинга указывают на необходимость изменения) находится в диапазоне [adjustInterval + perfDuration, adjustInterval + perfDuration * количество контейнеров]. Пользователи могут настроить эти параметры в соответствии со своими требованиями к чувствительности.## Ограничения на ввод-вывод (ioLimit) Ограничение использования ресурсов ввода-вывода (I/O) для pod с помощью функции blkio, предоставляемой cgroup. Пользователи должны вручную настроить аннотацию volcano. sh/blkio-limit для бизнес-пода. Формат аннотации следующий:

volcano. sh/blkio-limit: '{"device_read_bps":[{"device":"/dev/sda1","value":"10485760"}, {"device":"/dev/sda","value":"20971520"}],
                 "device_write_bps":[{"device":"/dev/sda1","value":"20971520"}],
                 "device_read_iops":[{"device":"/dev/sda1","value":"200"}],
                 "device_write_iops":[{"device":"/dev/sda1","value":"300"}]}'

Конфигурационные параметры:

1. Правила конфигурации ключа:value для настроек конфигурации и ключа:value для cgroup совпадают:
2. При записи значения будет преобразовано в кратное размеру страницы среды:
3. Настройки будут применяться только для устройств с младшим номером равным 0:
4. Для отмены ограничения скорости можно установить значение равным 0 |## Поддержка эластичного ограничения скорости Для решения проблемы снижения качества обслуживания (QoS) из-за ограничения скорости CPU для бизнес-приложений, контейнеры Rubik предоставляют функцию эластичного ограничения скорости, которая позволяет контейнерам использовать дополнительные ресурсы CPU, обеспечивая стабильную работу бизнес-приложений. Эластичное ограничение скорости включает в себя конфигурацию на уровне ядра и на уровне пользователя. Обе конфигурации не могут использоваться одновременно.

Конфигурация на уровне пользователя реализуется с помощью возможности CFS bandwidth control, предоставляемой ядром Linux. Она обеспечивает безопасное и стабильное состояние загрузки системы и не влияет на работу других бизнес-приложений, позволяя бизнес-контейнерам адаптивно корректировать ограничения CPU с помощью механизма двух уровней загрузки, что помогает снизить напряжённость ресурсов CPU и повысить производительность бизнес-приложений.Конфигурация на уровне ядра реализуется с помощью возможности CPU burst, предоставляемой ядром Linux. Она позволяет контейнерам временно превышать ограничения использования CPU. Конфигурация на уровне ядра требует ручного изменения пользователем значения burst для каждого pod, и Rubik не выполняет автоматическую корректировку.

Пользовательский режим решения quotaTurbo

Пользователь вручную указывает аннотацию "volcano.sh/quota-turbo=true" для бизнес-_Pods, которым требуется адаптивное изменение лимита CPU (только для_Pods с указанным лимитом CPU, то есть параметр CPULimit в yaml-файле).

Пользовательский режим стратегии управления квотами CPU регулярно корректирует квоты CPU белого списка контейнеров в зависимости от текущей загрузки CPU всего сервера и состояния выполнения контейнеров. При запуске и остановке Rubik происходит автоматическая проверка и восстановление квот всех контейнеров. (В данном разделе квота CPU контейнера определяется параметром cpu.cfs_quota_us).Стратегии корректировки включают:

1. При загрузке CPU всего сервера ниже предельного уровня, если белый список контейнеров подвергается сжатию CPU в текущем цикле, rubik постепенно увеличивает квоту CPU контейнера в зависимости от степени сжатия. Максимальное увеличение квоты контейнера за один цикл не должно превышать 1% от общей квоты CPU узла.
2. При загрузке CPU всего сервера выше верхнего уровня, если белый список контейнеров не подвергается сжатию CPU в текущем цикле, rubik медленно возвращает квоты CPU контейнеров к исходным значениям.
3. При загрузке CPU всего сервера выше предельного уровня, если текущая квота CPU контейнера превышает заданное значение, rubik быстро возвращает квоты CPU всех контейнеров к исходным значениям, чтобы гарантировать, что загрузка ниже предельного уровня.
4. Максимальная квота CPU контейнера не должна превышать 2 раза заданного пользователем значения (например, параметра CPULimit в yaml-файле_Pods), но не должна быть меньше заданного пользователем значения.
5. Общая загрузка CPU контейнера в течение 60 синхронных интервалов времени не должна превышать заданное пользователем значение.### quotaBurst ядро режим решения Пользователь вручную указывает аннотацию "volcano. sh/quota-burst-time" для_Pods, которым требуется управление квотами CPU. Rubik записывает значение аннотации в интерфейс burst ядра для всех контейнеров_Pods. После записи rubik не корректирует квоты в зависимости от использования CPU и других параметров. Пример:

metadata:    
  annotations:    
    volcano. sh/quota-burst-time : "2000"

Ядро режим решения реализуется через интерфейс ядра cpu. cfs_burst_us. Поддержка конфигурации ядра режима требует наличия файла cpu. cfs_burst_us в подкаталоге cpu подсистемы cgroup. Значения ограничиваются следующими условиями:

1. Если значение cpu. cfs_quota_us не равно -1, должно выполняться условие cfs_burst_us + cfs_quota_us <= 2^44-1 и cfs_burst_us <= cfs_quota_us.
2. Если значение cpu. cfs_quota_us равно -1, функция CPU burst не активна, значение cfs_burst_us по умолчанию равно 0, и другие значения не поддерживаются.

Ограничения

• Управление CPU-шириной в пользовательском режиме осуществляется с помощью CFS (Completely Fair Scheduler) bandwidth control, путем настройки параметров cpu. cfs_period_us и cpu. cfs_quota_us. Поэтому пользовательские ограничения следующие:
  • Запрещено третьим сторонам изменять параметры, связанные с CFS bandwidth control (включая, но не ограничиваясь, файлами cpu. cfs_quota_us и cpu. cfs_period_us), чтобы избежать неизвестных ошибок. - Запрещено использовать продукты, аналогичные по функциональности (включая, но не ограничиваясь, Kubernetes VPA и HPA, Tencent EVPA, Alibaba CPU Burst, функции cpu-share и bind-core, предоставляемые cgroup), поскольку это может привести к невозможности использования пользовательских функций.
  • Если пользователь мониторит параметры CFS bandwidth control, использование данной функции может нарушить целостность мониторинга.
• Ограничения в ядре:
  • Пользователи должны использовать интерфейсы k8s для установки значения burst для pod, запрещено ручное изменение файла cpu.cfs_burst_us в директории cgroup контейнера.
• Запрещено одновременное использование пользовательского и ядерного режимов для управления шириной шины.## Поддержка ioCost для управления весом ввода-вывода

Описание проблемы

Для решения проблемы снижения качества обслуживания (QoS) онлайн-услуг из-за высокой загрузки ввода-вывода (IO) от фоновых задач, контейнеры Rubik предоставляют функцию управления весом ввода-вывода на основе cgroup v1 iocost. Параметры и конфигурация iocost совпадают с cgroup v2, подробности см. в описании функций iocost в ядре

Требования к ядру

• Ядро должно поддерживать cgroup v1 blkcg iocost
• Ядро должно поддерживать cgroup v1 writeback, и в параметрах загрузки ядра необходимо добавить cgroup1_writeback### Инструкции по конфигурации В конфигурационном файле Rubik добавьте следующие параметры:

"nodeConfig": [
        {
            "nodeName": "slaver01", // имя узла k8s
            "iocostEnable": true, // включено ли
            "iocostConfig": [
                {
                    "dev": "sda",  // для какого устройства
                    "enable": false, // включено ли для этого устройства
                    "model": "linear", // выбранная модель iocost
                    "param": {
                        "rbps": 174610612, // максимальная скорость чтения (bps) при линейной модели
                        "rseqiops": 41788, // максимальное количество последовательных операций чтения (iops)
                        "rrandiops": 371, // максимальное количество случайных операций чтения (iops)
                        "wbps": 178587889, // максимальная скорость записи (bps)
                        "wseqiops": 42792, // максимальное количество последовательных операций записи (iops)
                        "wrandiops": 379 // максимальное количество случайных операций записи (iops)
                    }
                }
            ]
        }
    ]
```### Ограничения
- Контейнер rubik монтирует директорию /dev хост-системы и использует её для чтения параметров жесткого диска.
- Функциональность iocost ядра может быть настроена только для физических блочных устройств, логические тома настроить нельзя.### Другое
Параметры модели iocost linear можно вычислить с помощью скрипта [iocost_coef_gen.py](https://github.com/torvalds/linux/blob/master/tools/cgroup/iocost_coef_gen.py).