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 настраивается с помощью глобальных настроек, настроек модулей и различных кастомных ресурсов. Подробнее — в документации.

1. Display global Deckhouse settings:

1. Выведите глобальные настройки:

1. List the status of all modules (available for Deckhouse version 1.47+):

1. Выведите список состояния всех модулей (доступно для Deckhouse версии 1.47+):

1. Display the settings of the user-authn module configuration:

1. Выведите настройки модуля user-authn:

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. Для этого выполните следующую команду:

Example of the output:

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

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:

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 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:

An example of a resource with the update window skipping annotation in place:

Пример ресурса с установленной аннотацией пропуска окон обновлений:

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 displayed.
• 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, это может говорить о проблеме. Необходима диагностика.

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 by running the following command:

Также вы можете проверить состояние релизов Deckhouse, выполнив следующую команду:

bash kubectl get deckhouserelease

shell kubectl get deckhouserelease

Example output:

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

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:

Example output:

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

• 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:

Возможные варианты действий, если что-то пошло не так:

1. Check Deckhouse logs using the following command:

1. Проверьте логи, используя следующую команду:

1. Collect debugging information and contact technical support.
2. Ask for help from the community.

1. Соберите отладочную информацию и свяжитесь с технической поддержкой.
2. Попросите помощи у сообщества.

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:

Как только на установленном в кластере канале обновления появляется новая версия Deckhouse:

• 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.

• Отображается алерт DeckhouseReleaseIsWaitingManualApproval, если кластер использует ручной режим обновлений (параметр update.mode установлен в Manual).
• Появляется новый кастомный ресурс DeckhouseRelease. Используйте команду kubectl get deckhousereleases, чтобы посмотреть список релизов. Если DeckhouseRelease новой версии находится в состоянии Pending, указанная версия еще не установлена. Возможные причины, при которых DeckhouseRelease может находиться в Pending:
• Установлен ручной режим обновлений (параметр update.mode установлен в Manual).
• Установлен автоматический режим обновлений и настроены окна обновлений, интервал которых еще не наступил.
• Установлен автоматический режим обновлений, окна обновлений не настроены, но применение версии отложено на случайный период времени из-за механизма снижения нагрузки на репозиторий образов контейнеров. В поле status.message ресурса DeckhouseRelease будет соответствующее сообщение.
• Установлен параметр update.notification.minimalNotificationTime и указанное в нем время еще не прошло.

How do I get information about the upcoming update in advance?

Как заранее получать информацию о предстоящем обновлении?

You can get information in advance about updating minor versions of Deckhouse on the release channel in the following ways:

Заранее получать информацию об обновлении минорных версий Deckhouse на канале обновлений можно следующими способами:

• Configure manual update mode. In this case, when a new version appears on the release channel, the alert DeckhouseReleaseIsWaitingManualApproval will be displayed and a new custom resource DeckhouseRelease will be applied 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.

• Настройте ручной режим обновлений. В этом случае при появлении новой версии на канале обновлений отобразится алерт DeckhouseReleaseIsWaitingManualApproval и в кластере появится новый кастомный ресурс DeckhouseRelease.
• Настройте автоматический режим обновлений и укажите минимальное время в параметре minimalNotificationTime, на которое будет отложено обновление. В этом случае при появлении новой версии на канале обновлений в кластере появится новый кастомный ресурс 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.ru.

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

После появления кастомного ресурса DeckhouseRelease в кластере, Deckhouse выполнит обновление на соответствующую версию согласно установленным параметрам обновления (по умолчанию — автоматически, в любое время).

To get list and status of all releases use the following command:

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

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 EarlyAccess 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) и сравнивает их с данными из существующих в кластере кастомных ресурсов DeckhouseRelease:
• Более поздние релизы, которые не были применены (в статусе Pending), удаляются.
• Если более поздние релизы применены (в статусе Deployed), смены релиза не происходит. Релиз остается прежним до тех пор, пока на канале обновлений EarlyAccess не появится более поздняя версия.
• При смене канала обновлений на менее стабильный (например, с EarlyAccess на Alpha):
• Deckhouse скачивает данные о релизе (в примере — из канала Alpha) и сравнивает их с данными из существующих в кластере кастомных ресурсов DeckhouseRelease.
• Затем Deckhouse выполняет обновление согласно установленным параметрам обновления.

What do I do if Deckhouse fails to retrieve updates from the release channel?

Что делать, если Deckhouse не получает обновлений из канала обновлений?

1. Make sure that the desired release channel is configured.
2. Make sure that the DNS name of the Deckhouse container registry is resolved correctly.
3. 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.

1. Проверьте, что настроен нужный канал обновлений.
2. Проверьте корректность разрешения DNS-имени хранилища образов Deckhouse.

To retrieve the IP address of the Deckhouse container registry on a node, run the following command:

1. Получите и сравните IP-адреса хранилища образов Deckhouse (registry.deckhouse.ru) на одном из узлов и в поде Deckhouse. Они должны совпадать.

shell getent ahosts registry.deckhouse.io

Чтобы получить IP-адрес хранилища образов Deckhouse на узле, выполните следующую команду:

Example output:

shell getent ahosts registry.deckhouse.ru

console 46.4.145.194 STREAM registry.deckhouse.io 46.4.145.194 DGRAM 46.4.145.194 RAW

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

To retrieve the IP address of the Deckhouse container registry in a pod, run the following command:

console 185.193.90.38 STREAM registry.deckhouse.ru 185.193.90.38 DGRAM 185.193.90.38 RAW

shell kubectl -n d8-system exec -ti svc/deckhouse-leader -c deckhouse – getent ahosts registry.deckhouse.io

Чтобы получить IP-адрес хранилища образов Deckhouse в поде Deckhouse, выполните следующую команду:

Example output: console 46.4.145.194 STREAM registry.deckhouse.io 46.4.145.194 DGRAM registry.deckhouse.io

shell kubectl -n d8-system exec -ti svc/deckhouse-leader -c deckhouse – getent ahosts registry.deckhouse.ru

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 the following example).

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

console 185.193.90.38 STREAM registry.deckhouse.ru 185.193.90.38 DGRAM registry.deckhouse.ru

In the example, DNS settings produce different results when resolving names on the host and in the Kubernetes pod:

Если полученные IP-адреса не совпадают, проверьте настройки DNS на узле. Обратите внимание на список доменов в параметре search файла /etc/resolv.conf (он влияет на разрешение имен в поде Deckhouse). Если в параметре search файла /etc/resolv.conf указан домен, в котором настроено разрешение wildcard-записей, это может привести к неверному разрешению IP-адреса хранилища образов Deckhouse (см. пример).

• The /etc/resolv.conf file on the node:

text nameserver 10.0.0.10 search company.my

Пример, когда настройки DNS приводят к различному результату при разрешении имен на узле и в поде Kubernetes:

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.

• Пример файла /etc/resolv.conf на узле:

• 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.

text nameserver 10.0.0.10 search company.my

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).

Обратите внимание, что по умолчанию на узле параметр ndot равен 1 (options ndots:1). Но в подах Kubernetes параметр ndot равен 5. Таким образом, логика разрешения DNS-имен, имеющих в имени 5 точек и менее, различается на узле и в поде.

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.

• В DNS-зоне company.my настроено разрешение wildcard-записей *.company.my в адрес 10.0.0.100. То есть любое DNS-имя в зоне company.my, для которого нет конкретной записи в DNS, разрешается в адрес 10.0.0.100.

С учетом параметра search, указанного в файле /etc/resolv.conf, при обращении на адрес registry.deckhouse.ru на узле, система пытается получить IP-адрес для имени registry.deckhouse.ru (так как считает его полностью определенным, учитывая настройку по умолчанию параметра options ndots:1).

How to check the job queue in Deckhouse?

При обращении на адрес registry.deckhouse.ru из пода Kubernetes, учитывая параметры options ndots:5 (используется в Kubernetes по умолчанию) и search, система первоначально попытается получить IP-адрес для имени registry.deckhouse.ru.company.my. Это имя будет разрешено для IP-адреса 10.0.0.100, так как в DNS-зоне company.my настроено разрешение wildcard-записей *.company.my для адреса 10.0.0.100. В результате к хосту registry.deckhouse.ru будет невозможно подключиться и скачать информацию о доступных обновлениях Deckhouse.

To view the status of all Deckhouse job queues, run the following command:

Как проверить очередь заданий в Deckhouse?

shell kubectl -n d8-system exec -it svc/deckhouse-leader -c deckhouse – deckhouse-controller queue list

Для просмотра состояния всех очередей заданий Deckhouse, выполните следующую команду:

Example of the output (queues are empty):

shell kubectl -n d8-system exec -it svc/deckhouse-leader -c deckhouse – deckhouse-controller queue list

console Summary:

• ‘main’ queue: empty.
• 88 other queues (0 active, 88 empty): 0 tasks.
• no tasks to handle.

Пример вывода (очереди пусты):

To view the status of the main Deckhouse task queue, run the following command:

console Summary:

• ‘main’ queue: empty.
• 88 other queues (0 active, 88 empty): 0 tasks.
• no tasks to handle.

shell kubectl -n d8-system exec -it svc/deckhouse-leader -c deckhouse – deckhouse-controller queue main

Для просмотра состояния очереди заданий main Deckhouse, выполните следующую команду:

Example of the output (38 tasks in the main queue):

shell kubectl -n d8-system exec -it svc/deckhouse-leader -c deckhouse – deckhouse-controller queue main

console Queue ‘main’: length 38, status: ‘run first task’

Пример вывода (в очереди main 38 заданий):

Example of the output (the main queue is empty):

console Queue ‘main’: length 38, status: ‘run first task’

console Queue ‘main’: length 0, status: ‘waiting for task 0s’

Пример вывода (очередь main пуста):

Air-gapped environment; working via proxy and third-party registry

console Queue ‘main’: length 0, status: ‘waiting for task 0s’

How do I configure Deckhouse to use a third-party registry?

Закрытое окружение, работа через proxy и сторонние registry

This feature is available in the following editions: BE, SE, SE+, EE.

Как установить Deckhouse из стороннего registry?

Deckhouse only supports Bearer authentication for container registries.

Доступно в следующих редакциях: BE, SE, SE+, EE, CSE Lite (1.67), CSE Pro (1.67).

Tested and guaranteed to work with the following container registries: {{- registry[1].shortname }} , .

Deckhouse поддерживает работу только с Bearer token-схемой авторизации в container registry.

Deckhouse can be configured to work with a third-party registry (e.g., a proxy registry inside private environments).

Протестирована и гарантируется работа со следующими container registry: {{- registry[1].shortname }} , .

Define the following parameters in the InitConfiguration resource:

При установке Deckhouse можно настроить на работу со сторонним registry (например, проксирующий registry внутри закрытого контура).

• 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.

Установите следующие параметры в ресурсе InitConfiguration:

Use the following registryDockerCfg if anonymous access to Deckhouse images is allowed in the third-party registry:

• imagesRepo: <PROXY_REGISTRY>/<DECKHOUSE_REPO_PATH>/ee — адрес образа Deckhouse EE в стороннем registry. Пример: imagesRepo: registry.deckhouse.ru/deckhouse/ee;
• registryDockerCfg: <BASE64> — права доступа к стороннему registry, зашифрованные в Base64.

