Установка

На этой странице представлена обзорная информация по установке Deckhouse Platform.

Способы установки

Установить Deckhouse Platform можно следующими способами:

• с помощью CLI-установщика (доступен в виде образа контейнера и основан на утилите dhctl);
• с помощью графического установщика.

Далее рассмотрен процесс установки с помощью CLI-установщика.

Варианты установки

Установить Deckhouse Platform можно в следующих вариантах:

• В поддерживаемом облаке. Установщик автоматически создает и настраивает все необходимые ресурсы (включая виртуальные машины, сетевые объекты и т.д.), разворачивает кластер Kubernetes и устанавливает Deckhouse Platform. Полный список поддерживаемых облачных провайдеров доступен в разделе «Интеграция с IaaS».

• На серверах bare metal (в том числе гибридные кластеры) или в неподдерживаемых облаках. Установщик настраивает указанные в конфигурации серверы или виртуальные машины, разворачивает кластер Kubernetes и устанавливает Deckhouse Platform. Пошаговые инструкции по развертыванию на bare metal можно найти в разделе «Быстрый старт» → «Deckhouse Platform на bare metal».

• В существующем кластере Kubernetes. Установщик разворачивает Deckhouse Platform и интегрирует его с текущей инфраструктурой. Пошаговые инструкции по развертыванию в существующем кластере можно найти в разделе «Быстрый старт» → «Deckhouse Platform в существующем кластере».

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

Перед началом установки ознакомьтесь со сценариями развертывания Deckhouse Platform и требованиями к установке в разделе «Системные требования».

Подготовка конфигурации

Перед началом установки необходимо подготовить файл конфигурации установки, а также, при необходимости, post-bootstrap-скрипт.

Файл конфигурации установки

Файл конфигурации установки состоит из YAML-секций (документов) и содержит настройки Deckhouse Platform, а также описание (манифесты) объектов и ресурсов кластера, которые будут созданы после установки. Файл конфигурации установки используется в CLI-установщике и передается с помощью параметра --config (см. далее).

Список обязательных и опциональных объектов и ресурсов кластера, которые могут понадобиться в файле конфигурации установки:

1. InitConfiguration (обязательный) — начальные параметры конфигурации, необходимые для запуска Deckhouse Platform.

   Начиная с версии Deckhouse Platform 1.75, используйте ModuleConfig deckhouse для настройки доступа к хранилищу образов Deckhouse Platform. Настройка доступа с помощью InitConfiguration (параметры imagesRepo, registryDockerCfg, registryScheme, registryCA) считается устаревшим способом.

2. ClusterConfiguration — общие параметры кластера, такие как версия Kubernetes (компонентов control plane кластера), сетевые настройки, параметры CRI и т. д. Является обязательным, кроме случая, когда Deckhouse Platform устанавливается в уже существующий кластер Kubernetes.

3. StaticClusterConfiguration — параметры кластера, развертываемого на серверах bare-metal (в том числе гибридного кластера) или виртуальных машинах в неподдерживаемых облаках. Является обязательным, кроме случая, когда Deckhouse Platform устанавливается в уже существующий кластер Kubernetes.

   Для добавления группы узлов (объект NodeGroup) под рабочую нагрузку в кластер могут понадобиться также объекты StaticInstance и SSHCredentials.

4. <PROVIDER>ClusterConfiguration — параметры интеграции с облачным провайдером. Является обязательным при интеграции Deckhouse Platform с поддерживаемой облачной инфраструктурой.

   Ресурсы DVPClusterConfiguration, YandexClusterConfiguration и ZvirtClusterConfiguration устарели. Параметры интеграции со встроенной виртуализацией, Yandex Cloud и zVirt задаются в ModuleConfig модулей cloud-provider-dvp, cloud-provider-yandex и cloud-provider-zvirt и в связанных с ними ресурсах. Эти ресурсы описаны в разделах «Схемы размещения и настройка встроенной виртуализации», «Схемы размещения и настройка Yandex Cloud» и «Схемы размещения и настройка zVirt».

   Примеры ресурсов, настраивающих интеграцию Deckhouse Platform с облачным провайдером:

   • AWSClusterConfiguration — Amazon Web Services;
   • AzureClusterConfiguration — Microsoft Azure;
   • DynamixClusterConfiguration — Basis Dynamix;
   • ModuleConfig cloud-provider-dvp — Deckhouse Virtualization Platform (вместе с секретом d8-credentials и ресурсами DVPInstanceClass / NodeGroup);
   • GCPClusterConfiguration — Google Cloud Platform;
   • HuaweiCloudClusterConfiguration — Huawei Cloud;
   • OpenStackClusterConfiguration — OpenStack, OVHcloud, Selectel, VK Cloud;
   • VsphereClusterConfiguration — VMware vSphere;
   • VCDClusterConfiguration — VMware Cloud Director;
   • ModuleConfig cloud-provider-yandex — Yandex Cloud (вместе с секретом d8-credentials и ресурсами YandexInstanceClass / NodeGroup);
   • ModuleConfig cloud-provider-zvirt — zVirt (вместе с секретом d8-credentials и ресурсами ZvirtInstanceClass / NodeGroup).

   Для добавления облачных узлов в кластер также понадобятся объекты <PROVIDER>InstanceClass (например YandexInstanceClass для Yandex Cloud), которые описывают конфигурацию виртуальных машин в группе узлов (объект NodeGroup).

