FAQ

Как узнать все параметры Deckhouse?

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

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

kubectl get mc global -o yaml

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

kubectl get modules

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

kubectl get moduleconfigs user-authn -o yaml

Как найти документацию по установленной у меня версии?

Документация запущенной в кластере версии Deckhouse доступна по адресу documentation.<cluster_domain>, где <cluster_domain> — DNS-имя в соответствии с шаблоном из параметра modules.publicDomainTemplate глобальной конфигурации.

Обновление Deckhouse

Как понять, в каком режиме обновляется кластер?

Посмотреть режим обновления кластера можно в конфигурации модуля deckhouse. Для этого выполните следующую команду:

kubectl get mc deckhouse -oyaml

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

apiVersion: deckhouse.io/v1alpha1
kind: ModuleConfig
metadata:
  creationTimestamp: "2022-12-14T11:13:03Z"
  generation: 1
  name: deckhouse
  resourceVersion: "3258626079"
  uid: c64a2532-af0d-496b-b4b7-eafb5d9a56ee
spec:
  settings:
    releaseChannel: Stable
    update:
      windows:
      - days:
        - Mon
        from: "19:00"
        to: "20:00"
  version: 1
status:
  state: Enabled
  status: ""
  type: Embedded
  version: "1"

Существуют три возможных режима обновления:

• Автоматический + окна обновлений не заданы. Кластер обновится сразу после появления новой версии на соответствующем канале обновлений.
• Автоматический + заданы окна обновлений. Кластер обновится в ближайшее доступное окно после появления новой версии на канале обновлений.
• Ручной режим. Для применения обновления требуются ручные действия.

Как установить желаемый канал обновлений?

Чтобы перейти на другой канал обновлений автоматически, нужно в конфигурации модуля deckhouse изменить (установить) параметр releaseChannel.

В этом случае включится механизм автоматической стабилизации релизного канала.

Пример конфигурации модуля deckhouse с установленным каналом обновлений Stable:

apiVersion: deckhouse.io/v1alpha1
kind: ModuleConfig
metadata:
  name: deckhouse
spec:
  version: 1
  settings:
    releaseChannel: Stable

Как отключить автоматическое обновление?

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

В этом случае Deckhouse не проверяет обновления и даже обновление на patch-релизы не выполняется.

Как применить обновление минуя окна обновлений, canary-release и ручной режим обновлений?

Чтобы применить обновление немедленно, установите в соответствующем ресурсе DeckhouseRelease аннотацию release.deckhouse.io/apply-now: "true".

Пример команды установки аннотации пропуска окон обновлений для версии v1.56.2:

kubectl annotate deckhousereleases v1.56.2 release.deckhouse.io/apply-now="true"

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

apiVersion: deckhouse.io/v1alpha1
kind: DeckhouseRelease
metadata:
  annotations:
    release.deckhouse.io/apply-now: "true"
...

Как понять, какие изменения содержит обновление и как это повлияет на работу кластера?

Информацию о всех версиях Deckhouse можно найти в списке релизов Deckhouse.

Сводную информацию о важных изменениях, об обновлении версий компонентов, а также о том, какие компоненты в кластере буду перезапущены в процессе обновления, можно найти в описании нулевой patch-версии релиза. Например, v1.46.0 для релиза v1.46 Deckhouse.

Подробный список изменений можно найти в Changelog, ссылка на который есть в каждом релизе.

Как понять, что в кластере идет обновление?

Во время обновления:

• горит алерт DeckhouseUpdating;
• под deckhouse не в статусе Ready. Если под долго не переходит в статус Ready, это может говорить о наличии проблем в работе Deckhouse. Необходима диагностика.

Как понять, что обновление прошло успешно?

Если алерт DeckhouseUpdating погас, значит, обновление завершено.

Вы также можете проверить состояние релизов Deckhouse.

Пример:

$ kubectl get deckhouserelease
NAME       PHASE        TRANSITIONTIME   MESSAGE
v1.46.8    Superseded   13d
v1.46.9    Superseded   11d
v1.47.0    Superseded   4h12m
v1.47.1    Deployed     4h12m