json {“auths”: { “": {}}}

Если разрешен анонимный доступ к образам Deckhouse в стороннем registry, registryDockerCfg должен выглядеть следующим образом:

registryDockerCfg must be Base64-encoded.

json {“auths”: { “": {}}}

Use the following registryDockerCfg if authentication is required to access Deckhouse images in the third-party registry:

Приведенное значение должно быть закодировано в Base64.

json {“auths”: { “": {"username":"","password":"","auth":""}}}

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

• <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.

json {“auths”: { “": {"username":"","password":"","auth":""}}}

registryDockerCfg must be Base64-encoded.

где:

You can use the following script to generate registryDockerCfg:

• <PROXY_USERNAME> — имя пользователя для аутентификации на <PROXY_REGISTRY>;
• <PROXY_PASSWORD> — пароль пользователя для аутентификации на <PROXY_REGISTRY>;
• <PROXY_REGISTRY> — адрес стороннего registry в виде <HOSTNAME>[:PORT];
• <AUTH_BASE64> — строка вида <PROXY_USERNAME>:<PROXY_PASSWORD>, закодированная в Base64.

shell declare MYUSER=’' declare MYPASSWORD='' declare MYREGISTRY=''

Итоговое значение для registryDockerCfg должно быть также закодировано в Base64.

Вы можете использовать следующий скрипт для генерации registryDockerCfg:

echo “$MYRESULTSTRING”

shell declare MYUSER=’' declare MYPASSWORD='' declare MYREGISTRY=''

The InitConfiguration resource provides two more parameters for non-standard third-party registry configurations:

• 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.

echo “$MYRESULTSTRING”

Для настройки нестандартных конфигураций сторонних registry в ресурсе InitConfiguration предусмотрены еще два параметра:

Tips for configuring Nexus

• registryCA — корневой сертификат, которым можно проверить сертификат registry (если registry использует самоподписанные сертификаты);
• registryScheme — протокол доступа к registry (HTTP или HTTPS). По умолчанию — HTTPS.

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.

Using the URL value from the Nexus repository options is not acceptable

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

The following requirements must be met if the Nexus repository manager is used:

При взаимодействии с репозиторием типа docker расположенным в Nexus (например, при выполнении команд docker pull, docker push) требуется указывать адрес в формате <NEXUS_URL>:<REPOSITORY_PORT>/<PATH>.

• Docker proxy repository must be pre-created (Administration -> Repository -> Repositories):
• The Maximum metadata age parameter is set to 0 for the repository.
• Access control configured as follows:
• The Nexus role is created (Administration -> Security -> Roles) with the following permissions:
• nx-repository-view-docker-<repository>-browse
• nx-repository-view-docker-<repository>-read
• A user (Administration -> Security -> Users) with the Nexus role is created.

Использование значения URL из параметров репозитория Nexus недопустимо

Configuration:

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

1. Create a docker proxy repository (Administration -> Repository -> Repositories) pointing to the Deckhouse registry:

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

1. 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.
   • 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 a commercial edition of Deckhouse Kubernetes Platform, 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 Deckhouse Kubernetes Platform license key.

Настройка:

1. Создайте проксирующий репозиторий Docker (Administration -> Repository -> Repositories), указывающий на Deckhouse registry:

1. 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-<repository>-browse and nx-repository-view-docker-<repository>-read permissions.

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

• Create a user with the role above granted.

1. Настройте контроль доступа Nexus для доступа Deckhouse к созданному репозиторию:
   • Создайте роль Nexus (Administration -> Security -> Roles) с полномочиями nx-repository-view-docker-<репозиторий>-browse и nx-repository-view-docker-<репозиторий>-read.

Thus, Deckhouse images will be available at https://<NEXUS_HOST>:<REPOSITORY_PORT>/deckhouse/ee:<d8s-version>.

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

Tips for configuring Harbor

Use the Harbor Proxy Cache feature.

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

• 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 (the Deckhouse Kubernetes Platform license key).

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

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

• 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.

• Настройте Registry:
• Administration -> Registries -> New Endpoint.
• Provider: Docker Registry.
• Name — укажите любое, на ваше усмотрение.
• Endpoint URL: https://registry.deckhouse.ru.
• Укажите Access ID и Access Secret (лицензионный ключ для Deckhouse Kubernetes Platform).

Thus, Deckhouse images will be available at https://your-harbor.com/d8s/deckhouse/ee:{d8s-version}.

• Создайте новый проект:
• Projects -> New Project.
• Project Name будет частью URL. Используйте любой, например, d8s.
• Access Level: Public.
• Proxy Cache — включите и выберите в списке Registry, созданный на предыдущем шаге.

Manually uploading Deckhouse Kubernetes Platform, vulnerability scanner DB and Deckhouse modules to private registry

The d8 mirror command group is not available for Community Edition (CE) and Basic Edition (BE).

В результате настройки, образы Deckhouse станут доступны, например, по следующему адресу: https://your-harbor.com/d8s/deckhouse/ee:{d8s-version}.

Check releases.deckhouse.io for the current status of the release channels.

Ручная загрузка образов Deckhouse Kubernetes Platform, БД сканера уязвимостей и модулей Deckhouse в приватный registry

1. Download and install the Deckhouse CLI tool.

Утилита d8 mirror недоступна для использования с редакциями Community Edition (CE) и Basic Edition (BE).

1. Pull Deckhouse images using the d8 mirror pull command.

О текущем статусе версий на каналах обновлений можно узнать на releases.deckhouse.ru.

By default, d8 mirror pulls only the latest available patch versions for every actual Deckhouse release, latest enterprise security scanner databases (if your edition supports it) 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.

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

Run the following command (specify the edition code and the license key) to download actual images:

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

shell d8 mirror pull
–source=’registry.deckhouse.io/deckhouse/' \ --license='' /home/user/d8-bundle

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

where:

• <EDITION> — the edition code of the Deckhouse Kubernetes Platform (for example, ee, se);
• <LICENSE_KEY> — Deckhouse Kubernetes Platform license key.
• /home/user/d8-bundle — the directory to store the resulting bundle into. It will be created if not present.

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

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.

shell d8 mirror pull
–source=’registry.deckhouse.ru/deckhouse/' \ --license='' /home/user/d8-bundle

You can also use the following command options:

• --no-pull-resume — to forcefully start the download from the beginning;
• --no-platform — to skip downloading the Deckhouse Kubernetes Platform package (platform.tar);
• --no-modules — to skip downloading modules packages (module-*.tar);
• --no-security-db — to skip downloading security scanner databases (security.tar);
• --since-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 --deckhouse-tag parameter;
• --deckhouse-tag — to download only a specific build of Deckhouse (without considering update channels). This parameter cannot be used simultaneously with the --since-version parameter;
• --include-module / -i = name[@X.Y.Z] — to download only a specific whitelist of modules (and optionally their minimal versions). Specify multiple times to whitelist more modules. This flags are ignored if used with --no-modules.
• --exclude-module / -e = name — to skip downloading of a specific blacklisted set of modules. Specify multiple times to blacklist more modules. Ignored if --no-modules or --include-module are used.
• --modules-path-suffix — to change the suffix of the module repository path in the main Deckhouse repository. By default, the suffix is /modules. (for example, the full path to the repository with modules will look like registry.deckhouse.io/deckhouse/EDITION/modules with this default).
• --gost-digest — for calculating the checksums of the bundle in the format of GOST R 34.11-2012 (Streebog). The checksum for each package will be displayed and written to a file with the extension .tar.gostsum in the folder with the package;
• --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).

где:

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;

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

Example of a command to download all versions of Deckhouse EE starting from version 1.59 (provide the license key):

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

shell d8 mirror pull
–license=’' \ --source='registry.deckhouse.io/deckhouse/ee' \ --since-version=1.59 /home/user/d8-bundle

Вы также можете использовать следующие параметры команды:

Example of a command to download versions of Deckhouse SE for every release-channel available:

• --no-pull-resume — чтобы принудительно начать загрузку сначала;
• --no-platform — для пропуска загрузки пакета образов Deckhouse Kubernetes Platform (platform.tar);
• --no-modules — для пропуска загрузки пакетов модулей (module-*.tar);
• --no-security-db — для пропуска загрузки пакета баз данных сканера уязвимостей (security.tar);
• --include-module / -i = name[@X.Y.Z] — для загрузки только определенного набора модулей по принципу белого списка (и, при необходимости, их минимальных версий). Укажите несколько раз, чтобы добавить в белый список больше модулей. Эти флаги игнорируются, если используются совместно с --no-modules.
• --exclude-module / -e = name — для пропуска загрузки определенного набора модулей по принципу черного списка. Укажите несколько раз, чтобы добавить в черный список больше модулей. Игнорируется, если используются --no-modules или --include-module.
• --modules-path-suffix — для изменения суффикса пути к репозиторию модулей в основном репозитории Deckhouse. По умолчанию используется суффикс /modules (так, например, полный путь к репозиторию с модулями будет выглядеть как registry.deckhouse.ru/deckhouse/EDITION/modules).
• --since-version=X.Y — чтобы скачать все версии Deckhouse, начиная с указанной минорной версии. Параметр будет проигнорирован, если указана версия выше чем версия находящаяся на канале обновлений Rock Solid. Параметр не может быть использован одновременно с параметром --deckhouse-tag;
• --deckhouse-tag — чтобы скачать только конкретную версию Deckhouse (без учета каналов обновлений). Параметр не может быть использован одновременно с параметром --since-version;
• --gost-digest — для расчета контрольной суммы итогового набора образов Deckhouse в формате ГОСТ Р 34.11-2012 (Стрибог). Контрольная сумма будет отображена и записана в файл с расширением .tar.gostsum в папке с tar-архивом, содержащим образы Deckhouse;
• --source — чтобы указать адрес источника хранилища образов Deckhouse (по умолчанию registry.deckhouse.ru/deckhouse/ee);
• Для аутентификации в официальном хранилище образов 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).

shell d8 mirror pull
–license=’' \ --source='registry.deckhouse.io/deckhouse/se' \ /home/user/d8-bundle

Дополнительные параметры конфигурации для семейства команд d8 mirror доступны в виде переменных окружения:

Example of a command to download all versions of Deckhouse hosted on a third-party registry:

• 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;

shell d8 mirror pull
–source=’corp.company.com:5000/sys/deckhouse’
–source-login=’' --source-password='' /home/user/d8-bundle

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

Example of a command to download latest vulnerability scanner databases (if available for your deckhouse edition):

shell d8 mirror pull
–license=’' \ --since-version=1.59 /home/user/d8-bundle

shell d8 mirror pull
–license=’' \ --source='registry.deckhouse.io/deckhouse/ee' \ --no-platform --no-modules /home/user/d8-bundle

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

Example of a command to download all of Deckhouse modules available in registry:

shell d8 mirror pull
–license=’' \ --source='registry.deckhouse.ru/deckhouse/se' \ /home/user/d8-bundle

shell d8 mirror pull
–license=’' \ --source='registry.deckhouse.io/deckhouse/ee' \ --no-platform --no-security-db /home/user/d8-bundle

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

Example of a command to download stronghold and secrets-store-integration Deckhouse modules:

shell d8 mirror pull
–source=’corp.company.com:5000/sys/deckhouse’
–source-login=’' --source-password='' /home/user/d8-bundle

shell d8 mirror pull
–license=’' \ --source='registry.deckhouse.io/deckhouse/ee' \ --no-platform --no-security-db \ --include-module stronghold \ --include-module secrets-store-integration \ /home/user/d8-bundle

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

1. Upload the bundle with the pulled Deckhouse images to a host with access to the air-gapped registry and install the Deckhouse CLI tool onto it.

shell d8 mirror pull
–license=’' \ --no-platform --no-modules /home/user/d8-bundle

1. Push the images to the air-gapped registry using the d8 mirror push command.

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

The d8 mirror push command uploads images from all packages present in the given directory to the repository. If you need to upload only some specific packages to the repository, you can either run the command for each required package, passing in the direct path to the tar package instead of the directory, or by removing the .tar extension from unnecessary packages or moving them outside the directory.

shell d8 mirror pull
–license=’' \ --no-platform --no-security-db /home/user/d8-bundle

Example of a command for pushing images from the /mnt/MEDIA/d8-images directory (specify authorization data if necessary):

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

shell d8 mirror push /mnt/MEDIA/d8-images ‘corp.company.com:5000/sys/deckhouse’
–registry-login=’' --registry-password=''

shell d8 mirror pull
–license=’' \ --no-platform --no-security-db \ --include-module stronghold \ --include-module secrets-store-integration \ /home/user/d8-bundle

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.

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

1. 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.

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

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.

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

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).

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

After installation, apply DeckhouseReleases manifests that were generated by the d8 mirror pull command to your cluster via Deckhouse CLI as follows:

shell d8 mirror push /mnt/MEDIA/d8-images ‘corp.company.com:5000/sys/deckhouse’
–registry-login=’' --registry-password=''

shell d8 k apply -f ./deckhousereleases.yaml

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

How do I switch a running Deckhouse cluster to use a third-party registry?

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

Using a registry other than registry.deckhouse.io is only available in a commercial edition of Deckhouse Kubernetes Platform.

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

To switch the Deckhouse cluster to using a third-party registry, follow these steps:

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

• Run deckhouse-controller helper change-registry inside the Deckhouse Pod with the new registry settings.
• Example:

После завершения установки примените сгенерированные во время загрузки манифесты DeckhouseReleases к вашему кластеру, используя Deckhouse CLI:

shell kubectl -n d8-system exec -ti svc/deckhouse-leader -c deckhouse – deckhouse-controller helper change-registry –user MY-USER –password MY-PASSWORD registry.example.com/deckhouse/ee

shell d8 k apply -f ./deckhousereleases.yaml

• 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:

Как переключить работающий кластер Deckhouse на использование стороннего registry?

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”

Использование registry, отличных от registry.deckhouse.io и registry.deckhouse.ru, доступно только в коммерческих редакциях Deckhouse Kubernetes Platform.

• To view the list of available keys of the deckhouse-controller helper change-registry command, run the following command:

Для переключения кластера Deckhouse на использование стороннего registry выполните следующие действия:

shell kubectl -n d8-system exec -ti svc/deckhouse-leader -c deckhouse – deckhouse-controller helper change-registry –help

1. Выполните команду deckhouse-controller helper change-registry из пода Deckhouse с параметрами нового registry. Пример запуска:

Example output:

shell kubectl -n d8-system exec -ti svc/deckhouse-leader -c deckhouse – deckhouse-controller helper change-registry –user MY-USER –password MY-PASSWORD registry.example.com/deckhouse/ee

console usage: deckhouse-controller helper change-registry []

1. Если registry использует самоподписанные сертификаты, положите корневой сертификат соответствующего сертификата registry в файл /tmp/ca.crt в поде Deckhouse и добавьте к вызову опцию --ca-file /tmp/ca.crt или вставьте содержимое CA в переменную, как в примере ниже:

Change registry for deckhouse images.

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”

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).

Просмотреть список доступных ключей команды deckhouse-controller helper change-registry можно, выполнив следующую команду:

Args:

shell kubectl -n d8-system exec -ti svc/deckhouse-leader -c deckhouse – deckhouse-controller helper change-registry –help

• 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):

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

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

console usage: deckhouse-controller helper change-registry []

How to bootstrap a cluster and run Deckhouse without the usage of release channels?

Change registry for deckhouse images.

This method should only be used if there are no release channel images in your air-gapped registry.

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).

If you want to install Deckhouse with automatic updates disabled:

Args:

1. Use the installer image tag of the corresponding version. For example, if you want to install the v1.44.3 release, use the your.private.registry.com/deckhouse/install:v1.44.3 image.
2. Specify the corresponding version number in the deckhouse.devBranch parameter in the InitConfiguration resource.

   Do not specify the deckhouse.releaseChannel parameter in the InitConfiguration resource.

1. Дождитесь перехода пода Deckhouse в статус Ready. Если под находится в статусе ImagePullBackoff, перезапустите его.
2. Дождитесь применения bashible новых настроек на master-узле. В журнале bashible на master-узле (journalctl -u bashible) должно появится сообщение Configuration is in sync, nothing to do.
3. Если необходимо отключить автоматическое обновление Deckhouse через сторонний registry, удалите параметр releaseChannel из конфигурации модуля deckhouse.
4. Проверьте, не осталось ли в кластере подов с оригинальным адресом registry:

If you want to disable automatic updates for an already installed Deckhouse (including patch release updates), remove the releaseChannel parameter from the deckhouse module configuration.

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

Using a proxy server

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

This feature is available in the following editions: BE, SE, SE+, EE.

Этот способ следует использовать только в случае, если в изолированном приватном registry нет образов, содержащих информацию о каналах обновлений.

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

• 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):

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

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

shell apt-get install squid

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

• Create a config file:

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

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

Доступно в следующих редакциях: BE, SE, SE+, EE, CSE Lite (1.67), CSE Pro (1.67).

Choose the port you want. Below we set it to default 3128. http_port 3128

• Create a user for proxy-server authentication:

1. Подготовьте сервер (или виртуальную машину). Сервер должен быть доступен с необходимых узлов кластера, и у него должен быть выход в интернет.
2. Установите Squid (здесь и далее примеры для Ubuntu):

Example for the user test with the password test (be sure to change):

shell apt-get install squid

shell echo “test:$(openssl passwd -crypt test)” » /etc/squid/passwords

1. Создайте файл конфигурации Squid:

• Start squid and enable the system to start it up automatically:

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 systemctl restart squid systemctl enable squid

Укажите необходимый порт. Порт 3128 используется по умолчанию. http_port 3128

1. Создайте пользователя и пароль для аутентификации на proxy-сервере:

Use the proxy parameter of the ClusterConfiguration resource to configure proxy usage.

Пример для пользователя test с паролем test (обязательно измените):

An example:

shell echo “test:$(openssl passwd -crypt test)” » /etc/squid/passwords

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”

1. Запустите Squid и включите его автоматический запуск при загрузке сервера:

Changing the configuration

shell systemctl restart squid systemctl enable squid

To apply node configuration changes, you need to run the dhctl converge using the Deckhouse installer. This command synchronizes the state of the nodes with the specified configuration.

How do I change the configuration of a cluster?

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

The general cluster parameters are stored in the ClusterConfiguration structure.

Пример:

To change the general cluster parameters, run the command:

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”

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.

Для применения изменений конфигурации узлов необходимо выполнить команду dhctl converge, запустив инсталлятор 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.

Общие параметры кластера хранятся в структуре ClusterConfiguration.

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 cluster-configuration

How do I change the configuration of a static cluster?

После сохранения изменений Deckhouse приведет конфигурацию кластера к измененному состоянию. В зависимости от размеров кластера это может занять какое-то время.

Settings of a static cluster are stored in the StaticClusterConfiguration structure.

Как изменить конфигурацию облачного провайдера в кластере?

To change the settings of a static cluster, run the command:

Настройки используемого облачного провайдера в облачном или гибридном кластере хранятся в структуре <PROVIDER_NAME>ClusterConfiguration, где <PROVIDER_NAME> — название/код провайдера. Например, для провайдера OpenStack структура будет называться OpenStackClusterConfiguration.

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?

shell kubectl -n d8-system exec -ti svc/deckhouse-leader -c deckhouse – deckhouse-controller edit provider-cluster-configuration

The instruction implies using the public address of the container registry: registry.deckhouse.io. Using a registry other than registry.deckhouse.io is only available in a commercial edition of Deckhouse Kubernetes Platform.

Как изменить конфигурацию статического кластера?

Deckhouse CE does not support cloud clusters on OpenStack and VMware vSphere.

Настройки статического кластера хранятся в структуре StaticClusterConfiguration.

Follow this steps to switch a Deckhouse Enterprise Edition to Community Edition (all commands must be executed on the master node, either by a user with a configured kubectl context or by a superuser):

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

1. Run a temporary Deckhouse CE pod to retrieve up-to-date digests and module lists:

shell kubectl -n d8-system exec -ti svc/deckhouse-leader -c deckhouse – deckhouse-controller edit static-cluster-configuration

shell DECKHOUSE_VERSION=$(kubectl -n d8-system get deploy deckhouse -ojson | jq -r ‘.spec.template.spec.containers[] | select(.name == “deckhouse”) | .image’ | awk -F: ‘{print $2}’) kubectl run ce-image –image=registry.deckhouse.io/deckhouse/ce/install:$DECKHOUSE_VERSION –command sleep – infinity

Как переключить Deckhouse EE на CE?

Run an image of the latest installed Deckhouse version in the cluster. To find out which version is currently installed, use the following command:

shell kubectl get deckhousereleases | grep Deployed

Инструкция подразумевает использование публичного адреса container registry: registry.deckhouse.ru. Использование registry, отличных от registry.deckhouse.io и registry.deckhouse.ru, доступно только в коммерческих редакциях Deckhouse Kubernetes Platform.

1. Wait for the pod to become Running and then run the following commands:

В Deckhouse CE не поддерживается работа облачных кластеров на OpenStack и VMware vSphere.

• Retrieve the value of CE_SANDBOX_IMAGE:

Для переключения Deckhouse Enterprise Edition на Community Edition выполните следующие действия (все команды выполняются на master-узле кластера от имени пользователя с настроенным контекстом kubectl или от имени суперпользователя):

shell CE_SANDBOX_IMAGE=$(kubectl exec ce-image – cat deckhouse/candi/images_digests.json | jq -r “.common.pause”)

1. Выполните следующую команду для запуска временного пода Deckhouse CE для получения актуальных дайджестов и списка модулей:

Check the result of the command to make sure it was successful:

shell DECKHOUSE_VERSION=$(kubectl -n d8-system get deploy deckhouse -ojson | jq -r ‘.spec.template.spec.containers[] | select(.name == “deckhouse”) | .image’ | awk -F: ‘{print $2}’) kubectl run se-image –image=registry.deckhouse.ru/deckhouse/ce/install:$DECKHOUSE_VERSION –command sleep – infinity

shell echo $CE_SANDBOX_IMAGE

Запускайте образ последней установленной версии Deckhouse в кластере. Определить, какая версия сейчас установлена, можно командой:

shell kubectl get deckhousereleases | grep Deployed

Example output:

1. Как только под перейдёт в статус Running, выполните следующие команды:

console sha256:2a909cb9df4d0207f1fe5bd9660a0529991ba18ce6ce7b389dc008c05d9022d1

• Получите значение CE_SANDBOX_IMAGE:

• Retrieve the value of CE_K8S_API_PROXY:

shell CE_SANDBOX_IMAGE=$(kubectl exec ce-image – cat deckhouse/candi/images_digests.json | jq -r “.common.pause”)

shell CE_K8S_API_PROXY=$(kubectl exec ce-image – cat deckhouse/candi/images_digests.json | jq -r “.controlPlaneManager.kubernetesApiProxy”)

Проверка:

Check the result of the command to make sure it was successful:

shell echo $CE_SANDBOX_IMAGE

shell echo $CE_K8S_API_PROXY

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

Example output:

console sha256:2a909cb9df4d0207f1fe5bd9660a0529991ba18ce6ce7b389dc008c05d9022d1

console sha256:a5442437976a11dfa4860c2fbb025199d9d1b074222bb80173ed36b9006341dd

• Получите значение CE_K8S_API_PROXY:

• Retrieve the value of CE_REGISTRY_PACKAGE_PROXY:

shell CE_K8S_API_PROXY=$(kubectl exec ce-image – cat deckhouse/candi/images_digests.json | jq -r “.controlPlaneManager.kubernetesApiProxy”)

shell CE_REGISTRY_PACKAGE_PROXY=$(kubectl exec ce-image – cat deckhouse/candi/images_digests.json | jq -r “.registryPackagesProxy.registryPackagesProxy”)

Проверка:

Run the command:

shell echo $CE_K8S_API_PROXY

shell crictl pull registry.deckhouse.io/deckhouse/ce@$CE_REGISTRY_PACKAGE_PROXY

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

Example output:

console sha256:a5442437976a11dfa4860c2fbb025199d9d1b074222bb80173ed36b9006341dd

console Image is up to date for sha256:8127efa0f903a7194d6fb7b810839279b9934b200c2af5fc416660857bfb7832

• Получите значение CE_REGISTRY_PACKAGE_PROXY:

• Retrieve the value of CE_MODULES:

shell CE_REGISTRY_PACKAGE_PROXY=$(kubectl exec ce-image – cat deckhouse/candi/images_digests.json | jq -r “.registryPackagesProxy.registryPackagesProxy”)

shell CE_MODULES=$(kubectl exec ce-image – ls -l deckhouse/modules/ | grep -oE “\d.-\w” | awk {‘print $9’} | cut -c5-)

И выполните команду:

Check the result of the command to make sure it was successful:

shell crictl pull registry.deckhouse.ru/deckhouse/ce@$CE_REGISTRY_PACKAGE_PROXY

shell echo $CE_MODULES

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

Example output:

console Image is up to date for sha256:8127efa0f903a7194d6fb7b810839279b9934b200c2af5fc416660857bfb7832

console common priority-class deckhouse external-module-manager registrypackages …

• Получите значение CE_MODULES:

• Retrieve the value of USED_MODULES:

shell CE_MODULES=$(kubectl exec ce-image – ls -l deckhouse/modules/ | grep -oE “\d.-\w” | awk {‘print $9’} | cut -c5-)

shell USED_MODULES=$(kubectl get modules -o custom-columns=NAME:.metadata.name,SOURCE:.properties.source,STATE:.properties.state,ENABLED:.status.phase | grep Embedded | grep -E ‘Enabled|Ready’ | awk {‘print $1’})

Проверка:

Check the result of the command to make sure it was successful:

shell echo $CE_MODULES

shell echo $USED_MODULES

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

Example output:

console common priority-class deckhouse external-module-manager registrypackages …

console admission-policy-engine cert-manager chrony …

• Получите значение USED_MODULES:

• Retrieve the value of MODULES_WILL_DISABLE:

shell USED_MODULES=$(kubectl get modules -o custom-columns=NAME:.metadata.name,SOURCE:.properties.source,STATE:.properties.state,ENABLED:.status.phase | grep Embedded | grep -E ‘Enabled|Ready’ | awk {‘print $1’})

shell MODULES_WILL_DISABLE=$(echo $USED_MODULES | tr ‘ ‘ ‘\n’ | grep -Fxv -f <(echo $CE_MODULES | tr ‘ ‘ ‘\n’))

Проверка:

Check the result of the command to make sure it was successful:

shell echo $USED_MODULES

shell echo $MODULES_WILL_DISABLE

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

Example output:

console admission-policy-engine cert-manager chrony …

console node-local-dns registry-packages-proxy

• Получите значение MODULES_WILL_DISABLE:

Note that if registry-packages-proxy is listed in $MODULES_WILL_DISABLE, you will need to enable it back, otherwise the cluster will not be able to migrate to Deckhouse CE images. See paragraph 8 on how to enable it.

shell MODULES_WILL_DISABLE=$(echo $USED_MODULES | tr ‘ ‘ ‘\n’ | grep -Fxv -f <(echo $CE_MODULES | tr ‘ ‘ ‘\n’))

1. Ensure that the modules used in the cluster are supported in Deckhouse CE.

Проверка:

For this, print a list of modules that are not supported in Deckhouse CE and will be disabled:

shell echo $MODULES_WILL_DISABLE

shell echo $MODULES_WILL_DISABLE

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

Inspect the list and make sure that the listed modules are not in use in the cluster and that it is safe to disable them.

console node-local-dns registry-packages-proxy

Disable the modules that are not supported in Deckhouse CE:

Обратите внимание, если в $MODULES_WILL_DISABLE указана registry-packages-proxy, то его надо будет включить обратно, иначе кластер не сможет перейти на образы Deckhouse CE. Включение в 8 пункте.

shell echo $MODULES_WILL_DISABLE | tr ‘ ‘ ‘\n’ | awk {‘print “kubectl -n d8-system exec deploy/deckhouse – deckhouse-controller module disable”,$1’} | bash

1. Убедитесь, что используемые в кластере модули поддерживаются в Deckhouse CE.

An example of the output you might get as a result of running the previous command:

Отобразить список модулей, которые не поддерживаются в Deckhouse CE и будут отключены, можно следующей командой:

console Defaulted container “deckhouse” out of: deckhouse, kube-rbac-proxy, init-external-modules (init) Module node-local-dns disabled

shell echo $MODULES_WILL_DISABLE

Defaulted container “deckhouse” out of: deckhouse, kube-rbac-proxy, init-external-modules (init) Module registry-packages-proxy disabled

Проверьте список и убедитесь, что функциональность указанных модулей не задействована вами в кластере и вы готовы к их отключению.

1. Create a NodeGroupConfiguration resource:

Отключите не поддерживаемые в Deckhouse CE модули:

shell kubectl apply -f - «EOF apiVersion: deckhouse.io/v1alpha1 kind: NodeGroupConfiguration metadata: name: containerd-ce-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 echo $MODULES_WILL_DISABLE | tr ‘ ‘ ‘\n’ | awk {‘print “kubectl -n d8-system exec deploy/deckhouse – deckhouse-controller module disable”,$1’} | bash

mkdir -p /etc/containerd/conf.d bb-sync-file /etc/containerd/conf.d/ce-registry.toml - containerd-config-file-changed « “EOF_TOML” [plugins] [plugins.”io.containerd.grpc.v1.cri”] sandbox_image = “registry.deckhouse.io/deckhouse/ce@$CE_SANDBOX_IMAGE” [plugins.”io.containerd.grpc.v1.cri”.registry.configs] [plugins.”io.containerd.grpc.v1.cri”.registry.configs.”registry.deckhouse.io”.auth] auth = “” EOF_TOML

Пример результата выполнения:

console Defaulted container “deckhouse” out of: deckhouse, kube-rbac-proxy, init-external-modules (init) Module node-local-dns disabled

EOF

1. Создайте ресурс NodeGroupConfiguration:

Wait for the /etc/containerd/conf.d/ce-registry.toml file to propagate to the nodes and for bashible synchronization to complete.

shell kubectl apply -f - «EOF apiVersion: deckhouse.io/v1alpha1 kind: NodeGroupConfiguration metadata: name: containerd-ce-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’

The synchronization status can be tracked by the UPTODATE value (the displayed number of nodes in this status must match the total number of nodes (NODES) in the group):

mkdir -p /etc/containerd/conf.d bb-sync-file /etc/containerd/conf.d/ce-registry.toml - containerd-config-file-changed « “EOF_TOML” [plugins] [plugins.”io.containerd.grpc.v1.cri”] sandbox_image = “registry.deckhouse.ru/deckhouse/ce@$CE_SANDBOX_IMAGE” [plugins.”io.containerd.grpc.v1.cri”.registry.configs] [plugins.”io.containerd.grpc.v1.cri”.registry.configs.”registry.deckhouse.ru”.auth] auth = “” EOF_TOML

shell kubectl get ng -o custom-columns=NAME:.metadata.name,NODES:.status.nodes,READY:.status.ready,UPTODATE:.status.upToDate -w

Example output:

EOF

console NAME NODES READY UPTODATE master 1 1 1 worker 2 2 2

Дождитесь появления файла /etc/containerd/conf.d/ce-registry.toml на узлах и завершения синхронизации bashible.

Also, the Configuration is in sync, nothing to do message must show up in the bashible systemd service log after you run the following command:

Статус синхронизации можно отследить по значению UPTODATE (отображаемое число узлов в этом статусе должно совпадать с общим числом узлов (NODES) в группе):

shell journalctl -u bashible -n 5

shell kubectl get ng -o custom-columns=NAME:.metadata.name,NODES:.status.nodes,READY:.status.ready,UPTODATE:.status.upToDate -w

Example output:

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

console Aug 21 11:04:28 master-ee-to-ce-0 bashible.sh[53407]: Configuration is in sync, nothing to do. Aug 21 11:04:28 master-ee-to-ce-0 bashible.sh[53407]: Annotate node master-ee-to-ce-0 with annotation node.deckhouse.io/ configuration-checksum=9cbe6db6c91574b8b732108a654c99423733b20f04848d0b4e1e2dadb231206a Aug 21 11:04:29 master-ee-to-ce-0 bashible.sh[53407]: Successful annotate node master-ee-to-ce-0 with annotation node.deckhouse.io/ configuration-checksum=9cbe6db6c91574b8b732108a654c99423733b20f04848d0b4e1e2dadb231206a Aug 21 11:04:29 master-ee-to-ce-0 systemd[1]: bashible.service: Deactivated successfully.

console NAME NODES READY UPTODATE master 1 1 1 worker 2 2 2

1. Update the secret to access the Deckhouse registry by running the following command:

Также в журнале systemd-сервиса bashible должно появиться сообщение Configuration is in sync, nothing to do в результате выполнения следующей команды:

bash kubectl -n d8-system create secret generic deckhouse-registry
–from-literal=”.dockerconfigjson”=”{"auths": { "registry.deckhouse.io": {}}}”
–from-literal=”address”=registry.deckhouse.io
–from-literal=”path”=/deckhouse/ce
–from-literal=”scheme”=https
–type=kubernetes.io/dockerconfigjson
–dry-run=’client’
-o yaml | kubectl -n d8-system exec -i svc/deckhouse-leader -c deckhouse – kubectl replace -f -

shell journalctl -u bashible -n 5

1. Apply the webhook-handler image:

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

shell HANDLER=$(kubectl exec ce-image – cat deckhouse/candi/images_digests.json | jq -r “.deckhouse.webhookHandler”) kubectl –as=system:serviceaccount:d8-system:deckhouse -n d8-system set image deployment/webhook-handler handler=registry.deckhouse.io/deckhouse/ce@$HANDLER

console Aug 21 11:04:28 master-ee-to-ce-0 bashible.sh[53407]: Configuration is in sync, nothing to do. Aug 21 11:04:28 master-ee-to-ce-0 bashible.sh[53407]: Annotate node master-ee-to-ce-0 with annotation node.deckhouse.io/ configuration-checksum=9cbe6db6c91574b8b732108a654c99423733b20f04848d0b4e1e2dadb231206a Aug 21 11:04:29 master-ee-to-ce-0 bashible.sh[53407]: Successful annotate node master-ee-to-ce-0 with annotation node.deckhouse.io/ configuration-checksum=9cbe6db6c91574b8b732108a654c99423733b20f04848d0b4e1e2dadb231206a Aug 21 11:04:29 master-ee-to-ce-0 systemd[1]: bashible.service: Deactivated successfully.

1. Apply the Deckhouse CE image:

1. Актуализируйте секрет доступа к registry Deckhouse, выполнив следующую команду:

shell DECKHOUSE_KUBE_RBAC_PROXY=$(kubectl exec ce-image – cat deckhouse/candi/images_digests.json | jq -r “.common.kubeRbacProxy”) DECKHOUSE_INIT_CONTAINER=$(kubectl exec ce-image – cat deckhouse/candi/images_digests.json | jq -r “.common.init”) DECKHOUSE_VERSION=$(kubectl -n d8-system get deploy deckhouse -ojson | jq -r ‘.spec.template.spec.containers[] | select(.name == “deckhouse”) | .image’ | awk -F: ‘{print $2}’) kubectl –as=system:serviceaccount:d8-system:deckhouse -n d8-system set image deployment/deckhouse init-downloaded-modules=registry.deckhouse.io/deckhouse/ce@$DECKHOUSE_INIT_CONTAINER kube-rbac-proxy=registry.deckhouse.io/deckhouse/ce@$DECKHOUSE_KUBE_RBAC_PROXY deckhouse=registry.deckhouse.io/deckhouse/ce:$DECKHOUSE_VERSION

bash kubectl -n d8-system create secret generic deckhouse-registry
–from-literal=”.dockerconfigjson”=”{"auths": { "registry.deckhouse.ru": {}}}”
–from-literal=”address”=registry.deckhouse.ru
–from-literal=”path”=/deckhouse/ce
–from-literal=”scheme”=https
–type=kubernetes.io/dockerconfigjson
–dry-run=’client’
-o yaml | kubectl -n d8-system exec -i svc/deckhouse-leader -c deckhouse – kubectl replace -f -

1. Wait for the Deckhouse pod to become Ready and for all the queued jobs to complete. If an ImagePullBackOff error is generated in the process, wait for the pod to be restarted automatically.

1. Примените образ webhook-handler:

Use the following command to check the Deckhouse pod’s status:

shell HANDLER=$(kubectl exec ce-image – cat deckhouse/candi/images_digests.json | jq -r “.deckhouse.webhookHandler”) kubectl –as=system:serviceaccount:d8-system:deckhouse -n d8-system set image deployment/webhook-handler handler=registry.deckhouse.ru/deckhouse/ce@$HANDLER

shell kubectl -n d8-system get po -l app=deckhouse

1. Примените образ Deckhouse CE:

Use the following command to check the Deckhouse queue:

shell DECKHOUSE_KUBE_RBAC_PROXY=$(kubectl exec ce-image – cat deckhouse/candi/images_digests.json | jq -r “.common.kubeRbacProxy”) DECKHOUSE_INIT_CONTAINER=$(kubectl exec ce-image – cat deckhouse/candi/images_digests.json | jq -r “.common.init”) DECKHOUSE_VERSION=$(kubectl -n d8-system get deploy deckhouse -ojson | jq -r ‘.spec.template.spec.containers[] | select(.name == “deckhouse”) | .image’ | awk -F: ‘{print $2}’) kubectl –as=system:serviceaccount:d8-system:deckhouse -n d8-system set image deployment/deckhouse init-downloaded-modules=registry.deckhouse.ru/deckhouse/ce@$DECKHOUSE_INIT_CONTAINER kube-rbac-proxy=registry.deckhouse.ru/deckhouse/ce@$DECKHOUSE_KUBE_RBAC_PROXY deckhouse=registry.deckhouse.ru/deckhouse/ce:$DECKHOUSE_VERSION

shell kubectl -n d8-system exec deploy/deckhouse -c deckhouse – deckhouse-controller queue list

1. Дождитесь перехода пода Deckhouse в статус Ready и выполнения всех задач в очереди. Если в процессе возникает ошибка ImagePullBackOff, подождите автоматического перезапуска пода.

1. Check if there are any pods with the Deckhouse EE registry address left in the cluster:

Посмотреть статус пода Deckhouse:

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 -n d8-system get po -l app=deckhouse

If the module was disabled in the process, enable it again:

shell kubectl -n d8-system exec deploy/deckhouse – deckhouse-controller module enable registry-packages-proxy

Проверить состояние очереди Deckhouse:

1. Purge temporary files, NodeGroupConfiguration resource, and variables:

shell kubectl -n d8-system exec deploy/deckhouse -c deckhouse – deckhouse-controller queue list

shell kubectl delete ngc containerd-ce-config.sh kubectl delete pod ce-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/ce-registry.toml ]; then rm -f /etc/containerd/conf.d/ce-registry.toml fi EOF