5. Конфигурации модулей Deckhouse Platform.

   Каждый модуль настраивается (а также может быть включен или отключен) с помощью собственного объекта ModuleConfig с именем модуля (например, ModuleConfig user-authn для модуля user-authn). Допустимые параметры, которые можно указывать в объекте ModuleConfig, можно найти в документации соответствующего модуля в разделе «Настройки» (например, настройки модуля user-authn).

   Список всех модулей Deckhouse Platform доступен в разделе «Модули» документации.

   Некоторые модули могут быть включены и предварительно настроены автоматически, в зависимости от выбранного варианта установки и конфигурации кластера (например, модули, обеспечивающие работу control plane кластера и сети).

   Модули, часто настраиваемые при установке:

   • global — глобальные настройки Deckhouse Platform для указания параметров, которые используются по умолчанию всеми модулями и компонентами (шаблон DNS-имен, StorageClass, настройки расположения компонентов модулей и т.д.);
   • deckhouse — настройки доступа к хранилищу образов, желаемый канал обновлений и другие параметры;
   • user-authn — отвечает за единую систему аутентификации;
   • cni-cilium — отвечает за работу сети в кластере (например, используется при установке Deckhouse Platform на bare metal, в закрытом окружении, на РЕД-виртуализации и на SpaceVM);
   • virtualization — отвечает за запуск виртуальных машин в кластере, включается сразу при установке или позже.

   Если кластер изначально создается с узлами, выделенными для определенных типов нагрузки (например, системные узлы или узлы для мониторинга), рекомендуется в конфигурации модулей, использующих тома постоянного хранилища, явно задавать параметр nodeSelector (например, в параметре nodeSelector ModuleConfig prometheus для модуля prometheus).

6. IngressNginxController — параметры создаваемого балансировщика HTTP/HTTPS-трафика (Ingress-контроллера).

7. NodeGroup — параметры группы узлов. Необходим для добавления узлов под рабочую нагрузку в кластер.

8. Объекты для настройки аутентификации и авторизации, такие как ClusterAuthorizationRule, AuthorizationRule, User, Group, DexProvider.

   Читайте подробнее в документации о настройке аутентификации и авторизации.

apiVersion: deckhouse.io/v1
kind: ClusterConfiguration
clusterType: Cloud
cloud:
  provider: Azure
  prefix: cloud-demo
podSubnetCIDR: 10.111.0.0/16
serviceSubnetCIDR: 10.222.0.0/16
kubernetesVersion: "Automatic"
clusterDomain: cluster.local
---
apiVersion: deckhouse.io/v1
kind: AzureClusterConfiguration
layout: Standard
sshPublicKey: <SSH_PUBLIC_KEY>
vNetCIDR: 10.241.0.0/16
subnetCIDR: 10.241.0.0/24
masterNodeGroup:
  replicas: 3
  instanceClass:
    machineSize: Standard_D4ds_v4
    urn: Canonical:UbuntuServer:18.04-LTS:18.04.202010140
    enableExternalIP: true
provider:
  subscriptionId: <SUBSCRIPTION_ID>
  clientId: <CLIENT_ID>
  clientSecret: <CLIENT_SECRET>
  tenantId: <TENANT_ID>
  location: westeurope
---
apiVersion: deckhouse.io/v1alpha1
kind: ModuleConfig
metadata:
  name: deckhouse
spec:
  enabled: true
  settings:
    releaseChannel: Stable
    bundle: Default
    logLevel: Info
    registry:
      mode: Unmanaged
      unmanaged:
        imagesRepo: test-registry.io/some/path
        scheme: HTTPS
        username: <username>
        password: <password>
        ca: <CA>
  version: 1
---
apiVersion: deckhouse.io/v1alpha1
kind: ModuleConfig
metadata:
  name: global
spec:
  settings:
    modules:
      publicDomainTemplate: "%s.k8s.example.com"
  version: 2
---
apiVersion: deckhouse.io/v1alpha1
kind: ModuleConfig
metadata:
  name: user-authn
spec:
  version: 2
  enabled: true
  settings:
    controlPlaneConfigurator:
      dexCAMode: DoNotNeed
    publishAPI:
      enabled: true
      https:
        mode: Global
        global:
          kubeconfigGeneratorMasterCA: ""
---
apiVersion: deckhouse.io/v1alpha1
kind: ModuleConfig
metadata:
  name: node-manager
spec:
  version: 1
  enabled: true
  settings: {}
---
apiVersion: deckhouse.io/v1alpha1
kind: ModuleConfig
metadata:
  name: prometheus
spec:
  version: 2
  enabled: true
  # Укажите в случае использования выделенных узлов для мониторинга.
  # settings:
  #   nodeSelector:
  #     node.deckhouse.io/group: monitoring
---
apiVersion: deckhouse.io/v1
kind: IngressNginxController
metadata:
  name: main
spec:
  ingressClass: "nginx"
  inlet: "LoadBalancer"
  nodeSelector:
    node.deckhouse.io/group: worker
---
apiVersion: deckhouse.io/v1
kind: AzureInstanceClass
metadata:
  name: worker
spec:
  machineSize: Standard_F4
---
apiVersion: deckhouse.io/v1
kind: NodeGroup
metadata:
  name: worker
spec:
  cloudInstances:
    classReference:
      kind: AzureInstanceClass
      name: worker
    maxPerZone: 3
    minPerZone: 1
    zones: ["1"]
  nodeType: CloudEphemeral
---
apiVersion: deckhouse.io/v1
kind: ClusterAuthorizationRule
metadata:
  name: admin
spec:
  subjects:
  - kind: User
    name: admin@deckhouse.io
  accessLevel: SuperAdmin
  portForwarding: true
---
apiVersion: deckhouse.io/v1
kind: User
metadata:
  name: admin
spec:
  email: admin@deckhouse.io
  password: '$2a$10$isZrV6uzS6F7eGfaNB1EteLTWky7qxJZfbogRs1egWEPuT1XaOGg2'