Статус Deployed у соответствующей версии говорит о том, что переключение на соответствующую версию было выполнено (но это не значит, что оно закончилось успешно).

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

$ kubectl -n d8-system get pods -l app=deckhouse
NAME                   READY  STATUS   RESTARTS  AGE
deckhouse-7844b47bcd-qtbx9  1/1   Running  0       1d

• Если статус пода Running и в колонке READY указано 1/1 — обновление закончилось успешно.
• Если статус пода Running и в колонке READY указано 0/1 — обновление еще не закончилось. Если это продолжается более 20–30 минут, это может говорить о наличии проблем в работе Deckhouse. Необходима диагностика.
• Если статус пода не Running, это может говорить о наличии проблем в работе Deckhouse. Необходима диагностика.

Как узнать, что для кластера доступна новая версия?

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

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

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

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

• Настроить ручной режим обновлений. В этом случае при появлении новой версии на канале обновлений загорится алерт DeckhouseReleaseIsWaitingManualApproval и в кластере появится новый custom resource DeckhouseRelease.
• Настроить автоматический режим обновлений и указать минимальное время в параметре minimalNotificationTime, на которое будет отложено обновление. В этом случае при появлении новой версии на канале обновлений в кластере появится новый custom resource DeckhouseRelease. А если указать URL в параметре update.notification.webhook, дополнительно произойдет вызов webhook’а.

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

Информацию о том, какая версия Deckhouse находится на каком канале обновлений, можно получить на https://releases.deckhouse.io.

Как работает автоматическое обновление Deckhouse?

При указании в конфигурации модуля deckhouse параметра releaseChannel Deckhouse будет каждую минуту проверять данные о релизе на канале обновлений.

При появлении нового релиза Deckhouse скачивает его в кластер и создает custom resource DeckhouseRelease.

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

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

kubectl get deckhousereleases

Что происходит при смене канала обновлений?

• При смене канала обновлений на более стабильный (например, с Alpha на EarlyAccess) Deckhouse скачивает данные о релизе (в примере — из канала EarlyAccess) и сравнивает их с данными из существующих в кластере custom resource’ов DeckhouseRelease:
  • Более поздние релизы, которые еще не были применены (в статусе Pending), удаляются.
  • Если более поздние релизы уже применены (в статусе Deployed), смены релиза не происходит. В этом случае Deckhouse останется на таком релизе до тех пор, пока на канале обновлений EarlyAccess не появится более поздний релиз.
• При смене канала обновлений на менее стабильный (например, с EarlyAcess на Alpha):
  • Deckhouse скачивает данные о релизе (в примере — из канала Alpha) и сравнивает их с данными из существующих в кластере custom resource’ов DeckhouseRelease.
  • Затем Deckhouse выполняет обновление согласно установленным параметрам обновления.

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

• Проверьте, что настроен нужный канал обновлений.

• Проверьте корректность разрешения DNS-имени хранилища образов Deckhouse.

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

  Пример получения IP-адреса хранилища образов Deckhouse на узле:

  $ getent ahosts registry.deckhouse.ru
  185.193.90.38    STREAM registry.deckhouse.ru
  185.193.90.38    DGRAM
  185.193.90.38    RAW
  

  Пример получения IP-адреса хранилища образов Deckhouse в поде Deckhouse:

  $ kubectl -n d8-system exec -ti svc/deckhouse-leader -c deckhouse -- getent ahosts registry.deckhouse.ru
  185.193.90.38    STREAM registry.deckhouse.ru
  185.193.90.38    DGRAM  registry.deckhouse.ru
  

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

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

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

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

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

$ kubectl -n d8-system exec -it svc/deckhouse-leader -c deckhouse -- deckhouse-controller queue list
Summary:
- 'main' queue: empty.
- 88 other queues (0 active, 88 empty): 0 tasks.
- no tasks to handle.

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

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

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

$ kubectl -n d8-system exec -it svc/deckhouse-leader -c deckhouse -- deckhouse-controller queue main
Queue 'main': length 38, status: 'run first task'

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