1. Проверьте, не осталось ли в кластере подов с адресом registry для Deckhouse EE:

Once bashible synchronization is complete (you can track the synchronization status on nodes via the UPTODATE value of the NodeGroup), delete the NodeGroupConfiguration resource you created earlier:

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

shell kubectl delete ngc del-temp-config.sh

Если в процессе был отключён модуль, включите его обратно:

shell kubectl -n d8-system exec deploy/deckhouse – deckhouse-controller module enable registry-packages-proxy

How to switch Deckhouse CE to EE?

1. Удалите временные файлы, ресурс NodeGroupConfiguration и переменные:

You will need a valid license key (you can request a trial license key if necessary).

shell kubectl delete ngc containerd-ce-config.sh kubectl delete pod ce-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/ce-registry.toml ]; then rm -f /etc/containerd/conf.d/ce-registry.toml fi EOF

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.

После синхронизации bashible (статус синхронизации на узлах можно отследить по значению UPTODATE у NodeGroup) удалите созданный ресурс NodeGroupConfiguration:

Follow this steps to switch a Deckhouse Community Edition to Enterprise Edition (all commands must be executed on the master node, either by a user with a configured kubectl context or by a superuser):

shell kubectl delete ngc del-temp-config.sh

1. Create the variables containing the license token:

Как переключить Deckhouse CE на EE?

shell LICENSE_TOKEN= AUTH_STRING="$(echo -n license-token:${LICENSE_TOKEN} | base64 )"

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

1. Create a NodeGroupConfiguration resource for authorization in registry.deckhouse.io during the migration:

Инструкция подразумевает использование публичного адреса container registry: registry.deckhouse.ru. В случае использования другого адреса container registry измените команды или воспользуйтесь инструкцией по переключению Deckhouse на использование стороннего registry.

shell kubectl apply -f - «EOF apiVersion: deckhouse.io/v1alpha1 kind: NodeGroupConfiguration metadata: name: containerd-ee-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’

Для переключения Deckhouse Community Edition на Enterprise Edition выполните следующие действия (все команды выполняются на master-узле кластера от имени пользователя с настроенным контекстом kubectl или от имени суперпользователя):

mkdir -p /etc/containerd/conf.d bb-sync-file /etc/containerd/conf.d/ee-registry.toml - containerd-config-file-changed « “EOF_TOML” [plugins] [plugins.”io.containerd.grpc.v1.cri”] [plugins.”io.containerd.grpc.v1.cri”.registry.configs] [plugins.”io.containerd.grpc.v1.cri”.registry.configs.”registry.deckhouse.io”.auth] auth = “$AUTH_STRING” EOF_TOML

