Запуск модуля в кластере

В этом разделе рассмотрен процесс запуска настроенного модуля в кластере Deckhouse Kubernetes Platform (DKP).

Чтобы запустить модуль в кластере, необходимо выполнить следующие шаги:

• Определить источник модулей (ресурс ModuleSource).
• (не обязательно) Определить политику обновления модуля (ресурс ModuleUpdatePolicy).
• Включить модуль в кластере (ресурс ModuleConfig).

Источник модулей

Чтобы указать в кластере источник, откуда нужно загружать информацию о модулях, необходимо создать ресурс ModuleSource. В этом ресурсе указывается адрес container registry, откуда DKP будет загружать модули, параметры аутентификации и другие настройки.

Пример ресурса ModuleSource:

apiVersion: deckhouse.io/v1alpha1
kind: ModuleSource
metadata:
  name: example
spec:
  registry:
    repo: registry.example.com/deckhouse/modules
    dockerCfg: <base64 encoded credentials>

После создания ресурса ModuleSource DKP начнет выполнять периодическую (раз в три минуты) синхронизацию данных с источником модулей (загружать информацию о модулях, доступны в источнике).

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

kubectl get ms

Пример вывода в случае успешной синхронизации:

$ kubectl get ms
NAME        COUNT   SYNC   MSG
example     2       16s

В случае ошибок синхронизации в столбце MSG будет указано общее описание ошибки. Пример:

$ kubectl get ms
NAME        COUNT   SYNC   MSG
example     2       16s    Some errors occurred. Inspect status for details

Подробную информацию об ошибках можно получить в поле status.moduleErrors ресурса ModuleSource.

Пример получения подробной информации об ошибках из источника модулей example:

$ kubectl  get ms example -o jsonpath='{range .status.moduleErrors[*]}{.name}{" module error:\n\t"}{.error}{"\n"}{end}'
module-1 module error:
  fetch image error: GET https://registry.example.com/v2/deckhouse/modules/module-1/release/manifests/stable: MANIFEST_UNKNOWN: manifest unknown; map[Tag:stable]
module-2 module error:
  fetch image error: GET https://registry.example.com/v2/deckhouse/modules/module-2/release/manifests/stable: MANIFEST_UNKNOWN: manifest unknown; map[Tag:stable]

В случае успешной синхронизации поле .status.modules ресурса ModuleSource будет содержать список модулей, доступных для включения в кластере.

Пример получения списка модулей, доступных из источника модулей example:

$ kubectl get ms example -o jsonpath='{.status.modules[*].name}'
module-1 module-2

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

kubectl get ms  -o jsonpath='{.items[*].status.modules[*].name}'

После создания ресурса ModuleSource и успешной синхронизации, в кластере должны начать появляться релизы модулей — ресурсы ModuleRelease (DKP создает их автоматически, создавать их не нужно). Посмотреть список релизов можно с помощью следующей команды:

kubectl get mr

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

$ kubectl get mr
NAME                       PHASE        UPDATE POLICY   TRANSITIONTIME   MESSAGE
module-one-v1.21.3         Superseded   deckhouse       33h              
module-one-v1.22.0         Deployed     deckhouse       33h              
module-two-v1.2.0          Superseded   deckhouse       48d              
module-two-v1.2.1          Superseded   deckhouse       48d              
module-two-v1.2.3          Deployed     deckhouse       48d              
module-two-v1.2.4          Superseded   deckhouse       44d              
module-two-v1.2.5          Pending      deckhouse       44d              Waiting for manual approval

Если есть релиз модуля в статусе Deployed, то такой модуль можно включить в кластере. Если релиз модуля находится в статусе Superseded, это значит что релиз модуля устарел, и есть более новый релиз, который его заменил.

kubectl annotate mr <module_release_name> modules.deckhouse.io/approved="true"

Переключение модуля на другой источник модулей

Если необходимо развернуть модуль из другого источника модулей, выполните следующие шаги:

1. Определите, под какую политику обновлений подпадает модуль:

   kubectl get mr
   

   Проверьте UPDATE POLICY для релизов модуля.

2. Прежде чем удалить эту политику обновления, убедитесь, что нет ожидающих развертывания (в состоянии Pending) релизов, которые подпадают под удаляемую или изменяемую политику (или labelSelector, используемый политикой, больше не соответствует вашему модулю):

   kubectl delete mup <POLICY_NAME>
   

3. Создайте новый ресурс ModuleSource.

4. Создайте новый ресурс ModuleUpdatePolicy с указанием правильных меток (source) для нового ModuleSource.

5. Проверьте, что новые ModuleRelease для модуля создаются из нового ModuleSource в соответствии с политикой обновления.

   kubectl get mr
   

Политика обновления модуля

Политика обновления модуля — это правила, по которым DKP обновляет модули в кластере. Она определяется ресурсом ModuleUpdatePolicy, в котором можно настроить:

• режим обновления модуля (автоматический, ручной, обновления отключены);
• канал стабильности, используемый при обновлении;
• окна автоматического обновления, в пределах которых разрешено обновление модуля.