$ kubectl -n d8-system exec -it svc/deckhouse-leader -c deckhouse -- deckhouse-controller queue main
Queue 'main': length 0, status: 'waiting for task 0s'

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

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

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

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

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

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

{"auths": { "<PROXY_REGISTRY>": {}}}

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

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

{"auths": { "<PROXY_REGISTRY>": {"username":"<PROXY_USERNAME>","password":"<PROXY_PASSWORD>","auth":"<AUTH_BASE64>"}}}

где:

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

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

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

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

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

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

• Включен Docker Bearer Token Realm (Administration -> Security -> Realms).
• Создан проксирующий репозиторий Docker (Administration -> Repository -> Repositories):
  • Параметр Allow anonymous docker pull для репозитория должен быть включен. Данный параметр включает поддержку авторизации с помощью Bearer-токенов, при этом анонимный доступ не будет работать, если он не был явно включен в Administration -> Security -> Anonymous Access и пользователю anonymous не были даны права на доступ к репозиторию.
  • Параметр Maximum metadata age для репозитория должен быть установлен в 0.
• Должен быть настроен контроль доступа:
  • Создана роль Nexus (Administration -> Security -> Roles) со следующими полномочиями:
    • nx-repository-view-docker-<репозиторий>-browse
    • nx-repository-view-docker-<репозиторий>-read
  • Создан пользователь (Administration -> Security -> Users) с ролью, созданной выше.

Настройка:

• Включите Docker Bearer Token Realm (Administration -> Security -> Realms):

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

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

  

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

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

    

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

    

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

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

Необходимо использовать такой функционал Harbor, как Proxy Cache.

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

  

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

  

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

Ручная загрузка образов в изолированный приватный registry

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

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

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

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

   d8 mirror pull \
     --source='registry.deckhouse.ru/deckhouse/<EDITION>' \
     --license='<LICENSE_KEY>' $(pwd)/d8.tar
   

   где:

   • <EDITION> — код редакции Deckhouse Kubernetes Platform (например, ee, se, cse);
   • <LICENSE_KEY> — лицензионный ключ Deckhouse Kubernetes Platform.

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

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

   • --no-pull-resume — чтобы принудительно начать загрузку сначала;
   • --no-modules — для пропуска загрузки модулей;
   • --min-version=X.Y — чтобы скачать все версии Deckhouse, начиная с указанной минорной версии. Параметр будет проигнорирован, если указана версия выше чем версия находящаяся на канале обновлений Rock Solid. Параметр не может быть использован одновременно с параметром --release;
   • --release=X.Y.Z — чтобы скачать только конкретную версию Deckhouse (без учета каналов обновлений). Параметр не может быть использован одновременно с параметром --min-version;
   • --gost-digest — для расчета контрольной суммы итогового набора образов Deckhouse в формате ГОСТ Р 34.11-2012 (Стрибог). Контрольная сумма будет отображена и записана в файл с расширением .tar.gostsum в папке с tar-архивом, содержащим образы Deckhouse;
   • --source — чтобы указать адрес источника хранилища образов Deckhouse;
     • Для аутентификации в официальном хранилище образов Deckhouse нужно использовать лицензионный ключ и параметр --license;
     • Для аутентификации в стороннем хранилище образов нужно использовать параметры --source-login и --source-password;
   • --images-bundle-chunk-size=N — для указания максимального размера файла (в ГБ), на которые нужно разбить архив образов. В результате работы вместо одного файла архива образов будет создан набор .chunk-файлов (например, d8.tar.NNNN.chunk). Чтобы загрузить образы из такого набора файлов, укажите в команде d8 mirror push имя файла без суффикса .NNNN.chunk (например, d8.tar для файлов d8.tar.NNNN.chunk).

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

   • HTTP_PROXY/HTTPS_PROXY — URL прокси-сервера для запросов к HTTP(S) хостам, которые не указаны в списке хостов в переменной $NO_PROXY;
   • NO_PROXY — список хостов, разделенных запятыми, которые следует исключить из проксирования. Каждое значение может быть представлено в виде IP-адреса (1.2.3.4), CIDR (1.2.3.4/8), домена или символа (*). IP-адреса и домены также могут включать номер порта (1.2.3.4:80). Доменное имя соответствует как самому себе, так и всем поддоменам. Доменное имя начинающееся с ., соответствует только поддоменам. Например, foo.com соответствует foo.com и bar.foo.com; .y.com соответствует x.y.com, но не соответствует y.com. Символ * отключает проксирование;
   • SSL_CERT_FILE — указывает путь до сертификата SSL. Если переменная установлена, системные сертификаты не используются;
   • SSL_CERT_DIR — список каталогов, разделенный двоеточиями. Определяет, в каких каталогах искать файлы сертификатов SSL. Если переменная установлена, системные сертификаты не используются. Подробнее…;
   • TMPDIR (*nix)/TMP (Windows) — путь к директории для временных файлов, который будет использоваться во время операций загрузки и выгрузки образов. Вся обработка выполняется в этом каталоге. Он должен иметь достаточное количество свободного дискового пространства, чтобы вместить весь загружаемый пакет образов;
   • MIRROR_BYPASS_ACCESS_CHECKS — установите для этого параметра значение 1, чтобы отключить проверку корректности переданных учетных данных для registry;

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

   d8 mirror pull \
     --source='registry.deckhouse.ru/deckhouse/ee' \
     --license='<LICENSE_KEY>' --min-version=1.59 $(pwd)/d8.tar
   

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

   d8 mirror pull \
     --source='corp.company.com:5000/sys/deckhouse' \
     --source-login='<USER>' --source-password='<PASSWORD>' $(pwd)/d8.tar
   

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

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

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

   d8 mirror push /tmp/d8-images/d8.tar 'corp.company.com:5000/sys/deckhouse' \
     --registry-login='<USER>' --registry-password='<PASSWORD>'
   

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

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

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

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

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

   d8 k apply -f ./deckhousereleases.yaml
   