1. Подготовьте переменные с токеном лицензии:

EOF

shell LICENSE_TOKEN= AUTH_STRING="$(echo -n license-token:${LICENSE_TOKEN} | base64 )"

Wait for the /etc/containerd/conf.d/ee-registry.toml file to propagate to the nodes and for bashible synchronization to complete.

1. Cоздайте ресурс NodeGroupConfiguration для переходной авторизации в registry.deckhouse.ru:

You can track the synchronization status via the UPTODATE value (the displayed number of nodes having this status must match the total number of nodes (NODES) in the group):

shell kubectl apply -f - «EOF apiVersion: deckhouse.io/v1alpha1 kind: NodeGroupConfiguration metadata: name: containerd-ee-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 get ng -o custom-columns=NAME:.metadata.name,NODES:.status.nodes,READY:.status.ready,UPTODATE:.status.upToDate -w

mkdir -p /etc/containerd/conf.d bb-sync-file /etc/containerd/conf.d/ee-registry.toml - containerd-config-file-changed « “EOF_TOML” [plugins] [plugins.”io.containerd.grpc.v1.cri”] [plugins.”io.containerd.grpc.v1.cri”.registry.configs] [plugins.”io.containerd.grpc.v1.cri”.registry.configs.”registry.deckhouse.ru”.auth] auth = “$AUTH_STRING” EOF_TOML

Example output:

EOF

console NAME NODES READY UPTODATE master 1 1 1 worker 2 2 2

Дождитесь появления файла /etc/containerd/conf.d/ee-registry.toml на узлах и завершения синхронизации bashible.

Also, the Configuration is in sync, nothing to do message must show up in the bashible systemd service log after you run the following command:

Статус синхронизации можно отследить по значению UPTODATE (отображаемое число узлов в этом статусе должно совпадать с общим числом узлов (NODES) в группе):

shell journalctl -u bashible -n 5

shell kubectl get ng -o custom-columns=NAME:.metadata.name,NODES:.status.nodes,READY:.status.ready,UPTODATE:.status.upToDate -w

Example output:

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

console Aug 21 11:04:28 master-ce-to-ee-0 bashible.sh[53407]: , nothing to do. Aug 21 11:04:28 master-ce-to-ee-0 bashible.sh[53407]: Annotate node master-ce-to-ee-0 with annotation node.deckhouse.io/ configuration-checksum=9cbe6db6c91574b8b732108a654c99423733b20f04848d0b4e1e2dadb231206a Aug 21 11:04:29 master ce-to-ee-0 bashible.sh[53407]: Successful annotate node master-ce-to-ee-0 with annotation node.deckhouse.io/ configuration-checksum=9cbe6db6c91574b8b732108a654c99423733b20f04848d0b4e1e2dadb231206a Aug 21 11:04:29 master-ce-to-ee-0 systemd[1]: bashible.service: Deactivated successfully.

console NAME NODES READY UPTODATE master 1 1 1 worker 2 2 2

Run a temporary Deckhouse EE pod to retrieve up-to-date digests and module lists:

Также в журнале systemd-сервиса bashible должно появиться сообщение Configuration is in sync, nothing to do в результате выполнения следующей команды:

shell DECKHOUSE_VERSION=$(kubectl -n d8-system get deploy deckhouse -ojson | jq -r ‘.spec.template.spec.containers[] | select(.name == “deckhouse”) | .image’ | awk -F: ‘{print $2}’) kubectl run ee-image –image=registry.deckhouse.io/deckhouse/ee/install:$DECKHOUSE_VERSION –command sleep – infinity

shell journalctl -u bashible -n 5

Run an image of the latest installed Deckhouse version in the cluster. To find out which version is currently installed, use the following command:

shell kubectl get deckhousereleases | grep Deployed

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

1. Wait for the pod to become Running and then run the following commands:

console Aug 21 11:04:28 master-ce-to-ee-0 bashible.sh[53407]: Configuration is in sync, nothing to do. Aug 21 11:04:28 master-ce-to-ee-0 bashible.sh[53407]: Annotate node master-ce-to-ee-0 with annotation node.deckhouse.io/ configuration-checksum=9cbe6db6c91574b8b732108a654c99423733b20f04848d0b4e1e2dadb231206a Aug 21 11:04:29 master ce-to-ee-0 bashible.sh[53407]: Successful annotate node master-ce-to-ee-0 with annotation node.deckhouse.io/ configuration-checksum=9cbe6db6c91574b8b732108a654c99423733b20f04848d0b4e1e2dadb231206a Aug 21 11:04:29 master-ce-to-ee-0 systemd[1]: bashible.service: Deactivated successfully.

• Retrieve the value of EE_SANDBOX_IMAGE:

Выполните следующую команду для запуска временного пода Deckhouse EE для получения актуальных дайджестов и списка модулей:

shell EE_SANDBOX_IMAGE=$(kubectl exec ee-image – cat deckhouse/candi/images_digests.json | jq -r “.common.pause”)

shell DECKHOUSE_VERSION=$(kubectl -n d8-system get deploy deckhouse -ojson | jq -r ‘.spec.template.spec.containers[] | select(.name == “deckhouse”) | .image’ | awk -F: ‘{print $2}’) kubectl run ee-image –image=registry.deckhouse.ru/deckhouse/ee/install:$DECKHOUSE_VERSION –command sleep – infinity

Check the result of the command to make sure it was successful:

Запускайте образ последней установленной версии DH в кластере, посмотреть можно командой:

shell kubectl get deckhousereleases | grep Deployed

shell echo $EE_SANDBOX_IMAGE

1. Как только под перейдёт в статус Running, выполните следующие команды:

Example output:

• Получите значение EE_SANDBOX_IMAGE:

console sha256:2a909cb9df4d0207f1fe5bd9660a0529991ba18ce6ce7b389dc008c05d9022d1

shell EE_SANDBOX_IMAGE=$(kubectl exec ee-image – cat deckhouse/candi/images_digests.json | jq -r “.common.pause”)

• Retrieve the value of EE_K8S_API_PROXY:

Проверка:

shell EE_K8S_API_PROXY=$(kubectl exec ee-image – cat deckhouse/candi/images_digests.json | jq -r “.controlPlaneManager.kubernetesApiProxy”)

shell echo $EE_SANDBOX_IMAGE

Check the result of the command to make sure it was successful:

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

shell echo $EE_K8S_API_PROXY

console sha256:2a909cb9df4d0207f1fe5bd9660a0529991ba18ce6ce7b389dc008c05d9022d1

Example output:

• Получите значение EE_K8S_API_PROXY:

console sha256:80a2cf757adad6a29514f82e1c03881de205780dbd87c6e24da0941f48355d6c

shell EE_K8S_API_PROXY=$(kubectl exec ee-image – cat deckhouse/candi/images_digests.json | jq -r “.controlPlaneManager.kubernetesApiProxy”)

• Retrieve the value of EE_REGISTRY_PACKAGE_PROXY:

Проверка:

shell EE_REGISTRY_PACKAGE_PROXY=$(kubectl exec ce-image – cat deckhouse/candi/images_digests.json | jq -r “.registryPackagesProxy.registryPackagesProxy”)

shell echo $EE_K8S_API_PROXY

Run the command:

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

shell crictl pull registry.deckhouse.io/deckhouse/ee@$EE_REGISTRY_PACKAGE_PROXY

console sha256:80a2cf757adad6a29514f82e1c03881de205780dbd87c6e24da0941f48355d6c

Example output:

• Получите значение EE_REGISTRY_PACKAGE_PROXY:

console Image is up to date for sha256:8127efa0f903a7194d6fb7b810839279b9934b200c2af5fc416660857bfb7832

shell EE_REGISTRY_PACKAGE_PROXY=$(kubectl exec ee-image – cat deckhouse/candi/images_digests.json | jq -r “.registryPackagesProxy.registryPackagesProxy”)

1. Create a NodeGroupConfiguration resource:

И выполните команду:

shell kubectl apply -f - «EOF apiVersion: deckhouse.io/v1alpha1 kind: NodeGroupConfiguration metadata: name: ee-set-sha-images.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 crictl pull registry.deckhouse.ru/deckhouse/ee@$EE_REGISTRY_PACKAGE_PROXY

bb-sync-file /etc/containerd/conf.d/ee-sandbox.toml - containerd-config-file-changed « “EOF_TOML” [plugins] [plugins.”io.containerd.grpc.v1.cri”] sandbox_image = “registry.deckhouse.io/deckhouse/ee@$EE_SANDBOX_IMAGE” EOF_TOML

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

console Image is up to date for sha256:8127efa0f903a7194d6fb7b810839279b9934b200c2af5fc416660857bfb7832

EOF

1. Создайте ресурс NodeGroupConfiguration:

Wait for the /etc/containerd/conf.d/ee-sandbox.toml file to propagate to the nodes and for bashible synchronization to complete.

shell kubectl apply -f - «EOF apiVersion: deckhouse.io/v1alpha1 kind: NodeGroupConfiguration metadata: name: ee-set-sha-images.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’

You can track the synchronization status via the UPTODATE value (the displayed number of nodes having this status must match the total number of nodes (NODES) in the group):

bb-sync-file /etc/containerd/conf.d/ee-sandbox.toml - containerd-config-file-changed « “EOF_TOML” [plugins] [plugins.”io.containerd.grpc.v1.cri”] sandbox_image = “registry.deckhouse.ru/deckhouse/ee@$EE_SANDBOX_IMAGE” EOF_TOML

shell kubectl get ng -o custom-columns=NAME:.metadata.name,NODES:.status.nodes,READY:.status.ready,UPTODATE:.status.upToDate -w

Example output:

EOF

console NAME NODES READY UPTODATE master 1 1 1 worker 2 2 2

Дождитесь появления файла /etc/containerd/conf.d/ee-sandbox.toml на узлах и завершения синхронизации bashible.

Also, the Configuration is in sync, nothing to do message must show up in the bashible systemd service log after you run the following command:

Статус синхронизации можно отследить по значению UPTODATE (отображаемое число узлов в этом статусе должно совпадать с общим числом узлов (NODES) в группе):

shell journalctl -u bashible -n 5

shell kubectl get ng -o custom-columns=NAME:.metadata.name,NODES:.status.nodes,READY:.status.ready,UPTODATE:.status.upToDate -w

Example output:

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

console Aug 21 11:04:28 master-ce-to-ee-0 bashible.sh[53407]: Configuration is in sync, nothing to do. Aug 21 11:04:28 master-ce-to-ee-0 bashible.sh[53407]: Annotate node master-ce-to-ee-0 with annotation node.deckhouse.io/ configuration-checksum=9cbe6db6c91574b8b732108a654c99423733b20f04848d0b4e1e2dadb231206a Aug 21 11:04:29 master-ce-to-ee-0 bashible.sh[53407]: Successful annotate node master-ce-to-ee-0 with annotation node.deckhouse.io/ configuration-checksum=9cbe6db6c91574b8b732108a654c99423733b20f04848d0b4e1e2dadb231206a Aug 21 11:04:29 master-ce-to-ee-0 systemd[1]: bashible.service: Deactivated successfully.

console NAME NODES READY UPTODATE master 1 1 1 worker 2 2 2

1. Update the secret to access the Deckhouse registry by running the following command:

Также в журнале systemd-сервиса bashible должно появиться сообщение Configuration is in sync, nothing to do в результате выполнения следующей команды:

shell kubectl -n d8-system create secret generic deckhouse-registry
–from-literal=”.dockerconfigjson”=”{"auths": { "registry.deckhouse.io": { "username": "license-token", "password": "$LICENSE_TOKEN", "auth": "$AUTH_STRING" }}}”
–from-literal=”address”=registry.deckhouse.io
–from-literal=”path”=/deckhouse/ee
–from-literal=”scheme”=https
–type=kubernetes.io/dockerconfigjson
–dry-run=’client’
-o yaml | kubectl -n d8-system exec -i svc/deckhouse-leader -c deckhouse – kubectl replace -f -

shell journalctl -u bashible -n 5

1. Apply the webhook-handler image:

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

shell HANDLER=$(kubectl exec ee-image – cat deckhouse/candi/images_digests.json | jq -r “.deckhouse.webhookHandler”) kubectl –as=system:serviceaccount:d8-system:deckhouse -n d8-system set image deployment/webhook-handler handler=registry.deckhouse.io/deckhouse/ee@$HANDLER

console Aug 21 11:04:28 master-ce-to-ee-0 bashible.sh[53407]: Configuration is in sync, nothing to do. Aug 21 11:04:28 master-ce-to-ee-0 bashible.sh[53407]: Annotate node master-ce-to-ee-0 with annotation node.deckhouse.io/ configuration-checksum=9cbe6db6c91574b8b732108a654c99423733b20f04848d0b4e1e2dadb231206a Aug 21 11:04:29 master-ce-to-ee-0 bashible.sh[53407]: Successful annotate node master-ce-to-ee-0 with annotation node.deckhouse.io/ configuration-checksum=9cbe6db6c91574b8b732108a654c99423733b20f04848d0b4e1e2dadb231206a Aug 21 11:04:29 master-ce-to-ee-0 systemd[1]: bashible.service: Deactivated successfully.