apiVersion: deckhouse.io/v1
kind: ClusterConfiguration
clusterType: Cloud
cloud:
  provider: Azure
  prefix: cloud-demo
podSubnetCIDR: 10.111.0.0/16
serviceSubnetCIDR: 10.222.0.0/16
kubernetesVersion: "Automatic"
clusterDomain: cluster.local
---
apiVersion: deckhouse.io/v1
kind: InitConfiguration
deckhouse:
  imagesRepo: registry.deckhouse.ru/deckhouse/ee
  registryDockerCfg: eyJhdXRocyI6IHsgInJlZ2zzzmRlY2tob3Vxxcxxxc5ydSI6IsssfX0K
---
apiVersion: deckhouse.io/v1
kind: AzureClusterConfiguration
layout: Standard
sshPublicKey: <SSH_PUBLIC_KEY>
vNetCIDR: 10.241.0.0/16
subnetCIDR: 10.241.0.0/24
masterNodeGroup:
  replicas: 3
  instanceClass:
    machineSize: Standard_D4ds_v4
    urn: Canonical:UbuntuServer:18.04-LTS:18.04.202010140
    enableExternalIP: true
provider:
  subscriptionId: <SUBSCRIPTION_ID>
  clientId: <CLIENT_ID>
  clientSecret: <CLIENT_SECRET>
  tenantId: <TENANT_ID>
  location: westeurope
---
apiVersion: deckhouse.io/v1alpha1
kind: ModuleConfig
metadata:
  name: deckhouse
spec:
  enabled: true
  settings:
    releaseChannel: Stable
    bundle: Default
    logLevel: Info
  version: 1
---
apiVersion: deckhouse.io/v1alpha1
kind: ModuleConfig
metadata:
  name: global
spec:
  settings:
    modules:
      publicDomainTemplate: "%s.k8s.example.com"
  version: 2
---
apiVersion: deckhouse.io/v1alpha1
kind: ModuleConfig
metadata:
  name: user-authn
spec:
  version: 2
  enabled: true
  settings:
    controlPlaneConfigurator:
      dexCAMode: DoNotNeed
    publishAPI:
      enabled: true
      https:
        mode: Global
        global:
          kubeconfigGeneratorMasterCA: ""
---
apiVersion: deckhouse.io/v1alpha1
kind: ModuleConfig
metadata:
  name: node-manager
spec:
  version: 1
  enabled: true
  settings: {}
---
apiVersion: deckhouse.io/v1alpha1
kind: ModuleConfig
metadata:
  name: prometheus
spec:
  version: 2
  enabled: true
  # Укажите в случае использования выделенных узлов для мониторинга.
  # settings:
  #   nodeSelector:
  #     node.deckhouse.io/group: monitoring
---
apiVersion: deckhouse.io/v1
kind: IngressNginxController
metadata:
  name: main
spec:
  ingressClass: "nginx"
  inlet: "LoadBalancer"
  nodeSelector:
    node.deckhouse.io/group: worker
---
apiVersion: deckhouse.io/v1
kind: AzureInstanceClass
metadata:
  name: worker
spec:
  machineSize: Standard_F4
---
apiVersion: deckhouse.io/v1
kind: NodeGroup
metadata:
  name: worker
spec:
  cloudInstances:
    classReference:
      kind: AzureInstanceClass
      name: worker
    maxPerZone: 3
    minPerZone: 1
    zones: ["1"]
  nodeType: CloudEphemeral
---
apiVersion: deckhouse.io/v1
kind: ClusterAuthorizationRule
metadata:
  name: admin
spec:
  subjects:
  - kind: User
    name: admin@deckhouse.io
  accessLevel: SuperAdmin
  portForwarding: true
---
apiVersion: deckhouse.io/v1
kind: User
metadata:
  name: admin
spec:
  email: admin@deckhouse.io
  password: '$2a$10$isZrV6uzS6F7eGfaNB1EteLTWky7qxJZfbogRs1egWEPuT1XaOGg2'

Post-bootstrap-скрипт

Установщик позволяет выполнить пользовательский скрипт на одном из master-узлов после завершения установки (post-bootstrap-скрипт). Такой скрипт может использоваться для:

• дополнительной настройки кластера;
• сбора диагностической информации;
• интеграции с внешними системами и других задач.

Указать путь к post-bootstrap-скрипту можно с помощью параметра --post-bootstrap-script-path при запуске CLI-установщика.

#!/usr/bin/env bash

set -e
set -o pipefail


INGRESS_NAME="nginx"


echo_err() { echo "$@" 1>&2; }

# Объявление переменной.
lb_ip=""

# Получение IP-адреса балансировщика нагрузки.
for i in {0..100}
do
  if lb_ip="$(kubectl -n d8-ingress-nginx get svc "${INGRESS_NAME}-load-balancer" -o jsonpath='{.status.loadBalancer.ingress[0].ip}')"; then
    if [ -n "$lb_ip" ]; then
      break
    fi
  fi

  lb_ip=""

  sleep 5
done

if [ -n "$lb_ip" ]; then
  echo_err "The load balancer external IP: $lb_ip"
else
  echo_err "Could not get the external IP of the load balancer"
  exit 1
fi

outContent="{\"frontend_ips\":[\"$lb_ip\"]}"

if [ -z "$OUTPUT" ]; then
  echo_err "The OUTPUT env is empty. The result was not saved to the output file."
else
  echo "$outContent" > "$OUTPUT"
fi

Установка

docker login -u license-token registry.deckhouse.ru

Команда для запуска контейнера с установщиком из публичного хранилища образов контейнеров Deckhouse:

docker run --pull=always -it [<MOUNT_OPTIONS>] registry.deckhouse.ru/deckhouse/<DECKHOUSE_REVISION>/install:<RELEASE_CHANNEL> bash

Где:

1. <DECKHOUSE_REVISION> — редакция Deckhouse Platform. Например, ee — для Enterprise Edition, ce — для Community Edition и т. д.
2. <MOUNT_OPTIONS> — параметры монтирования файлов в контейнер установщика, таких как:
   • SSH-ключи доступа;
   • файл конфигурации;
   • файл ресурсов и т. д.
3. <RELEASE_CHANNEL> — канал обновлений в формате kebab-case:
   • alpha — для канала обновлений Alpha;
   • beta — для канала обновлений Beta;
   • early-access — для канала обновлений Early Access;
   • stable — для канала обновлений Stable;
   • rock-solid — для канала обновлений Rock Solid.

Пример команды для запуска контейнера с установщиком Deckhouse Platform Community Edition (Deckhouse Platform Boost) из канала обновлений Stable:

docker run -it --pull=always \
  -v "$PWD/config.yaml:/config.yaml" \
  -v "$PWD/dhctl-tmp:/tmp/dhctl" \
  -v "$HOME/.ssh/:/tmp/.ssh/" registry.deckhouse.ru/deckhouse/ce/install:stable bash

Установка Deckhouse Platform осуществляется в контейнере установщика с помощью команды dhctl:

• Для запуска установки Deckhouse Platform с развертыванием нового кластера (все случаи, кроме установки в существующий кластер) используйте команду dhctl bootstrap.
• Для установки Deckhouse Platform в уже существующий кластер используйте команду dhctl bootstrap-phase install-deckhouse.

Пример запуска установки Deckhouse Platform с развертыванием кластера в облаке:

dhctl bootstrap \
  --ssh-user=<SSH_USER> --ssh-agent-private-keys=/tmp/.ssh/<SSH_PRIVATE_KEY_FILE> \
  --config=/config.yml

Где:

• /config.yml — файл конфигурации установки;
• <SSH_USER> — имя пользователя для подключения по SSH к серверу;
• --ssh-agent-private-keys — файл приватного SSH-ключа для подключения по SSH.
• <SSH_PRIVATE_KEY_FILE> — имя приватного ключа. Например, для ключа с RSA-шифрованием это может быть id_rsa, а для ключа с ED25519-шифрованием — id_ed25519.

Если сервер принимает только ключи, подписанные центром сертификации SSH, положите сертификат рядом с приватным ключом под именем <SSH_PRIVATE_KEY_FILE>-cert.pub, например id_ed25519-cert.pub. dhctl использует его автоматически.

Проверки перед началом установки

Список проверок, выполняемых установщиком перед началом установки Deckhouse Platform:

1. Общие проверки:
   • Значения параметров publicDomainTemplate и clusterDomain (или устаревшего ClusterConfiguration.clusterDomain) не совпадают.
   • Данные аутентификации для хранилища образов, указанные в конфигурации установки, корректны.
   • Имя хоста соответствует следующим требованиям:
     • длина не более 63 символов;
     • состоит только из строчных букв;
     • не содержит спецсимволов (допускаются символы - (дефис) и . (точка), при этом они не могут быть в начале или в конце имени).
   • На сервере (ВМ) установлен поддерживаемый container runtime (containerd).
   • Имя хоста уникально в пределах кластера.
   • На сервере установлено корректное время.
   • Адресное пространство подов (podSubnetCIDR) и сервисов (serviceSubnetCIRD) кластера не пересекаются.
2. Проверки для установки статического и гибридного кластера:
   • Указан только один параметр --ssh-host. Для статической конфигурации кластера можно задать только один IP-адрес для настройки первого master-узла.
   • Должна быть возможность подключения по SSH с использованием указанных данных аутентификации.
   • Должна быть возможность установки SSH-туннеля до сервера (или виртуальной машины) master-узла.
   • Сервер (ВМ), выбранный для установки master-узла, соответствует минимальным ресурсам, приведённым в разделе «Требования к ресурсам». Там же приведены ресурсы узлов для каждого варианта размещения.
   • На сервере (ВМ) для master-узла должен быть доступен Python (Python 3 или Python 2). Также должны быть доступны стандартные модули Python, используемые установщиком:
     • для работы с HTTP-запросами: urllib.request (Python 3) или urllib2 (Python 2);
     • для обработки HTTP-ошибок: urllib.error (Python 3) или urllib2 (Python 2);
     • для работы с конфигурацией: configparser (Python 3) или ConfigParser (Python 2);
     • для запуска HTTP-сервера: http.server (Python 3) или SimpleHTTPServer (Python 2);
     • для работы с TCP-сервером: http.server (Python 3) или SocketServer (Python 2).
   • Хранилище образов доступно через прокси (если настройки прокси указаны в конфигурации установки).
   • На сервере (ВМ) для master-узла и на хосте, с которого запускается установщик, должен быть доступен порт 22/TCP (сетевой доступ от персонального компьютера), необходимый для процесса установки. Подробнее в разделе «Сетевое взаимодействие компонентов платформы».
   • DNS должен разрешать localhost в IP-адрес 127.0.0.1.
   • На сервере (ВМ) пользователю доступна команда sudo.
   • Открыты необходимые порты для установки:
     • между хостом запуска установщика и сервером — порт 22/TCP;
     • отсутствуют конфликты по портам, которые используются процессом установки.
   • На сервере (ВМ) установлено корректное время.
   • Адресное пространство подов (podSubnetCIDR), сервисов (serviceSubnetCIRD) и внутренней сети кластера (internalNetworkCIDRs) не пересекаются.
   • На сервере (ВМ) нет конфликтов с локальной служебной учетной записью deckhouse: пользователь и группа либо отсутствуют, либо пользователь имеет UID и основной GID 64535, группа имеет GID 64535, пользователь не имеет прав sudo, а UID/GID 64535 не заняты другими учетными записями. Подробнее — в разделе «Локальная служебная учетная запись deckhouse».