Ручная загрузка образов подключаемых модулей Deckhouse в изолированный приватный registry

Для ручной загрузки образов модулей, подключаемых из источника модулей (ресурс ModuleSource), выполните следующие шаги:

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

2. Создайте строку аутентификации для официального хранилища образов registry.deckhouse.ru, выполнив следующую команду (укажите лицензионный ключ):

   LICENSE_KEY='<LICENSE_KEY>' base64 -w0 <<EOF
     {
       "auths": {
         "registry.deckhouse.ru": {
           "auth": "$(echo -n license-token:${LICENSE_KEY} | base64 -w0)"
         }
       }
     }
   EOF
   

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

   Если не передан параметр --filter, то d8 mirror modules pull скачивает только версии модулей, доступные в каналах обновлений модуля на момент копирования.

   • Создайте файл с описанием ресурса ModuleSource (например, $HOME/module_source.yml).

     Пример ресурса ModuleSource:

     apiVersion: deckhouse.io/v1alpha1
     kind: ModuleSource
     metadata:
       name: deckhouse
     spec:
       registry:
         # Укажите строку аутентификации для официального хранилища образов, полученную в п. 2
         dockerCfg: <BASE64_REGISTRY_CREDENTIALS>
         repo: registry.deckhouse.ru/deckhouse/ee/modules
         scheme: HTTPS
       # Выберите подходящий канал обновлений: Alpha, Beta, EarlyAccess, Stable, RockSolid
       releaseChannel: "Stable"
     

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

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

     d8 mirror modules pull -d ./d8-modules -m $HOME/module_source.yml
     

     Для загрузки только набора из определенных модулей конкретных версий используйте параметр --filter, передав набор необходимых модулей и их минимальных версий, разделенных символом ;.

     Пример:

     d8 mirror modules pull -d /tmp/d8-modules -m $HOME/module_source.yml \
       --filter='deckhouse-admin@1.3.3; sds-drbd@0.0.1'
     

     Команда выше загрузит только модули deckhouse-admin и sds-drbd. Для deckhouse-admin будут загружены все доступные версии начиная с 1.3.3, для sds-drbd — все доступные версии начиная с 0.0.1.

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

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

   Пример команды для загрузки образов из директории /tmp/d8-modules:

   d8 mirror modules push \
     -d /tmp/d8-modules --registry='corp.company.com:5000/deckhouse/modules' \
     --registry-login='<USER>' --registry-password='<PASSWORD>'
   

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

