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            ENABLED   VERSION   AGE     MESSAGE
deckhouse       true      1         12h
documentation   true      1         12h
global                    1         12h
prometheus      true      2         12h
upmeter         false     2         12h

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

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

kubectl 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         ENABLED   VERSION   AGE   MESSAGE
user-authn   false     1         12h

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

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

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

Особенности работы с набором модулей Minimal

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

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

Для установки Deckhouse с набором модулей Minimal включите как минимум следующие модули, указав их в конфигурационном файле установщика:

  • cloud-data-crd;
  • cni-cilium или другой модуль управления CNI (при необходимости);
  • control-plane-manager;
  • kube-dns;
  • terraform-manager, в случае развертывания облачного кластера;
  • node-manager;
  • registry-packages-proxy;
  • модуль облачного провайдера (например, cloud-provider-aws для AWS), в случае развертывания облачного кластера).

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

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

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

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

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

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

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

  • Модули monitoring (operator-prometheus, prometheus и vertical-pod-autoscaler):
    • Порядок поиска узлов (для определения nodeSelector):
      1. Наличие узла с лейблом node-role.deckhouse.io/MODULE_NAME.
      2. Наличие узла с лейблом node-role.deckhouse.io/monitoring.
      3. Наличие узла с лейблом 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):
      1. Наличие узла с лейблом node-role.deckhouse.io/MODULE_NAME.
      2. Наличие узла с лейблом node-role.deckhouse.io/frontend.
    • Добавляемые toleration’ы (добавляются одновременно все):
      • {"key":"dedicated.deckhouse.io","operator":"Equal","value":"MODULE_NAME"};
      • {"key":"dedicated.deckhouse.io","operator":"Equal","value":"frontend"}.
  • Все остальные модули:
    • Порядок поиска узлов (для определения nodeSelector):
      1. Наличие узла с лейблом node-role.deckhouse.io/MODULE_NAME (например, node-role.deckhouse.io/cert-manager).
      2. Наличие узла с лейблом 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"}.