3. Проверки для установки облачного кластера:
   • Конфигурация виртуальной машины master-узла удовлетворяет минимальным ресурсам, приведённым в разделе «Требования к ресурсам».
   • API облачного провайдера доступно с узлов кластера.
   • Проверка конфигурации Yandex Cloud с NAT Instance.

    dhctl bootstrap \
    --ssh-user=<SSH_USER> --ssh-agent-private-keys=/tmp/.ssh/<SSH_PRIVATE_KEY_FILE> \
    --config=/config.yml \
    --preflight-skip-all-checks

Локальная служебная учетная запись deckhouse

Компоненты Deckhouse Platform используют UID/GID 64535 для запуска непривилегированных процессов и доступа к своим файлам на узле. Локальный пользователь и группа deckhouse закрепляют эти идентификаторы за Deckhouse Platform и позволяют ОС отображать имя deckhouse вместо числовых UID/GID в выводе ps, top и ls. Процессы, запущенные от имени пользователя deckhouse, могут отображаться в выводе ps и top — это штатная ситуация. Они принадлежат компонентам Deckhouse Platform и не являются пользовательскими сеансами.

Если учетная запись отсутствует, bashible создает ее с оболочкой /sbin/nologin, без пароля и прав sudo. В /etc/passwd для пользователя указан домашний каталог по умолчанию (обычно /home/deckhouse). Bashible создает этот каталог отдельно как базовый каталог для домашних каталогов пользователей, заданных ресурсами NodeUser; сама служебная учетная запись deckhouse не предназначена для входа и хранения пользовательских файлов. Учетная запись не должна предоставляться через AD или LDAP.

Имя deckhouse и UID/GID 64535 зарезервированы для Deckhouse Platform и не настраиваются. Не удаляйте и не переименовывайте пользователя или группу, не меняйте их UID/GID и не назначайте пользователю права sudo. Preflight-проверка допускает отсутствие пользователя и группы либо их наличие, если пользователь имеет UID и основной GID 64535, группа имеет GID 64535, а пользователь не имеет прав sudo. Установка завершается ошибкой, если имя используется с другими идентификаторами или UID/GID 64535 заняты другими учетными записями.

Флаг --preflight-skip-check=deckhouse-user отключает проверку, но не устраняет конфликт. Если пользователь или группа deckhouse существуют с другими идентификаторами, bashible не изменяет их и выводит предупреждение в журнал. Если UID/GID 64535 заняты другой учетной записью, bashible не сможет создать пользователя или группу deckhouse. Права sudo у существующего пользователя bashible не отзывает.

Если конфликт остался от предыдущей установки Deckhouse Platform на статическом узле, выполните ручную очистку статического узла. Это деструктивная операция: скрипт очистки удаляет службы, конфигурацию и локальные данные Kubernetes, containerd и etcd, а также учетные записи Deckhouse Platform, после чего перезагружает сервер. Выполняйте очистку только на узле, подготовленном к повторному развертыванию. В остальных случаях устраните конфликт вручную или пересоздайте узел.

Откат установки

Если установка была прервана или возникли проблемы во время установки в поддерживаемом облаке, то могут остаться ресурсы, созданные в процессе установки. Для их удаления выполните следующую команду в контейнере с установщиком:

dhctl bootstrap-phase abort

Установка виртуализации

Виртуализация включается ресурсом ModuleConfig virtualization и разворачивает свои компоненты в неймспейсе d8-virtualization. Ресурс можно задать сразу в файле конфигурации установки либо применить в готовом кластере.

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

apiVersion: deckhouse.io/v1alpha1
kind: ModuleConfig
metadata:
  name: virtualization
spec:
  enabled: true
  version: 1
  settings:
    dvcr:
      storage:
        type: PersistentVolumeClaim
        persistentVolumeClaim:
          size: 50G
    virtualMachineCIDRs:
      - 10.66.10.0/24

Остальные параметры описаны в справочнике настроек модуля.

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

d8 k get modules virtualization

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

NAME             WEIGHT   SOURCE      PHASE   ENABLED   READY
virtualization   900      deckhouse   Ready   True      True

Фаза модуля должна быть Ready.

Размещение компонентов виртуализации по узлам

Распределение компонентов по узлам зависит от конфигурации кластера. В нём могут быть только master-узлы, на которых работают и компоненты control plane, и нагрузка; master-узлы и worker-узлы; master-узлы, system-узлы и worker-узлы; либо другие сочетания. Под worker-узлами здесь понимаются узлы без ограничений (taints), мешающих запуску обычной рабочей нагрузки.

Компоненты Deckhouse Platform распределяет по приоритету, и если в кластере есть подходящий тип узлов, компонент попадёт на него. За что отвечает каждый компонент, описано в разделе «Подсистема Virtualization».

Компонент virt-handler-* запускается только на узлах, где Deckhouse Platform обнаружил поддержку KVM и проставил лейбл virtualization.deckhouse.io/kvm-enabled, а компонент virtualization-dra-* — только на узлах с лейблом virtualization.deckhouse.io/usbip.

Компоненты, которые создают и загружают образы и диски виртуальных машин, запускаются только на время этой работы:

Кластер с taints на всех узлах

