How do I find out all Deckhouse parameters?
| Как узнать все параметры Deckhouse?
|
Deckhouse is configured using global settings, module settings, and various custom resources. Read more in the documentation.
| Deckhouse настраивается с помощью глобальных настроек, настроек модулей и различных сustom resource’ов. Подробнее — в документации.
|
To view global Deckhouse settings:
| Вывести глобальные настройки:
|
shell
kubectl get mc global -o yaml
| shell
kubectl get mc global -o yaml
|
To list the status of all modules (available for Deckhouse version 1.47+):
| Вывести список состояния всех модулей (доступно для Deckhouse версии 1.47+):
|
shell
kubectl get modules
| shell
kubectl get modules
|
To get the user-authn module configuration:
| Вывести настройки модуля user-authn :
|
shell
kubectl get moduleconfigs user-authn -o yaml
| shell
kubectl get moduleconfigs user-authn -o yaml
|
How do I find the documentation for the version installed?
| Как найти документацию по установленной у меня версии?
|
The documentation for the Deckhouse version running in the cluster is available at documentation.<cluster_domain> , where <cluster_domain> is the DNS name that matches the template defined in the modules.publicDomainTemplate parameter.
| Документация запущенной в кластере версии Deckhouse доступна по адресу documentation.<cluster_domain> , где <cluster_domain> — DNS-имя в соответствии с шаблоном из параметра modules.publicDomainTemplate глобальной конфигурации.
|
Documentation is available when the documentation module is enabled. It is enabled by default except the Minimal bundle.
| Документация доступна, если в кластере включен модуль documentation. Он включен по умолчанию, кроме варианта поставки Minimal .
|
Deckhouse update
| Обновление Deckhouse
|
How to find out in which mode the cluster is being updated?
| Как понять, в каком режиме обновляется кластер?
|
You can view the cluster update mode in the configuration of the deckhouse module. To do this, run the following command:
| Посмотреть режим обновления кластера можно в конфигурации модуля deckhouse . Для этого выполните следующую команду:
|
shell
kubectl get mc deckhouse -oyaml
| shell
kubectl get mc deckhouse -oyaml
|
Example of the output:
| Пример вывода:
|
yaml
apiVersion: deckhouse.io/v1alpha1
kind: ModuleConfig
metadata:
creationTimestamp: “2022-12-14T11:13:03Z”
generation: 1
name: deckhouse
resourceVersion: “3258626079”
uid: c64a2532-af0d-496b-b4b7-eafb5d9a56ee
spec:
settings:
releaseChannel: Stable
update:
windows:
- days:
- Mon
from: “19:00”
to: “20:00”
version: 1
status:
state: Enabled
status: “”
type: Embedded
version: “1”
| yaml
apiVersion: deckhouse.io/v1alpha1
kind: ModuleConfig
metadata:
creationTimestamp: “2022-12-14T11:13:03Z”
generation: 1
name: deckhouse
resourceVersion: “3258626079”
uid: c64a2532-af0d-496b-b4b7-eafb5d9a56ee
spec:
settings:
releaseChannel: Stable
update:
windows:
- days:
- Mon
from: “19:00”
to: “20:00”
version: 1
status:
state: Enabled
status: “”
type: Embedded
version: “1”
|
There are three possible update modes:
- Automatic + update windows are not set. The cluster will be updated after the new version appears on the corresponding release channel.
- Automatic + update windows are set. The cluster will be updated in the nearest available window after the new version appears on the release channel.
- Manual. Manual action is required to apply the update.
| Существуют три возможных режима обновления:
- Автоматический + окна обновлений не заданы. Кластер обновится сразу после появления новой версии на соответствующем канале обновлений.
- Автоматический + заданы окна обновлений. Кластер обновится в ближайшее доступное окно после появления новой версии на канале обновлений.
- Ручной режим. Для применения обновления требуются ручные действия.
|
How do I set the desired release channel?
| Как установить желаемый канал обновлений?
|
Change (set) the releaseChannel parameter in the deckhouse module configuration to automatically switch to another release channel.
| Чтобы перейти на другой канал обновлений автоматически, нужно в конфигурации модуля deckhouse изменить (установить) параметр releaseChannel.
|
It will activate the mechanism of automatic stabilization of the release channel.
| В этом случае включится механизм автоматической стабилизации релизного канала.
|
Here is an example of the deckhouse module configuration with the Stable release channel:
| Пример конфигурации модуля deckhouse с установленным каналом обновлений Stable :
|
yaml
apiVersion: deckhouse.io/v1alpha1
kind: ModuleConfig
metadata:
name: deckhouse
spec:
version: 1
settings:
releaseChannel: Stable
| yaml
apiVersion: deckhouse.io/v1alpha1
kind: ModuleConfig
metadata:
name: deckhouse
spec:
version: 1
settings:
releaseChannel: Stable
|
How do I disable automatic updates?
| Как отключить автоматическое обновление?
|
To completely disable the Deckhouse update mechanism, remove the releaseChannel parameter in the deckhouse module configuration.
| Чтобы полностью отключить механизм обновления Deckhouse, удалите в конфигурации модуля deckhouse параметр releaseChannel.
|
In this case, Deckhouse does not check for updates and even doesn’t apply patch releases.
| В этом случае Deckhouse не проверяет обновления и даже обновление на patch-релизы не выполняется.
|
It is highly not recommended to disable automatic updates! It will block updates to patch releases that may contain critical vulnerabilities and bugs fixes.
| Крайне не рекомендуется отключать автоматическое обновление! Это заблокирует обновления на patch-релизы, которые могут содержать исправления критических уязвимостей и ошибок.
|
How do I apply an update without having to wait for the update window, canary-release and manual update mode?
| Как применить обновление минуя окна обновлений, canary-release и ручной режим обновлений?
|
To apply an update immediately, set the release.deckhouse.io/apply-now : "true" annotation on the DeckhouseRelease resource.
| Чтобы применить обновление немедленно, установите в соответствующем ресурсе DeckhouseRelease аннотацию release.deckhouse.io/apply-now: "true" .
|
Caution! In this case, the update windows, settings canary-release and manual cluster update mode will be ignored. The update will be applied immediately after the annotation is installed.
| Обратите внимание! В этом случае будут проигнорированы окна обновления, настройки canary-release и режим ручного обновления кластера. Обновление применится сразу после установки аннотации.
|
An example of a command to set the annotation to skip the update windows for version v1.56.2 :
| Пример команды установки аннотации пропуска окон обновлений для версии v1.56.2 :
|
shell
kubectl annotate deckhousereleases v1.56.2 release.deckhouse.io/apply-now=”true”
| shell
kubectl annotate deckhousereleases v1.56.2 release.deckhouse.io/apply-now=”true”
|
An example of a resource with the update window skipping annotation in place:
| Пример ресурса с установленной аннотацией пропуска окон обновлений:
|
yaml
apiVersion: deckhouse.io/v1alpha1
kind: DeckhouseRelease
metadata:
annotations:
release.deckhouse.io/apply-now: “true”
…
| yaml
apiVersion: deckhouse.io/v1alpha1
kind: DeckhouseRelease
metadata:
annotations:
release.deckhouse.io/apply-now: “true”
…
|
How to understand what changes the update contains and how it will affect the cluster?
| Как понять, какие изменения содержит обновление и как это повлияет на работу кластера?
|
You can find all the information about Deckhouse versions in the list of Deckhouse releases.
| Информацию о всех версиях Deckhouse можно найти в списке релизов Deckhouse.
|
Summary information about important changes, component version updates, and which components in the cluster will be restarted during the update process can be found in the description of the zero patch version of the release. For example, v1.46.0 for the v1.46 Deckhouse release.
| Сводную информацию о важных изменениях, об обновлении версий компонентов, а также о том, какие компоненты в кластере буду перезапущены в процессе обновления, можно найти в описании нулевой patch-версии релиза. Например, v1.46.0 для релиза v1.46 Deckhouse.
|
A detailed list of changes can be found in the Changelog, which is referenced in each release.
| Подробный список изменений можно найти в Changelog, ссылка на который есть в каждом релизе.
|
How do I understand that the cluster is being updated?
| Как понять, что в кластере идет обновление?
|
During the update:
- The
DeckhouseUpdating alert is firing.
- The
deckhouse Pod is not the Ready status. If the Pod does not go to the Ready status for a long time, then this may indicate that there are problems in the work of Deckhouse. Diagnosis is necessary.
| Во время обновления:
- горит алерт
DeckhouseUpdating ;
- под
deckhouse не в статусе Ready . Если под долго не переходит в статус Ready , это может говорить о наличии проблем в работе Deckhouse. Необходима диагностика.
|
How do I know that the update was successful?
| Как понять, что обновление прошло успешно?
|
If the DeckhouseUpdating alert is resolved, then the update is complete.
| Если алерт DeckhouseUpdating погас, значит, обновление завершено.
|
You can also check the status of Deckhouse releases.
| Вы также можете проверить состояние релизов Deckhouse.
|
An example:
| Пример:
|
console
$ kubectl get deckhouserelease
NAME PHASE TRANSITIONTIME MESSAGE
v1.46.8 Superseded 13d
v1.46.9 Superseded 11d
v1.47.0 Superseded 4h12m
v1.47.1 Deployed 4h12m
| console
$ kubectl get deckhouserelease
NAME PHASE TRANSITIONTIME MESSAGE
v1.46.8 Superseded 13d
v1.46.9 Superseded 11d
v1.47.0 Superseded 4h12m
v1.47.1 Deployed 4h12m
|
The Deployed status of the corresponding version indicates that the switch to the corresponding version was performed (but this does not mean that it ended successfully).
| Статус Deployed у соответствующей версии говорит о том, что переключение на соответствующую версию было выполнено (но это не значит, что оно закончилось успешно).
|
Check the status of the Deckhouse Pod:
| Проверьте состояние пода Deckhouse:
|
shell
$ kubectl -n d8-system get pods -l app=deckhouse
NAME READY STATUS RESTARTS AGE
deckhouse-7844b47bcd-qtbx9 1/1 Running 0 1d
| shell
$ kubectl -n d8-system get pods -l app=deckhouse
NAME READY STATUS RESTARTS AGE
deckhouse-7844b47bcd-qtbx9 1/1 Running 0 1d
|
- If the status of the Pod is
Running , and 1/1 indicated in the READY column, the update was completed successfully.
- If the status of the Pod is
Running , and 0/1 indicated in the READY column, the update is not over yet. If this goes on for more than 20-30 minutes, then this may indicate that there are problems in the work of Deckhouse. Diagnosis is necessary.
- If the status of the Pod is not
Running , then this may indicate that there are problems in the work of Deckhouse. Diagnosis is necessary.
|
- Если статус пода
Running и в колонке READY указано 1/1 — обновление закончилось успешно.
- Если статус пода
Running и в колонке READY указано 0/1 — обновление еще не закончилось. Если это продолжается более 20–30 минут, это может говорить о наличии проблем в работе Deckhouse. Необходима диагностика.
- Если статус пода не
Running , это может говорить о наличии проблем в работе Deckhouse. Необходима диагностика.
|
Possible options for action if something went wrong:
- Check Deckhouse logs using the following command:
| Возможные варианты действий, если что-то пошло не так:
- Проверьте логи, используя следующую команду:
|
shell
kubectl -n d8-system logs -f -l app=deckhouse | jq -Rr ‘fromjson? | .msg’
| shell
kubectl -n d8-system logs -f -l app=deckhouse | jq -Rr ‘fromjson? | .msg’
|
|
|
How do I know that a new version is available for the cluster?
| Как узнать, что для кластера доступна новая версия?
|
As soon as a new version of Deckhouse appears on the release channel installed in the cluster:
- The alert
DeckhouseReleaseIsWaitingManualApproval fires, if the cluster uses manual update mode (the update.mode parameter is set to Manual ).
- There is a new custom resource DeckhouseRelease. Use the
kubectl get deckhousereleases command, to view the list of releases. If the DeckhouseRelease is in the Pending state, the specified version has not yet been installed. Possible reasons why DeckhouseRelease may be in Pending :
- Manual update mode is set (the update.mode parameter is set to
Manual ).
- The automatic update mode is set, and the update windows are configured, the interval of which has not yet come.
- The automatic update mode is set, update windows are not configured, but the installation of the version has been postponed for a random time due to the mechanism of reducing the load on the repository of container images. There will be a corresponding message in the
status.message field of the DeckhouseRelease resource.
- The update.notification.minimalNotificationTime parameter is set, and the specified time has not passed yet.
| Как только на установленном в кластере канале обновления появляется новая версия Deckhouse:
- Загорается алерт
DeckhouseReleaseIsWaitingManualApproval , если кластер использует ручной режим обновлений (параметр update.mode установлен в Manual ).
- Появляется новый custom resource DeckhouseRelease. Используйте команду
kubectl get deckhousereleases , чтобы посмотреть список релизов. Если DeckhouseRelease новой версии находится в состоянии Pending , указанная версия еще не установлена. Возможные причины, при которых DeckhouseRelease может находиться в Pending :
- Установлен ручной режим обновлений (параметр update.mode установлен в
Manual ).
- Установлен автоматический режим обновлений и настроены окна обновлений, интервал которых еще не наступил.
- Установлен автоматический режим обновлений, окна обновлений не настроены, но применение версии отложено на случайный период времени из-за механизма снижения нагрузки на репозиторий образов контейнеров. В поле
status.message ресурса DeckhouseRelease будет соответствующее сообщение.
- Установлен параметр update.notification.minimalNotificationTime и указанное в нем время еще не прошло.
|
| Как заранее получать информацию о предстоящем обновлении?
|
You can get information in advance about updating minor versions of Deckhouse on the release channel in the following ways:
- Configure manual update mode. In this case, when a new version appears on the release channel, the alert
DeckhouseReleaseIsWaitingManualApproval will fire and a new custom resource DeckhouseRelease will appear in the cluster.
- Configure automatic update mode and specify the minimum time in the minimalNotificationTime parameter for which the update will be postponed. In this case, when a new version appears on the release channel, a new custom resource DeckhouseRelease will appear in the cluster. And if you specify a URL in the update.notification.webhook parameter, then the webhook will be called additionally.
| Получать заранее информацию об обновлении минорных версий Deckhouse на канале обновлений можно следующими способами:
- Настроить ручной режим обновлений. В этом случае при появлении новой версии на канале обновлений загорится алерт
DeckhouseReleaseIsWaitingManualApproval и в кластере появится новый custom resource DeckhouseRelease.
- Настроить автоматический режим обновлений и указать минимальное время в параметре minimalNotificationTime, на которое будет отложено обновление. В этом случае при появлении новой версии на канале обновлений в кластере появится новый custom resource DeckhouseRelease. А если указать URL в параметре update.notification.webhook, дополнительно произойдет вызов webhook’а.
|
How do I find out which version of Deckhouse is on which release channel?
| Как узнать, какая версия Deckhouse находится на каком канале обновлений?
|
Information about which version of Deckhouse is on which release channel can be obtained at https://releases.deckhouse.io.
| Информацию о том, какая версия Deckhouse находится на каком канале обновлений, можно получить на https://releases.deckhouse.io.
|
How does automatic Deckhouse update work?
| Как работает автоматическое обновление Deckhouse?
|
Every minute Deckhouse checks a new release appeared in the release channel specified by the releaseChannel parameter.
| При указании в конфигурации модуля deckhouse параметра releaseChannel Deckhouse будет каждую минуту проверять данные о релизе на канале обновлений.
|
When a new release appears on the release channel, Deckhouse downloads it and creates CustomResource DeckhouseRelease.
| При появлении нового релиза Deckhouse скачивает его в кластер и создает custom resource DeckhouseRelease.
|
After creating a DeckhouseRelease custom resource in a cluster, Deckhouse updates the deckhouse Deployment and sets the image tag to a specified release tag according to selected update mode and update windows (automatic at any time by default).
| После появления custom resource’а DeckhouseRelease в кластере Deckhouse выполняет обновление на соответствующую версию согласно установленным параметрам обновления (по умолчанию — автоматически, в любое время).
|
To get list and status of all releases use the following command:
| Чтобы посмотреть список и состояние всех релизов, воспользуйтесь командной:
|
shell
kubectl get deckhousereleases
| shell
kubectl get deckhousereleases
|
Patch releases (e.g., an update from version 1.30.1 to version 1.30.2 ) ignore update windows settings and apply as soon as they are available.
| Patch-релизы (например, обновление на версию 1.30.2 при установленной версии 1.30.1 ) устанавливаются без учета режима и окон обновления, то есть при появлении на канале обновления patch-релиза он всегда будет установлен.
|
What happens when the release channel changes?
| Что происходит при смене канала обновлений?
|
- When switching to a more stable release channel (e.g., from
Alpha to EarlyAccess ), Deckhouse downloads release data from the release channel (the EarlyAccess release channel in the example) and compares it with the existing DeckhouseReleases :
- Deckhouse deletes later releases (by semver) that have not yet been applied (with the
Pending status).
- if the latest releases have been already Deployed, then Deckhouse will hold the current release until a later release appears on the release channel (on the
EarlyAccess release channel in the example).
- When switching to a less stable release channel (e.g., from
EarlyAcess to Alpha ), the following actions take place:
- Deckhouse downloads release data from the release channel (the
Alpha release channel in the example) and compares it with the existing DeckhouseReleases .
- Then Deckhouse performs the update according to the update parameters.
|
- При смене канала обновлений на более стабильный (например, с
Alpha на EarlyAccess ) Deckhouse скачивает данные о релизе (в примере — из канала EarlyAccess ) и сравнивает их с данными из существующих в кластере custom resource’ов DeckhouseRelease :
- Более поздние релизы, которые еще не были применены (в статусе
Pending ), удаляются.
- Если более поздние релизы уже применены (в статусе
Deployed ), смены релиза не происходит. В этом случае Deckhouse останется на таком релизе до тех пор, пока на канале обновлений EarlyAccess не появится более поздний релиз.
- При смене канала обновлений на менее стабильный (например, с
EarlyAcess на Alpha ):
- Deckhouse скачивает данные о релизе (в примере — из канала
Alpha ) и сравнивает их с данными из существующих в кластере custom resource’ов DeckhouseRelease .
- Затем Deckhouse выполняет обновление согласно установленным параметрам обновления.
|
![The scheme of using the releaseChannel parameter during Deckhouse installation and operation](images/common/deckhouse-update-process.png)
| ![Схема использования параметра releaseChannel при установке и в процессе работы Deckhouse](images/common/deckhouse-update-process.png)
|
How to check the job queue in Deckhouse?
| Что делать, если Deckhouse не получает обновлений из канала обновлений?
|
To view the status of all Deckhouse job queues, run the following command:
|
- Проверьте, что настроен нужный канал обновлений.
- Проверьте корректность разрешения DNS-имени хранилища образов Deckhouse.
|
shell
kubectl -n d8-system exec -it svc/deckhouse-leader -c deckhouse – deckhouse-controller queue list
| Получите и сравните IP-адреса хранилища образов Deckhouse (registry.deckhouse.ru ) на одном из узлов и в поде Deckhouse. Они должны совпадать.
|
Example of output (queues are empty):
| Пример получения IP-адреса хранилища образов Deckhouse на узле:
|
console
$ kubectl -n d8-system exec -it svc/deckhouse-leader -c deckhouse – deckhouse-controller queue list
Summary:
- ‘main’ queue: empty.
- 88 other queues (0 active, 88 empty): 0 tasks.
- no tasks to handle.
| shell
$ getent ahosts registry.deckhouse.ru
185.193.90.38 STREAM registry.deckhouse.ru
185.193.90.38 DGRAM
185.193.90.38 RAW
|
To view the status of the main Deckhouse task queue, run the following command:
| Пример получения IP-адреса хранилища образов Deckhouse в поде Deckhouse:
|
shell
kubectl -n d8-system exec -it svc/deckhouse-leader -c deckhouse – deckhouse-controller queue main
| shell
$ kubectl -n d8-system exec -ti svc/deckhouse-leader -c deckhouse – getent ahosts registry.deckhouse.ru
185.193.90.38 STREAM registry.deckhouse.ru
185.193.90.38 DGRAM registry.deckhouse.ru
|
Example of output (38 tasks in the main queue):
| Если полученные IP-адреса не совпадают, проверьте настройки DNS на узле. В частности, обратите внимание на список доменов в параметре search файла /etc/resolv.conf (он влияет на разрешение имен в поде Deckhouse). Если в параметре search файла /etc/resolv.conf указан домен, в котором настроено разрешение wildcard-записей, это может привести к неверному разрешению IP-адреса хранилища образов Deckhouse (см. пример).
|
console
$ kubectl -n d8-system exec -it svc/deckhouse-leader -c deckhouse – deckhouse-controller queue main
Queue ‘main’: length 38, status: ‘run first task’
|
|
Example of output (the main queue is empty):
| Далее описан пример, когда настройки DNS приводят к различному результату при разрешении имен на узле и в поде Kubernetes:
- Пример файла
/etc/resolv.conf на узле:
|
console
$ kubectl -n d8-system exec -it svc/deckhouse-leader -c deckhouse – deckhouse-controller queue main
Queue ‘main’: length 0, status: ‘waiting for task 0s’
| text
nameserver 10.0.0.10
search company.my
|
What do I do if Deckhouse fails to retrieve updates from the release channel?
|
Обратите внимание, что по умолчанию на узле параметр ndot равен 1 (options ndots:1 ). Но в подах Kubernetes параметр ndot равен 5. Таким образом, логика разрешения DNS-имен, имеющих в имени 5 точек и менее, различается на узле и в поде.
|
- Make sure that the desired release channel is configured.
- Make sure that the DNS name of the Deckhouse container registry is resolved correctly.
|
- В DNS-зоне
company.my настроено разрешение wildcard-записей *.company.my в адрес 10.0.0.100 . То есть любое DNS-имя в зоне company.my , для которого нет конкретной записи в DNS, разрешается в адрес 10.0.0.100 .
|
Retrieve and compare the IP addresses of the Deckhouse container registry (registry.deckhouse.io ) on one of the nodes and in the Deckhouse pod. They should match.
| Тогда с учетом параметра search , указанного в файле /etc/resolv.conf , при обращении на адрес registry.deckhouse.ru на узле система попробует получить IP-адрес для имени registry.deckhouse.ru (так как считает его полностью определенным, учитывая настройку по умолчанию параметра options ndots:1 ).
|
Here is how you can retrieve the IP address of the Deckhouse container registry on a node:
| При обращении же на адрес registry.deckhouse.ru из пода Kubernetes, учитывая параметры options ndots:5 (используется в Kubernetes по умолчанию) и search , система первоначально попробует получить IP-адрес для имени registry.deckhouse.ru.company.my . Имя registry.deckhouse.ru.company.my разрешится в IP-адрес 10.0.0.100 , так как в DNS-зоне company.my настроено разрешение wildcard-записей *.company.my в адрес 10.0.0.100 . В результате к хосту registry.deckhouse.ru будет невозможно подключиться и скачать информацию о доступных обновлениях Deckhouse.
|
shell
$ getent ahosts registry.deckhouse.io
46.4.145.194 STREAM registry.deckhouse.io
46.4.145.194 DGRAM
46.4.145.194 RAW
| Как проверить очередь заданий в Deckhouse?
|
Here is how you can retrieve the IP address of the Deckhouse container registry in a pod:
| Для просмотра состояния всех очередей заданий Deckhouse, выполните следующую команду:
|
shell
$ kubectl -n d8-system exec -ti svc/deckhouse-leader -c deckhouse – getent ahosts registry.deckhouse.io
46.4.145.194 STREAM registry.deckhouse.io
46.4.145.194 DGRAM registry.deckhouse.io
| shell
kubectl -n d8-system exec -it svc/deckhouse-leader -c deckhouse – deckhouse-controller queue list
|
If the retrieved IP addresses do not match, inspect the DNS settings on the host. Specifically, check the list of domains in the search parameter of the /etc/resolv.conf file (it affects name resolution in the Deckhouse pod). If the search parameter of the /etc/resolv.conf file includes a domain where wildcard record resolution is configured, it may result in incorrect resolution of the IP address of the Deckhouse container registry (see example).
| Пример вывода (очереди пусты):
|
| console
$ kubectl -n d8-system exec -it svc/deckhouse-leader -c deckhouse – deckhouse-controller queue list
Summary:
- ‘main’ queue: empty.
- 88 other queues (0 active, 88 empty): 0 tasks.
- no tasks to handle.
|
In the example below, DNS settings produce different results when resolving names on the host and in the Kubernetes pod:
- The
/etc/resolv.conf file on the node:
| Для просмотра состояния очереди заданий main Deckhouse, выполните следующую команду:
|
text
nameserver 10.0.0.10
search company.my
| shell
kubectl -n d8-system exec -it svc/deckhouse-leader -c deckhouse – deckhouse-controller queue main
|
Note that the ndot parameter defaults to 1 (options ndots:1 ) on the node. But in Kubernetes pods, the ndot parameter is set to 5.
Therefore, the logic for resolving DNS names with 5 dots or less in the name is different on the host and in the pod.
| Пример вывода (в очереди main 38 заданий):
|
- The
company.my DNS zone is configured to resolve wildcard records *.company.my to 10.0.0.100 . That is, any DNS name in the company.my zone for which there is no specific DNS entry is resolved to 10.0.0.100 .
| console
$ kubectl -n d8-system exec -it svc/deckhouse-leader -c deckhouse – deckhouse-controller queue main
Queue ‘main’: length 38, status: ‘run first task’
|
In this case, subject to the search parameter specified in the /etc/resolv.conf file, when accessing the registry.deckhouse.io address on the node, the system will try to obtain the IP address for the registry.deckhouse.io name (it treats it as a fully qualified name given the default setting of options ndots:1 ).
| Пример вывода (очередь main пуста):
|
On the other hand, when accessing registry.deckhouse.io from a Kubernetes pod, given the options ndots:5 parameter (the default one in Kubernetes) and the search parameter, the system will initially try to resolve the IP address for the registry.deckhouse.io.company.my name. The registry.deckhouse.io.company.my name will be resolved to 10.0.0.100 because the company.my DNS zone is configured to resolve wildcard records *.company.my to 10.0.0.100 . As a result, the registry.deckhouse.io host and information about the available Deckhouse updates will be unreachable.
| console
$ kubectl -n d8-system exec -it svc/deckhouse-leader -c deckhouse – deckhouse-controller queue main
Queue ‘main’: length 0, status: ‘waiting for task 0s’
|
| Закрытое окружение, работа через proxy и сторонние registry
|
Air-gapped environment; working via proxy and third-party registry
| Как установить Deckhouse из стороннего registry?
|
| Доступно только в Enterprise Edition.
|
This feature is available in Enterprise Edition only.
| Deckhouse поддерживает работу только с Bearer token-схемой авторизации в container registry.
|
Deckhouse only supports Bearer authentication for container registries.
| Протестирована и гарантируется работа со следующими container registry:
{{- registry[1].shortname }}
,
.
|
Tested and guaranteed to work with the following container registries:
{{- registry[1].shortname }}
,
.
| При установке Deckhouse можно настроить на работу со сторонним registry (например, проксирующий registry внутри закрытого контура).
|
Deckhouse can be configured to work with a third-party registry (e.g., a proxy registry inside private environments).
| Установите следующие параметры в ресурсе InitConfiguration :
|
Define the following parameters in the InitConfiguration resource:
|
imagesRepo: <PROXY_REGISTRY>/<DECKHOUSE_REPO_PATH>/ee — адрес образа Deckhouse EE в стороннем registry. Пример: imagesRepo: registry.deckhouse.ru/deckhouse/ee ;
registryDockerCfg: <BASE64> — права доступа к стороннему registry, зашифрованные в Base64.
|
imagesRepo: <PROXY_REGISTRY>/<DECKHOUSE_REPO_PATH>/ee . The path to the Deckhouse EE image in the third-party registry, for example imagesRepo: registry.deckhouse.io/deckhouse/ee ;
registryDockerCfg: <BASE64> . Base64-encoded auth credentials of the third-party registry.
| Если разрешен анонимный доступ к образам Deckhouse в стороннем registry, registryDockerCfg должен выглядеть следующим образом:
|
Use the following registryDockerCfg if anonymous access to Deckhouse images is allowed in the third-party registry:
| json
{“auths”: { “": {}}}
|
json
{“auths”: { “": {}}}
| Приведенное значение должно быть закодировано в Base64.
|
registryDockerCfg must be Base64-encoded.
| Если для доступа к образам Deckhouse в стороннем registry необходима аутентификация, registryDockerCfg должен выглядеть следующим образом:
|
Use the following registryDockerCfg if authentication is required to access Deckhouse images in the third-party registry:
| json
{“auths”: { “": {"username":"","password":"","auth":""}}}
|
json
{“auths”: { “": {"username":"","password":"","auth":""}}}
| где:
|
<PROXY_USERNAME> — auth username for <PROXY_REGISTRY> .
<PROXY_PASSWORD> — auth password for <PROXY_REGISTRY> .
<PROXY_REGISTRY> — registry address: <HOSTNAME>[:PORT] .
<AUTH_BASE64> — Base64-encoded <PROXY_USERNAME>:<PROXY_PASSWORD> auth string.
|
<PROXY_USERNAME> — имя пользователя для аутентификации на <PROXY_REGISTRY> ;
<PROXY_PASSWORD> — пароль пользователя для аутентификации на <PROXY_REGISTRY> ;
<PROXY_REGISTRY> — адрес стороннего registry в виде <HOSTNAME>[:PORT] ;
<AUTH_BASE64> — строка вида <PROXY_USERNAME>:<PROXY_PASSWORD> , закодированная в Base64.
|
registryDockerCfg must be Base64-encoded.
| Итоговое значение для registryDockerCfg должно быть также закодировано в Base64.
|
The InitConfiguration resource provides two more parameters for non-standard third-party registry configurations:
| Для настройки нестандартных конфигураций сторонних registry в ресурсе InitConfiguration предусмотрены еще два параметра:
|
registryCA - root CA certificate to validate the third-party registry’s HTTPS certificate (if self-signed certificates are used);
registryScheme - registry scheme (HTTP or HTTPS ). The default value is HTTPS .
|
registryCA — корневой сертификат, которым можно проверить сертификат registry (если registry использует самоподписанные сертификаты);
registryScheme — протокол доступа к registry (HTTP или HTTPS ). По умолчанию — HTTPS .
|
|
|
Tips for configuring Nexus
| Особенности настройки Nexus
|
When interacting with a docker repository located in Nexus (e. g. executing docker pull , docker push commands), you must specify the address in the <NEXUS_URL>:<REPOSITORY_PORT>/<PATH> format.
| При взаимодействии с репозиторием типа docker расположенным в Nexus (например, при выполнении команд docker pull , docker push ) требуется указывать адрес в формате <NEXUS_URL>:<REPOSITORY_PORT>/<PATH> .
|
Using the URL value from the Nexus repository options is not acceptable
| Использование значения URL из параметров репозитория Nexus недопустимо
|
The following requirements must be met if the Nexus repository manager is used:
| При использовании менеджера репозиториев Nexus должны быть выполнены следующие требования:
|
Docker Bearer Token Realm must be enabled (Administration -> Security -> Realms).
- Docker proxy repository must be pre-created (Administration -> Repository -> Repositories):
Allow anonymous docker pull must be enabled. This option enables Bearer token authentication to work. Note that anonymous access won’t work unless explicitly enabled in Administration -> Security -> Anonymous Access, and the anonymous user is not granted access rights to the created repository.
Maximum metadata age for the created repository must be set to 0 .
- Access control must be configured as follows:
- The Nexus role must be created (Administration -> Security -> Roles) with the following permissions:
nx-repository-view-docker-<repo>-browse
nx-repository-view-docker-<repo>-read
- The user (Administration -> Security -> Users) must be created with the above role granted.
|
- Включен
Docker Bearer Token Realm (Administration -> Security -> Realms).
- Создан проксирующий репозиторий Docker (Administration -> Repository -> Repositories):
- Параметр
Allow anonymous docker pull для репозитория должен быть включен. Данный параметр включает поддержку авторизации с помощью Bearer-токенов, при этом анонимный доступ не будет работать, если он не был явно включен в Administration -> Security -> Anonymous Access и пользователю anonymous не были даны права на доступ к репозиторию.
- Параметр
Maximum metadata age для репозитория должен быть установлен в 0 .
- Должен быть настроен контроль доступа:
- Создана роль Nexus (Administration -> Security -> Roles) со следующими полномочиями:
nx-repository-view-docker-<репозиторий>-browse
nx-repository-view-docker-<репозиторий>-read
- Создан пользователь (Administration -> Security -> Users) с ролью, созданной выше.
|
Configuration:
| Настройка:
|
- Enable
Docker Bearer Token Realm (Administration -> Security -> Realms):
![Enable `Docker Bearer Token Realm`](images/registry/nexus/nexus-realm.png)
|
- Включите
Docker Bearer Token Realm (Administration -> Security -> Realms):
![Включение `Docker Bearer Token Realm`](images/registry/nexus/nexus-realm.png)
|
- Create a docker proxy repository (Administration -> Repository -> Repositories) pointing to the Deckhouse registry:
![Create docker proxy repository](images/registry/nexus/nexus-repository.png)
|
- Создайте проксирующий репозиторий Docker (Administration -> Repository -> Repositories), указывающий на Deckhouse registry:
![Создание проксирующего репозитория Docker](images/registry/nexus/nexus-repository.png)
|
- Fill in the fields on the Create page as follows:
Name must contain the name of the repository you created earlier, e.g., d8-proxy .
Repository Connectors / HTTP or Repository Connectors / HTTPS must contain a dedicated port for the created repository, e.g., 8123 or other.
Allow anonymous docker pull must be enabled for the Bearer token authentication to work. Note that anonymous access won’t work unless explicitly enabled in Administration -> Security -> Anonymous Access and the anonymous user is not granted access rights to the created repository.
Remote storage must be set to https://registry.deckhouse.io/ .
- You can disable
Auto blocking enabled and Not found cache enabled for debugging purposes, otherwise they must be enabled.
Maximum Metadata Age must be set to 0 .
Authentication must be enabled if you plan to use Deckhouse Enterprise Edition and the related fields must be set as follows:
Authentication Type must be set to Username .
Username must be set to license-token .
Password must contain your license key for Deckhouse Enterprise Edition.
|
- Заполните поля страницы создания репозитория следующим образом:
Name должно содержать имя создаваемого репозитория, например d8-proxy .
Repository Connectors / HTTP или Repository Connectors / HTTPS должно содержать выделенный порт для создаваемого репозитория, например 8123 или иной.
Allow anonymous docker pull должно быть включено, чтобы работала авторизация с помощью Bearer-токенов. При этом анонимный доступ не будет работать, если он не был явно включен в Administration -> Security -> Anonymous Access и пользователю anonymous не были даны права на доступ к репозиторию.
Remote storage должно иметь значение https://registry.deckhouse.ru/ .
Auto blocking enabled и Not found cache enabled могут быть выключены для отладки; в противном случае их следует включить.
Maximum Metadata Age должно быть равно 0 .
- Если планируется использовать Deckhouse Enterprise Edition, флажок
Authentication должен быть включен, а связанные поля должны быть заполнены следующим образом:
Authentication Type должно иметь значение Username .
Username должно иметь значение license-token .
Password должно содержать ключ лицензии Deckhouse Enterprise Edition.
|
![Repository settings example 3](images/registry/nexus/nexus-repo-example-3.png)
|
![Пример настроек репозитория 3](images/registry/nexus/nexus-repo-example-3.png)
|
- Configure Nexus access control to allow Nexus access to the created repository:
- Create a Nexus role (Administration -> Security -> Roles) with the
nx-repository-view-docker-<repo>-browse and nx-repository-view-docker-<repo>-read permissions.
|
- Настройте контроль доступа Nexus для доступа Deckhouse к созданному репозиторию:
- Создайте роль Nexus (Administration -> Security -> Roles) с полномочиями
nx-repository-view-docker-<репозиторий>-browse и nx-repository-view-docker-<репозиторий>-read .
|
![Create a Nexus role](images/registry/nexus/nexus-role.png)
| ![Создание роли Nexus](images/registry/nexus/nexus-role.png)
|
- Create a user with the role above granted.
|
- Создайте пользователя (Administration -> Security -> Users) с ролью, созданной выше.
|
![Create a Nexus user](images/registry/nexus/nexus-user.png)
| ![Создание пользователя Nexus](images/registry/nexus/nexus-user.png)
|
Thus, Deckhouse images will be available at https://<NEXUS_HOST>:<REPOSITORY_PORT>/deckhouse/ee:<d8s-version> .
| В результате образы Deckhouse будут доступны, например, по следующему адресу: https://<NEXUS_HOST>:<REPOSITORY_PORT>/deckhouse/ee:<d8s-version> .
|
Tips for configuring Harbor
| Особенности настройки Harbor
|
You need to use the Proxy Cache feature of a Harbor.
| Необходимо использовать такой функционал Harbor, как Proxy Cache.
|
- Create a Registry:
Administration -> Registries -> New Endpoint .
Provider : Docker Registry .
Name — specify any of your choice.
Endpoint URL : https://registry.deckhouse.io .
- Specify the
Access ID and Access Secret for Deckhouse Enterprise Edition.
|
- Настройте Registry:
Administration -> Registries -> New Endpoint .
Provider : Docker Registry .
Name — укажите любое, на ваше усмотрение.
Endpoint URL : https://registry.deckhouse.ru .
- Укажите
Access ID и Access Secret для Deckhouse Enterprise Edition.
|
![Create a Registry](images/registry/harbor/harbor1.png)
| ![Настройка Registry](images/registry/harbor/harbor1.png)
|
- Create a new Project:
Projects -> New Project .
Project Name will be used in the URL. You can choose any name, for example, d8s .
Access Level : Public .
Proxy Cache — enable and choose the Registry, created in the previous step.
|
- Создайте новый проект:
Projects -> New Project .
Project Name будет частью URL. Используйте любой, например, d8s .
Access Level : Public .
Proxy Cache — включите и выберите в списке Registry, созданный на предыдущем шаге.
|
![Create a new Project](images/registry/harbor/harbor2.png)
| ![Создание нового проекта](images/registry/harbor/harbor2.png)
|
Thus, Deckhouse images will be available at https://your-harbor.com/d8s/deckhouse/ee:{d8s-version} .
| В результате образы Deckhouse будут доступны, например, по следующему адресу: https://your-harbor.com/d8s/deckhouse/ee:{d8s-version} .
|
Manually uploading images to an air-gapped registry
| Ручная загрузка образов в изолированный приватный registry
|
This feature is only available in Standard Edition (SE), Enterprise Edition (EE), and Certified Security Edition (CSE).
| Доступно только в Standard Edition (SE), Enterprise Edition (EE) и Certified Security Edition (CSE).
|
Check releases.deckhouse.io for the current status of the release channels.
| О текущем статусе версий на каналах обновлений можно узнать на releases.deckhouse.io.
|
- Download and install the Deckhouse CLI tool.
|
- Скачайте и установите утилиту Deckhouse CLI.
|
- Pull Deckhouse images using the
d8 mirror pull command.
|
- Скачайте образы Deckhouse в выделенную директорию, используя команду
d8 mirror pull .
|
By default, d8 mirror pulls only the latest available patch versions for every actual Deckhouse release and the current set of officially supplied modules.
For example, for Deckhouse 1.59, only version 1.59.12 will be pulled, since this is sufficient for updating Deckhouse from 1.58 to 1.59.
| По умолчанию d8 mirror pull скачивает только актуальные версии Deckhouse и официально поставляемых модулей.
Например, для Deckhouse 1.59 будет скачана только версия 1.59.12 , т. к. этого достаточно для обновления Deckhouse с 1.58 до 1.59.
|
Run the following command (specify the edition code and the license key) to download actual images:
| Выполните следующую команду (укажите код редакции и лицензионный ключ), чтобы скачать образы актуальных версий:
|
shell
d8 mirror pull
–source=’registry.deckhouse.io/deckhouse/' \
--license='' $(pwd)/d8.tar
| shell
d8 mirror pull
–source=’registry.deckhouse.ru/deckhouse/' \
--license='' $(pwd)/d8.tar
|
where:
<EDITION> — the edition code of the Deckhouse Kubernetes Platform (for example, ee , se , cse );
<LICENSE_KEY> — Deckhouse Kubernetes Platform license key.
| где:
<EDITION> — код редакции Deckhouse Kubernetes Platform (например, ee , se , cse );
<LICENSE_KEY> — лицензионный ключ Deckhouse Kubernetes Platform.
|
If the loading of images is interrupted, rerunning the command will resume the loading if no more than a day has passed since it stopped.
|
Если загрузка образов будет прервана, повторный вызов команды продолжит загрузку, если с момента ее остановки прошло не более суток.
|
You can also use the following command options:
--no-pull-resume — to forcefully start the download from the beginning;
--no-modules — to skip downloading modules;
--min-version=X.Y — to download all versions of Deckhouse starting from the specified minor version. This parameter will be ignored if a version higher than the version on the Rock Solid updates channel is specified. This parameter cannot be used simultaneously with the --release parameter;
--release=X.Y.Z — to download only a specific version of Deckhouse (without considering update channels). This parameter cannot be used simultaneously with the --min-version parameter;
--gost-digest — for calculating the checksum of the Deckhouse images in the format of GOST R 34.11-2012 (Streebog). The checksum will be displayed and written to a file with the extension .tar.gostsum in the folder with the tar archive containing Deckhouse images;
--source — to specify the address of the Deckhouse source registry;
- To authenticate in the official Deckhouse image registry, you need to use a license key and the
--license parameter;
- To authenticate in a third-party registry, you need to use the
--source-login and --source-password parameters;
--images-bundle-chunk-size=N — to specify the maximum file size (in GB) to split the image archive into. As a result of the operation, instead of a single file archive, a set of .chunk files will be created (e.g., d8.tar.NNNN.chunk ). To upload images from such a set of files, specify the file name without the .NNNN.chunk suffix in the d8 mirror push command (e.g., d8.tar for files like d8.tar.NNNN.chunk ).
| Вы также можете использовать следующие параметры команды:
--no-pull-resume — чтобы принудительно начать загрузку сначала;
--no-modules — для пропуска загрузки модулей;
--min-version=X.Y — чтобы скачать все версии Deckhouse, начиная с указанной минорной версии. Параметр будет проигнорирован, если указана версия выше чем версия находящаяся на канале обновлений Rock Solid. Параметр не может быть использован одновременно с параметром --release ;
--release=X.Y.Z — чтобы скачать только конкретную версию Deckhouse (без учета каналов обновлений). Параметр не может быть использован одновременно с параметром --min-version ;
--gost-digest — для расчета контрольной суммы итогового набора образов Deckhouse в формате ГОСТ Р 34.11-2012 (Стрибог). Контрольная сумма будет отображена и записана в файл с расширением .tar.gostsum в папке с tar-архивом, содержащим образы Deckhouse;
--source — чтобы указать адрес источника хранилища образов Deckhouse;
- Для аутентификации в официальном хранилище образов Deckhouse нужно использовать лицензионный ключ и параметр
--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 ).
|
Additional configuration options for the d8 mirror family of commands are available as environment variables:
HTTP_PROXY /HTTPS_PROXY — URL of the proxy server for HTTP(S) requests to hosts that are not listed in the variable $NO_PROXY ;
NO_PROXY — comma-separated list of hosts to exclude from proxying. Supported value formats include IP addresses (1.2.3.4 ), CIDR notations (1.2.3.4/8 ), domains, and the asterisk character (* ). The IP addresses and domain names can also include a literal port number (1.2.3.4:80 ). The domain name matches that name and all the subdomains. The domain name with a leading . matches subdomains only. For example, foo.com matches foo.com and bar.foo.com ; .y.com matches x.y.com but does not match y.com . A single asterisk * indicates that no proxying should be done;
SSL_CERT_FILE — path to the SSL certificate. If the variable is set, system certificates are not used;
SSL_CERT_DIR — list of directories to search for SSL certificate files, separated by a colon. If set, system certificates are not used. See more…;
TMPDIR (*nix) /TMP (Windows) — path to a temporary directory to use for image pulling and pushing. All processing is done in this directory, so make sure there is enough free disk space to accommodate the entire bundle you are downloading;
MIRROR_BYPASS_ACCESS_CHECKS — set to 1 to skip validation of registry credentials;
| Дополнительные параметры конфигурации для семейства команд 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. Если переменная установлена, системные сертификаты не используются. Подробнее…;
TMPDIR (*nix) /TMP (Windows) — путь к директории для временных файлов, который будет использоваться во время операций загрузки и выгрузки образов. Вся обработка выполняется в этом каталоге. Он должен иметь достаточное количество свободного дискового пространства, чтобы вместить весь загружаемый пакет образов;
MIRROR_BYPASS_ACCESS_CHECKS — установите для этого параметра значение 1 , чтобы отключить проверку корректности переданных учетных данных для registry;
|
Example of a command to download all versions of Deckhouse EE starting from version 1.59 (provide the license key):
| Пример команды для загрузки всех версий Deckhouse EE начиная с версии 1.59 (укажите лицензионный ключ):
|
shell
d8 mirror pull
–source=’registry.deckhouse.io/deckhouse/ee’
–license=’' --min-version=1.59 $(pwd)/d8.tar
| shell
d8 mirror pull
–source=’registry.deckhouse.ru/deckhouse/ee’
–license=’' --min-version=1.59 $(pwd)/d8.tar
|
Example of a command for downloading Deckhouse images from a third-party registry:
| Пример команды для загрузки образов Deckhouse из стороннего хранилища образов:
|
shell
d8 mirror pull
–source=’corp.company.com:5000/sys/deckhouse’
–source-login=’' --source-password='' $(pwd)/d8.tar
| shell
d8 mirror pull
–source=’corp.company.com:5000/sys/deckhouse’
–source-login=’' --source-password='' $(pwd)/d8.tar
|
- Upload the bundle with the pulled Deckhouse images to a host with access to the air-gapped registry and install the Deckhouse CLI tool.
|
- На хост с доступом к хранилищу, куда нужно загрузить образы Deckhouse, скопируйте загруженный пакет образов Deckhouse и установите Deckhouse CLI.
|
- Push the images to the air-gapped registry using the
d8 mirror push command.
|
- Загрузите образы Deckhouse в хранилище с помощью команды
d8 mirror push .
|
Example of a command for pushing images from the /tmp/d8-images/d8.tar tarball (specify authorization data if necessary):
| Пример команды для загрузки образов из файла /tmp/d8-images/d8.tar (укажите данные для авторизации при необходимости):
|
shell
d8 mirror push /tmp/d8-images/d8.tar ‘corp.company.com:5000/sys/deckhouse’
–registry-login=’' --registry-password=''
| shell
d8 mirror push /tmp/d8-images/d8.tar ‘corp.company.com:5000/sys/deckhouse’
–registry-login=’' --registry-password=''
|
Before pushing images, make sure that the path for loading into the registry exists (/sys/deckhouse in the example above), and the account being used has write permissions.
Harbor users, please note that you will not be able to upload images to the project root; instead use a dedicated repository in the project to host Deckhouse images.
|
Перед загрузкой образов убедитесь, что путь для загрузки в хранилище образов существует (в примере — /sys/deckhouse ) и у используемой учетной записи есть права на запись.
Если вы используете Harbor, вы не сможете выгрузить образы в корень проекта, используйте выделенный репозиторий в проекте для размещения образов Deckhouse.
|
- Once pushing images to the air-gapped private registry is complete, you are ready to install Deckhouse from it. Refer to the Getting started guide.
|
- После загрузки образов в хранилище можно переходить к установке Deckhouse. Воспользуйтесь руководством по быстрому старту.
|
When launching the installer, use a repository where Deckhouse images have previously been loaded instead of official Deckhouse registry. For example, the address for launching the installer will look like corp.company.com:5000/sys/deckhouse/install:stable instead of registry.deckhouse.io/deckhouse/ee/install:stable .
| При запуске установщика используйте не официальное публичное хранилище образов Deckhouse, а хранилище в которое ранее были загружены образы Deckhouse. Для примера выше адрес запуска установщика будет иметь вид corp.company.com:5000/sys/deckhouse/install:stable , вместо registry.deckhouse.ru/deckhouse/ee/install:stable .
|
During installation, add your registry address and authorization data to the InitConfiguration resource (the imagesRepo and registryDockerCfg parameters; you might refer to step 3 of the Getting started guide as well).
| В ресурсе InitConfiguration при установке также используйте адрес вашего хранилища и данные авторизации (параметры imagesRepo, registryDockerCfg или шаг 3 руководства по быстрому старту).
|
After installation, apply DeckhouseReleases manifests that were generated by the d8 mirror pull command to your cluster via Deckhouse CLI as follows:
| После завершения установки примените сгенерированные во время загрузки манифесты DeckhouseReleases к вашему кластеру, используя Deckhouse CLI:
|
shell
d8 k apply -f ./deckhousereleases.yaml
| shell
d8 k apply -f ./deckhousereleases.yaml
|
Manually uploading images of Deckhouse modules into an air-gapped registry
| Ручная загрузка образов подключаемых модулей Deckhouse в изолированный приватный registry
|
Follow these steps for manual loading images of modules, connected from the module source (the ModuleSource resource):
| Для ручной загрузки образов модулей, подключаемых из источника модулей (ресурс ModuleSource), выполните следующие шаги:
|
- Download and install the Deckhouse CLI tool.
|
- Скачайте и установите утилиту Deckhouse CLI.
|
- Create an authentication string for
registry.deckhouse.io using the following command (provide the license key):
|
- Создайте строку аутентификации для официального хранилища образов
registry.deckhouse.ru , выполнив следующую команду (укажите лицензионный ключ):
|
shell
LICENSE_KEY=”LICENSE_KEY” base64 -w0 «EOF
{
“auths”: {
“registry.deckhouse.io”: {
“auth”: “$(echo -n license-token:${LICENSE_KEY} | base64 -w0)”
}
}
}
EOF
| shell
LICENSE_KEY=’' base64 -w0 <<EOF
{
"auths": {
"registry.deckhouse.ru": {
"auth": "$(echo -n license-token:${LICENSE_KEY} | base64 -w0)"
}
}
}
EOF
|
- Pull module images from their source registry, defined as a
ModuleSource resource, into a dedicated directory using the d8 mirror modules pull command.
|
- Скачайте образы модулей из их источника, описанного в виде ресурса
ModuleSource , в выделенную директорию, используя команду d8 mirror modules pull .
|
d8 mirror modules pull pulls only the module versions available in the module release channels at the time of copying unless the --filter flag is set.
| Если не передан параметр --filter , то d8 mirror modules pull скачивает только версии модулей, доступные в каналах обновлений модуля на момент копирования.
|
- Create a file with the
ModuleSource resource (for example, $HOME/module_source.yml ).
|
- Создайте файл с описанием ресурса
ModuleSource (например, $HOME/module_source.yml ).
|
Below is an example of a ModuleSource resource:
| Пример ресурса ModuleSource:
|
yaml
apiVersion: deckhouse.io/v1alpha1
kind: ModuleSource
metadata:
name: deckhouse
spec:
registry:
Specify credentials for the official Deckhouse registry obtained in step 2.
dockerCfg:
repo: registry.deckhouse.io/deckhouse/ee/modules
scheme: HTTPS
Select the appropriate release channel: Alpha, Beta, EarlyAccess, Stable, or RockSolid
releaseChannel: "Stable"
| yaml
apiVersion: deckhouse.io/v1alpha1
kind: ModuleSource
metadata:
name: deckhouse
spec:
registry:
Укажите строку аутентификации для официального хранилища образов, полученную в п. 2
dockerCfg:
repo: registry.deckhouse.ru/deckhouse/ee/modules
scheme: HTTPS
Выберите подходящий канал обновлений: Alpha, Beta, EarlyAccess, Stable, RockSolid
releaseChannel: "Stable"
|
- Download module images from the source described in the
ModuleSource resource to the specified directory, using the command d8 mirror modules pull .
|
- Скачайте образы модулей из источника, описанного в ресурсе
ModuleSource , в выделенную директорию, используя команду d8 mirror modules pull .
|
An example of a command:
| Пример команды:
|
shell
d8 mirror modules pull -d ./d8-modules -m $HOME/module_source.yml
| shell
d8 mirror modules pull -d ./d8-modules -m $HOME/module_source.yml
|
To download only a specific set of modules of specific versions, use the --filter flag followed by the list of required modules and their minimal required versions separated by the ; character.
| Для загрузки только набора из определенных модулей конкретных версий используйте параметр --filter , передав набор необходимых модулей и их минимальных версий, разделенных символом ; .
|
For example:
| Пример:
|
shell
d8 mirror modules pull -d /tmp/d8-modules -m $HOME/module_source.yml
–filter=’deckhouse-admin@1.3.3; sds-drbd@0.0.1’
| shell
d8 mirror modules pull -d /tmp/d8-modules -m $HOME/module_source.yml
–filter=’deckhouse-admin@1.3.3; sds-drbd@0.0.1’
|
The command above will only pull the deckhouse-admin and sds-drbd modules. For deckhouse-admin , all available versions starting from 1.3.3 will be pulled; for sds-drbd — those starting from 0.0.1 .
| Команда выше загрузит только модули deckhouse-admin и sds-drbd . Для deckhouse-admin будут загружены все доступные версии начиная с 1.3.3 , для sds-drbd — все доступные версии начиная с 0.0.1 .
|
- Upload the directory with the pulled images of the Deckhouse modules to a host with access to the air-gapped registry and install Deckhouse CLI tool.
|
- На хост с доступом к хранилищу, куда нужно загрузить образы, скопируйте директорию с загруженными образами модулей Deckhouse и установите Deckhouse CLI.
|
- Upload module images to the air-gapped registry using the
d8 mirror modules push command.
|
- Загрузите образы модулей в хранилище с помощью команды
d8 mirror modules push .
|
Below is an example of a command for pushing images from the /tmp/d8-modules directory:
| Пример команды для загрузки образов из директории /tmp/d8-modules :
|
shell
d8 mirror modules push
-d /tmp/d8-modules –registry=’corp.company.com:5000/deckhouse/modules’
–registry-login=’' --registry-password=''
| shell
d8 mirror modules push
-d /tmp/d8-modules –registry=’corp.company.com:5000/deckhouse/modules’
–registry-login=’' --registry-password=''
|
Before pushing images, make sure that the path for loading into the registry exists (/deckhouse/modules in the example above), and the account being used has write permissions.
|
Перед загрузкой образов убедитесь, что путь для загрузки в хранилище образов существует (в примере — /deckhouse/modules ) и у используемой учетной записи есть права на запись.
|
- After uploading the images to the air-gapped registry, edit the
ModuleSource YAML manifest prepared in step 3:
|
- Отредактируйте YAML-манифест
ModuleSource , подготовленный на шаге 3:
|
- Change the
.spec.registry.repo field to the address that you specified in the --registry parameter when you uploaded the images;
- Change the
.spec.registry.dockerCfg field to a base64 string with the authorization data for your registry in dockercfg format. Refer to your registry’s documentation for information on how to obtain this token.
|
- Измените поле
.spec.registry.repo на адрес, который вы указали в параметре --registry при загрузке образов.
- Измените поле
.spec.registry.dockerCfg на Base64-строку с данными для авторизации в вашем хранилище образов в формате dockercfg . Обратитесь к документации вашего registry для получения информации о том, как сгенерировать этот токен.
|
An example:
| Пример ModuleSource :
|
yaml
apiVersion: deckhouse.io/v1alpha1
kind: ModuleSource
metadata:
name: deckhouse
spec:
registry:
Specify the authentication string for your registry.
dockerCfg:
repo: 'corp.company.com:5000/deckhouse/modules'
scheme: HTTPS
Select the appropriate release channel: Alpha, Beta, EarlyAccess, Stable, or RockSolid
releaseChannel: "Stable"
| yaml
apiVersion: deckhouse.io/v1alpha1
kind: ModuleSource
metadata:
name: deckhouse
spec:
registry:
Укажите строку аутентификации для вашего хранилища образов.
dockerCfg:
repo: 'corp.company.com:5000/deckhouse/modules'
scheme: HTTPS
Выберите подходящий канал обновлений: Alpha, Beta, EarlyAccess, Stable, RockSolid
releaseChannel: "Stable"
|
- Apply the
ModuleSource manifest you got in the previous step to the cluster.
|
- Примените в кластере исправленный манифест
ModuleSource :
|
shell
d8 k apply -f $HOME/module_source.yml
| shell
d8 k apply -f $HOME/module_source.yml
|
Once the manifest has been applied, the modules are ready for use. For more detailed instructions on configuring and using modules, please refer to the module developer’s documentation.
| После применения манифеста модули готовы к использованию. Обратитесь к документации по разработке модуля для получения дополнительной информации.
|
How do I switch a running Deckhouse cluster to use a third-party registry?
| Как переключить работающий кластер Deckhouse на использование стороннего registry?
|
Using a registry other than registry.deckhouse.io and registry.deckhouse.ru is only available in the Enterprise Edition.
| Использование registry отличных от registry.deckhouse.io и registry.deckhouse.ru доступно только в Enterprise Edition.
|
To switch the Deckhouse cluster to using a third-party registry, follow these steps:
| Для переключения кластера Deckhouse на использование стороннего registry выполните следующие действия:
|
- Run
deckhouse-controller helper change-registry inside the Deckhouse Pod with the new registry settings.
- Example:
|
- Выполните команду
deckhouse-controller helper change-registry из пода Deckhouse с параметрами нового registry.
- Пример запуска:
|
shell
kubectl exec -ti -n d8-system svc/deckhouse-leader -c deckhouse – deckhouse-controller helper change-registry –user MY-USER –password MY-PASSWORD registry.example.com/deckhouse
| shell
kubectl exec -ti -n d8-system svc/deckhouse-leader -c deckhouse – deckhouse-controller helper change-registry
–user MY-USER –password MY-PASSWORD registry.example.com/deckhouse/ee
|
- If the registry uses a self-signed certificate, put the root CA certificate that validates the registry’s HTTPS certificate to file
/tmp/ca.crt in the Deckhouse Pod and add the --ca-file /tmp/ca.crt option to the script or put the content of CA into a variable as follows:
|
- Если registry использует самоподписанные сертификаты, положите корневой сертификат соответствующего сертификата registry в файл
/tmp/ca.crt в поде Deckhouse и добавьте к вызову опцию --ca-file /tmp/ca.crt или вставьте содержимое CA в переменную, как в примере ниже:
|
shell
$ CA_CONTENT=$(cat «EOF
—–BEGIN CERTIFICATE—–
CERTIFICATE
—–END CERTIFICATE—–
—–BEGIN CERTIFICATE—–
CERTIFICATE
—–END CERTIFICATE—–
EOF
)
$ kubectl -n d8-system exec svc/deckhouse-leader -c deckhouse – bash -c “echo ‘$CA_CONTENT’ > /tmp/ca.crt && deckhouse-controller helper change-registry –ca-file /tmp/ca.crt –user MY-USER –password MY-PASSWORD registry.example.com/deckhouse/ee”
| shell
$ CA_CONTENT=$(cat «EOF
—–BEGIN CERTIFICATE—–
CERTIFICATE
—–END CERTIFICATE—–
—–BEGIN CERTIFICATE—–
CERTIFICATE
—–END CERTIFICATE—–
EOF
)
$ kubectl -n d8-system exec svc/deckhouse-leader -c deckhouse – bash -c “echo ‘$CA_CONTENT’ > /tmp/ca.crt && deckhouse-controller helper change-registry –ca-file /tmp/ca.crt –user MY-USER –password MY-PASSWORD registry.example.com/deckhouse/ee”
|
- To view the list of available keys of the
deckhouse-controller helper change-registry command, run the following command:
|
- Просмотреть список доступных ключей команды
deckhouse-controller helper change-registry можно, выполнив следующую команду:
|
shell
kubectl -n d8-system exec -ti svc/deckhouse-leader -c deckhouse – deckhouse-controller helper change-registry –help
| shell
kubectl -n d8-system exec -ti svc/deckhouse-leader -c deckhouse – deckhouse-controller helper change-registry –help
|
Example output:
| Пример вывода:
|
shell
usage: deckhouse-controller helper change-registry []
| shell
usage: deckhouse-controller helper change-registry []
|
Change registry for deckhouse images.
| Change registry for deckhouse images.
|
Flags:
–help Show context-sensitive help (also try –help-long and –help-man).
–user=USER User with pull access to registry.
–password=PASSWORD Password/token for registry user.
–ca-file=CA-FILE Path to registry CA.
–scheme=SCHEME Used scheme while connecting to registry, http or https.
–dry-run Don’t change deckhouse resources, only print them.
–new-deckhouse-tag=NEW-DECKHOUSE-TAG
New tag that will be used for deckhouse deployment image (by default
current tag from deckhouse deployment will be used).
| Flags:
–help Show context-sensitive help (also try –help-long and –help-man).
–user=USER User with pull access to registry.
–password=PASSWORD Password/token for registry user.
–ca-file=CA-FILE Path to registry CA.
–scheme=SCHEME Used scheme while connecting to registry, http or https.
–dry-run Don’t change deckhouse resources, only print them.
–new-deckhouse-tag=NEW-DECKHOUSE-TAG
New tag that will be used for deckhouse deployment image (by default
current tag from deckhouse deployment will be used).
|
Args:
Registry that will be used for deckhouse images (example:
registry.deckhouse.io/deckhouse/ce). By default, https will be used, if you need
http - provide '--scheme' flag with http value
| Args:
Registry that will be used for deckhouse images (example:
registry.deckhouse.io/deckhouse/ce). By default, https will be used, if you need
http - provide '--scheme' flag with http value
|
- Wait for the Deckhouse Pod to become
Ready . Restart Deckhouse Pod if it will be in ImagePullBackoff state.
- Wait for bashible to apply the new settings on the master node. The bashible log on the master node (
journalctl -u bashible ) should contain the message Configuration is in sync, nothing to do .
- If you want to disable Deckhouse automatic updates, remove the releaseChannel parameter from the
deckhouse module configuration.
- Check if there are Pods with original registry in cluster (if there are — restart them):
|
- Дождитесь перехода пода Deckhouse в статус
Ready . Если под будет находиться в статусе ImagePullBackoff , перезапустите его.
- Дождитесь применения bashible новых настроек на master-узле. В журнале bashible на master-узле (
journalctl -u bashible ) должно появится сообщение Configuration is in sync, nothing to do .
- Если необходимо отключить автоматическое обновление Deckhouse через сторонний registry, удалите параметр
releaseChannel из конфигурации модуля deckhouse .
- Проверьте, не осталось ли в кластере подов с оригинальным адресом registry:
|
shell
kubectl get pods -A -o json | jq -r ‘.items[] | select(.spec.containers[]
| select(.image | startswith(“registry.deckhouse”))) | .metadata.namespace + “\t” + .metadata.name’ | sort | uniq
| shell
kubectl get pods -A -o json | jq -r ‘.items[] | select(.spec.containers[]
| select(.image | startswith(“registry.deckhouse”))) | .metadata.namespace + “\t” + .metadata.name’ | sort | uniq
|
How to bootstrap a cluster and run Deckhouse without the usage of release channels?
| Как создать кластер и запустить Deckhouse без использования каналов обновлений?
|
This method should only be used if there are no release channel images in your air-gapped registry.
| Данный способ следует использовать только в случае, если в изолированном приватном registry нет образов, содержащих информацию о каналах обновлений.
|
- If you want to install Deckhouse with automatic updates disabled:
- Use the tag of the installer image of the corresponding version. For example, use the image
your.private.registry.com/deckhouse/install:v1.60.5 , if you want to install release v1.60.5 .
- Do not set the deckhouse.releaseChannel parameter of the
InitConfiguration resource.
- If you want to disable automatic updates for an already installed Deckhouse (including patch release updates), then delete the releaseChannel parameter from the
deckhouse module configuration.
|
- Если вы хотите установить Deckhouse с отключенным автоматическим обновлением:
- Используйте тег образа установщика соответствующей версии. Например, если вы хотите установить релиз
v1.60.5 , используйте образ your.private.registry.com/deckhouse/install:v1.60.5 .
- Не указывайте параметр deckhouse.releaseChannel в ресурсе InitConfiguration.
- Если вы хотите отключить автоматические обновления у уже установленного Deckhouse (включая обновления patch-релизов), удалите параметр releaseChannel из конфигурации модуля
deckhouse .
|
Using a proxy server
| Использование proxy-сервера
|
This feature is available in Enterprise Edition only.
| Доступно только в Enterprise Edition.
|
- Prepare the VM for setting up the proxy. The machine must be accessible to the nodes that will use it as a proxy and be connected to the Internet.
- Install Squid on the server (here and further examples for Ubuntu):
|
- Подготовьте сервер (или виртуальную машину). Сервер должен быть доступен с необходимых узлов кластера, и у него должен быть выход в интернет.
- Установите Squid (здесь и далее примеры для Ubuntu):
|
shell
apt-get install squid
| shell
apt-get install squid
|
|
- Создайте файл конфигурации Squid:
|
shell
cat «EOF > /etc/squid/squid.conf
auth_param basic program /usr/lib/squid3/basic_ncsa_auth /etc/squid/passwords
auth_param basic realm proxy
acl authenticated proxy_auth REQUIRED
http_access allow authenticated
| shell
cat «EOF > /etc/squid/squid.conf
auth_param basic program /usr/lib/squid3/basic_ncsa_auth /etc/squid/passwords
auth_param basic realm proxy
acl authenticated proxy_auth REQUIRED
http_access allow authenticated
|
Choose the port you want. Below we set it to default 3128.
http_port 3128
| Choose the port you want. Below we set it to default 3128.
http_port 3128
|
- Create a user for proxy-server authentication:
|
- Создайте пользователя и пароль для аутентификации на proxy-сервере:
|
Example for the user test with the password test (be sure to change):
| Пример для пользователя test с паролем test (обязательно измените):
|
shell
echo “test:$(openssl passwd -crypt test)” » /etc/squid/passwords
| shell
echo “test:$(openssl passwd -crypt test)” » /etc/squid/passwords
|
- Start squid and enable the system to start it up automatically:
|
- Запустите Squid и включите его автоматический запуск при загрузке сервера:
|
shell
systemctl restart squid
systemctl enable squid
| shell
systemctl restart squid
systemctl enable squid
|
|
|
Use the proxy parameter of the ClusterConfiguration resource to configure proxy usage.
| Для настройки Deckhouse на использование proxy используйте параметр proxy ресурса ClusterConfiguration .
|
An example:
| Пример:
|
yaml
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”
| yaml
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”
|
Changing the configuration
| Изменение конфигурации
|
How do I change the configuration of a cluster?
| Как изменить конфигурацию кластера?
|
The general cluster parameters are stored in the ClusterConfiguration structure.
| Общие параметры кластера хранятся в структуре ClusterConfiguration.
|
To change the general cluster parameters, run the command:
| Чтобы изменить общие параметры кластера, выполните команду:
|
shell
kubectl -n d8-system exec -ti svc/deckhouse-leader -c deckhouse – deckhouse-controller edit cluster-configuration
| shell
kubectl -n d8-system exec -ti svc/deckhouse-leader -c deckhouse – deckhouse-controller edit cluster-configuration
|
After saving the changes, Deckhouse will bring the cluster configuration to the state according to the changed configuration. Depending on the size of the cluster, this may take some time.
| После сохранения изменений Deckhouse приведет конфигурацию кластера к измененному состоянию. В зависимости от размеров кластера это может занять какое-то время.
|
How do I change the configuration of a cloud provider in a cluster?
| Как изменить конфигурацию облачного провайдера в кластере?
|
Cloud provider setting of a cloud of hybrid cluster are stored in the <PROVIDER_NAME>ClusterConfiguration structure, where <PROVIDER_NAME> — name/code of the cloud provider. E.g., for an OpenStack provider, the structure will be called OpenStackClusterConfiguration.
| Настройки используемого облачного провайдера в облачном или гибридном кластере хранятся в структуре <PROVIDER_NAME>ClusterConfiguration , где <PROVIDER_NAME> — название/код провайдера. Например, для провайдера OpenStack структура будет называться OpenStackClusterConfiguration.
|
Regardless of the cloud provider used, its settings can be changed using the following command:
| Независимо от используемого облачного провайдера его настройки можно изменить с помощью следующей команды:
|
shell
kubectl -n d8-system exec -ti svc/deckhouse-leader -c deckhouse – deckhouse-controller edit provider-cluster-configuration
| shell
kubectl -n d8-system exec -ti svc/deckhouse-leader -c deckhouse – deckhouse-controller edit provider-cluster-configuration
|
How do I change the configuration of a static cluster?
| Как изменить конфигурацию статического кластера?
|
Settings of a static cluster are stored in the StaticClusterConfiguration structure.
| Настройки статического кластера хранятся в структуре StaticClusterConfiguration.
|
To change the settings of a static cluster, run the command:
| Чтобы изменить параметры статического кластера, выполните команду:
|
shell
kubectl -n d8-system exec -ti svc/deckhouse-leader -c deckhouse – deckhouse-controller edit static-cluster-configuration
| shell
kubectl -n d8-system exec -ti svc/deckhouse-leader -c deckhouse – deckhouse-controller edit static-cluster-configuration
|
How to switch Deckhouse EE to CE?
| Как переключить Deckhouse EE на CE?
|
The instruction implies using the public address of the container registry: registry.deckhouse.io . Using a registry other than registry.deckhouse.io and registry.deckhouse.ru is only available in the Enterprise Edition.
| Инструкция подразумевает использование публичного адреса container registry: registry.deckhouse.ru . Использование registry отличных от registry.deckhouse.io и registry.deckhouse.ru доступно только в Enterprise Edition.
|
Deckhouse CE does not support cloud clusters on OpenStack and VMware vSphere.
| В Deckhouse CE не поддерживается работа облачных кластеров на OpenStack и VMware vSphere.
|
To switch Deckhouse Enterprise Edition to Community Edition, follow these steps:
| Для переключения кластера Deckhouse Enterprise Edition на Community Edition выполните следующие действия (все команды выполняются на master-узле действующего кластера):
|
- Make sure that the modules used in the cluster are supported in Deckhouse CE. Disable modules that are not supported in Deckhouse CE.
|
- Убедитесь, что используемые в кластере модули поддерживаются в версии CE. Отключите модули, которые не поддерживаются в Deckhouse CE.
|
- Run the following command:
|
- Выполните следующую команду:
|
shell
kubectl exec -ti -n d8-system svc/deckhouse-leader -c deckhouse – deckhouse-controller helper change-registry registry.deckhouse.io/deckhouse/ce
| shell
kubectl exec -ti -n d8-system svc/deckhouse-leader -c deckhouse – deckhouse-controller helper change-registry registry.deckhouse.ru/deckhouse/ce
|
- Wait for the Deckhouse Pod to become
Ready :
|
- Дождитесь перехода пода Deckhouse в статус
Ready :
|
shell
kubectl -n d8-system get po -l app=deckhouse
| shell
kubectl -n d8-system get po -l app=deckhouse
|
- Restart Deckhouse Pod if it will be in
ImagePullBackoff state:
|
- Если под будет находиться в статусе
ImagePullBackoff , перезапустите его:
|
shell
kubectl -n d8-system delete po -l app=deckhouse
| shell
kubectl -n d8-system delete po -l app=deckhouse
|
- Wait until Deckhouse restarts and all tasks in the queue are completed:
|
- Дождитесь перезапуска Deckhouse и выполнения всех задач в очереди:
|
shell
kubectl -n d8-system exec -it svc/deckhouse-leader -c deckhouse – deckhouse-controller queue list
| shell
kubectl -n d8-system exec -it svc/deckhouse-leader -c deckhouse – deckhouse-controller queue list
|
- On the master node, check the application of the new settings.
|
- На master-узле проверьте применение новых настроек.
|
The message Configuration is in sync, nothing to do should appear in the bashible systemd service log on the master node.
| В журнале systemd-сервиса bashible на master-узле должно появиться сообщение Configuration is in sync, nothing to do .
|
An example::
| Пример:
|
console
journalctl -u bashible -n 5
Jan 12 12:38:20 demo-master-0 bashible.sh[868379]: Configuration is in sync, nothing to do.
Jan 12 12:38:20 demo-master-0 systemd[1]: bashible.service: Deactivated successfully.
Jan 12 12:39:18 demo-master-0 systemd[1]: Started Bashible service.
Jan 12 12:39:19 demo-master-0 bashible.sh[869714]: Configuration is in sync, nothing to do.
Jan 12 12:39:19 demo-master-0 systemd[1]: bashible.service: Deactivated successfully.
| console
journalctl -u bashible -n 5
Jan 12 12:38:20 demo-master-0 bashible.sh[868379]: Configuration is in sync, nothing to do.
Jan 12 12:38:20 demo-master-0 systemd[1]: bashible.service: Deactivated successfully.
Jan 12 12:39:18 demo-master-0 systemd[1]: Started Bashible service.
Jan 12 12:39:19 demo-master-0 bashible.sh[869714]: Configuration is in sync, nothing to do.
Jan 12 12:39:19 demo-master-0 systemd[1]: bashible.service: Deactivated successfully.
|
- Check if there are any Pods left in the cluster with the Deckhouse EE registry address:
|
- Проверьте, не осталось ли в кластере подов с адресом registry для Deckhouse EE:
|
shell
kubectl get pods -A -o json | jq -r ‘.items[] | select(.spec.containers[]
| select(.image | contains(“deckhouse.io/deckhouse/ee”))) | .metadata.namespace + “\t” + .metadata.name’ | sort | uniq
| shell
kubectl get pods -A -o json | jq -r ‘.items[] | select(.spec.containers[]
| select(.image | contains(“deckhouse.ru/deckhouse/ee”))) | .metadata.namespace + “\t” + .metadata.name’ | sort | uniq
|
Sometimes, some static Pods may remain running (for example, kubernetes-api-proxy-* ). This is due to the fact that kubelet does not restart the Pod despite changing the corresponding manifest, because the image used is the same for the Deckhouse CE and EE. To make sure that the corresponding manifests have also been changed, run the following command on any master node:
| Иногда могут оставаться запущенными некоторые static Pod’ы (например, kubernetes-api-proxy-* ). Это связанно с тем, что kubelet не перезапускает под несмотря на изменение соответствующего манифеста, так как используемый образ одинаков для Deckhouse CE и EE. Выполните на любом master-узле следующую команду, чтобы убедиться, что соответствующие манифесты также были изменены:
|
shell
grep -ri ‘deckhouse.io/deckhouse/ee’ /etc/kubernetes | grep -v backup
| shell
grep -ri ‘deckhouse.ru/deckhouse/ee’ /etc/kubernetes | grep -v backup
|
The output of the command should be empty.
| Вывод команды должен быть пуст.
|
How to switch Deckhouse CE to EE?
| Как переключить Deckhouse CE на EE?
|
You will need a valid license key (you can request a trial license key if necessary).
| Вам потребуется действующий лицензионный ключ (вы можете запросить временный ключ при необходимости).
|
The instruction implies using the public address of the container registry: registry.deckhouse.io . If you use a different container registry address, change the commands or use the instruction for switching Deckhouse to using a third-party registry.
| Инструкция подразумевает использование публичного адреса container registry: registry.deckhouse.ru . В случае использования другого адреса container registry измените команды или воспользуйтесь инструкцией по переключению Deckhouse на использование стороннего registry.
|
To switch Deckhouse Community Edition to Enterprise Edition, follow these steps:
| Для переключения кластера Deckhouse Community Edition на Enterprise Edition выполните следующие действия (все команды выполняются на master-узле действующего кластера):
|
- Run the following command:
|
- Выполните следующую команду:
|
shell
LICENSE_TOKEN=
kubectl exec -ti -n d8-system svc/deckhouse-leader -c deckhouse -- deckhouse-controller helper change-registry --user license-token --password $LICENSE_TOKEN registry.deckhouse.io/deckhouse/ee
| shell
LICENSE_TOKEN=
kubectl exec -ti -n d8-system svc/deckhouse-leader -c deckhouse -- deckhouse-controller helper change-registry --user license-token --password $LICENSE_TOKEN registry.deckhouse.ru/deckhouse/ee
|
- Wait for the Deckhouse Pod to become
Ready :
|
- Дождитесь перехода пода Deckhouse в статус
Ready :
|
shell
kubectl -n d8-system get po -l app=deckhouse
| shell
kubectl -n d8-system get po -l app=deckhouse
|
- Restart Deckhouse Pod if it will be in
ImagePullBackoff state:
|
- Если под будет находиться в статусе
ImagePullBackoff , перезапустите его:
|
shell
kubectl -n d8-system delete po -l app=deckhouse
| shell
kubectl -n d8-system delete po -l app=deckhouse
|
- Wait until Deckhouse restarts and all tasks in the queue are completed:
|
- Дождитесь перезапуска Deckhouse и выполнения всех задач в очереди:
|
shell
kubectl -n d8-system exec -it svc/deckhouse-leader -c deckhouse – deckhouse-controller queue list
| shell
kubectl -n d8-system exec -it svc/deckhouse-leader -c deckhouse – deckhouse-controller queue list
|
- On the master node, check the application of the new settings.
|
- На master-узле проверьте применение новых настроек.
|
The message Configuration is in sync, nothing to do should appear in the bashible systemd service log on the master node.
| В журнале systemd-сервиса bashible на master-узле должно появиться сообщение Configuration is in sync, nothing to do .
|
An example:
| Пример:
|
console
journalctl -u bashible -n 5
Jan 12 12:38:20 demo-master-0 bashible.sh[868379]: Configuration is in sync, nothing to do.
Jan 12 12:38:20 demo-master-0 systemd[1]: bashible.service: Deactivated successfully.
Jan 12 12:39:18 demo-master-0 systemd[1]: Started Bashible service.
Jan 12 12:39:19 demo-master-0 bashible.sh[869714]: Configuration is in sync, nothing to do.
Jan 12 12:39:19 demo-master-0 systemd[1]: bashible.service: Deactivated successfully.
| console
journalctl -u bashible -n 5
Jan 12 12:38:20 demo-master-0 bashible.sh[868379]: Configuration is in sync, nothing to do.
Jan 12 12:38:20 demo-master-0 systemd[1]: bashible.service: Deactivated successfully.
Jan 12 12:39:18 demo-master-0 systemd[1]: Started Bashible service.
Jan 12 12:39:19 demo-master-0 bashible.sh[869714]: Configuration is in sync, nothing to do.
Jan 12 12:39:19 demo-master-0 systemd[1]: bashible.service: Deactivated successfully.
|
- Check if there are any Pods left in the cluster with the Deckhouse CE registry address:
|
- Проверьте, не осталось ли в кластере подов с адресом registry для Deckhouse CE:
|
shell
kubectl get pods -A -o json | jq -r ‘.items[] | select(.spec.containers[]
| select(.image | contains(“deckhouse.io/deckhouse/ce”))) | .metadata.namespace + “\t” + .metadata.name’ | sort | uniq
| shell
kubectl get pods -A -o json | jq -r ‘.items[] | select(.spec.containers[]
| select(.image | contains(“deckhouse.ru/deckhouse/ce”))) | .metadata.namespace + “\t” + .metadata.name’ | sort | uniq
|
Sometimes, some static Pods may remain running (for example, kubernetes-api-proxy-* ). This is due to the fact that kubelet does not restart the Pod despite changing the corresponding manifest, because the image used is the same for the Deckhouse CE and EE. To make sure that the corresponding manifests have also been changed, run the following command on any master node:
| Иногда могут оставаться запущенными некоторые static Pod’ы (например, kubernetes-api-proxy-* ). Это связанно с тем, что kubelet не перезапускает под несмотря на изменение соответствующего манифеста, так как используемый образ одинаков для Deckhouse CE и EE. Выполните на любом master-узле следующую команду, чтобы убедиться, что соответствующие манифесты также были изменены:
|
shell
grep -ri ‘deckhouse.io/deckhouse/ce’ /etc/kubernetes | grep -v backup
| shell
grep -ri ‘deckhouse.ru/deckhouse/ce’ /etc/kubernetes | grep -v backup
|
The output of the command should be empty.
| Вывод команды должен быть пуст.
|
How do I get access to Deckhouse controller in multimaster cluster?
| Как переключить Deckhouse EE на CSE?
|
In clusters with multiple master nodes Deckhouse runs in high availability mode (in several instances). To access the active Deckhouse controller, you can use the following command (as an example of the command deckhouse-controller queue list ):
|
- Инструкция подразумевает использование публичного адреса container registry:
registry-cse.deckhouse.ru . В случае использования другого адреса container registry измените команды или воспользуйтесь инструкцией по переключению Deckhouse на использование стороннего registry.
- В Deckhouse CSE не поддерживается работа облачных кластеров и ряда модулей.
- На текущий момент мигрировать на CSE-редакцию можно только с релиза 1.58.
- При переключении на CSE-редакцию может наблюдаться недоступность компонентов кластера.
|
shell
kubectl -n d8-system exec -it svc/deckhouse-leader -c deckhouse – deckhouse-controller queue list
| Для переключения кластера Deckhouse Enterprise Edition на Certified Security Edition выполните следующие действия (все команды выполняются на master-узле действующего кластера):
|
How do I upgrade the Kubernetes version in a cluster?
|
- Подготовьте переменные с токеном лицензии и создайте NodeGroupConfiguration для переходной авторизации в
registry-cse.deckhouse.ru :
|
To upgrade the Kubernetes version in a cluster change the kubernetesVersion parameter in the ClusterConfiguration structure by making the following steps:
- Run the command:
| shell
LICENSE_TOKEN=
AUTH_STRING="$(echo -n license-token:${LICENSE_TOKEN} | base64 )"
kubectl apply -f - <<EOF
---
apiVersion: deckhouse.io/v1alpha1
kind: NodeGroupConfiguration
metadata:
name: containerd-cse-config.sh
spec:
nodeGroups:
- ‘*’
bundles:
- ‘*’
weight: 30
content: |
_on_containerd_config_changed() {
bb-flag-set containerd-need-restart
}
bb-event-on ‘containerd-config-file-changed’ ‘_on_containerd_config_changed’
|
shell
kubectl -n d8-system exec -ti svc/deckhouse-leader -c deckhouse – deckhouse-controller edit cluster-configuration
| mkdir -p /etc/containerd/conf.d
bb-sync-file /etc/containerd/conf.d/cse-registry.toml - containerd-config-file-changed « “EOF_TOML”
[plugins]
[plugins.”io.containerd.grpc.v1.cri”]
[plugins.”io.containerd.grpc.v1.cri”.registry]
[plugins.”io.containerd.grpc.v1.cri”.registry.mirrors]
[plugins.”io.containerd.grpc.v1.cri”.registry.mirrors.”registry-cse.deckhouse.ru”]
endpoint = [“https://registry-cse.deckhouse.ru”]
[plugins.”io.containerd.grpc.v1.cri”.registry.configs]
[plugins.”io.containerd.grpc.v1.cri”.registry.configs.”registry-cse.deckhouse.ru”.auth]
auth = “$AUTH_STRING”
EOF_TOML
EOF
|
- Change the
kubernetesVersion field.
- Save the changes. Cluster nodes will start updating sequentially.
- Wait for the update to finish. You can track the progress of the update using the
kubectl get no command. The update is completed when the new version appears in the command’s output for each cluster node in the VERSION column.
| Дождитесь появления файла на узлах и завершения синхронизации bashible:
|
How do I run Deckhouse on a particular node?
| shell
/etc/containerd/conf.d/cse-registry.toml
|
Set the nodeSelector parameter of the deckhouse module and avoid setting tolerations . The necessary values will be assigned to the tolerations parameter automatically.
| Статус синхронизации можно отследить по значению UPTODATE (отображаемое число узлов в этом статусе должно совпадать с общим числом узлов (NODES ) в группе):
|
Use only nodes with the CloudStatic or Static type to run Deckhouse. Also, avoid using a NodeGroup containing only one node to run Deckhouse.
| shell
kubectl get ng -o custom-columns=NAME:.metadata.name,NODES:.status.nodes,READY:.status.ready,UPTODATE:.status.upToDate -w
|
Here is an example of the module configuration:
| Пример:
|
yaml
apiVersion: deckhouse.io/v1alpha1
kind: ModuleConfig
metadata:
name: deckhouse
spec:
version: 1
settings:
nodeSelector:
node-role.deckhouse.io/deckhouse: “”
| console
root@master-ee-to-cse-0:~# kubectl get ng -o custom-columns=NAME:.metadata.name,NODES:.status.nodes,READY:.status.ready,UPTODATE:.status.upToDate -w
NAME NODES READY UPTODATE
master 1 1 1
worker 2 2 2
|
| Также в журнале systemd-сервиса bashible должно появиться сообщение Configuration is in sync, nothing to do .
|
| Пример:
|
| console
journalctl -u bashible -n 5
Aug 21 11:04:28 master-ee-to-cse-0 bashible.sh[53407]: Configuration is in sync, nothing to do.
Aug 21 11:04:28 master-ee-to-cse-0 bashible.sh[53407]: Annotate node master-ee-to-cse-0 with annotation node.deckhouse.io/configuration-checksum=9cbe6db6c91574b8b732108a654c99423733b20f04848d0b4e1e2dadb231206a
Aug 21 11:04:29 master-ee-to-cse-0 bashible.sh[53407]: Succesful annotate node master-ee-to-cse-0 with annotation node.deckhouse.io/configuration-checksum=9cbe6db6c91574b8b732108a654c99423733b20f04848d0b4e1e2dadb231206a
Aug 21 11:04:29 master-ee-to-cse-0 systemd[1]: bashible.service: Deactivated successfully.
|
|
- Выполните следующие команды для запуска временного пода CSE-редакции для получения актуальных дайджестов и списка модулей:
|
| console
kubectl run cse-image –image=registry-cse.deckhouse.ru/deckhouse/cse/install:v1.58.2 –command sleep – infinity
|
| Как только под перейдёт в статус Running , выполните следующие команды:
|
| console
CSE_SANDBOX_IMAGE=$(kubectl exec cse-image – cat deckhouse/candi/images_digests.json | grep pause | grep -oE ‘sha256:\w’)
CSE_K8S_API_PROXY=$(kubectl exec cse-image – cat deckhouse/candi/images_digests.json | grep kubernetesApiProxy | grep -oE ‘sha256:\w’)
CSE_MODULES=$(kubectl exec cse-image – ls -l deckhouse/modules/ | awk {‘print $9’} |grep -oP “\d.-\w” | cut -c5-)
USED_MODULES=$(kubectl get modules | grep -v ‘snapshot-controller-crd’ | grep Enabled |awk {‘print $1’})
MODULES_WILL_DISABLE=$(echo $USED_MODULES | tr ‘ ‘ ‘\n’ | grep -Fxv -f <(echo $CSE_MODULES | tr ‘ ‘ ‘\n’))
|
|
- Убедитесь, что используемые в кластере модули поддерживаются в CSE-редакции.
Например, на текущий момент в CSE-редакции отсутствует модуль cert-manager, поэтому перед его отключением необходимо перевести
https.mode для связанных компонентов (например user-authn или prometheus) на альтернативные варианты.
|
| Отобразить список модулей, которые не поддерживаются в CSE-редакции и будут отключены, можно следующей командой:
|
| shell
echo $MODULES_WILL_DISABLE
|
|
Проверьте список и убедитесь, что функциональность указанных модулей не задействована вами в кластере, и вы готовы к их отключению.
|
| Отключите неподдерживаемые в CSE-редакции модули:
|
| shell
echo $MODULES_WILL_DISABLE |
tr ‘ ‘ ‘\n’ | awk {‘print “kubectl -n d8-system exec deploy/deckhouse – deckhouse-controller module disable”,$1’} | bash
|
| Дождитесь перехода пода Deckhouse в статус Ready и выполнения всех задач в очереди.
|
|
- Создайте NodeGroupConfiguration:
|
| shell
kubectl apply -f - «EOF
apiVersion: deckhouse.io/v1alpha1
kind: NodeGroupConfiguration
metadata:
name: cse-set-sha-images.sh
spec:
nodeGroups:
- ‘*’
bundles:
- ‘*’
weight: 50
content: |
_on_containerd_config_changed() {
bb-flag-set containerd-need-restart
}
bb-event-on ‘containerd-config-file-changed’ ‘_on_containerd_config_changed’
|
| bb-sync-file /etc/containerd/conf.d/cse-sandbox.toml - containerd-config-file-changed « “EOF_TOML”
[plugins]
[plugins.”io.containerd.grpc.v1.cri”]
sandbox_image = “registry-cse.deckhouse.ru/deckhouse/cse@$CSE_SANDBOX_IMAGE”
EOF_TOML
|
| sed -i ‘s|image: .|image: registry-cse.deckhouse.ru/deckhouse/cse@$CSE_K8S_API_PROXY|’ /var/lib/bashible/bundle_steps/051_pull_and_configure_kubernetes_api_proxy.sh
sed -i ‘s|crictl pull .|crictl pull registry-cse.deckhouse.ru/deckhouse/cse@$CSE_K8S_API_PROXY|’ /var/lib/bashible/bundle_steps/051_pull_and_configure_kubernetes_api_proxy.sh
EOF
|
| Дождитесь завершения синхронизации bashible на всех узлах.
|
| Состояние синхронизации можно отследить по значению UPTODATE статуса (отображаемое число узлов в этом статусе должно совпадать с общим числом узлов (NODES ) в группе):
|
| shell
kubectl get ng -o custom-columns=NAME:.metadata.name,NODES:.status.nodes,READY:.status.ready,UPTODATE:.status.upToDate -w
|
| Также в журнале systemd-сервиса bashible на узлах должно появиться сообщение Configuration is in sync, nothing to do .
|
| Пример:
|
| console
journalctl -u bashible -n 5
Aug 21 11:04:28 master-ee-to-cse-0 bashible.sh[53407]: Configuration is in sync, nothing to do.
Aug 21 11:04:28 master-ee-to-cse-0 bashible.sh[53407]: Annotate node master-ee-to-cse-0 with annotation node.deckhouse.io/configuration-checksum=9cbe6db6c91574b8b732108a654c99423733b20f04848d0b4e1e2dadb231206a
Aug 21 11:04:29 master-ee-to-cse-0 bashible.sh[53407]: Succesful annotate node master-ee-to-cse-0 with annotation node.deckhouse.io/configuration-checksum=9cbe6db6c91574b8b732108a654c99423733b20f04848d0b4e1e2dadb231206a
Aug 21 11:04:29 master-ee-to-cse-0 systemd[1]: bashible.service: Deactivated successfully.
|
|
- Актуализируйте секрет доступа к registry Deckhouse, выполнив следующую команду:
|
| console
kubectl -n d8-system create secret generic deckhouse-registry
–from-literal=”.dockerconfigjson”=”{"auths": { "registry-cse.deckhouse.ru": { "username": "license-token", "password": "$LICENSE_TOKEN", "auth": "$AUTH_STRING" }}}”
–from-literal=”address”=registry-cse.deckhouse.ru
–from-literal=”path”=/deckhouse/cse
–from-literal=”scheme”=https
–type=kubernetes.io/dockerconfigjson
–dry-run=’client’
-o yaml | kubectl replace -f -
|
|
- Примените CSE-образ:
|
| console
kubectl -n d8-system set image deployment/deckhouse deckhouse=registry-cse.deckhouse.ru/deckhouse/cse:v1.58.2
|
|
- Дождитесь перехода пода Deckhouse в статус
Ready и выполнения всех задач в очереди. Если в процессе возникает ошибка ImagePullBackOff , подождите автоматического перезапуска пода.
|
| Посмотреть статус пода Deckhouse:
|
| console
kubectl -n d8-system get po -l app=deckhouse
|
| Проверить состояние очереди Deckhouse:
|
| console
kubectl -n d8-system exec deploy/deckhouse -c deckhouse – deckhouse-controller queue list
|
|
- Проверьте, не осталось ли в кластере подов с адресом registry для Deckhouse EE:
|
| console
kubectl get pods -A -o json | jq -r ‘.items[] | select(.spec.containers[]
| select(.image | contains(“deckhouse.ru/deckhouse/ee”))) | .metadata.namespace + “\t” + .metadata.name’ | sort | uniq
|
| Если в выводе присутствуют поды модуля chrony, заново включите данный модуль (в CSE этот модуль по умолчанию выключен):
|
| console
kubectl -n d8-system exec deploy/deckhouse – deckhouse-controller module enable chrony
|
|
- Очистите временные файлы, ngc и переменные:
|
| console
rm /tmp/cse-deckhouse-registry.yaml
|
| kubectl delete ngc containerd-cse-config.sh cse-set-sha-images.sh
|
| kubectl delete pod cse-image
|
| kubectl apply -f - «EOF
apiVersion: deckhouse.io/v1alpha1
kind: NodeGroupConfiguration
metadata:
name: del-temp-config.sh
spec:
nodeGroups:
- ‘*’
bundles:
- ‘*’
weight: 90
content: |
if [ -f /etc/containerd/conf.d/cse-registry.toml ]; then
rm -f /etc/containerd/conf.d/cse-registry.toml
fi
if [ -f /etc/containerd/conf.d/cse-sandbox.toml ]; then
rm -f /etc/containerd/conf.d/cse-sandbox.toml
fi
EOF
|
| После синхронизации bashible (статус синхронизации на узлах можно отследить по значению UPTODATE у nodegroup) удалите созданную ngc:
|
| shell
kubectl delete ngc del-temp-config.sh
|
| Как получить доступ к контроллеру Deckhouse в multi-master-кластере?
|
| В кластерах с несколькими master-узлами Deckhouse запускается в режиме высокой доступности (в нескольких экземплярах). Для доступа к активному контроллеру Deckhouse можно использовать следующую команду (на примере команды deckhouse-controller queue list ):
|
| shell
kubectl -n d8-system exec -it svc/deckhouse-leader -c deckhouse – deckhouse-controller queue list
|
| Как обновить версию Kubernetes в кластере?
|
| Чтобы обновить версию Kubernetes в кластере, измените параметр kubernetesVersion в структуре ClusterConfiguration, выполнив следующие шаги:
- Выполните команду:
|
| shell
kubectl -n d8-system exec -ti svc/deckhouse-leader
-c deckhouse – deckhouse-controller edit cluster-configuration
|
|
- Измените параметр
kubernetesVersion .
- Сохраните изменения. Узлы кластера начнут последовательно обновляться.
- Дождитесь окончания обновления. Отслеживать ход обновления можно с помощью команды
kubectl get no . Обновление можно считать завершенным, когда в выводе команды у каждого узла кластера в колонке VERSION появится обновленная версия.
|
| Как запускать Deckhouse на произвольном узле?
|
| Для запуска Deckhouse на произвольном узле установите у модуля deckhouse соответствующий параметр nodeSelector и не задавайте tolerations . Необходимые значения tolerations в этом случае будут проставлены автоматически.
|
| Используйте для запуска Deckhouse только узлы с типом CloudStatic или Static. Также избегайте использования для запуска Deckhouse группы узлов (NodeGroup ), содержащей только один узел.
|
| Пример конфигурации модуля:
|
| yaml
apiVersion: deckhouse.io/v1alpha1
kind: ModuleConfig
metadata:
name: deckhouse
spec:
version: 1
settings:
nodeSelector:
node-role.deckhouse.io/deckhouse: “”
|