Deckhouse состоит из оператора Deckhouse и модулей. Модуль — это набор из Helm-чарта, хуков Addon-operator’а, правил сборки компонентов модуля (компонентов Deckhouse) и других файлов.

Deckhouse настраивается с помощью:

  • Глобальных настроек. Глобальные настройки хранятся в custom resource ModuleConfig/global. Глобальные настройки можно рассматривать как специальный модуль global, который нельзя отключить.
  • Настроек модулей. Настройки каждого модуля хранятся в custom resource ModuleConfig, имя которого совпадает с именем модуля (в kebab-case).
  • Custom resource’ов. Некоторые модули настраиваются с помощью дополнительных custom resource’ов.

Пример набора custom resource’ов конфигурации Deckhouse:

# Глобальные настройки.
apiVersion: deckhouse.io/v1alpha1
kind: ModuleConfig
metadata:
  name: global
spec:
  version: 1
  settings:
    modules:
      publicDomainTemplate: "%s.kube.company.my"
---
# Настройки модуля monitoring-ping.
apiVersion: deckhouse.io/v1alpha1
kind: ModuleConfig
metadata:
  name: monitoring-ping
spec:
  version: 1
  settings:
    externalTargets:
    - host: 8.8.8.8
---
# Отключить модуль dashboard.
apiVersion: deckhouse.io/v1alpha1
kind: ModuleConfig
metadata:
  name: dashboard
spec:
  enabled: false

Посмотреть список custom resource’ов ModuleConfig, состояние модуля (включен/выключен) и его статус можно с помощью команды kubectl get moduleconfigs:

$ kubectl get moduleconfigs
NAME                STATE      VERSION    STATUS    AGE
deckhouse           Enabled    1                    12h
deckhouse-web       Enabled    2                    12h
global              Enabled    1                    12h
prometheus          Enabled    2                    12h
upmeter             Disabled   2                    12h

Чтобы изменить глобальную конфигурацию Deckhouse или конфигурацию модуля, нужно создать или отредактировать соответствующий ресурс ModuleConfig.

Например, чтобы отредактировать конфигурацию модуля upmeter, выполните следующую команду:

kubectl -n d8-system edit moduleconfig/upmeter

После завершения редактирования изменения применяются автоматически.

Настройка модуля

При работе с модулями Deckhouse использует проект addon-operator. Ознакомьтесь с его документацией, если хотите понять как Deckhouse работает с модулями, хуками модулей и параметрами модулей. Будем признательны, если поставите проекту звезду.

Модуль настраивается с помощью custom resource ModuleConfig, имя которого совпадает с именем модуля (в kebab-case). Custom resource ModuleConfig имеет следующие поля:

  • metadata.name — название модуля Deckhouse в kebab-case (например prometheus, node-manager).
  • spec.version — версия схемы настроек модуля (целое число, больше нуля). Обязательное поле, если spec.settings не пустое. Номер актуальной версии можно увидеть в документации модуля в разделе “Настройки”.
    • Deckhouse поддерживает обратную совместимость версий схемы настроек модуля. Если используется схема настроек устаревшей версии, при редактировании или просмотре custom resource’а будет выведено предупреждение о необходимости обновить схему настроек модуля.
  • spec.settings — настройки модуля. Необязательное поле, если используется поле spec.enabled. Описание возможных настроек можно найти в документации модуля в разделе “Настройки”.
  • spec.enabled — необязательное поле для явного включения или отключения модуля. Если не задано, модуль может быть включён по умолчанию в одном из наборов модулей.

Deckhouse не изменяет custom resource’ы ModuleConfig. Это позволяет применять подход Infrastructure as Code (IaC) при хранении конфигурации. Другими словами, можно воспользоваться всеми преимуществами системы контроля версий для хранения настроек Deckhouse, использовать Helm, kubectl и другие привычные инструменты.

Пример custom resource для настройки модуля kube-dns:

apiVersion: deckhouse.io/v1alpha1
kind: ModuleConfig
metadata:
  name: kube-dns
spec:
  version: 1
  settings:
    stubZones:
    - upstreamNameservers:
      - 192.168.121.55
      - 10.2.7.80
      zone: directory.company.my
    upstreamNameservers:
    - 10.2.100.55
    - 10.2.200.55

Некоторые модули настраиваются с помощью дополнительных custom resource’ов. Воспользуйтесь поиском (наверху страницы) или выберите модуль в меню слева, чтобы просмотреть документацию по его настройкам и используемым custom resource’ам.

Включение и отключение модуля

Некоторые модули могут быть включены по умолчанию в зависимости от используемого набора модулей.

Для явного включения или отключения модуля необходимо установить true или false в поле .spec.enabled в соответствующем custom resource ModuleConfig. Если для модуля нет такого custom resource ModuleConfig, его нужно создать.

Пример явного выключения модуля user-authn (модуль будет выключен независимо от используемого набора модулей):

apiVersion: deckhouse.io/v1alpha1
kind: ModuleConfig
metadata:
  name: user-authn
spec:
  enabled: false

Проверить состояние модуля можно с помощью команды kubectl get moduleconfig <ИМЯ_МОДУЛЯ>.