Иногда taints настроены на всех узлах кластера, и так администратор явно контролирует, на какие узлы попадает рабочая нагрузка. В такой конфигурации учитывайте следующее:

1. При создании VirtualDisk обратите внимание на volumeBindingMode StorageClass. Если задано Immediate, PersistentVolume создаётся сразу после создания диска, ещё до планирования виртуальной машины. Убедитесь, что хранилище может создавать тома на узлах, которые разрешены для виртуальных машин через параметры размещения, включая nodeSelector, tolerations и настройки в spec виртуальной машины или VirtualMachineClass. Иначе диск может оказаться на узле, где виртуальная машина не сможет запуститься. При WaitForFirstConsumer том создаётся на узле планирования виртуальной машины, и эта проблема не возникает.

2. Для работы VirtualImage и ClusterVirtualImage нужны временные компоненты из таблицы выше. У них есть toleration к taint dedicated.deckhouse.io=system.

3. В кластере должна быть NodeGroup system, либо администратор сам добавляет taint dedicated.deckhouse.io=system на выбранные узлы без создания NodeGroup. Без таких узлов эти компоненты не будут запланированы, и образы не перейдут в фазу Ready.

Закрытое окружение, работа через прокси-сервер и стороннее хранилище образов контейнеров

Установка из стороннего хранилища образов контейнеров

Deckhouse Platform можно установить из стороннего хранилища образов или через проксирующий сервер внутри закрытого контура.

Варианты настройки работы со сторонними хранилищами образов при установке кластера:

• начиная с версии Deckhouse Platform 1.75 — с помощью ModuleConfig deckhouse;
• до версии Deckhouse Platform 1.75 — с помощью InitConfiguration (устаревший способ, пример приведен ниже).

Для настройки с помощью ModuleConfig deckhouse укажите параметры доступа к стороннему хранилищу образов в секции settings.registry.

Пример:

apiVersion: deckhouse.io/v1alpha1
kind: ModuleConfig
metadata:
  name: deckhouse
spec:
  version: 1
  enabled: true
  settings:
    registry:
      mode: Direct
      direct:
        imagesRepo: test-registry.io/some/path
        scheme: HTTPS
        username: <username>
        password: <password>
        ca: <CA>

{"auths": { "<PROXY_REGISTRY>": {}}}

{"auths": { "<PROXY_REGISTRY>": {"username":"<PROXY_USERNAME>","password":"<PROXY_PASSWORD>","auth":"<AUTH_BASE64>"}}}

declare MYUSER='<PROXY_USERNAME>'
declare MYPASSWORD='<PROXY_PASSWORD>'
declare MYREGISTRY='<PROXY_REGISTRY>'

MYAUTH=$(echo -n "$MYUSER:$MYPASSWORD" | base64 -w0)
MYRESULTSTRING=$(echo -n "{\"auths\":{\"$MYREGISTRY\":{\"username\":\"$MYUSER\",\"password\":\"$MYPASSWORD\",\"auth\":\"$MYAUTH\"}}}" | base64 -w0)

echo "$MYRESULTSTRING"

Особенности настройки Nexus

При использовании менеджера репозиториев Nexus должны быть выполнены следующие требования:

• Создан проксирующий репозиторий Docker («Administration» → «Repository» → «Repositories»):
  • установлен в 0 параметр Maximum metadata age для репозитория.
• Настроен контроль доступа:
  • создана роль Nexus («Administration» → «Security» → «Roles») со следующими полномочиями:
    • nx-repository-view-docker-<репозиторий>-browse;
    • nx-repository-view-docker-<репозиторий>-read;
  • создан пользователь («Administration» → «Security» → «Users») с ролью Nexus.

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

1. Создайте проксирующий репозиторий Docker («Administration» → «Repository» → «Repositories»), указывающий на публичное хранилище образов Deckhouse.

2. Заполните поля страницы создания репозитория следующим образом:
   • Name должно содержать имя создаваемого репозитория, например, d8-proxy.
   • Repository Connectors / HTTP или Repository Connectors / HTTPS должно содержать выделенный порт для создаваемого репозитория, например, 8123 или иной.
   • Remote storage должно иметь значение https://registry.deckhouse.ru/.
   • Auto blocking enabled и Not found cache enabled могут быть выключены для отладки; в противном случае их следует включить.
   • Maximum Metadata Age должно быть равно 0.
   • Если планируется использовать коммерческую редакцию Deckhouse Platform, флажок Authentication должен быть включен, а связанные поля должны быть заполнены следующим образом:
     • Authentication Type должно иметь значение Username.
     • Username должно иметь значение license-token.
     • Password должно содержать ключ лицензии Deckhouse Platform.

   

3. Настройте контроль доступа Nexus для доступа Deckhouse Platform к созданному репозиторию:

   • Создайте роль Nexus («Administration» → «Security» → «Roles») с полномочиями nx-repository-view-docker-<репозиторий>-browse и nx-repository-view-docker-<репозиторий>-read.

     

   • Создайте пользователя («Administration» → «Security» → «Users») с ролью, созданной выше.

     

   • Включите Docker Bearer Token Realm («Administration» → «Security» → «Realms»):

     • Docker Bearer Token Realm должен быть в списке Active (справа), а не в Available (слева).
     • Если его нет в Active:
       1. Найдите в списке Available.
       2. Переместите стрелкой в Active.
       3. Нажмите Save.
       4. Перезапустите Nexus (это обязательно, для применения изменений).

     

В результате образы Deckhouse Platform будут доступны, например, по следующему адресу: https://<NEXUS_HOST>:<REPOSITORY_PORT>/deckhouse/ee:<d8s-version>.

