Установка

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

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

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

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

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

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

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

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

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

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

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

Для оценки ресурсов, необходимых для установки Deckhouse Kubernetes Platform, вы можете ознакомиться со следующими руководствами:

• Руководство по подбору ресурсов для кластера на bare metal
• Руководство по разметке и объему дисков
• Руководство по подготовке к production

Перед установкой убедитесь в следующем:

• Для кластера на bare metal (в том числе гибридного кластера) и при установке в неподдерживаемых облаках: сервер использует операционную систему из списка поддерживаемых ОС или совместимую с ним, а также доступен по SSH через ключ.

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

• Есть доступ к хранилищу образов контейнеров Deckhouse (к публичному — registry.deckhouse.io или registry.deckhouse.ru, либо к зеркалу).

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

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

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

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

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

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

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

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

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

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

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

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

   • AWSClusterConfiguration — Amazon Web Services;
   • AzureClusterConfiguration — Microsoft Azure;
   • DynamixClusterConfiguration — Базис.DynamiX;
   • DVPClusterConfiguration — Deckhouse Virtualization Platform;
   • GCPClusterConfiguration — Google Cloud Platform;
   • HuaweiCloudClusterConfiguration — Huawei Cloud;
   • OpenStackClusterConfiguration — OpenStack, OVHcloud, Selectel, VK Cloud;
   • VsphereClusterConfiguration — VMware vSphere;
   • VCDClusterConfiguration — VMware Cloud Director;
   • YandexClusterConfiguration — Yandex Cloud;
   • ZvirtClusterConfiguration — zVirt.

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

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

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

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

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

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

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

   Если кластер изначально создается с узлами, выделенными для определенных типов нагрузки (например, системные узлы или узлы для мониторинга), рекомендуется в конфигурации модулей, использующих тома постоянного хранилища, явно задавать параметр 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:
    earlyOomEnabled: false
---
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:
    earlyOomEnabled: false
---
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> — редакция DKP. Например, 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.

Пример команды для запуска контейнера с установщиком DKP Community Edition из канала обновлений 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

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

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

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

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

Где:

• /config.yml — файл конфигурации установки;
• <SSH_USER> — имя пользователя для подключения по SSH к серверу;
• --ssh-agent-private-keys — файл приватного SSH-ключа для подключения по SSH.

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

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

1. Общие проверки:
   • Значения параметров publicDomainTemplate и clusterDomain не совпадают.
   • Данные аутентификации для хранилища образов, указанные в конфигурации установки, корректны.
   • Имя хоста соответствует следующим требованиям:
     • длина не более 63 символов;
     • состоит только из строчных букв;
     • не содержит спецсимволов (допускаются символы - (дефис) и . (точка), при этом они не могут быть в начале или в конце имени).
   • На сервере (ВМ) установлен поддерживаемый container runtime (containerd).
   • Имя хоста уникально в пределах кластера.
   • На сервере установлено корректное время.
   • Адресное пространство подов (podSubnetCIDR) и сервисов (serviceSubnetCIRD) кластера не пересекаются.
2. Проверки для установки статического и гибридного кластера:
   • Указан только один параметр --ssh-host. Для статической конфигурации кластера можно задать только один IP-адрес для настройки первого master-узла.
   • Должна быть возможность подключения по SSH с использованием указанных данных аутентификации.
   • Должна быть возможность установки SSH-туннеля до сервера (или виртуальной машины) master-узла.
   • Сервер (ВМ), выбранный для установки master-узла, должен соответствовать минимальным системным требованиям:
     • не менее 4 CPU;
     • не менее 8 ГБ RAM;
     • не менее 60 ГБ диска с производительностью 400+ IOPS;
     • ядро Linux версии 5.8 или новее;
     • установлен один из пакетных менеджеров: apt, apt-get, yum или rpm;
     • доступ к стандартным системным репозиториям для установки зависимостей;
     • в случае с РЕД ОС — убедитесь, что установлены yum и which (по умолчанию могут отсутствовать);
     • в случае использования ContainerdV2 в качестве container runtime по умолчанию на узлах кластера:
       • поддержка CgroupsV2;
       • systemd версии 244;
       • поддержка модуля ядра erofs.
   • На сервере (ВМ) для master-узла установлен Python.
   • Хранилище образов доступно через прокси (если настройки прокси указаны в конфигурации установки).
   • На сервере (ВМ) для master-узла и в хосте, на котором запущен установщик, свободны порты, необходимые для процесса установки.
   • DNS должен разрешать localhost в IP-адрес 127.0.0.1.
   • На сервере (ВМ) пользователю доступна команда sudo.
   • Открыты необходимые порты для установки:
     • между хостом запуска установщика и сервером — порт 22/TCP;
     • отсутствуют конфликты по портам, которые используются процессом установки.
   • На сервере (ВМ) установлено корректное время.
   • Адресное пространство подов (podSubnetCIDR), сервисов (serviceSubnetCIRD) и внутренней сети кластера (internalNetworkCIDRs) не пересекаются.
   • На сервере (ВМ) отсутствует пользователь deckhouse.
3. Проверки для установки облачного кластера:
   • Конфигурация виртуальной машины master-узла удовлетворяет минимальным требованиям.
   • API облачного провайдера доступно с узлов кластера.
   • Проверка конфигурации Yandex Cloud с NAT Instance.

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

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

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

dhctl bootstrap-phase abort

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

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

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

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

• начиная с версии DKP 1.75 — с помощью ModuleConfig deckhouse;
• до версии DKP 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 Kubernetes Platform, флажок Authentication должен быть включен, а связанные поля должны быть заполнены следующим образом:
     • Authentication Type должно иметь значение Username.
     • Username должно иметь значение license-token.
     • Password должно содержать ключ лицензии Deckhouse Kubernetes Platform.

   

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

   • Создайте роль 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 (это обязательно, для применения изменений).

     

В результате образы DKP будут доступны, например, по следующему адресу: 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 Kubernetes Platform;
   • задайте остальные параметры по своему усмотрению;
   • нажмите «ОК», чтобы подтвердить создание эндпоинта для хранилища образов.

   

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

   

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

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

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

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

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

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

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

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

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

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

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

  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
  

  Пример команды для загрузки точной версии модуля 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
  

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

• Загрузите образы DKP в хранилище образов с помощью команды 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, вы не сможете выгрузить образы в корень проекта. Используйте выделенный репозиторий в проекте для размещения образов DKP.

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

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

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

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

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

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

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

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

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

Для настройки DKP на работу с прокси-сервером используйте параметр 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, в DKP больше не настраивается файл /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 }}