Механизм очередей

Модуль deckhouse реализует ядро Deckhouse Kubernetes Platform (DKP), выполняющее различные операции по управлению платформой с использованием механизма очередей. Подробнее с архитектурой модуля можно ознакомиться в соответствующем разделе документации.

Контроллер Deckhouse реализует очереди addon-operator и marketplace.

Очереди addon-operator

Очереди addon-operator — это основной механизм обработки встроенных и внешних модулей DKP. Очередь реализована в shell-operator и расширена типами задач addon-operator. Контроллер Deckhouse синхронизирует кастомные ресурсы ModuleConfig и обновляет глобальные или модульные values для addon-operator.

Типы задач:

Типы очередей addon-operator:

Каждая очередь — отдельный пайплайн с одним worker-узлом, который реализует очередь со следующими свойствами:

• задачи могут вставляться как в конец (AddLast), так и в начало (AddFirst) очереди;
• выполнение задач происходит с начала очереди;
• поддерживается работа с многофазными операциями, которые используют операции:
  • AddHeadTasks — вставить подзадачи перед текущей;
  • AddTailTasks — вставить подзадачу в конец очереди после того, как текущая завершится успешно;
  • AddAfterTasks — вставить подзадачу сразу после текущей;
• задача выполняется до успеха, если не указано allowFailure: true в параметре задачи;
• в случае ошибки выполняется экспоненциальный перезапуск (backoff), начиная с задержки в 5 секунд между попытками.

При старте контроллер Deckhouse создает очереди main и parallel_queue_0..19 и добавляет в main задачи в следующем порядке:

• GlobalHookRun (onStartup) — для каждого global hook;
• GlobalHookEnableScheduleBindings — для включения планировщика cron;
• GlobalHookEnableKubernetesBindings — для включения глобальных задач, отслеживающих ресурсы Kubernetes;
• GlobalHookWaitKubernetesSynchronization;
• ConvergeModules (OperatorStartup) — первый converge всех модулей.

После ConvergeModules контроллер добавляет задачу DiscoverHelmReleases — очистка неизвестных helm releases.

Порядок обработки модулей в задаче ConvergeModules определяется несколькими атрибутами:

• критичность модуля — заданный параметр critical в конфигурации модуля module.yaml;
• вес модуля — числовое обозначение порядка обработки модуля, чем число выше, тем позже будет обрабатываться модуль. Вес модуля берётся из параметра weight конфигурации модуля module.yaml, если этого параметра нет или он равен 0, то используется вес по-умолчанию, равный 900. Если файла конфигурации модуля не существует, то используется вес из числового префикса директории с модулем (например: 040-node-manager — вес 40). Если вес не удалось получить из имени директории, используется вес, равный 100;
• зависимости модуля — список модулей, которые должны быть установлены до текущего модуля.

На основе этих атрибутов планировщик контроллера Deckhouse выстраивает порядок обработки по следующим принципам:

• для критичных модулей учитывается вес модуля в порядке возрастания — задачи помещаются в очередь main;
• для некритичных модулей вес модуля не учитывается — задачи помещаются в очереди parallel_queue_0..19;
• для всех модулей учитываются зависимости от других модулей.

При этом, если критичные модули могут быть обработаны параллельно, то планировщик контроллера Deckhouse помещает в очередь main задачу ParallelModuleRun с указанием списка модулей. Задача ParallelModuleRun запускает для каждого модуля задачу ModuleRun в очередях parallel_queue_0..19 и ждёт завершения их работы, тем самым блокируя очередь main. Если при обработке задачи ModuleRun происходит ошибка, то такую задачу планировщик перемещает в конец очереди и запускает следующую задачу из очереди.

Процесс установки критичных модулей изображен на следующей диаграмме:

Процесс установки некритичных (функциональных) модулей изображен на следующей диаграмме:

Если в очередь добавлено более одной идентичной задачи, то при старте выполнения такой задачи все остальные задачи удаляются из очереди для дедупликации.

Для просмотра очередей addon-operator можно использовать команду d8 system queue list.

Очереди Marketplace

Очереди Marketplace — реализация очереди для работы функционала Marketplace.

Каждая очередь, которую обслуживает контроллер Deckhouse для Marketplace, обладает следующими свойствами:

• FIFO (First In First Out) — определяет неизменяемый порядок выполнения задач. Задача, поступившая в очередь первой, будет исполнена в первую очередь;
• строго последовательное выполнение задач, одна задача за раз;
• запуск задач происходит только при получении событий (event-driven), исключён опрос каких-либо ресурсов;
• повторный запуск при ошибке с экспоненциальным ростом промежутка между попытками, начиная с 15 секунд, но не более 1 минуты, без лимита на количество попыток;
• поддерживается каскадная отмена задач при смене версии или удалении пакета.

Типы очередей:

Типы задач:

Выполнение задач в одной очереди не блокирует выполнение задач в другой очереди.

Для просмотра очередей Marketplace используйте следующую команду:

Дополнительные ресурсы

• Глобальные кастомные ресурсы
• Документация модуля deckhouse