В этом руководстве описано, как развернуть кластер Deckhouse Kubernetes Platform в закрытом окружении без прямого доступа к хранилищу образов контейнеров DKP (registry.deckhouse.ru) и внешним репозиториям deb/rpm-пакетов, используемых на узлах поддерживаемых операционных систем.
Обратите внимание, что установка DKP в закрытом окружении доступна в следующих редакциях: SE, SE+, EE, CSE Lite (1.67), CSE Pro (1.67).
Особенности закрытого окружения
Установка в закрытом окружении практически не отличается от установки на bare metal.
Ключевые особенности:
- доступ в Интернет для приложений, развёрнутых в закрытом контуре, предоставляется через прокси-сервер, параметры которого необходимо указать в конфигурации кластера;
- container registry с образами контейнеров DKP разворачивается отдельно с доступом изнутри контура, а в кластере настраивается его использование и необходимые права доступа.
Взаимодействие с внешними ресурсами выполняется через отдельный физический сервер или виртуальную машину Bastion (bastion-хост). На bastion-хосте разворачиваются container registry и прокси-сервер, а также выполняются все операции по управлению кластером.
Общая схема закрытого окружения:

На схеме также показан внутренний репозиторий пакетов ОС. Он требуется для установки curl на узлах будущего кластера, если доступ к официальным репозиториям невозможен даже через прокси-сервер.
Выбор инфраструктуры
В данном руководстве описывается развёртывание в закрытом окружении кластера, состоящего из одного master-узла и одного worker-узла.
Для выполнения работ потребуются:
- персональный компьютер, с которого будут выполняться операции;
- отдельный физический сервер или виртуальная машина Bastion (bastion-хост), где будут развёрнуты container registry и сопутствующие компоненты;
- два физических сервера или две виртуальные машины под узлы кластера.
Требования к серверам:
- Bastion — не менее 4 ядер CPU, 8 ГБ ОЗУ, 150 ГБ на быстром диске. Такой объём требуется, поскольку на bastion-хосте будут храниться все образы DKP, необходимые для установки. Перед загрузкой в приватный registry образы скачиваются с публичного registry DKP на bastion-хост.
- Узлы кластера — ресурсы под будущие узлы кластера выбираются исходя из требований к планируемой нагрузке. Для примера подойдёт минимально рекомендуемая конфигурация — 4 ядра CPU, 8 ГБ ОЗУ и 60 ГБ на быстром диске (400+ IOPS) на каждый узел.
Подготовка приватного container registry
DKP поддерживает только Bearer token-схему авторизации в container registry.
Протестирована и гарантируется работа со следующими container registry — Nexus, Harbor, Artifactory, Docker Registry, Quay.
Установка Harbor
В качестве приватного registry используется Harbor. Он поддерживает настройку политик и управление доступом на основе ролей (RBAC), выполняет проверку образов на уязвимости и позволяет помечать доверенные артефакты. Harbor входит в состав проектов CNCF.
Установите последнюю версию Harbor из GitHub-репозитория проекта. Для этого скачайте архив с установщиком из нужного релиза, выбрав вариант с harbor-offline-installer в названии.