1. Apply the Deckhouse EE image:

1. Актуализируйте секрет доступа к registry Deckhouse, выполнив следующую команду:

shell DECKHOUSE_KUBE_RBAC_PROXY=$(kubectl exec ee-image – cat deckhouse/candi/images_digests.json | jq -r “.common.kubeRbacProxy”) DECKHOUSE_INIT_CONTAINER=$(kubectl exec ee-image – cat deckhouse/candi/images_digests.json | jq -r “.common.init”) DECKHOUSE_VERSION=$(kubectl -n d8-system get deploy deckhouse -ojson | jq -r ‘.spec.template.spec.containers[] | select(.name == “deckhouse”) | .image’ | awk -F: ‘{print $2}’) kubectl –as=system:serviceaccount:d8-system:deckhouse -n d8-system set image deployment/deckhouse init-downloaded-modules=registry.deckhouse.io/deckhouse/ee@$DECKHOUSE_INIT_CONTAINER kube-rbac-proxy=registry.deckhouse.io/deckhouse/ee@$DECKHOUSE_KUBE_RBAC_PROXY deckhouse=registry.deckhouse.io/deckhouse/ee:$DECKHOUSE_VERSION

shell kubectl -n d8-system create secret generic deckhouse-registry
–from-literal=”.dockerconfigjson”=”{"auths": { "registry.deckhouse.ru": { "username": "license-token", "password": "$LICENSE_TOKEN", "auth": "$AUTH_STRING" }}}”
–from-literal=”address”=registry.deckhouse.ru
–from-literal=”path”=/deckhouse/ee
–from-literal=”scheme”=https
–type=kubernetes.io/dockerconfigjson
–dry-run=’client’
-o yaml | kubectl -n d8-system exec -i svc/deckhouse-leader -c deckhouse – kubectl replace -f -

1. Wait for the Deckhouse pod to become Ready and for all the queued jobs to complete. If an ImagePullBackOff error is generated in the process, wait for the pod to be restarted automatically.

1. Примените образ webhook-handler:

Use the following command to check the Deckhouse pod’s status:

shell HANDLER=$(kubectl exec ee-image – cat deckhouse/candi/images_digests.json | jq -r “.deckhouse.webhookHandler”) kubectl –as=system:serviceaccount:d8-system:deckhouse -n d8-system set image deployment/webhook-handler handler=registry.deckhouse.ru/deckhouse/ee@$HANDLER

shell kubectl -n d8-system get po -l app=deckhouse

1. Примените образ Deckhouse EE:

Use the following command to check the Deckhouse queue:

shell DECKHOUSE_KUBE_RBAC_PROXY=$(kubectl exec ee-image – cat deckhouse/candi/images_digests.json | jq -r “.common.kubeRbacProxy”) DECKHOUSE_INIT_CONTAINER=$(kubectl exec ee-image – cat deckhouse/candi/images_digests.json | jq -r “.common.init”) DECKHOUSE_VERSION=$(kubectl -n d8-system get deploy deckhouse -ojson | jq -r ‘.spec.template.spec.containers[] | select(.name == “deckhouse”) | .image’ | awk -F: ‘{print $2}’) kubectl –as=system:serviceaccount:d8-system:deckhouse -n d8-system set image deployment/deckhouse init-downloaded-modules=registry.deckhouse.ru/deckhouse/ee@$DECKHOUSE_INIT_CONTAINER kube-rbac-proxy=registry.deckhouse.ru/deckhouse/ee@$DECKHOUSE_KUBE_RBAC_PROXY deckhouse=registry.deckhouse.ru/deckhouse/ee:$DECKHOUSE_VERSION

shell kubectl -n d8-system exec deploy/deckhouse -c deckhouse – deckhouse-controller queue list

1. Дождитесь перехода пода Deckhouse в статус Ready и выполнения всех задач в очереди. Если в процессе возникает ошибка ImagePullBackOff, подождите автоматического перезапуска пода.

1. Check if there are any pods with the Deckhouse CE registry address left in the cluster:

Посмотреть статус пода Deckhouse:

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 -n d8-system get po -l app=deckhouse

1. Purge temporary files, NodeGroupConfiguration resource, and variables:

Проверить состояние очереди Deckhouse:

shell kubectl delete ngc containerd-ee-config.sh ee-set-sha-images.sh kubectl delete pod ee-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/ee-registry.toml ]; then rm -f /etc/containerd/conf.d/ee-registry.toml fi if [ -f /etc/containerd/conf.d/ee-sandbox.toml ]; then rm -f /etc/containerd/conf.d/ee-sandbox.toml fi EOF

shell kubectl -n d8-system exec deploy/deckhouse -c deckhouse – deckhouse-controller queue list

Once bashible synchronization is complete (you can track the synchronization status on nodes via the UPTODATE value of the NodeGroup), delete the NodeGroupConfiguration resource you created earlier:

1. Проверьте, не осталось ли в кластере подов с адресом registry для Deckhouse CE:

shell kubectl delete ngc del-temp-config.sh

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

How to Switch Deckhouse EE to SE?

1. Удалите временные файлы, ресурс NodeGroupConfiguration и переменные:

You will need a valid license key. You can request a trial license key if necessary.

shell kubectl delete ngc containerd-ee-config.sh ee-set-sha-images.sh kubectl delete pod ee-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/ee-registry.toml ]; then rm -f /etc/containerd/conf.d/ee-registry.toml fi if [ -f /etc/containerd/conf.d/ee-sandbox.toml ]; then rm -f /etc/containerd/conf.d/ee-sandbox.toml fi EOF

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.

После синхронизации bashible (статус синхронизации на узлах можно отследить по значению UPTODATE у NodeGroup) удалите созданный ресурс NodeGroupConfiguration:

The Deckhouse SE edition does not support certain cloud providers dynamix, openstack, VCD, VSphere and a number of modules.

shell kubectl delete ngc del-temp-config.sh

To switch Deckhouse Enterprise Edition to Standard Edition, follow these steps:

Как переключить Deckhouse EE на SE?

All commands should be executed on a master node of the existing cluster.

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

1. Set up environment variables with your license token:

В инструкции используется публичный адрес container registry: registry.deckhouse.ru. Если вы используете другой адрес реестра, адаптируйте команды или воспользуйтесь инструкцией по переключению Deckhouse на использование стороннего registry.

shell LICENSE_TOKEN= AUTH_STRING="$(echo -n license-token:${LICENSE_TOKEN} | base64 )"

В Deckhouse SE не поддерживается работа облачных провайдеров dynamix, openstack, VCD, VSphere и ряда модулей.

1. Create a NodeGroupConfiguration resource for transitional authorization in registry.deckhouse.io:

Ниже описаны шаги для переключения кластера Deckhouse Enterprise Edition на Standard Edition:

shell kubectl apply -f - «EOF apiVersion: deckhouse.io/v1alpha1 kind: NodeGroupConfiguration metadata: name: containerd-se-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’

Все команды выполняются на master-узле существующего кластера:

mkdir -p /etc/containerd/conf.d bb-sync-file /etc/containerd/conf.d/se-registry.toml - containerd-config-file-changed « “EOF_TOML” [plugins] [plugins.”io.containerd.grpc.v1.cri”] [plugins.”io.containerd.grpc.v1.cri”.registry.configs] [plugins.”io.containerd.grpc.v1.cri”.registry.configs.”registry.deckhouse.io”.auth] auth = “$AUTH_STRING” EOF_TOML

1. Подготовьте переменные с токеном лицензии:

EOF

shell LICENSE_TOKEN= AUTH_STRING="$(echo -n license-token:${LICENSE_TOKEN} | base64 )"

Wait for the /etc/containerd/conf.d/se-registry.toml file to propagate to the nodes and for bashible synchronization to complete. You can track the synchronization status via the  UPTODATE value (the displayed number of nodes having this status must match the total number of nodes (NODES) in the group):

1. Cоздайте ресурс NodeGroupConfiguration для переходной авторизации в registry.deckhouse.ru:

shell kubectl get ng -o custom-columns=NAME:.metadata.name,NODES:.status.nodes,READY:.status.ready,UPTODATE:.status.upToDate -w

shell kubectl apply -f - «EOF apiVersion: deckhouse.io/v1alpha1 kind: NodeGroupConfiguration metadata: name: containerd-se-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’

Example output:

mkdir -p /etc/containerd/conf.d bb-sync-file /etc/containerd/conf.d/se-registry.toml - containerd-config-file-changed « “EOF_TOML” [plugins] [plugins.”io.containerd.grpc.v1.cri”] [plugins.”io.containerd.grpc.v1.cri”.registry.configs] [plugins.”io.containerd.grpc.v1.cri”.registry.configs.”registry.deckhouse.ru”.auth] auth = “$AUTH_STRING” EOF_TOML

console NAME NODES READY UPTODATE master 1 1 1 worker 2 2 2

EOF

Also, the Configuration is in sync, nothing to do message must show up in the bashible systemd service log after you run the following command:

Дождитесь появления файла /etc/containerd/conf.d/se-registry.toml на узлах и завершения синхронизации bashible. Чтобы отследить статус синхронизации, проверьте значение UPTODATE (число узлов в этом статусе должно совпадать с общим числом узлов (NODES) в группе):

shell journalctl -u bashible -n 5

shell kubectl get ng -o custom-columns=NAME:.metadata.name,NODES:.status.nodes,READY:.status.ready,UPTODATE:.status.upToDate -w

Example output:

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

console Aug 21 11:04:28 master-ee-to-se-0 bashible.sh[53407]: Configuration is in sync, nothing to do. Aug 21 11:04:28 master-ee-to-se-0 bashible.sh[53407]: Annotate node master-ee-to-se-0 with annotation node.deckhouse.io/ configuration-checksum=9cbe6db6c91574b8b732108a654c99423733b20f04848d0b4e1e2dadb231206a Aug 21 11:04:29 master ee-to-se-0 bashible.sh[53407]: Successful annotate node master-ee-to-se-0 with annotation node.deckhouse.io/ configuration-checksum=9cbe6db6c91574b8b732108a654c99423733b20f04848d0b4e1e2dadb231206a Aug 21 11:04:29 master-ee-to-se-0 systemd[1]: bashible.service: Deactivated successfully.

console NAME NODES READY UPTODATE master 1 1 1 worker 2 2 2

1. Run a temporary Deckhouse SE pod, to retrieve up-to-date digests and module lists:

Также в журнале systemd-сервиса bashible должно появиться сообщение Configuration is in sync, nothing to do в результате выполнения следующей команды:

shell DECKHOUSE_VERSION=$(kubectl -n d8-system get deploy deckhouse -ojson | jq -r ‘.spec.template.spec.containers[] | select(.name == “deckhouse”) | .image’ | awk -F: ‘{print $2}’) kubectl run se-image –image=registry.deckhouse.io/deckhouse/se/install:$DECKHOUSE_VERSION –command sleep – infinity

shell journalctl -u bashible -n 5

To find the latest Deckhouse version, you can run:

shell kubectl get deckhousereleases | grep Deployed

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

1. Wait for the pod to become Running and then run the following commands:

console Aug 21 11:04:28 master-ee-to-se-0 bashible.sh[53407]: Configuration is in sync, nothing to do. Aug 21 11:04:28 master-ee-to-se-0 bashible.sh[53407]: Annotate node master-ee-to-se-0 with annotation node.deckhouse.io/ configuration-checksum=9cbe6db6c91574b8b732108a654c99423733b20f04848d0b4e1e2dadb231206a Aug 21 11:04:29 master ee-to-se-0 bashible.sh[53407]: Successful annotate node master-ee-to-se-0 with annotation node.deckhouse.io/ configuration-checksum=9cbe6db6c91574b8b732108a654c99423733b20f04848d0b4e1e2dadb231206a Aug 21 11:04:29 master-ee-to-se-0 systemd[1]: bashible.service: Deactivated successfully.

• Retrieve the value of SE_SANDBOX_IMAGE:

1. Запустите временный под Deckhouse SE, чтобы получить актуальные дайджесты и список модулей:

shell SE_SANDBOX_IMAGE=$(kubectl exec se-image – cat deckhouse/candi/images_digests.json | jq -r “.common.pause”)

shell DECKHOUSE_VERSION=$(kubectl -n d8-system get deploy deckhouse -ojson | jq -r ‘.spec.template.spec.containers[] | select(.name == “deckhouse”) | .image’ | awk -F: ‘{print $2}’) kubectl run se-image –image=registry.deckhouse.ru/deckhouse/se/install:$DECKHOUSE_VERSION –command sleep – infinity

Check the result of the command to make sure it was successful:

Узнать текущую версию Deckhouse можно при помощи команды:

shell kubectl get deckhousereleases | grep Deployed

shell echo $SE_SANDBOX_IMAGE

1. После перехода пода в статус Running выполните следующие команды:

Example output:

• Получите значение SE_SANDBOX_IMAGE:

console sha256:2a909cb9df4d0207f1fe5bd9660a0529991ba18ce6ce7b389dc008c05d9022d1

shell SE_SANDBOX_IMAGE=$(kubectl exec se-image – cat deckhouse/candi/images_digests.json | jq -r “.common.pause”)

• Retrieve the value of SE_K8S_API_PROXY:

Проверка:

shell SE_K8S_API_PROXY=$(kubectl exec se-image – cat deckhouse/candi/images_digests.json | jq -r “.controlPlaneManager.kubernetesApiProxy”)

shell echo $SE_SANDBOX_IMAGE

Check the result of the command to make sure it was successful:

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

shell echo $SE_K8S_API_PROXY

console sha256:2a909cb9df4d0207f1fe5bd9660a0529991ba18ce6ce7b389dc008c05d9022d1

Example output:

• Получите значение SE_K8S_API_PROXY:

console sha256:af92506a36f4bd032a6459295069f9478021ccf67d37557a664878bc467dd9fd

shell SE_K8S_API_PROXY=$(kubectl exec se-image – cat deckhouse/candi/images_digests.json | jq -r “.controlPlaneManager.kubernetesApiProxy”)

• Retrieve the value of SE_REGISTRY_PACKAGE_PROXY:

Проверка:

shell SE_REGISTRY_PACKAGE_PROXY=$(kubectl exec se-image – cat deckhouse/candi/images_digests.json | jq -r “.registryPackagesProxy.registryPackagesProxy”)

shell echo $SE_K8S_API_PROXY

Run the command:

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

shell sudo /opt/deckhouse/bin/crictl pull registry.deckhouse.io/deckhouse/se@$SE_REGISTRY_PACKAGE_PROXY

console sha256:af92506a36f4bd032a6459295069f9478021ccf67d37557a664878bc467dd9fd

Example output:

• Получите значение SE_REGISTRY_PACKAGE_PROXY:

console Image is up to date for sha256:7e9908d47580ed8a9de481f579299ccb7040d5c7fade4689cb1bff1be74a95de

shell SE_REGISTRY_PACKAGE_PROXY=$(kubectl exec se-image – cat deckhouse/candi/images_digests.json | jq -r “.registryPackagesProxy.registryPackagesProxy”)

• Retrieve the value of SE_MODULES:

Затем выполните команду:

shell SE_MODULES=$(kubectl exec se-image – ls -l deckhouse/modules/ | grep -oE “\d.-\w” | awk {‘print $9’} | cut -c5-)

shell sudo /opt/deckhouse/bin/crictl pull registry.deckhouse.ru/deckhouse/se@$SE_REGISTRY_PACKAGE_PROXY

Check the result of the command to make sure it was successful:

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

shell echo $SE_MODULES

console Image is up to date for sha256:7e9908d47580ed8a9de481f579299ccb7040d5c7fade4689cb1bff1be74a95de

Example output:

• Получите значение SE_MODULES:

console common priority-class deckhouse external-module-manager …

shell SE_MODULES=$(kubectl exec se-image – ls -l deckhouse/modules/ | grep -oE “\d.-\w” | awk {‘print $9’} | cut -c5-)

• Retrieve the value of USED_MODULES:

Проверка:

shell USED_MODULES=$(kubectl get modules -o custom-columns=NAME:.metadata.name,SOURCE:.properties.source,STATE:.properties.state,ENABLED:.status.phase | grep Embedded | grep -E ‘Enabled|Ready’ | awk {‘print $1’})

shell echo $SE_MODULES

Check the result of the command to make sure it was successful:

console common priority-class deckhouse external-module-manager …

shell echo $USED_MODULES

• Получите значение USED_MODULES:

Example output:

shell USED_MODULES=$(kubectl get modules -o custom-columns=NAME:.metadata.name,SOURCE:.properties.source,STATE:.properties.state,ENABLED:.status.phase | grep Embedded | grep -E ‘Enabled|Ready’ | awk {‘print $1’})

console admission-policy-engine cert-manager chrony …

Проверка:

• Form the list of modules that must be disabled:

shell echo $USED_MODULES

shell MODULES_WILL_DISABLE=$(echo $USED_MODULES | tr ‘ ‘ ‘\n’ | grep -Fxv -f <(echo $SE_MODULES | tr ‘ ‘ ‘\n’))

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

1. Verify that the modules in use are supported by the SE edition. Run the following command to display modules that are not supported by SE and will be disabled:

console admission-policy-engine cert-manager chrony …

shell echo $MODULES_WILL_DISABLE

• Сформируйте список модулей, которые должны быть отключены:

Check the list and make sure the functionality of these modules is not required in your cluster or that you are prepared to disable them.

shell MODULES_WILL_DISABLE=$(echo $USED_MODULES | tr ‘ ‘ ‘\n’ | grep -Fxv -f <(echo $SE_MODULES | tr ‘ ‘ ‘\n’))

Disable the unsupported modules:

1. Убедитесь, что используемые в кластере модули поддерживаются в SE-редакции. Посмотреть список модулей, которые не поддерживаются SE-редакцией и будут отключены:

shell echo $MODULES_WILL_DISABLE | tr ‘ ‘ ‘\n’ | awk {‘print “kubectl -n d8-system exec deploy/deckhouse – deckhouse-controller module disable”,$1’} | bash

shell echo $MODULES_WILL_DISABLE

Wait until the Deckhouse pod is in the Ready state and all tasks in the queue are completed.

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

1. Create a NodeGroupConfiguration resource:

Отключите неподдерживаемые в SE-редакции модули:

shell kubectl apply -f - «EOF apiVersion: deckhouse.io/v1alpha1 kind: NodeGroupConfiguration metadata: name: se-set-sha-images.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 echo $MODULES_WILL_DISABLE | tr ‘ ‘ ‘\n’ | awk {‘print “kubectl -n d8-system exec deploy/deckhouse – deckhouse-controller module disable”,$1’} | bash

bb-sync-file /etc/containerd/conf.d/se-sandbox.toml - containerd-config-file-changed « “EOF_TOML” [plugins] [plugins.”io.containerd.grpc.v1.cri”] sandbox_image = “registry.deckhouse.io/deckhouse/se@$SE_SANDBOX_IMAGE” EOF_TOML

Дождитесь, пока под Deckhouse перейдёт в состояние Ready и убедитесь в выполнении всех задач в очереди.

1. Создайте ресурс NodeGroupConfiguration:

EOF

shell kubectl apply -f - «EOF apiVersion: deckhouse.io/v1alpha1 kind: NodeGroupConfiguration metadata: name: se-set-sha-images.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’

Wait for the /etc/containerd/conf.d/se-sandbox.toml file to propagate to the nodes and for bashible synchronization to complete.

bb-sync-file /etc/containerd/conf.d/se-sandbox.toml - containerd-config-file-changed « “EOF_TOML” [plugins] [plugins.”io.containerd.grpc.v1.cri”] sandbox_image = “registry.deckhouse.ru/deckhouse/se@$SE_SANDBOX_IMAGE” EOF_TOML

You can track the synchronization status via the UPTODATE value (the displayed number of nodes having this status must match the total number of nodes (NODES) in the group):

shell kubectl get ng -o custom-columns=NAME:.metadata.name,NODES:.status.nodes,READY:.status.ready,UPTODATE:.status.upToDate -w

EOF

Example output:

Дождитесь появления файла /etc/containerd/conf.d/se-sandbox.toml на узлах и завершения синхронизации bashible.

console NAME NODES READY UPTODATE master 1 1 1 worker 2 2 2

Статус синхронизации можно отследить по значению UPTODATE (отображаемое число узлов в этом статусе должно совпадать с общим числом узлов (NODES) в группе):

Also, the Configuration is in sync, nothing to do message must show up in the bashible systemd service log after you run the following command:

shell kubectl get ng -o custom-columns=NAME:.metadata.name,NODES:.status.nodes,READY:.status.ready,UPTODATE:.status.upToDate -w

shell journalctl -u bashible -n 5

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

Example output:

console NAME NODES READY UPTODATE master 1 1 1 worker 2 2 2

console Aug 21 11:04:28 master-ee-to-se-0 bashible.sh[53407]: Configuration is in sync, nothing to do. Aug 21 11:04:28 master-ee-to-se-0 bashible.sh[53407]: Annotate node master-ee-to-se-0 with annotation node.deckhouse.io/ configuration-checksum=9cbe6db6c91574b8b732108a654c99423733b20f04848d0b4e1e2dadb231206a Aug 21 11:04:29 master ee-to-se-0 bashible.sh[53407]: Successful annotate node master-ee-to-se-0 with annotation node.deckhouse.io/ configuration-checksum=9cbe6db6c91574b8b732108a654c99423733b20f04848d0b4e1e2dadb231206a Aug 21 11:04:29 master-ee-to-se-0 systemd[1]: bashible.service: Deactivated successfully.

Также в журнале systemd-сервиса bashible должно появиться сообщение Configuration is in sync, nothing to do в результате выполнения следующей команды:

1. Update the secret to access the Deckhouse registry by running the following command:

shell journalctl -u bashible -n 5

shell kubectl -n d8-system create secret generic deckhouse-registry
–from-literal=”.dockerconfigjson”=”{"auths": { "registry.deckhouse.io": { "username": "license-token", "password": "$LICENSE_TOKEN", "auth": "$AUTH_STRING" }}}”
–from-literal=”address”=registry.deckhouse.io –from-literal=”path”=/deckhouse/se
–from-literal=”scheme”=https –type=kubernetes.io/dockerconfigjson
–dry-run=client
-o yaml | kubectl -n d8-system exec -i svc/deckhouse-leader -c deckhouse – kubectl replace -f -

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

1. Apply the webhook-handler image:

console Aug 21 11:04:28 master-ee-to-se-0 bashible.sh[53407]: Configuration is in sync, nothing to do. Aug 21 11:04:28 master-ee-to-se-0 bashible.sh[53407]: Annotate node master-ee-to-se-0 with annotation node.deckhouse.io/ configuration-checksum=9cbe6db6c91574b8b732108a654c99423733b20f04848d0b4e1e2dadb231206a Aug 21 11:04:29 master ee-to-se-0 bashible.sh[53407]: Successful annotate node master-ee-to-se-0 with annotation node.deckhouse.io/ configuration-checksum=9cbe6db6c91574b8b732108a654c99423733b20f04848d0b4e1e2dadb231206a Aug 21 11:04:29 master-ee-to-se-0 systemd[1]: bashible.service: Deactivated successfully.

shell HANDLER=$(kubectl exec se-image – cat deckhouse/candi/images_digests.json | jq -r “.deckhouse.webhookHandler”) kubectl –as=system:serviceaccount:d8-system:deckhouse -n d8-system set image deployment/webhook-handler handler=registry.deckhouse.io/deckhouse/se@$HANDLER

1. Актуализируйте секрет доступа к registry Deckhouse, выполнив следующую команду:

1. Apply the Deckhouse SE image:

shell kubectl -n d8-system create secret generic deckhouse-registry
–from-literal=”.dockerconfigjson”=”{"auths": { "registry.deckhouse.ru": { "username": "license-token", "password": "$LICENSE_TOKEN", "auth": "$AUTH_STRING" }}}”
–from-literal=”address”=registry.deckhouse.ru –from-literal=”path”=/deckhouse/se
–from-literal=”scheme”=https –type=kubernetes.io/dockerconfigjson
–dry-run=client
-o yaml | kubectl -n d8-system exec -i svc/deckhouse-leader -c deckhouse – kubectl replace -f -

shell DECKHOUSE_KUBE_RBAC_PROXY=$(kubectl exec se-image – cat deckhouse/candi/images_digests.json | jq -r “.common.kubeRbacProxy”) DECKHOUSE_INIT_CONTAINER=$(kubectl exec se-image – cat deckhouse/candi/images_digests.json | jq -r “.common.init”) DECKHOUSE_VERSION=$(kubectl -n d8-system get deploy deckhouse -ojson | jq -r ‘.spec.template.spec.containers[] | select(.name == “deckhouse”) | .image’ | awk -F: ‘{print $2}’) kubectl –as=system:serviceaccount:d8-system:deckhouse -n d8-system set image deployment/deckhouse init-downloaded-modules=registry.deckhouse.io/deckhouse/se@$DECKHOUSE_INIT_CONTAINER kube-rbac-proxy=registry.deckhouse.io/deckhouse/se@$DECKHOUSE_KUBE_RBAC_PROXY deckhouse=registry.deckhouse.io/deckhouse/se:$DECKHOUSE_VERSION

1. Примените образ webhook-handler:

To find the latest Deckhouse version, you can run:

shell kubectl get deckhousereleases | grep Deployed

shell HANDLER=$(kubectl exec se-image – cat deckhouse/candi/images_digests.json | jq -r “.deckhouse.webhookHandler”) kubectl –as=system:serviceaccount:d8-system:deckhouse -n d8-system set image deployment/webhook-handler handler=registry.deckhouse.ru/deckhouse/se@$HANDLER

1. Wait for the Deckhouse pod to become Ready and for all the queued jobs to complete. If an ImagePullBackOff error is generated in the process, wait for the pod to be restarted automatically.

1. Примените образ Deckhouse SE:

Use the following command to check the Deckhouse pod’s status:

shell DECKHOUSE_KUBE_RBAC_PROXY=$(kubectl exec se-image – cat deckhouse/candi/images_digests.json | jq -r “.common.kubeRbacProxy”) DECKHOUSE_INIT_CONTAINER=$(kubectl exec se-image – cat deckhouse/candi/images_digests.json | jq -r “.common.init”) DECKHOUSE_VERSION=$(kubectl -n d8-system get deploy deckhouse -ojson | jq -r ‘.spec.template.spec.containers[] | select(.name == “deckhouse”) | .image’ | awk -F: ‘{print $2}’) kubectl –as=system:serviceaccount:d8-system:deckhouse -n d8-system set image deployment/deckhouse init-downloaded-modules=registry.deckhouse.ru/deckhouse/se@$DECKHOUSE_INIT_CONTAINER kube-rbac-proxy=registry.deckhouse.ru/deckhouse/se@$DECKHOUSE_KUBE_RBAC_PROXY deckhouse=registry.deckhouse.ru/deckhouse/se:$DECKHOUSE_VERSION

shell kubectl -n d8-system get po -l app=deckhouse

Узнать текущую версию Deckhouse можно при помощи команды:

shell kubectl get deckhousereleases | grep Deployed

Use the following command to check the Deckhouse queue:

1. Дождитесь перехода пода Deckhouse в статус Ready и убедитесь в выполнении всех задач в очереди. Если во время обновления возникает ошибка ImagePullBackOff, подождите, пока под перезапустится автоматически.

shell kubectl -n d8-system exec deploy/deckhouse -c deckhouse – deckhouse-controller queue list

Посмотреть статус пода Deckhouse:

1. Check if there are any pods with the Deckhouse EE registry address left in the cluster:

shell kubectl -n d8-system get po -l app=deckhouse

shell kubectl get pods -A -o json | jq -r ‘.items[] | select(.status.phase==”Running” or .status.phase==”Pending” or .status.phase==”PodInitializing”) | select(.spec.containers[] | select(.image | contains(“deckhouse.io/deckhouse/ee”))) | .metadata.namespace + “\t” + .metadata.name’ | sort | uniq

Проверить состояние очереди Deckhouse:

1. Purge temporary files, NodeGroupConfiguration resource, and variables:

shell kubectl -n d8-system exec deploy/deckhouse -c deckhouse – deckhouse-controller queue list

shell kubectl delete ngc containerd-se-config.sh se-set-sha-images.sh kubectl delete pod se-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/se-registry.toml ]; then rm -f /etc/containerd/conf.d/se-registry.toml fi if [ -f /etc/containerd/conf.d/se-sandbox.toml ]; then rm -f /etc/containerd/conf.d/se-sandbox.toml fi EOF

1. Проверьте, не осталось ли в кластере подов с адресом registry для Deckhouse EE:

Once bashible synchronization is complete (you can track the synchronization status on nodes via the UPTODATE value of the NodeGroup), delete the NodeGroupConfiguration resource you created earlier:

shell kubectl get pods -A -o json | jq -r ‘.items[] | select(.status.phase==”Running” or .status.phase==”Pending” or .status.phase==”PodInitializing”) | select(.spec.containers[] | select(.image | contains(“deckhouse.ru/deckhouse/ee”))) | .metadata.namespace + “\t” + .metadata.name’ | sort | uniq

shell kubectl delete ngc del-temp-config.sh

1. Удалите временные файлы, ресурс NodeGroupConfiguration и переменные:

How do I get access to Deckhouse controller in multimaster cluster?

shell kubectl delete ngc containerd-se-config.sh se-set-sha-images.sh kubectl delete pod se-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/se-registry.toml ]; then rm -f /etc/containerd/conf.d/se-registry.toml fi if [ -f /etc/containerd/conf.d/se-sandbox.toml ]; then rm -f /etc/containerd/conf.d/se-sandbox.toml fi EOF

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):

После завершения синхронизации bashible (статус синхронизации на узлах отображается по значению UPTODATE у NodeGroup), удалите созданный ресурс NodeGroupConfiguration:

shell kubectl -n d8-system exec -it svc/deckhouse-leader -c deckhouse – deckhouse-controller queue list

shell kubectl delete ngc del-temp-config.sh

How do I upgrade the Kubernetes version in a cluster?

Как переключить Deckhouse EE на CSE?

To upgrade the Kubernetes version in a cluster change the kubernetesVersion parameter in the ClusterConfiguration structure by making the following steps:

• Инструкция подразумевает использование публичного адреса container registry: registry-cse.deckhouse.ru. В случае использования другого адреса container registry измените команды или воспользуйтесь инструкцией по переключению Deckhouse на использование стороннего registry.
• В Deckhouse CSE не поддерживается работа облачных кластеров и ряда модулей.
• Миграция на Deckhouse CSE возможна только с версии Deckhouse EE 1.58 или 1.64.
• Актуальные версии Deckhouse CSE: 1.58.2 для релиза 1.58 и 1.64.1 для релиза 1.64. Эти версии потребуется использовать далее для указания переменной DECKHOUSE_VERSION.
• Переход поддерживается только между одинаковыми минорными версиями, например, с Deckhouse EE 1.58 на Deckhouse CSE 1.58. Попытки обновить версию на несколько релизов сразу могут привести к неработоспособности кластера.
• Deckhouse CSE совместим только с Kubernetes версии 1.27.
• При переключении на Deckhouse CSE возможна временная недоступность компонентов кластера.

1. Run the command:

Для переключения кластера Deckhouse Enterprise Edition на Certified Security Edition выполните следующие действия (все команды выполняются на master-узле кластера от имени пользователя с настроенным контекстом kubectl или от имени суперпользователя):

shell kubectl -n d8-system exec -ti svc/deckhouse-leader -c deckhouse – deckhouse-controller edit cluster-configuration

1. Настройте кластер на использование Kubernetes версии 1.27. Для этого:
2. Выполните команду:

1. Change the kubernetesVersion field.
2. Save the changes. Cluster nodes will start updating sequentially.
3. 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.

shell kubectl -n d8-system exec -ti svc/deckhouse-leader -c deckhouse – deckhouse-controller edit cluster-configuration

How do I run Deckhouse on a particular node?

1. Измените параметр kubernetesVersion на значение "1.27" (в кавычках).
2. Сохраните изменения. Узлы кластера начнут последовательно обновляться.
3. Дождитесь окончания обновления. Отслеживать ход обновления можно с помощью команды kubectl get no. Обновление можно считать завершенным, когда в выводе команды у каждого узла кластера в колонке VERSION появится обновленная версия.

Set the nodeSelector parameter of the deckhouse module and avoid setting tolerations. The necessary values will be assigned to the tolerations parameter automatically.

1. Подготовьте переменные с токеном лицензии и создайте NodeGroupConfiguration для переходной авторизации в registry-cse.deckhouse.ru:

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 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’

Here is an example of the module 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

yaml apiVersion: deckhouse.io/v1alpha1 kind: ModuleConfig metadata: name: deckhouse spec: version: 1 settings: nodeSelector: node-role.deckhouse.io/deckhouse: “”

Дождитесь появления файла на узлах и завершения синхронизации bashible:

shell /etc/containerd/conf.d/cse-registry.toml

Статус синхронизации можно отследить по значению UPTODATE (отображаемое число узлов в этом статусе должно совпадать с общим числом узлов (NODES) в группе):

shell kubectl get ng -o custom-columns=NAME:.metadata.name,NODES:.status.nodes,READY:.status.ready,UPTODATE:.status.upToDate -w

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

console NAME NODES READY UPTODATE master 1 1 1 worker 2 2 2

В журнале systemd-сервиса bashible должно появиться сообщение Configuration is in sync, nothing to do в результате выполнения следующей команды:

shell journalctl -u bashible -n 5

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

console 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]: Successful 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.

1. Выполните следующие команды для запуска временного пода Deckhouse CSE для получения актуальных дайджестов и списка модулей:

shell DECKHOUSE_VERSION=v<ВЕРСИЯ_DECKHOUSE_CSE> Например, DECKHOUSE_VERSION=v1.58.2 kubectl run cse-image --image=registry-cse.deckhouse.ru/deckhouse/cse/install:$DECKHOUSE_VERSION --command sleep -- infinity

Как только под перейдёт в статус Running, выполните следующие команды:

shell 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 -o custom-columns=NAME:.metadata.name,SOURCE:.properties.source,STATE:.properties.state,ENABLED:.status.phase | grep Embedded | grep -E ‘Enabled|Ready’ | awk {‘print $1’}) MODULES_WILL_DISABLE=$(echo $USED_MODULES | tr ‘ ‘ ‘\n’ | grep -Fxv -f <(echo $CSE_MODULES | tr ‘ ‘ ‘\n’)) CSE_DECKHOUSE_KUBE_RBAC_PROXY=$(kubectl exec cse-image – cat deckhouse/candi/images_digests.json | jq -r “.common.kubeRbacProxy”)

Дополнительная команда, которая необходима только при переключении на Deckhouse CSE версии 1.64:

shell CSE_DECKHOUSE_INIT_CONTAINER=$(kubectl exec cse-image – cat deckhouse/candi/images_digests.json | jq -r “.common.init”)

1. Убедитесь, что используемые в кластере модули поддерживаются в Deckhouse CSE. Например, на текущий момент в Deckhouse CSE отсутствует модуль cert-manager. Поэтому, перед отключением модуля cert-manager необходимо перевести режим работы HTTPS некоторых компонентов (например user-authn или prometheus) на альтернативные варианты работы, либо изменить глобальный параметр отвечающий за режим работы HTTPS в кластере.

Отобразить список модулей, которые не поддерживаются в Deckhouse CSE и будут отключены, можно следующей командой:

shell echo $MODULES_WILL_DISABLE

Проверьте список и убедитесь, что функциональность указанных модулей не задействована вами в кластере, и вы готовы к их отключению.

Отключите неподдерживаемые в Deckhouse CSE модули:

shell echo $MODULES_WILL_DISABLE | tr ‘ ‘ ‘\n’ | awk {‘print “kubectl -n d8-system exec deploy/deckhouse – deckhouse-controller module disable”,$1’} | bash

На данный момент в Deckhouse CSE версий 1.58 и 1.64 не поддерживается компонент earlyOOM. Отключите его с помощью настройки.

Дождитесь перехода пода Deckhouse в статус Ready и выполнения всех задач в очереди.

shell kubectl -n d8-system exec -it svc/deckhouse-leader -c deckhouse – deckhouse-controller queue list

Проверьте, что отключенные модули перешли в состояние Disabled.

shell kubectl get modules

1. Создайте 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 в результате выполнения следующей команды:

shell journalctl -u bashible -n 5

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

console 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]: Successful 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.

1. Актуализируйте секрет доступа к registry Deckhouse CSE, выполнив следующую команду:

shell 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 -n d8-system exec -i svc/deckhouse-leader -c deckhouse – kubectl replace -f -

1. Измените образ Deckhouse на образ Deckhouse CSE:

Команда для Deckhouse CSE версии 1.58:

shell kubectl -n d8-system set image deployment/deckhouse kube-rbac-proxy=registry-cse.deckhouse.ru/deckhouse/cse@$CSE_DECKHOUSE_KUBE_RBAC_PROXY deckhouse=registry-cse.deckhouse.ru/deckhouse/cse:$DECKHOUSE_VERSION

Команда для Deckhouse CSE версии 1.64:

shell kubectl -n d8-system set image deployment/deckhouse init-downloaded-modules=registry-cse.deckhouse.ru/deckhouse/cse@$CSE_DECKHOUSE_INIT_CONTAINER kube-rbac-proxy=registry-cse.deckhouse.ru/deckhouse/cse@$CSE_DECKHOUSE_KUBE_RBAC_PROXY deckhouse=registry-cse.deckhouse.ru/deckhouse/cse:$DECKHOUSE_VERSION

1. Дождитесь перехода пода Deckhouse в статус Ready и выполнения всех задач в очереди. Если в процессе возникает ошибка ImagePullBackOff, подождите автоматического перезапуска пода.

Посмотреть статус пода Deckhouse:

shell kubectl -n d8-system get po -l app=deckhouse

Проверить состояние очереди Deckhouse:

shell kubectl -n d8-system exec deploy/deckhouse -c deckhouse – deckhouse-controller queue list

1. Проверьте, не осталось ли в кластере подов с адресом registry для Deckhouse EE:

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

Если в выводе присутствуют поды модуля chrony, заново включите данный модуль (в Deckhouse CSE этот модуль по умолчанию выключен):

shell kubectl -n d8-system exec deploy/deckhouse – deckhouse-controller module enable chrony

1. Очистите временные файлы, ресурс NodeGroupConfiguration и переменные:

shell 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) удалите созданный ресурс NodeGroupConfiguration:

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, выполнив следующие шаги:

1. Выполните команду:

shell kubectl -n d8-system exec -ti svc/deckhouse-leader
-c deckhouse – deckhouse-controller edit cluster-configuration

1. Измените параметр kubernetesVersion.
2. Сохраните изменения. Узлы кластера начнут последовательно обновляться.
3. Дождитесь окончания обновления. Отслеживать ход обновления можно с помощью команды 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: “”