Пример:

$ kubectl get moduleconfig user-authn
NAME                STATE      VERSION    STATUS    AGE
user-authn          Disabled   1                    12h

Наборы модулей

В зависимости от используемого набора модулей (bundle) модули могут быть включены или выключены по умолчанию.

Набор модулей (bundle)Список включенных по умолчанию модулей
Default
  • admission-policy-engine
  • cert-manager
  • chrony
  • containerized-data-importer
  • control-plane-manager
  • dashboard
  • external-module-manager
  • deckhouse
  • deckhouse-web
  • descheduler
  • extended-monitoring
  • flow-schema
  • ingress-nginx
  • kube-dns
  • kube-proxy
  • local-path-provisioner
  • log-shipper
  • monitoring-custom
  • monitoring-deckhouse
  • monitoring-kubernetes-control-plane
  • monitoring-kubernetes
  • monitoring-ping
  • namespace-configurator
  • node-manager
  • pod-reloader
  • priority-class
  • prometheus
  • prometheus-metrics-adapter
  • secret-copier
  • smoke-mini
  • snapshot-controller
  • terraform-manager
  • upmeter
  • user-authn
  • user-authz
  • vertical-pod-autoscaler
  • flant-integration
  • node-local-dns
Managed
  • admission-policy-engine
  • cert-manager
  • containerized-data-importer
  • dashboard
  • external-module-manager
  • deckhouse
  • deckhouse-web
  • descheduler
  • extended-monitoring
  • flow-schema
  • ingress-nginx
  • local-path-provisioner
  • log-shipper
  • monitoring-custom
  • monitoring-deckhouse
  • monitoring-kubernetes
  • monitoring-ping
  • namespace-configurator
  • pod-reloader
  • prometheus
  • prometheus-metrics-adapter
  • secret-copier
  • snapshot-controller
  • upmeter
  • user-authz
  • vertical-pod-autoscaler
  • flant-integration
Minimal
  • deckhouse

Обратите внимание, что в наборе модулей Minimal не включен ряд базовых модулей (например, модуль работы с CNI). Deckhouse с набором модулей Minimal без включения базовых модулей сможет работать только в уже развернутом кластере.

Управление размещением компонентов Deckhouse

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

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

  1. Если параметр nodeSelector модуля не указан, то Deckhouse попытается вычислить nodeSelector автоматически. В этом случае, если в кластере присутствуют узлы с лейблами из списка или лейблами определенного формата, Deckhouse укажет их в качестве nodeSelector ресурсам модуля.
  2. Если параметр tolerations модуля не указан, то Pod’ам модуля автоматически устанавливаются все возможные toleration’ы (подробнее).
  3. Отключить автоматическое вычисление параметров nodeSelector или tolerations можно, указав значение false.

Возможность настройки nodeSelector и tolerations отключена для модулей:

  • которые работают на всех узлах кластера (например, cni-flannel, monitoring-ping);
  • которые работают на всех master-узлах (например, prometheus-metrics-adapter, vertical-pod-autoscaler).

Особенности автоматики, зависящие от типа модуля

  • Модули monitoring (operator-prometheus, prometheus и vertical-pod-autoscaler):
    • Порядок поиска узлов (для определения nodeSelector):
      • Наличие узла с лейблом node-role.deckhouse.io/MODULE_NAME.
      • Наличие узла с лейблом node-role.deckhouse.io/monitoring.
      • Наличие узла с лейблом node-role.deckhouse.io/system.
    • Добавляемые toleration’ы (добавляются одновременно все):

      • {"key":"dedicated.deckhouse.io","operator":"Equal","value":"MODULE_NAME"};

        Например: {"key":"dedicated.deckhouse.io","operator":"Equal","value":"operator-prometheus"};

      • {"key":"dedicated.deckhouse.io","operator":"Equal","value":"monitoring"};
      • {"key":"dedicated.deckhouse.io","operator":"Equal","value":"system"};
  • Модули frontend (исключительно модуль ingress-nginx):
    • Порядок поиска узлов (для определения nodeSelector):
      • Наличие узла с лейблом node-role.deckhouse.io/MODULE_NAME.
      • Наличие узла с лейблом node-role.deckhouse.io/frontend.
    • Добавляемые toleration’ы (добавляются одновременно все):
      • {"key":"dedicated.deckhouse.io","operator":"Equal","value":"MODULE_NAME"};
      • {"key":"dedicated.deckhouse.io","operator":"Equal","value":"frontend"};
  • Все остальные модули:
    • Порядок поиска узлов (для определения nodeSelector):

      • Наличие узла с лейблом node-role.deckhouse.io/MODULE_NAME.

        Например: node-role.deckhouse.io/cert-manager.

      • Наличие узла с лейблом node-role.deckhouse.io/system.

    • Добавляемые toleration’ы (добавляются одновременно все):

      • {"key":"dedicated.deckhouse.io","operator":"Equal","value":"MODULE_NAME"};

        Например: {"key":"dedicated.deckhouse.io","operator":"Equal","value":"network-gateway"};

      • {"key":"dedicated.deckhouse.io","operator":"Equal","value":"system"}.