6. Отредактируйте YAML-манифест ModuleSource, подготовленный на шаге 3:

   • Измените поле .spec.registry.repo на адрес, который вы указали в параметре --registry при загрузке образов.
   • Измените поле .spec.registry.dockerCfg на Base64-строку с данными для авторизации в вашем хранилище образов в формате dockercfg. Обратитесь к документации вашего registry для получения информации о том, как сгенерировать этот токен.

   Пример ModuleSource:

   apiVersion: deckhouse.io/v1alpha1
   kind: ModuleSource
   metadata:
     name: deckhouse
   spec:
     registry:
       # Укажите строку аутентификации для вашего хранилища образов.
       dockerCfg: <BASE64_REGISTRY_CREDENTIALS>
       repo: 'corp.company.com:5000/deckhouse/modules'
       scheme: HTTPS
     # Выберите подходящий канал обновлений: Alpha, Beta, EarlyAccess, Stable, RockSolid
     releaseChannel: "Stable"
   

7. Примените в кластере исправленный манифест ModuleSource:

   d8 k apply -f $HOME/module_source.yml
   

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

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

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

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

  • Пример запуска:

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

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

    $ 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"
    

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

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

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

    usage: deckhouse-controller helper change-registry [<flags>] <new-registry>
    
    Change registry for deckhouse images.
    
    Flags:
      --help               Show context-sensitive help (also try --help-long and --help-man).
      --user=USER          User with pull access to registry.
      --password=PASSWORD  Password/token for registry user.
      --ca-file=CA-FILE    Path to registry CA.
      --scheme=SCHEME      Used scheme while connecting to registry, http or https.
      --dry-run            Don't change deckhouse resources, only print them.
      --new-deckhouse-tag=NEW-DECKHOUSE-TAG
                          New tag that will be used for deckhouse deployment image (by default
                          current tag from deckhouse deployment will be used).
    
    Args:
      <new-registry>  Registry that will be used for deckhouse images (example:
                      registry.deckhouse.io/deckhouse/ce). By default, https will be used, if you need
                      http - provide '--scheme' flag with http value
    

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

• Проверьте, не осталось ли в кластере подов с оригинальным адресом registry:

  kubectl get pods -A -o json | jq -r '.items[] | select(.spec.containers[]
    | select(.image | startswith("registry.deckhouse"))) | .metadata.namespace + "\t" + .metadata.name' | sort | uniq
  

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

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

• Если вы хотите установить Deckhouse с отключенным автоматическим обновлением:
  • Используйте тег образа установщика соответствующей версии. Например, если вы хотите установить релиз v1.60.5, используйте образ your.private.registry.com/deckhouse/install:v1.60.5.
  • Не указывайте параметр deckhouse.releaseChannel в ресурсе InitConfiguration.
• Если вы хотите отключить автоматические обновления у уже установленного Deckhouse (включая обновления patch-релизов), удалите параметр releaseChannel из конфигурации модуля deckhouse.

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

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

Пример:

apiVersion: deckhouse.io/v1
kind: ClusterConfiguration
clusterType: Cloud
cloud:
  provider: OpenStack
  prefix: main
podSubnetCIDR: 10.111.0.0/16
serviceSubnetCIDR: 10.222.0.0/16
kubernetesVersion: "Automatic"
cri: "Containerd"
clusterDomain: "cluster.local"
proxy:
  httpProxy: "http://user:password@proxy.company.my:3128"
  httpsProxy: "https://user:password@proxy.company.my:8443"

Изменение конфигурации

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2. Выполните следующую команду:

   kubectl exec -ti -n d8-system svc/deckhouse-leader -c deckhouse -- deckhouse-controller helper change-registry registry.deckhouse.ru/deckhouse/ce
   

3. Дождитесь перехода пода Deckhouse в статус Ready:

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