Скопируйте адрес ссылки. Например, для версии harbor-offline-installer-v2.14.1.tgz ссылка будет выглядеть следующим образом: https://github.com/goharbor/harbor/releases/download/v2.14.1/harbor-offline-installer-v2.14.1.tgz.
Подключитесь к серверу Bastion по SSH и скачайте архив любым удобным способом.
Распакуйте скачанный архив (укажите имя архива):
tar -zxf ./harbor-offline-installer-v2.14.1.tgz
В полученной директории harbor расположены файлы, необходимые для установки.
Перед развёртыванием хранилища сгенерируйте самоподписанный (self-signed) TLS-сертификат.
Из-за ограничений доступа в закрытом окружении невозможно получить сертификаты, например, от Let’s Encrypt, так как сервис не сможет выполнить проверку, необходимую для выдачи сертификата.
Существует несколько способов генерации сертификатов. В этом руководстве приведён один из вариантов. При необходимости используйте другой подходящий способ или разместите уже имеющийся сертификат.
Создайте директорию certs в директории harbor:
cd harbor/
mkdir certs
Сгенерируйте сертификаты для внешнего доступа следующими командами:
openssl genrsa -out ca.key 4096
openssl req -x509 -new -nodes -sha512 -days 3650 -subj "/C=RU/ST=Moscow/L=Moscow/O=example/OU=Personal/CN=myca.local" -key ca.key -out ca.crt
Сгенерируйте сертификаты для внутреннего доменного имени harbor.local, чтобы внутри приватной сети обращаться к серверу Bastion по защищённому соединению:
openssl genrsa -out harbor.local.key 4096
openssl req -sha512 -new -subj "/C=RU/ST=Moscow/L=Moscow/O=example/OU=Personal/CN=harbor.local" -key harbor.local.key -out harbor.local.csr
cat > v3.ext <<-EOF
authorityKeyIdentifier=keyid, issuer
basicConstraints=CA:FALSE
keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment
extendedKeyUsage = serverAuth
subjectAltName = @alt_names
[alt_names]
IP.1=<INTERNAL_IP_ADDRESS>
DNS.1=harbor.local
EOF
Не забудьте заменить <INTERNAL_IP_ADDRESS> на внутренний IP-адрес сервера Bastion. По нему будет выполняться обращение к container registry изнутри закрытого контура. С этим же адресом связано доменное имя harbor.local.
openssl x509 -req -sha512 -days 3650 -extfile v3.ext -CA ca.crt -CAkey ca.key -CAcreateserial -in harbor.local.csr -out harbor.local.crt
openssl x509 -inform PEM -in harbor.local.crt -out harbor.local.cert
Проверьте, что все сертификаты созданы успешно:
ls -la
Далее настройте Docker для работы с приватным container registry, доступ к которому выполняется по TLS. Для этого создайте директорию harbor.local в /etc/docker/certs.d/:
sudo mkdir -p /etc/docker/certs.d/harbor.local
Параметр
-pуказывает утилитеmkdirсоздать родительские директории, если они отсутствуют (в данном случае — директориюcerts.d).
Скопируйте в неё созданные сертификаты:
cp ca.crt /etc/docker/certs.d/harbor.local/
cp harbor.local.cert /etc/docker/certs.d/harbor.local/
cp harbor.local.key /etc/docker/certs.d/harbor.local/
Эти сертификаты будут использоваться при обращении к registry по доменному имени harbor.local.
Скопируйте шаблон конфигурационного файла, который поставляется вместе с установщиком:
cp harbor.yml.tmpl harbor.yml
Измените в harbor.yml следующие параметры:
hostname— укажитеharbor.local(для него генерировались сертификаты);certificate— укажите путь к сгенерированному сертификату в директорииcerts(например,/home/ubuntu/harbor/certs/harbor.local.crt);private_key— укажите путь к приватному ключу (например,/home/ubuntu/harbor/certs/harbor.local.key);harbor_admin_password— задайте пароль для доступа в веб-интерфейс.
Сохраните файл.
Установите на сервер Bastion Docker и плагин Docker Compose.
Запустите скрипт установки:
./install.sh
Начнётся установка Harbor — будут подготовлены необходимые образы и запущены контейнеры.
Проверьте, что Harbor успешно запущен:
docker ps
Добавьте в файл /etc/hosts ассоциацию доменного имени harbor.local с localhost сервера Bastion, чтобы можно было обращаться к Harbor по этому имени с этого же сервера:
127.0.0.1 localhost harbor.local
В некоторых облачных провайдерах (например, Yandex Cloud) изменения в /etc/hosts могут быть сброшены после перезагрузки виртуальной машины. Сообщение об этом обычно указано в начале файла /etc/hosts.
# Your system has configured 'manage_etc_hosts' as True.
# As a result, if you wish for changes to this file to persist
# then you will need to either
# a.) make changes to the master file in /etc/cloud/templates/hosts.debian.tmpl
# b.) change or remove the value of 'manage_etc_hosts' in
# /etc/cloud/cloud.cfg or cloud-config from user-data
Если у вашего провайдера действует такая схема, внесите соответствующие изменения также в файл шаблона, указанный в комментарии, чтобы настройки сохранялись после перезагрузки.
На этом установка Harbor завершена! 🎉
Настройка Harbor
Создайте проект и пользователя, от имени которого будет выполняться работа с этим проектом.
Откройте веб-интерфейс Harbor по адресу harbor.local:

Чтобы открыть Harbor по доменному имени harbor.local с рабочего компьютера, добавьте соответствующую запись в файл /etc/hosts, указав IP-адрес сервера Bastion.
Для входа в интерфейс воспользуйтесь логином и паролем, указанными в конфигурационном файле harbor.yml.

Браузер может предупреждать о самоподписанном сертификате и считать соединение «небезопасным». Для закрытого окружения это ожидаемо и допустимо. При необходимости добавьте сертификат в хранилище доверенных сертификатов браузера или операционной системы, чтобы убрать предупреждения.
Создайте новый проект. Для этого нажмите на кнопку «Новый проект» и введите его название: deckhouse. Остальные настройки оставьте без изменений.

Создайте нового пользователя для этого проекта. Перейдите на вкладку «Пользователи» в левом меню и нажмите «Новый пользователь»:

Укажите имя пользователя, адрес электронной почты и пароль:

Добавьте созданного пользователя в проект deckhouse: перейдите в «Проекты», откройте проект deckhouse, затем вкладку «Участники» и нажмите «Пользователь», чтобы добавить участника.

Оставьте роль по умолчанию: «Администратор проекта».

На этом настройка Harbor завершена! 🎉
Копирование образов DKP в приватный container registry
Следующим шагом необходимо скопировать образы компонентов DKP из публичного registry Deckhouse Kubernetes Platform в Harbor.
Для дальнейших действий в этом разделе потребуется утилита Deckhouse CLI. Установите её на сервер Bastion согласно документации.
Загрузка образов занимает продолжительное время. Чтобы не потерять прогресс при разрыве SSH-соединения, запускайте команды в сессии tmux или screen. В случае обрыва соединения вы сможете переподключиться к сессии и продолжить работу, не начиная процесс заново. Обе утилиты обычно доступны в репозиториях дистрибутивов Linux и устанавливаются через пакетный менеджер.
Выполните команду, которая скачает все необходимые образы и упакует их в архив d8.tar. Укажите лицензионный ключ и редакцию DKP (например, se-plus — для Standard Edition+, ee — для Enterprise Edition и т.д.):
d8 mirror pull --source="registry.deckhouse.ru/deckhouse/<РЕДАКЦИЯ_DKP>" --license="<ЛИЦЕНЗИОННЫЙ КЛЮЧ>" $(pwd)/d8.tar
В зависимости от скорости интернет-соединения процесс может занять от 30 до 40 минут.
Проверьте, что архив создан:
$ ls -lh
total 650M
drwxr-xr-x 2 ubuntu ubuntu 4.0K Dec 11 15:08 d8.tar
Загрузите скачанные образы в приватный registry (укажите редакцию DKP и учётные данные пользователя, созданного в Harbor):
d8 mirror push $(pwd)/d8.tar 'harbor.local:443/deckhouse/<РЕДАКЦИЯ_DKP>' --registry-login='deckhouse' --registry-password='<PASSWORD>' --tls-skip-verify
Флаг
--tls-skip-verifyуказывает утилите доверять сертификату registry и пропустить его проверку.
Архив будет распакован, после чего образы будут загружены в registry. Этот этап обычно выполняется быстрее, чем скачивание, так как работа идёт с локальным архивом. Как правило, он занимает около 15 минут.
Проверить, что образы загружены, можно в веб-интерфейсе Harbor: откройте проект deckhouse в веб-интерфейсе Harbor.

