Страница находится в стадии активной разработки и может содержать неполные данные. Ниже представлена обзорная информация о процессе установки Deckhouse. Для более детального ознакомления рекомендуем перейти в раздел Быстрый старт, где доступны пошаговые инструкции.
Попробуйте графический установщик Deckhouse Kubernetes Platform! Beta
Инсталлятор Deckhouse доступен в виде образа контейнера и основан на утилите dhctl, в задачи которой входят:
- Создание и настройка объектов в облачной инфраструктуре с помощью Terraform;
- Установка необходимых пакетов ОС на узлах (в том числе установка пакетов Kubernetes);
- Установка Deckhouse;
- Создание, настройка узлов кластера Kubernetes;
- Поддержание состояния кластера в соответствии с описанной конфигурацией.
Варианты установки Deckhouse:
-
В поддерживаемом облаке. Утилита
dhctl
автоматически создает и настраивает все необходимые ресурсы, включая виртуальные машины, развертывает Kubernetes-кластер и устанавливает Deckhouse. Полный список поддерживаемых облачных провайдеров доступен в разделе Кластер Kubernetes. -
На серверах bare-metal или в неподдерживаемых облаках. В этом варианте
dhctl
выполняет настройку сервера или виртуальной машины, развертывает Kubernetes-кластер с одним master-узлом и устанавливает Deckhouse. Для добавления дополнительных узлов в кластер можно воспользоваться готовыми скриптами настройки. -
В существующем Kubernetes-кластере. Если Kubernetes-кластер уже развернут,
dhctl
устанавливает Deckhouse, интегрируя его с текущей инфраструктурой.
Подготовка инфраструктуры
Перед установкой убедитесь в следующем:
-
Для кластеров на bare-metal и в неподдерживаемых облаках: сервер использует операционную систему из списка поддерживаемых ОС или совместимую с ним, а также доступен по SSH через ключ.
-
Для поддерживаемых облаков: имеются необходимые квоты для создания ресурсов и подготовлены параметры доступа к облачной инфраструктуре (зависят от конкретного провайдера).
-
Для всех вариантов установки: настроен доступ к container registry с образами Deckhouse (
registry.deckhouse.io
илиregistry.deckhouse.ru
).
Подготовка конфигурации
Перед началом установки Deckhouse необходимо выполнить подготовку YAML-файла конфигурации установки. Этот файл содержит основные параметры для настройки Deckhouse, включая информацию о кластерных компонентах, сетевых настройках и интеграциях, а также описание ресурсов для создания после установки (настройки узлов и Ingress-контроллера).
Убедитесь, что конфигурационный файл соответствует требованиям вашей инфраструктуры и включает все необходимые параметры для корректного развертывания.
Файл конфигурации установки
YAML-файл конфигурации установки содержит параметры нескольких ресурсов (манифесты):
-
InitConfiguration — начальные параметры конфигурации Deckhouse, необходимые для корректного запуска Deckhouse после установки.
Основные настройки, задаваемые в этом ресурсе:
- Параметры размещения компонентов;
- Используемый StorageClass;
- Параметры доступа к container registry;
- Шаблон DNS-имен;
- Другие важные параметры, без которых Deckhouse не сможет корректно функционировать.
- ClusterConfiguration — общие параметры кластера, такие как версия control plane, сетевые настройки, параметры CRI и т. д.
Этот ресурс требуется использовать только в случае, если Deckhouse устанавливается с предварительным развертыванием кластера Kubernetes. Если Deckhouse устанавливается в уже существующий кластер, этот ресурс не нужен.
- StaticClusterConfiguration — параметры для кластеров Kubernetes, развертываемых на серверах bare-metal или виртуальных машинах в неподдерживаемых облаках.
Этот ресурс требуется использовать только в случае, если Deckhouse устанавливается с предварительным развертыванием кластера Kubernetes. Если Deckhouse устанавливается в уже существующий кластер, этот ресурс не нужен.
-
<CLOUD_PROVIDER>ClusterConfiguration
— набор ресурсов, содержащих параметры конфигурации поддерживаемых облачных провайдеров. Включает такие параметры, как:- Настройки доступа к облачной инфраструктуре (параметры аутентификации);
- Тип и параметры схемы размещения ресурсов;
- Сетевые параметры;
- Настройки создаваемых групп узлов.
Список ресурсов конфигурации поддерживаемых облачных провайдеров:
- AWSClusterConfiguration — Amazon Web Services;
- AzureClusterConfiguration — Microsoft Azure;
- GCPClusterConfiguration — Google Cloud Platform;
- OpenStackClusterConfiguration — OpenStack;
- VsphereClusterConfiguration — VMware vSphere;
- VCDClusterConfiguration — VMware Cloud Director;
- YandexClusterConfiguration — Yandex Cloud;
- ZvirtClusterConfiguration — zVirt.
-
ModuleConfig
— набор ресурсов, содержащих параметры конфигурации встроенных модулей Deckhouse.Если кластер изначально создается с узлами, выделенными для определенных типов нагрузки (например, системные узлы или узлы для мониторинга), рекомендуется в конфигурации модулей, использующих тома постоянного хранилища явно задавать параметр
nodeSelector
.Например, для модуля
prometheus
настройка указывается в параметре nodeSelector. -
IngressNginxController
— развертывание Ingress-контроллера. -
NodeGroup
— создание дополнительных групп узлов. -
InstanceClass
— добавление конфигурационных ресурсов. ClusterAuthorizationRule
,User
— настройка прав и пользователей.
Post-bootstrap-скрипт
После завершения установки Deckhouse инсталлятор предоставляет возможность выполнить пользовательский скрипт на одном из master-узлов. Такой скрипт может использоваться для:
- Выполнения дополнительной настройки кластера;
- Сбора диагностической информации;
- Интеграции с внешними системами и других задач.
Указать путь к post-bootstrap-скрипту можно с помощью параметра --post-bootstrap-script-path
при запуске процесса инсталляции.
Установка Deckhouse
При установке коммерческой редакции Deckhouse Kubernetes Platform из официального container registry registry.deckhouse.ru
, необходимо предварительно пройти аутентификацию с использованием лицензионного ключа:
docker login -u license-token registry.deckhouse.ru
Запуск контейнера инсталлятора Deckhouse из публичного container registry выглядит следующим образом:
docker run --pull=always -it [<MOUNT_OPTIONS>] registry.deckhouse.ru/deckhouse/<DECKHOUSE_REVISION>/install:<RELEASE_CHANNEL> bash
Где:
<DECKHOUSE_REVISION>
— редакция Deckhouse, напримерee
— для Enterprise Edition,ce
— для Community Edition и т. д.<MOUNT_OPTIONS>
— параметры монтирования файлов в контейнер инсталлятора, такие как:- SSH-ключи доступа;
- Файл конфигурации;
- Файл ресурсов и т. д.
<RELEASE_CHANNEL>
— канал обновлений в формате kebab-case:alpha
— для канала обновлений Alpha;beta
— для канала обновлений Beta;early-access
— для канала обновлений Early Access;stable
— для канала обновлений Stable;rock-solid
— для канала обновлений Rock Solid.
Пример команды для запуска инсталлятора Deckhouse в редакции CE:
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 осуществляется в контейнере инсталлятора с помощью утилиты dhctl
:
- Для запуска установки Deckhouse с развертыванием нового кластера (все случаи, кроме установки в существующий кластер) используйте команду
dhctl bootstrap
. - Для установки Deckhouse в уже существующий кластер используйте команду
dhctl bootstrap-phase install-deckhouse
.
Для получения подробной справки по параметрам команды выполните dhctl bootstrap -h
.
Пример запуска установки Deckhouse с развертыванием кластера в облаке:
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:
- Общие проверки:
- Значения параметров PublicDomainTemplate clusterDomain не совпадают.
- Данные аутентификации для хранилища образов контейнеров, указанные в конфигурации установки, корректны.
- Имя хоста соответствует следующим требованиям:
- Длина не более 63 символов;
- Состоит только из строчных букв;
- Не содержит спецсимволов (допускаются символы
-
и.
, при этом они не могут быть в начале или в конце имени).
- На сервере (ВМ) установлен поддерживаемый container runtime (
containerd
). - Имя хоста уникально в пределах кластера.
- На сервере установлено корректное время.
- Адресное пространство подов (
podSubnetCIDR
) и сервисов (serviceSubnetCIRD
) кластера не пересекаются.
- Проверки для установки статического и гибридного кластера:
- Указан только один параметр
--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
(по умолчанию могут отсутствовать).
- На сервере (ВМ) для master-узла установлен Python.
- Хранилище образов контейнеров доступно через прокси (если настройки прокси указаны в конфигурации установки).
- На сервере (ВМ) для master-узла и в хосте инсталлятора свободны порты, необходимые для процесса установки.
- DNS должен разрешать
localhost
в IP-адрес 127.0.0.1. - На сервере (ВМ) пользователю доступна команда
sudo
. - Открыты необходимые порты для установки:
- между хостом запуска установщика и сервером — порт 22/TCP;
- отсутствуют конфликты по портам, которые используются процессом установки.
- На сервере (ВМ) установлено корректное время.
- Адресное пространство подов (
podSubnetCIDR
), сервисов (serviceSubnetCIRD
) и внутренней сети кластера (internalNetworkCIDRs
) не пересекаются. - На сервере (ВМ) отсутствует пользователь
deckhouse
.
- Указан только один параметр
- Проверки для установки облачного кластера:
- Конфигурация виртуальной машины master-узла удовлетворяет минимальным требованиям.
- API облачного провайдера доступно с узлов кластера.
- Проверка конфигурации Yandex Cloud с NAT Instance.
Откат установки
Если установка была прервана или возникли проблемы во время установки в поддерживаемом облаке, то могут остаться ресурсы, созданные в процессе установки. Для их удаления используйте команду dhctl bootstrap-phase abort
, выполнив ее в контейнере инсталлятора.
Файл конфигурации, передаваемый через параметр --config
при запуске инсталлятора, должен быть тем же, с которым проводилась первоначальная установка.
Закрытое окружение, работа через proxy и сторонние registries
Установка Deckhouse Kubernetes Platform из стороннего registry
Доступно в следующих редакциях: BE, SE, SE+, EE, CSE Lite (1.67), CSE Pro (1.67).
DKP поддерживает работу только с Bearer token-схемой авторизации в container registry.
Протестирована и гарантируется работа со следующими container registries: Nexus, Harbor, Artifactory, Docker Registry, Quay.
При установке DKP можно настроить на работу со сторонним registry (например, проксирующий registry внутри закрытого контура).
Установите следующие параметры в ресурсе InitConfiguration:
imagesRepo: <PROXY_REGISTRY>/<DECKHOUSE_REPO_PATH>/ee
— адрес образа DKP EE в стороннем registry. Пример:imagesRepo: registry.deckhouse.ru/deckhouse/ee
;registryDockerCfg: <BASE64>
— права доступа к стороннему registry, зашифрованные в Base64.
Если разрешен анонимный доступ к образам DKP в стороннем registry, registryDockerCfg
должен выглядеть следующим образом:
{"auths": { "<PROXY_REGISTRY>": {}}}
Приведенное значение должно быть закодировано в Base64.
Если для доступа к образам DKP в стороннем registry необходима аутентификация, registryDockerCfg
должен выглядеть следующим образом:
{"auths": { "<PROXY_REGISTRY>": {"username":"<PROXY_USERNAME>","password":"<PROXY_PASSWORD>","auth":"<AUTH_BASE64>"}}}
где:
<PROXY_USERNAME>
— имя пользователя для аутентификации на<PROXY_REGISTRY>
;<PROXY_PASSWORD>
— пароль пользователя для аутентификации на<PROXY_REGISTRY>
;<PROXY_REGISTRY>
— адрес стороннего registry в виде<HOSTNAME>[:PORT]
;<AUTH_BASE64>
— строка вида<PROXY_USERNAME>:<PROXY_PASSWORD>
, закодированная в Base64.
Итоговое значение для registryDockerCfg
должно быть также закодировано в Base64.
Вы можете использовать следующий скрипт для генерации registryDockerCfg
:
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"
Для настройки нестандартных конфигураций сторонних registries в ресурсе InitConfiguration предусмотрены еще два параметра:
registryCA
— корневой сертификат, которым можно проверить сертификат registry (если registry использует самоподписанные сертификаты);registryScheme
— протокол доступа к registry (HTTP
илиHTTPS
). По умолчанию —HTTPS
.
Особенности настройки Nexus
При взаимодействии с репозиторием типа docker
расположенным в Nexus (например, при выполнении команд docker pull
, docker push
) требуется указывать адрес в формате <NEXUS_URL>:<REPOSITORY_PORT>/<PATH>
.
Использование значения URL
из параметров репозитория 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 («Administration» → «Security» → «Roles») со следующими полномочиями:
Настройка:
-
Создайте проксирующий репозиторий Docker («Administration» → «Repository» → «Repositories»), указывающий на Deckhouse registry:
- Заполните поля страницы создания репозитория следующим образом:
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.
- Настройте контроль доступа Nexus для доступа DKP к созданному репозиторию:
-
Создайте роль Nexus («Administration» → «Security» → «Roles») с полномочиями
nx-repository-view-docker-<репозиторий>-browse
иnx-repository-view-docker-<репозиторий>-read
. -
Создайте пользователя («Administration» → «Security» → «Users») с ролью, созданной выше.
-
В результате образы DKP будут доступны, например, по следующему адресу: https://<NEXUS_HOST>:<REPOSITORY_PORT>/deckhouse/ee:<d8s-version>
.
Особенности настройки Harbor
Используйте функцию Harbor Proxy Cache.
- Настройте registry:
- «Administration» → «Registries» → «New Endpoint».
- «Provider: Docker Registry».
- «Name» — укажите любое, на ваше усмотрение.
- «Endpoint URL:
https://registry.deckhouse.ru
». -
Укажите «Access ID» и «Access Secret» (лицензионный ключ для Deckhouse Kubernetes Platform).
- Создайте новый проект:
- «Projects → New Project».
- «Project Name» будет частью URL. Используйте любой, например,
d8s
. - «Access Level:
Public
». -
«Proxy Cache» — включите и выберите в списке registry, созданный на предыдущем шаге.
В результате настройки, образы DKP станут доступны, например, по следующему адресу: https://your-harbor.com/d8s/deckhouse/ee:{d8s-version}
.
Ручная загрузка образов Deckhouse Kubernetes Platform, БД сканера уязвимостей и модулей DKP в приватный registry
Утилита d8 mirror
недоступна для использования с редакциями Community Edition (CE) и Basic Edition (BE).
О текущем статусе версий на каналах обновлений можно узнать на releases.deckhouse.ru.
-
Скачайте образы 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
где:
<EDITION>
— код редакции Deckhouse Kubernetes Platform (например,ee
,se
,se-plus
). По умолчанию параметр--source
ссылается на редакцию Enterprise Edition (ee
) и может быть опущен;<LICENSE_KEY>
— лицензионный ключ Deckhouse Kubernetes Platform;/home/user/d8-bundle
— директория, в которой будут расположены пакеты образов. Будет создана, если не существует.
Если загрузка образов будет прервана, повторный вызов команды продолжит загрузку, если с момента ее остановки прошло не более суток.
Вы также можете использовать следующие параметры команды:
--no-pull-resume
— чтобы принудительно начать загрузку сначала;--no-platform
— для пропуска загрузки пакета образов Deckhouse Kubernetes Platform (platform.tar);--no-modules
— для пропуска загрузки пакетов модулей (module-*.tar);--no-security-db
— для пропуска загрузки пакета баз данных сканера уязвимостей (security.tar);--include-module
/-i
=name[@Major.Minor]
— для загрузки только определенного набора модулей по принципу белого списка (и, при необходимости, их минимальных версий). Укажите несколько раз, чтобы добавить в белый список больше модулей. Эти флаги игнорируются, если используются совместно с--no-modules
.--exclude-module
/-e
=name
— для пропуска загрузки определенного набора модулей по принципу черного списка. Укажите несколько раз, чтобы добавить в черный список больше модулей. Игнорируется, если используются--no-modules
или--include-module
.--modules-path-suffix
— для изменения суффикса пути к репозиторию модулей в основном репозитории DKP. По умолчанию используется суффикс/modules
(так, например, полный путь к репозиторию с модулями будет выглядеть какregistry.deckhouse.ru/deckhouse/EDITION/modules
).--since-version=X.Y
— чтобы скачать все версии DKP, начиная с указанной минорной версии. Параметр будет проигнорирован, если указана версия выше чем версия находящаяся на канале обновлений Rock Solid. Параметр не может быть использован одновременно с параметром--deckhouse-tag
;--deckhouse-tag
— чтобы скачать только конкретную версию DKP (без учета каналов обновлений). Параметр не может быть использован одновременно с параметром--since-version
;--gost-digest
— для расчета контрольной суммы итогового набора образов DKP в формате ГОСТ Р 34.11-2012 (Стрибог). Контрольная сумма будет отображена и записана в файл с расширением.tar.gostsum
в папке с tar-архивом, содержащим образы DKP;--source
— чтобы указать адрес источника хранилища образов DKP (по умолчаниюregistry.deckhouse.ru/deckhouse/ee
);- Для аутентификации в официальном хранилище образов DKP нужно использовать лицензионный ключ и параметр
--license
; - Для аутентификации в стороннем хранилище образов нужно использовать параметры
--source-login
и--source-password
; --images-bundle-chunk-size=N
— для указания максимального размера файла (в ГБ), на которые нужно разбить архив образов. В результате работы вместо одного файла архива образов будет создан набор.chunk
-файлов (например,d8.tar.NNNN.chunk
). Чтобы загрузить образы из такого набора файлов, укажите в командеd8 mirror push
имя файла без суффикса.NNNN.chunk
(например,d8.tar
для файловd8.tar.NNNN.chunk
);--tmp-dir
— путь к директории для временных файлов, который будет использоваться во время операций загрузки и выгрузки образов. Вся обработка выполняется в этом каталоге. Он должен иметь достаточное количество свободного дискового пространства, чтобы вместить весь загружаемый пакет образов. По умолчанию используется поддиректория.tmp
в директории с пакетами образов.
Дополнительные параметры конфигурации для семейства команд
d8 mirror
доступны в виде переменных окружения:HTTP_PROXY
/HTTPS_PROXY
— URL прокси-сервера для запросов к HTTP(S) хостам, которые не указаны в списке хостов в переменной$NO_PROXY
;NO_PROXY
— список хостов, разделенных запятыми, которые следует исключить из проксирования. Каждое значение может быть представлено в виде IP-адреса (1.2.3.4
), CIDR (1.2.3.4/8
), домена или символа (*
). IP-адреса и домены также могут включать номер порта (1.2.3.4:80
). Доменное имя соответствует как самому себе, так и всем поддоменам. Доменное имя начинающееся с.
, соответствует только поддоменам. Например,foo.com
соответствуетfoo.com
иbar.foo.com
;.y.com
соответствуетx.y.com
, но не соответствуетy.com
. Символ*
отключает проксирование;SSL_CERT_FILE
— указывает путь до сертификата SSL. Если переменная установлена, системные сертификаты не используются;SSL_CERT_DIR
— список каталогов, разделенный двоеточиями. Определяет, в каких каталогах искать файлы сертификатов SSL. Если переменная установлена, системные сертификаты не используются. Подробнее…;MIRROR_BYPASS_ACCESS_CHECKS
— установите для этого параметра значение1
, чтобы отключить проверку корректности переданных учетных данных для registry;
Пример команды для загрузки всех версий 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
-
На хост с доступом к хранилищу, куда нужно загрузить образы 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
.В ресурсе InitConfiguration при установке также используйте адрес вашего хранилища и данные авторизации (параметры imagesRepo, registryDockerCfg или шаг 3 руководства по быстрому старту).
Создание кластера и запуск DKP без использования каналов обновлений
Этот способ следует использовать только в случае, если в изолированном приватном registry нет образов, содержащих информацию о каналах обновлений.
Если необходимо установить DKP с отключенным автоматическим обновлением:
- Используйте тег образа установщика соответствующей версии. Например, если вы хотите установить релиз
v1.44.3
, используйте образyour.private.registry.com/deckhouse/install:v1.44.3
. - Укажите соответствующий номер версии в параметре deckhouse.devBranch в ресурсе InitConfiguration.
Не указывайте параметр deckhouse.releaseChannel в ресурсе InitConfiguration.
Если вы хотите отключить автоматические обновления у уже установленного Deckhouse (включая обновления patch-релизов), удалите параметр releaseChannel из конфигурации модуля deckhouse
.
Использование proxy-сервера
Доступно в следующих редакциях: BE, SE, SE+, EE, CSE Lite (1.67), CSE Pro (1.67).
Для настройки DKP на использование proxy используйте параметр 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"
Автозагрузка переменных proxy пользователям в CLI
Начиная с версии платформы DKP v1.67 больше не настраивается файл /etc/profile.d/d8-system-proxy.sh
, который устанавливал переменные proxy для пользователей. Для автозагрузки переменных proxy пользователям в 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 }}