Особенности настройки Harbor

Используйте функцию Harbor Proxy Cache.

1. Настройте доступ к хранилищу образов:
   • в боковом меню перейдите в раздел «Administration» → «Registries» и нажмите «New Endpoint», чтобы добавить эндпоинт для хранилища образов;
   • в выпадающем списке «Provider» выберите «Docker Registry»;
   • в поле «Name» укажите имя эндпоинта на свое усмотрение;
   • в поле «Endpoint URL» укажите https://registry.deckhouse.ru;
   • в поле «Access ID» укажите license-token;
   • в поле «Access Secret» укажите свой лицензионный ключ Deckhouse Platform;
   • задайте остальные параметры по своему усмотрению;
   • нажмите «ОК», чтобы подтвердить создание эндпоинта для хранилища образов.

   

2. Создайте новый проект:
   • в боковом меню перейдите в раздел «Projects» и нажмите «New Project», чтобы добавить проект;
   • в поле «Project Name» укажите любое имя проекта на свое усмотрение (например, d8s). Указанное имя будет частью URL-адреса;
   • в поле «Access Level» выберите «Public»;
   • включите «Proxy Cache» и в выпадающем списке выберите хранилище образов, созданное ранее;
   • задайте остальные параметры по своему усмотрению;
   • нажмите «ОК», чтобы подтвердить создание проекта.

   

После настройки Harbor образы Deckhouse Platform станут доступны по адресу следующего вида: https://your-harbor.com/d8s/deckhouse/ee:{d8s-version}.

Ручная загрузка образов Deckhouse Platform и БД уязвимостей в приватное хранилище образов контейнеров

• Скачайте и установите утилиту Deckhouse CLI.

• Скачайте образы Deckhouse Platform в выделенную директорию, используя команду d8 mirror pull.

  По умолчанию d8 mirror pull скачивает только актуальные версии Deckhouse Platform, базы данных сканера уязвимостей (если они входят в редакцию Deckhouse Platform) и официально поставляемых модулей. Например, для Deckhouse Platform 1.59 будет скачана только версия 1.59.12, т. к. этого достаточно для обновления платформы с 1.58 до 1.59.

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

  d8 mirror pull \
    --source='registry.deckhouse.ru/deckhouse/<EDITION>' \
    --license='<LICENSE_KEY>' /home/user/d8-bundle
  

  где:

  • --source — адрес хранилища образов Deckhouse;
  • <EDITION> — код редакции Deckhouse Platform (например, ee, se, se-plus). По умолчанию параметр --source ссылается на редакцию Enterprise Edition (ee) и может быть опущен;
  • --license — параметр для указания лицензионного ключа Deckhouse Platform для аутентификации в официальном хранилище образов;
  • <LICENSE_KEY> — лицензионный ключ Deckhouse Platform;
  • /home/user/d8-bundle — директория, в которой будут расположены пакеты образов. Будет создана, если не существует.

  Если загрузка образов будет прервана, повторный вызов команды продолжит загрузку, если с момента ее остановки прошло не более суток.

  Пример команды для загрузки всех версий Deckhouse Platform EE, начиная с версии 1.59 (укажите лицензионный ключ):

  d8 mirror pull \
  --license='<LICENSE_KEY>' \
  --since-version=1.59 /home/user/d8-bundle
  

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

  d8 mirror pull \
  --license='<LICENSE_KEY>' \
  --source='registry.deckhouse.ru/deckhouse/se' \
  /home/user/d8-bundle
  

  Пример команды для загрузки образов Deckhouse Platform из стороннего хранилища образов:

  d8 mirror pull \
  --source='corp.company.com:5000/sys/deckhouse' \
  --source-login='<USER>' --source-password='<PASSWORD>' /home/user/d8-bundle
  

  Пример команды для загрузки пакета баз данных сканера уязвимостей:

  d8 mirror pull \
  --license='<LICENSE_KEY>' \
  --no-platform --no-modules /home/user/d8-bundle
  

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

  d8 mirror pull \
  --license='<LICENSE_KEY>' \
  --no-platform --no-security-db /home/user/d8-bundle
  

  Пример команды для загрузки пакетов модулей stronghold и secrets-store-integration:

  d8 mirror pull \
  --license='<LICENSE_KEY>' \
  --no-platform --no-security-db \
  --include-module stronghold \
  --include-module secrets-store-integration \
  /home/user/d8-bundle
  

  Пример команды для загрузки модуля stronghold с semver-ограничением ^ (разрешает обновления, которые не меняют первую ненулевую цифру слева) от версии 1.2.0:

  d8 mirror pull \
  --license='<LICENSE_KEY>' \
  --no-platform --no-security-db \
  --include-module stronghold@1.2.0 \
  /home/user/d8-bundle
  

  Пример команды для загрузки модуля secrets-store-integration с semver-ограничением ~ (разрешает обновления, которые не меняют разряд последней указанной цифры) от версии 1.1.0:

  d8 mirror pull \
  --license='<LICENSE_KEY>' \
  --no-platform --no-security-db \
  --include-module secrets-store-integration@~1.1.0 \
  /home/user/d8-bundle
  

  Заключайте в кавычки значение флага --include-module, если оно содержит >= или <=. Без кавычек shell обработает это как перенаправление ввода/вывода.

  Пример команды для загрузки модуля console с semver-ограничением >= (любая версия, начиная с указанной и выше) от версии 1.43.2:

  d8 mirror pull \
  --license='<LICENSE_KEY>' \
  --no-platform --no-security-db \
  --include-module "console@>=1.43.2" \
  /home/user/d8-bundle
  

  Пример команды для загрузки точной версии модуля stronghold 1.2.5 с публикацией во все каналы обновлений:

  d8 mirror pull \
  --license='<LICENSE_KEY>' \
  --no-platform --no-security-db \
  --include-module stronghold@=v1.2.5 \
  /home/user/d8-bundle
  