Образы загружены и готовы к использованию! 🎉
Установка прокси-сервера
Чтобы серверы будущих узлов кластера, находящиеся в закрытом окружении, могли получить доступ к внешним репозиториям пакетов (для установки необходимых для работы DKP пакетов), разверните на сервере Bastion прокси-сервер, через который будет осуществляться этот доступ.
Можно использовать любой прокси-сервер, соответствующий вашим требованиям. В качестве примера воспользуемся Squid.
Разверните Squid на сервере Bastion в контейнере:
docker run -d --name squid -p 3128:3128 ubuntu/squid
Убедитесь, что контейнер запущен:
059b21fddbd2 ubuntu/squid "entrypoint.sh -f /e…" About a minute ago Up About a minute 0.0.0.0:3128->3128/tcp, [::]:3128->3128/tcp squid
В списке запущенных контейнеров должен быть контейнер с соответствующим именем (squid).
Вход в registry для запуска установщика
Войдите в registry Harbor, чтобы Docker смог загрузить из него образ установщика dhctl:
docker login harbor.local
Подготовка ВМ для будущих узлов
Требования к ВМ
Во время установки в качестве container runtime по умолчанию на узлах кластера используется ContainerdV2.
Для его работы узлы должны соответствовать следующим требованиям:
- поддержка
CgroupsV2; - systemd версии
244; - поддержка модуля ядра
erofs.
Некоторые дистрибутивы (например, Astra Linux 1.7.4) не соответствуют этим требованиям, и ОС на узлах необходимо привести в соответствие требованиям перед установкой Deckhouse Kubernetes Platform. Подробнее — в документации.
Серверы для будущих узлов кластера должны соответствовать следующим требованиям:
- не менее 4 ядер CPU;
- не менее 8 ГБ RAM;
- не менее 60 ГБ дискового пространства на быстром диске (400+ IOPS);
- поддерживаемая ОС;
- ядро Linux версии
5.8или новее; - уникальный hostname в пределах всех серверов кластера (физических серверов и виртуальных машин);
-
наличие одного из пакетных менеджеров (
apt/apt-get,yumилиrpm).Важно: в РЕД ОС по умолчанию могут отсутствовать
yumиwhich, поэтому их необходимо заранее установить; - установленный Python;
- доступ к проксирующему registry или к приватному хранилищу образов контейнеров с образами Deckhouse;
- доступ к стандартным для используемой ОС репозиториям пакетов (через прокси-сервер или до внутреннего сервера-репозитория пакетов);
- SSH-доступ от сервера Bastion по ключу;
- сетевой доступ от сервера Bastion по порту
22/TCP; - на узле не должно быть установлено пакетов container runtime, например containerd или Docker.
Для правильного выбора ресурсов серверов ознакомьтесь с рекомендациями по подготовке к production и инструкцией по выбору типов и количества узлов кластера, а также ресурсов для них, в зависимости от ваших требований к эксплуатации будущего кластера.
Настройка доступа к серверу Bastion
Чтобы серверы, на которых будут разворачиваться master и worker-узлы, могли получить доступ к созданному приватному registry, настройте на них соответствие доменного имени harbor.local внутреннему IP-адресу сервера Bastion в приватной сети.
Для этого по очереди подключитесь к каждому серверу и добавьте запись в /etc/hosts (а при необходимости также в облачный шаблон, если провайдер управляет этим файлом).
<INTERNAL-IP-ADDRESS> harbor.local proxy.local
Не забудьте заменить
<INTERNAL-IP-ADDRESS>на реальный внутренний IP-адрес сервера Bastion.
Создание пользователя для master-узла
Для выполнения установки DKP создайте на будущем master-узле пользователя, под которым будет выполняться подключение и установка платформы.
Выполните команды от root (подставьте публичную часть своего SSH-ключа):
useradd deckhouse -m -s /bin/bash -G sudo
echo 'deckhouse ALL=(ALL) NOPASSWD: ALL' | sudo EDITOR='tee -a' visudo
mkdir /home/deckhouse/.ssh
export KEY='ssh-rsa AAAAB3NzaC1yc2EAAAADA...'
echo $KEY >> /home/deckhouse/.ssh/authorized_keys
chown -R deckhouse:deckhouse /home/deckhouse
chmod 700 /home/deckhouse/.ssh
chmod 600 /home/deckhouse/.ssh/authorized_keys
В результате этих команд:
- создаётся новый пользователь
deckhouse, который добавляется в группуsudo; - настраиваются права на повышение привилегий без ввода пароля;
- копируется публичная часть ключа, по которому можно будет войти на сервер под этим пользователем.
Проверьте подключение под новым пользователем:
ssh -J ubuntu@<BASTION_IP> deckhouse@<NODE_IP>
Если вход выполнен успешно, пользователь создан корректно.
Подготовка конфигурационного файла
Конфигурационный файл для установки в закрытом окружении отличается от конфигурации для установки на bare-metal несколькими параметрами. Возьмите файл config.yml из четвёртого шага руководства по установке на bare-metal и внесите следующие изменения:
-
В секции
deckhouseблокаClusterConfigurationизмените параметры используемого container registry с публичного registry Deckhouse Kubernetes Platform на приватный:# Настройки proxy-сервера. proxy: httpProxy: http://proxy.local:3128 httpsProxy: https://proxy.local:3128 noProxy: ["harbor.local", "proxy.local", "10.128.0.8", "10.128.0.32", "10.128.0.18"]Здесь указываются следующие параметры:
- адреса HTTP и HTTPS прокси-сервера, развёрнутого на сервере Bastion;
- список доменов и IP-адресов, которые не будут проксироваться через прокси-сервер (внутренние доменные имена и внутренние IP-адреса всех серверов).
-
В секции
InitConfigurationдобавьте параметры доступа к registry:deckhouse: # Адрес Docker registry с образами Deckhouse (укажите редакцию DKP). imagesRepo: harbor.local/deckhouse/<РЕДАКЦИЯ_DKP> # Строка с ключом для доступа к Docker registry в формате Base64. # Получить их можно командой `cat .docker/config.json | base64`. registryDockerCfg: <DOCKER_CFG_BASE64> # Протокол доступа к registry (HTTP или HTTPS). registryScheme: HTTPS # Корневой сертификат, созданный ранее. # Получить его можно командой: `cat harbor/certs/ca.crt`. registryCA: | -----BEGIN CERTIFICATE----- ... -----END CERTIFICATE----- - В параметре releaseChannel ModuleConfig
deckhouseизмените наStableдля использования стабильного канала обновлений. -
В ModuleConfig global укажите использование самоподписанных сертификатов для компонентов кластера и укажите шаблон доменного имени для системных приложений в параметре
publicDomainTemplate:settings: modules: # Шаблон, который будет использоваться для составления адресов системных приложений в кластере. # Например, Grafana для %s.example.com будет доступна на домене 'grafana.example.com'. # Домен НЕ ДОЛЖЕН совпадать с указанным в параметре clusterDomain ресурса ClusterConfiguration. # Можете изменить на свой сразу, либо следовать шагам руководства и сменить его после установки. publicDomainTemplate: "%s.test.local" # Способ реализации протокола HTTPS, используемый модулями Deckhouse. https: certManager: # Использовать самоподписанные сертификаты для модулей Deckhouse. clusterIssuerName: selfsigned -
В ModuleConfig
user-authnизмените значение параметра dexCAMode наFromIngressSecret:settings: controlPlaneConfigurator: dexCAMode: FromIngressSecret -
Добавьте включение и конфигурацию модуля cert-manager, в которой будет отключено использование Let’s Encrypt:
apiVersion: deckhouse.io/v1alpha1 kind: ModuleConfig metadata: name: cert-manager spec: version: 1 enabled: true settings: disableLetsencrypt: true -
В параметре internalNetworkCIDRs StaticClusterConfiguration укажите подсеть внутренних IP-адресов узлов кластера. Например:
internalNetworkCIDRs: - 10.128.0.0/24
Конфигурационный файл для установки подготовлен.
Установка DKP
Перенесите подготовленный конфигурационный файл на сервер Bastion (например, в директорию ~/deckhouse). Перейдите в директорию и запустите установщик командой:
docker run --pull=always -it -v "$PWD/config.yml:/config.yml" -v "$HOME/.ssh/:/tmp/.ssh/" --network=host -v "$PWD/dhctl-tmp:/tmp/dhctl" harbor.local/deckhouse/<РЕДАКЦИЯ_DKP>/install:stable bash
Если во внутренней сети нет локального DNS-сервера, и доменные имена прописаны в /etc/hosts сервера Bastion, то обязательно укажите параметр --network=host, чтобы Docker смог ими воспользоваться.
После успешной загрузки и запуска контейнера вы увидите приглашение командной строки внутри контейнера:
[deckhouse] root@guide-bastion / #
Запустите установку DKP командой (укажите внутренний IP-адрес master-узла):
dhctl bootstrap --ssh-user=deckhouse --ssh-host=<master_ip> --ssh-agent-private-keys=/tmp/.ssh/id_rsa \
--config=/config.yml \
--ask-become-pass
Процесс установки может занять до 30 минут в зависимости от скорости сетевого соединения.
При успешном завершении установки вы увидите следующее сообщение:
┌ ⛵ ~ Bootstrap: Run post bootstrap actions
│ ┌ Set release channel to deckhouse module config
│ │ 🎉 Succeeded!
│ └ Set release channel to deckhouse module config (0.09 seconds)
└ ⛵ ~ Bootstrap: Run post bootstrap actions (0.09 seconds)
┌ ⛵ ~ Bootstrap: Clear cache
│ ❗ ~ Next run of "dhctl bootstrap" will create a new Kubernetes cluster.
└ ⛵ ~ Bootstrap: Clear cache (0.00 seconds)
🎉 Deckhouse cluster was created successfully!
Добавление узлов в кластер
Добавьте узел в кластер (подробнее о добавлении статического узла в кластер читайте в документации).
Для этого выполните следующие шаги:
-
Настройте StorageClass локального хранилища, выполнив на master-узле следующую команду:
sudo -i d8 k create -f - << EOF apiVersion: deckhouse.io/v1alpha1 kind: LocalPathProvisioner metadata: name: localpath spec: path: "/opt/local-path-provisioner" reclaimPolicy: Delete EOF -
Укажите, что созданный StorageClass должен использоваться как StorageClass по умолчанию. Для этого выполните на master-узле следующую команду:
sudo -i d8 k patch mc global --type merge \ -p "{\"spec\": {\"settings\":{\"defaultClusterStorageClass\":\"localpath\"}}}" -
Создайте NodeGroup
workerи добавьте узел с помощью Cluster API Provider Static (CAPS):sudo -i d8 k create -f - <<EOF apiVersion: deckhouse.io/v1 kind: NodeGroup metadata: name: worker spec: nodeType: Static staticInstances: count: 1 labelSelector: matchLabels: role: worker EOF -
Сгенерируйте SSH-ключ с пустой парольной фразой. Для этого выполните на master-узле следующую команду:
ssh-keygen -t rsa -f /dev/shm/caps-id -C "" -N "" -
Создайте в кластере ресурс SSHCredentials. Для этого выполните на master-узле следующую команду:
sudo -i d8 k create -f - <<EOF apiVersion: deckhouse.io/v1alpha2 kind: SSHCredentials metadata: name: caps spec: user: caps privateSSHKey: "`cat /dev/shm/caps-id | base64 -w0`" EOF -
Выведите публичную часть сгенерированного ранее SSH-ключа (он понадобится на следующем шаге). Для этого выполните на master-узле следующую команду:
cat /dev/shm/caps-id.pub -
На подготовленном сервере для worker-узла создайте пользователя
caps. Для этого выполните следующую команду, указав публичную часть SSH-ключа, полученную на предыдущем шаге:# Укажите публичную часть SSH-ключа пользователя. export KEY='<SSH-PUBLIC-KEY>' useradd -m -s /bin/bash caps usermod -aG sudo caps echo 'caps ALL=(ALL) NOPASSWD: ALL' | sudo EDITOR='tee -a' visudo mkdir /home/caps/.ssh echo $KEY >> /home/caps/.ssh/authorized_keys chown -R caps:caps /home/caps chmod 700 /home/caps/.ssh chmod 600 /home/caps/.ssh/authorized_keys
-
Создайте StaticInstance для добавляемого узла. Для этого выполните на master-узле следующую команду, указав IP-адрес добавляемого узла:
# Укажите IP-адрес узла, который нужно подключить к кластеру. export NODE=<NODE-IP-ADDRESS> sudo -i d8 k create -f - <<EOF apiVersion: deckhouse.io/v1alpha2 kind: StaticInstance metadata: name: d8cluster-worker labels: role: worker spec: address: "$NODE" credentialsRef: kind: SSHCredentials name: caps EOF -
Убедитесь, что все узлы кластера находятся в статусе
Ready:$ sudo -i d8 k get no NAME STATUS ROLES AGE VERSION d8cluster Ready control-plane,master 30m v1.23.17 d8cluster-worker Ready worker 10m v1.23.17Запуск всех компонентов DKP после завершения установки может занять некоторое время.
Настройка Ingress-контроллера и создание пользователя
Установка ingress-контроллера
Убедитесь, что под Kruise controller manager модуля ingress-nginx запустился и находится в статусе Running. Для этого выполните на master-узле следующую команду:
$ sudo -i d8 k -n d8-ingress-nginx get po -l app=kruise
NAME READY STATUS RESTARTS AGE
kruise-controller-manager-7dfcbdc549-b4wk7 3/3 Running 0 15m
Создайте на master-узле файл ingress-nginx-controller.yml, содержащий конфигурацию Ingress-контроллера:
# Секция, описывающая параметры NGINX Ingress controller.
# https://deckhouse.ru/modules/ingress-nginx/cr.html
apiVersion: deckhouse.io/v1
kind: IngressNginxController
metadata:
name: nginx
spec:
# Имя Ingress-класса для обслуживания NGINX Ingress controller.
ingressClass: nginx
# Способ поступления трафика из внешнего мира.
inlet: HostPort
hostPort:
httpPort: 80
httpsPort: 443
# Описывает, на каких узлах будет находиться компонент.
# Возможно, захотите изменить.
nodeSelector:
node-role.kubernetes.io/control-plane: ""
tolerations:
- effect: NoSchedule
key: node-role.kubernetes.io/control-plane
operator: Exists
Примените его, выполнив на master-узле следующую команду:
sudo -i d8 k create -f $PWD/ingress-nginx-controller.yml
Запуск Ingress-контроллера после завершения установки DKP может занять некоторое время. Прежде чем продолжить, убедитесь, что Ingress-контроллер запустился (выполните на master-узле):
$ sudo -i d8 k -n d8-ingress-nginx get po -l app=controller
NAME READY STATUS RESTARTS AGE
controller-nginx-r6hxc 3/3 Running 0 5m
Создание пользователя для доступа в веб-интерфейсы кластера
Создайте на master-узле файл user.yml, содержащий описание учётной записи пользователя и прав доступа:
# Настройки RBAC и авторизации.
# https://deckhouse.ru/modules/user-authz/cr.html#clusterauthorizationrule
apiVersion: deckhouse.io/v1
kind: ClusterAuthorizationRule
metadata:
name: admin
spec:
# Список учётных записей Kubernetes RBAC.
subjects:
- kind: User
name: admin@deckhouse.io
# Предустановленный шаблон уровня доступа.
accessLevel: SuperAdmin
# Разрешить пользователю делать kubectl port-forward.
portForwarding: true
---
# Данные статического пользователя.
# https://deckhouse.ru/modules/user-authn/cr.html#user
apiVersion: deckhouse.io/v1
kind: User
metadata:
name: admin
spec:
# E-mail пользователя.
email: admin@deckhouse.io
# Это хэш пароля 3xqgv2auys, сгенерированного сейчас.
# Сгенерируйте свой или используйте этот, но только для тестирования:
# echo -n '3xqgv2auys' | htpasswd -BinC 10 "" | cut -d: -f2 | tr -d '\n' | base64 -w0; echo
# Возможно, захотите изменить.
password: 'JDJhJDEwJGtsWERBY1lxMUVLQjVJVXoxVkNrSU8xVEI1a0xZYnJNWm16NmtOeng5VlI2RHBQZDZhbjJH'
Примените его, выполнив на master-узле следующую команду:
sudo -i d8 k create -f $PWD/user.yml
Настройка DNS-записей
Для доступа к веб-интерфейсам кластера настройте соответствие следующих доменных имён внутреннему IP-адресу master-узла (используйте DNS имена, в соответствии с шаблоном DNS-имен, указанным в параметре publicDomainTemplate). Пример для шаблона DNS-имён %s.example.com:
api.example.com
code.example.com
commander.example.com
console.example.com
dex.example.com
documentation.example.com
grafana.example.com
hubble.example.com
istio.example.com
istio-api-proxy.example.com
kubeconfig.example.com
openvpn-admin.example.com
prometheus.example.com
status.example.com
tools.example.com
upmeter.example.com
Сделать это можно как на внутреннем DNS-сервере, так и прописав на нужных компьютерах соответствие в /etc/hosts.
Проверить, что кластер корректно развёрнут и работает, можно в веб-интерфейсе Grafana, где отображается состояние кластера. Адрес Grafana формируется по шаблону publicDomainTemplate. Например, при значении %s.example.com интерфейс будет доступен по адресу grafana.example.com. Для входа используйте учётные данные пользователя, созданного ранее.