4. Если под будет находиться в статусе ImagePullBackoff, перезапустите его:

   kubectl -n d8-system delete po -l app=deckhouse
   

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

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

6. На master-узле проверьте применение новых настроек.

   В журнале systemd-сервиса bashible на master-узле должно появиться сообщение Configuration is in sync, nothing to do.

   Пример:

   # journalctl -u bashible -n 5
   Jan 12 12:38:20 demo-master-0 bashible.sh[868379]: Configuration is in sync, nothing to do.
   Jan 12 12:38:20 demo-master-0 systemd[1]: bashible.service: Deactivated successfully.
   Jan 12 12:39:18 demo-master-0 systemd[1]: Started Bashible service.
   Jan 12 12:39:19 demo-master-0 bashible.sh[869714]: Configuration is in sync, nothing to do.
   Jan 12 12:39:19 demo-master-0 systemd[1]: bashible.service: Deactivated successfully.
   

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

   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
   

   Иногда могут оставаться запущенными некоторые static Pod’ы (например, kubernetes-api-proxy-*). Это связанно с тем, что kubelet не перезапускает под несмотря на изменение соответствующего манифеста, так как используемый образ одинаков для Deckhouse CE и EE. Выполните на любом master-узле следующую команду, чтобы убедиться, что соответствующие манифесты также были изменены:

   grep -ri 'deckhouse.ru/deckhouse/ee' /etc/kubernetes | grep -v backup
   

   Вывод команды должен быть пуст.

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

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

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

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

   LICENSE_TOKEN=<PUT_YOUR_LICENSE_TOKEN_HERE>
   kubectl exec -ti -n d8-system svc/deckhouse-leader -c deckhouse -- deckhouse-controller helper change-registry --user license-token --password $LICENSE_TOKEN registry.deckhouse.ru/deckhouse/ee
   

2. Дождитесь перехода пода Deckhouse в статус Ready:

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

3. Если под будет находиться в статусе ImagePullBackoff, перезапустите его:

   kubectl -n d8-system delete po -l app=deckhouse
   

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

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

5. На master-узле проверьте применение новых настроек.

   В журнале systemd-сервиса bashible на master-узле должно появиться сообщение Configuration is in sync, nothing to do.

   Пример:

   # journalctl -u bashible -n 5
   Jan 12 12:38:20 demo-master-0 bashible.sh[868379]: Configuration is in sync, nothing to do.
   Jan 12 12:38:20 demo-master-0 systemd[1]: bashible.service: Deactivated successfully.
   Jan 12 12:39:18 demo-master-0 systemd[1]: Started Bashible service.
   Jan 12 12:39:19 demo-master-0 bashible.sh[869714]: Configuration is in sync, nothing to do.
   Jan 12 12:39:19 demo-master-0 systemd[1]: bashible.service: Deactivated successfully.
   

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

   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
   

   Иногда могут оставаться запущенными некоторые static Pod’ы (например, kubernetes-api-proxy-*). Это связанно с тем, что kubelet не перезапускает под несмотря на изменение соответствующего манифеста, так как используемый образ одинаков для Deckhouse CE и EE. Выполните на любом master-узле следующую команду, чтобы убедиться, что соответствующие манифесты также были изменены:

   grep -ri 'deckhouse.ru/deckhouse/ce' /etc/kubernetes | grep -v backup
   

   Вывод команды должен быть пуст.

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

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

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

   LICENSE_TOKEN=<PUT_YOUR_LICENSE_TOKEN_HERE>
   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'
   
       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
   

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

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

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

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

   Пример:

   root@master-ee-to-cse-0:~# kubectl  get ng  -o custom-columns=NAME:.metadata.name,NODES:.status.nodes,READY:.status.ready,UPTODATE:.status.upToDate -w
   NAME     NODES   READY   UPTODATE
   master   1       1       1
   worker   2       2       2
   

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

   Пример:

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

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

   kubectl run cse-image --image=registry-cse.deckhouse.ru/deckhouse/cse/install:v1.58.2 --command sleep -- infinity
   

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

   CSE_SANDBOX_IMAGE=$(kubectl exec cse-image -- cat deckhouse/candi/images_digests.json | grep  pause | grep -oE 'sha256:\w*')
   CSE_K8S_API_PROXY=$(kubectl exec cse-image -- cat deckhouse/candi/images_digests.json | grep kubernetesApiProxy | grep -oE 'sha256:\w*')
   CSE_MODULES=$(kubectl exec cse-image -- ls -l deckhouse/modules/ | awk {'print $9'}  |grep -oP "\d.*-\w*"  | cut -c5-)
   USED_MODULES=$(kubectl get modules | grep -v 'snapshot-controller-crd' | grep Enabled |awk {'print $1'})
   MODULES_WILL_DISABLE=$(echo $USED_MODULES | tr ' ' '\n' | grep -Fxv -f <(echo $CSE_MODULES | tr ' ' '\n'))
   

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

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

   echo $MODULES_WILL_DISABLE
   

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

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

   echo $MODULES_WILL_DISABLE | 
     tr ' ' '\n' | awk {'print "kubectl -n d8-system exec  deploy/deckhouse -- deckhouse-controller module disable",$1'} | bash
   

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