Создавать ресурс ModuleUpdatePolicy не обязательно. Если политика обновления для модуля не определена (отсутствует соответствующий ресурс ModuleUpdatePolicy), то настройки обновления соответствуют настройкам обновления самого DKP (параметр update модуля deckhouse).

Пример ресурса ModuleUpdatePolicy, который определяет политику обновления модуля module-1 источника модулей example (ModuleSource example). Политика обновления разрешает автоматическое обновление модуля по понедельникам и средам с 13:30 до 14:00 UTC:

apiVersion: deckhouse.io/v1alpha1
kind: ModuleUpdatePolicy
metadata:
  name: example-update-policy
spec:
  moduleReleaseSelector:
    labelSelector:
      matchLabels:
        source: example
        module: module-1
  releaseChannel: Alpha
  update:
    mode: Auto
    windows:
    - days:
      - "Mon"
      - "Wed"
      from: "13:30"
      to: "14:00"

Примеры moduleReleaseSelector

• Применить политику ко всем модулям ModuleSource deckhouse:

  moduleReleaseSelector:
    labelSelector:
      matchLabels:
        source: deckhouse
  

• Применить политику к модулю deckhouse-admin независимо от ModuleSource:

  moduleReleaseSelector:
    labelSelector:
      matchLabels:
        module: deckhouse-admin
  

• Применить политику к модулю deckhouse-admin из ModuleSource deckhouse:

  moduleReleaseSelector:
    labelSelector:
      matchLabels:
        module: deckhouse-admin
        source: deckhouse
  

• Применить политику только к модулям deckhouse-admin и secrets-store-integration в ModuleSource deckhouse:

  moduleReleaseSelector:
    labelSelector:
      matchExpressions:
      - key: module
        operator: In
        values:
        - deckhouse-admin
        - secrets-store-integration
      matchLabels:
        source: deckhouse
  

• Применить политику ко всем модулям ModuleSource deckhouse, кроме deckhouse-admin:

  moduleReleaseSelector:
    labelSelector:
      matchExpressions:
      - key: module
        operator: NotIn
        values:
        - deckhouse-admin
      matchLabels:
        source: deckhouse
  

Включение модуля в кластере

Прежде чем включить модуль, проверьте что он доступен для включения. Выполните следующую команду, чтобы вывести список всех доступных модулей DKP:

kubectl get modules

Модуль должен быть в списке.

Пример вывода:

$ kubectl get modules
NAME                                  WEIGHT   STATE      SOURCE
...
module-test                           900      Disabled   example
...

Вывод показывает, что модуль module-test доступен для включения.

Если модуля нет в списке, то проверьте что определен источник модулей и модуль есть в списке в источнике модулей. Также проверьте политику обновления модуля (если она определена). Если политика обновления модуля не определена, то она соответствует политике обновления DKP (параметр releaseChannel и секция update параметров модуля deckhouse).

Включить модуль можно аналогично встроенному модулю DKP любым из следующих способов:

• Выполнить следующую команду (укажите имя модуля):

  kubectl -ti -n d8-system exec svc/deckhouse-leader -c deckhouse -- deckhouse-controller module enable <MODULE_NAME>
  

• Создать ресурс ModuleConfig с параметром enabled: true и настройками модуля.

  Пример ModuleConfig, для включения и настройки модуля module-1 в кластере:

  apiVersion: deckhouse.io/v1alpha1
  kind: ModuleConfig
  metadata:
    name: module-1
  spec:
    enabled: true
    settings:
      parameter: value
    version: 1
  

Если что-то пошло не так

Если при включении модуля в кластере возникли ошибки, то получить информацию о них можно следующими способами:

• Посмотреть журнал DKP:

  kubectl -n d8-system logs -l app=deckhouse
  

• Посмотреть ресурс ModuleConfig модуля:

  Пример вывода информации об ошибке модуля module-1:

  $ kubectl get moduleconfig module-1
  NAME        ENABLED   VERSION   AGE   MESSAGE
  module-1    true                7s    Ignored: unknown module name
  

По аналогии с DeckhouseRelease (ресурсом релиза DKP) у модулей есть аналогичный ресурс — ModuleRelease. DKP создает ресурсы ModuleRelease исходя из того, что хранится в container registry. При поиске проблем с модулем проверьте также доступные в кластере релизы модуля:

kubectl get mr

Пример вывода:

$ kubectl get mr
NAME                 PHASE        UPDATE POLICY          TRANSITIONTIME   MESSAGE
module-1-v1.23.2     Pending      example-update-policy  3m               Waiting for manual approval

В примере вывода показан ModuleRelease, когда режим обновления (параметр update.mode ресурса ModuleUpdatePolicy установлен в Manual. В этом случае необходимо вручную подтвердить установку новой версии модуля, установив на релиз аннотацию modules.deckhouse.io/approved="true":

kubectl annotate mr module-1-v1.23.2 modules.deckhouse.io/approved="true"