• На хост с доступом к хранилищу образов, куда нужно загрузить образы Deckhouse Platform, скопируйте загруженный пакет образов Deckhouse Platform и установите Deckhouse CLI.

• Загрузите образы Deckhouse Platform в хранилище образов с помощью команды d8 mirror push.

  Команда d8 mirror push загружает в хранилище образов образы из всех пакетов, которые присутствуют в переданной директории. При необходимости выгрузить в хранилище образов только часть пакетов вы можете либо выполнить команду для каждого необходимого пакета образов, передав ей прямой путь до TAR-пакета вместо директории, либо убрав расширение .tar у ненужных пакетов или переместив их вне директории.

  Пример команды для загрузки пакетов образов из директории /mnt/MEDIA/d8-images (укажите данные для авторизации при необходимости):

  d8 mirror push /mnt/MEDIA/d8-images 'corp.company.com:5000/sys/deckhouse' \
    --registry-login='<USER>' --registry-password='<PASSWORD>'
  

  Перед загрузкой образов убедитесь, что путь для загрузки в хранилище образов существует (в примере — /sys/deckhouse) и у используемой учетной записи есть права на запись.

  Если вы используете Harbor, вы не сможете выгрузить образы в корень проекта. Используйте выделенный репозиторий в проекте для размещения образов Deckhouse Platform.

• После загрузки образов в хранилище образов можно переходить к установке Deckhouse Platform. Воспользуйтесь руководством по быстрому старту.

  При запуске установщика используйте хранилище образов, в которое ранее были загружены образы, а не официальное публичное хранилище образов Deckhouse Platform. Для примера выше адрес запуска установщика будет иметь вид corp.company.com:5000/sys/deckhouse/install:stable вместо registry.deckhouse.ru/deckhouse/ee/install:stable.

  В секции параметров registry ModuleConfig deckhouse при установке также используйте адрес вашего хранилища образов и данные авторизации (с версии Deckhouse Platform 1.75). Устаревший способ — использование InitConfiguration (параметры imagesRepo, registryDockerCfg).

Создание кластера и запуск Deckhouse Platform без использования каналов обновлений

Если необходимо установить Deckhouse Platform с отключенным автоматическим обновлением:

1. Используйте тег образа установщика соответствующей версии. Например, если вы хотите установить релиз v1.44.3, используйте образ your.private.registry.com/deckhouse/install:v1.44.3.

2. Укажите соответствующий номер версии в параметре deckhouse.devBranch в InitConfiguration.

   Не указывайте параметр deckhouse.releaseChannel в InitConfiguration.

Если вы хотите отключить автоматические обновления для уже установленного Deckhouse Platform (включая обновления patch-релизов), удалите параметр releaseChannel из конфигурации модуля deckhouse.

Использование прокси-сервера

Для настройки Deckhouse Platform на работу с прокси-сервером используйте параметр proxy ресурса ClusterConfiguration.

Пример:

apiVersion: deckhouse.io/v1
kind: ClusterConfiguration
clusterType: Cloud
cloud:
  provider: OpenStack
  prefix: main
podSubnetCIDR: 10.111.0.0/16
serviceSubnetCIDR: 10.222.0.0/16
kubernetesVersion: "Automatic"
cri: "Containerd"
clusterDomain: "cluster.local"
proxy:
  httpProxy: "http://user:password@proxy.company.my:3128"
  httpsProxy: "https://user:password@proxy.company.my:8443"

Автозагрузка прокси-переменных пользователям в CLI

Начиная с версии 1.67, в Deckhouse Platform больше не настраивается файл /etc/profile.d/d8-system-proxy.sh, который ранее устанавливал прокси-переменные для пользователей. Для автозагрузки прокси-переменных пользователям в CLI используйте ресурс NodeGroupConfiguration:

apiVersion: deckhouse.io/v1alpha1
kind: NodeGroupConfiguration
metadata:
  name: profile-proxy.sh
spec:
  bundles:
    - '*'
  nodeGroups:
    - '*'
  weight: 99
  content: |
    {{- if .proxy }}
      {{- if .proxy.httpProxy }}
    export HTTP_PROXY={{ .proxy.httpProxy | quote }}
    export http_proxy=${HTTP_PROXY}
      {{- end }}
      {{- if .proxy.httpsProxy }}
    export HTTPS_PROXY={{ .proxy.httpsProxy | quote }}
    export https_proxy=${HTTPS_PROXY}
      {{- end }}
      {{- if .proxy.noProxy }}
    export NO_PROXY={{ .proxy.noProxy | join "," | quote }}
    export no_proxy=${NO_PROXY}
      {{- end }}
    bb-sync-file /etc/profile.d/profile-proxy.sh - << EOF
    export HTTP_PROXY=${HTTP_PROXY}
    export http_proxy=${HTTP_PROXY}
    export HTTPS_PROXY=${HTTPS_PROXY}
    export https_proxy=${HTTPS_PROXY}
    export NO_PROXY=${NO_PROXY}
    export no_proxy=${NO_PROXY}
    EOF
    {{- else }}
    rm -rf /etc/profile.d/profile-proxy.sh
    {{- end }}

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

• Быстрый старт
• Поддерживаемые версии ОС и Kubernetes
• Интеграция с инфраструктурой
• Установка Deckhouse Platform в закрытом окружении
• Подготовка к Production
• Глобальные кастомные ресурсы
• Глобальные параметры