4. Создайте NodeGroupConfiguration:

   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) в группе):

   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.

   Пример:

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

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

   kubectl -n d8-system create secret generic deckhouse-registry \
     --from-literal=".dockerconfigjson"="{\"auths\": { \"registry-cse.deckhouse.ru\": { \"username\": \"license-token\", \"password\": \"$LICENSE_TOKEN\", \"auth\": \"$AUTH_STRING\" }}}" \
     --from-literal="address"=registry-cse.deckhouse.ru \
     --from-literal="path"=/deckhouse/cse \
     --from-literal="scheme"=https \
     --type=kubernetes.io/dockerconfigjson \
     --dry-run='client' \
     -o yaml | kubectl replace -f -
   

6. Примените CSE-образ:

   kubectl -n d8-system set image deployment/deckhouse deckhouse=registry-cse.deckhouse.ru/deckhouse/cse:v1.58.2
   

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

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

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

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

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

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

   kubectl get pods -A -o json | jq -r '.items[] | select(.spec.containers[]
     | select(.image | contains("deckhouse.ru/deckhouse/ee"))) | .metadata.namespace + "\t" + .metadata.name' | sort | uniq
   

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

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

9. Очистите временные файлы, ngc и переменные:

   rm /tmp/cse-deckhouse-registry.yaml
   
   kubectl delete ngc containerd-cse-config.sh cse-set-sha-images.sh
   
   kubectl delete pod cse-image
   
   kubectl apply -f - <<EOF
   apiVersion: deckhouse.io/v1alpha1
   kind: NodeGroupConfiguration
   metadata:
     name: del-temp-config.sh
   spec:
     nodeGroups:
     - '*'
     bundles:
     - '*'
     weight: 90
     content: |
       if [ -f /etc/containerd/conf.d/cse-registry.toml ]; then
         rm -f /etc/containerd/conf.d/cse-registry.toml
       fi
       if [ -f /etc/containerd/conf.d/cse-sandbox.toml ]; then
         rm -f /etc/containerd/conf.d/cse-sandbox.toml
       fi
   EOF
   

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

   kubectl  delete ngc del-temp-config.sh
   

Как получить доступ к контроллеру Deckhouse в multi-master-кластере?

В кластерах с несколькими master-узлами Deckhouse запускается в режиме высокой доступности (в нескольких экземплярах). Для доступа к активному контроллеру Deckhouse можно использовать следующую команду (на примере команды deckhouse-controller queue list):

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

Как обновить версию Kubernetes в кластере?

Чтобы обновить версию Kubernetes в кластере, измените параметр kubernetesVersion в структуре ClusterConfiguration, выполнив следующие шаги:

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

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

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

Как запускать Deckhouse на произвольном узле?

Для запуска Deckhouse на произвольном узле установите у модуля deckhouse соответствующий параметр nodeSelector и не задавайте tolerations. Необходимые значения tolerations в этом случае будут проставлены автоматически.

Пример конфигурации модуля:

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