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

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

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

    kubectl get mc global -o yaml
    
  2. Выведите список состояния всех модулей (доступно для Deckhouse версии 1.47+):

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

    kubectl get moduleconfigs user-authn -o yaml
    

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

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

Документация доступна, если в кластере включен модуль documentation. Он включен по умолчанию, кроме варианта поставки Minimal.

Обновление 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-релизы.

Крайне не рекомендуется отключать автоматическое обновление! Это заблокирует обновления на patch-релизы, которые могут содержать исправления критических уязвимостей и ошибок.

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

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

Обратите внимание! В этом случае будут проигнорированы окна обновления, настройки canary-release и режим ручного обновления кластера. Обновление применится сразу после установки аннотации.

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

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

Если алерт 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. Необходима диагностика.

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

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

    kubectl -n d8-system logs -f -l app=deckhouse | jq -Rr 'fromjson? | .msg'
    
  2. Соберите отладочную информацию и свяжитесь с технической поддержкой.
  3. Попросите помощи у сообщества.

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

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

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

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

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

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

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

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

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

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

При появлении нового релиза Deckhouse скачает его в кластер и создаст кастомный ресурс DeckhouseRelease.

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

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

kubectl get deckhousereleases

Patch-релизы (например, обновление на версию 1.30.2 при установленной версии 1.30.1) устанавливаются без учета режима и окон обновления, то есть при появлении на канале обновления patch-релиза он всегда будет установлен.

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

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

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

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

  3. Получите и сравните 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 (см. пример).

Пример настроек DNS, которые могут привести к ошибкам в разрешении IP-адреса хранилища образов Deckhouse…

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

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

    nameserver 10.0.0.10
    search company.my
    

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

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

При обращении на адрес 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.

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

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

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 заданий):

Queue 'main': length 38, status: 'run first task'

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

Queue 'main': length 0, status: 'waiting for task 0s'

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

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

Доступно только в Enterprise Edition.

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

Протестирована и гарантируется работа со следующими container registry: Nexus, Harbor, Artifactory, Docker Registry, Quay.

При установке 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.

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

declare MYUSER='<PROXY_USERNAME>'
declare MYPASSWORD='<PROXY_PASSWORD>'
declare MYREGISTRY='<PROXY_REGISTRY>'

MYAUTH=$(echo -n "$MYUSER:$MYPASSWORD" | base64 -w0)
MYRESULTSTRING=$(echo -n "{\"auths\":{\"$MYREGISTRY\":{\"username\":\"$MYUSER\",\"password\":\"$MYPASSWORD\",\"auth\":\"$MYAUTH\"}}}" | base64 -w0)

echo "$MYRESULTSTRING"

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

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

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

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

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

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

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

Настройка:

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

  2. Заполните поля страницы создания репозитория следующим образом:
    • 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 Enterprise Edition, флажок Authentication должен быть включен, а связанные поля должны быть заполнены следующим образом:
      • Authentication Type должно иметь значение Username.
      • Username должно иметь значение license-token.
      • Password должно содержать ключ лицензии Deckhouse Enterprise Edition.

    Пример настроек репозитория 1 Пример настроек репозитория 2 Пример настроек репозитория 3

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

      Создание роли Nexus

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

      Создание пользователя Nexus

В результате образы 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.

      Настройка Registry

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

      Создание нового проекта

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

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

Доступно только в Standard Edition (SE), Enterprise Edition (EE) и Certified Security Edition (CSE).

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

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

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

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

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

    d8 mirror pull \
      --source='registry.deckhouse.ru/deckhouse/<EDITION>' \
      --license='<LICENSE_KEY>' /home/user/d8-bundle
    

    где:

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

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

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

    • --no-pull-resume — чтобы принудительно начать загрузку сначала;
    • --no-platform — для пропуска загрузки пакета образов Deckhouse Kubernetes Platform (platform.tar);
    • --no-modules — для пропуска загрузки пакетов модулей (module-*.tar);
    • --no-security-db — для пропуска загрузки пакета баз данных сканера уязвимостей (security.tar);
    • --include-module / -i = name[@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).

    Дополнительные параметры конфигурации для семейства команд 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 \
    --license='<LICENSE_KEY>' \
    --since-version=1.59 /home/user/d8-bundle
    

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

    d8 mirror pull \
    --license='<LICENSE_KEY>' \
    --source='registry.deckhouse.ru/deckhouse/se' \
    /home/user/d8-bundle
    

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

    d8 mirror pull \
    --source='corp.company.com:5000/sys/deckhouse' \
    --source-login='<USER>' --source-password='<PASSWORD>' /home/user/d8-bundle
    

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

    d8 mirror pull \
    --license='<LICENSE_KEY>' \
    --no-platform --no-modules /home/user/d8-bundle
    

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

    d8 mirror pull \
    --license='<LICENSE_KEY>' \
    --no-platform --no-security-db /home/user/d8-bundle
    

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

    d8 mirror pull \
    --license='<LICENSE_KEY>' \
    --no-platform --no-security-db \
    --include-module stronghold \
    --include-module secrets-store-integration \
    /home/user/d8-bundle
    
  3. На хост с доступом к хранилищу, куда нужно загрузить образы Deckhouse, скопируйте загруженный пакет образов Deckhouse и установите Deckhouse CLI.

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

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

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

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

    Перед загрузкой образов убедитесь, что путь для загрузки в хранилище образов существует (в примере — /sys/deckhouse) и у используемой учетной записи есть права на запись. Если вы используете Harbor, вы не сможете выгрузить образы в корень проекта, используйте выделенный репозиторий в проекте для размещения образов 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?

Использование registry, отличных от registry.deckhouse.io и registry.deckhouse.ru, доступно только в Enterprise Edition.

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

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

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

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

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

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

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

Доступно только в Enterprise Edition.

Пример шагов по настройке proxy-сервера на базе Squid…

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

    apt-get install squid
    
  3. Создайте файл конфигурации Squid:

    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
    
    # Укажите необходимый порт. Порт 3128 используется по умолчанию.
    http_port 3128
    
  4. Создайте пользователя и пароль для аутентификации на proxy-сервере:

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

    echo "test:$(openssl passwd -crypt test)" >> /etc/squid/passwords
    
  5. Запустите Squid и включите его автоматический запуск при загрузке сервера:

    systemctl restart squid
    systemctl enable squid
    

Для настройки 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"

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

Для применения изменений конфигурации узлов необходимо выполнить команду dhctl converge, запустив инсталлятор Deckhouse. Эта команда синхронизирует состояние узлов с указанным в конфигурации.

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

Общие параметры кластера хранятся в структуре 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?

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

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

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

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

    kubectl run ce-image --image=registry.deckhouse.ru/deckhouse/ce/install:<DECKHOUSE_VERSION> --command sleep -- infinity
    

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

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

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

      CE_SANDBOX_IMAGE=$(kubectl exec ce-image -- cat deckhouse/candi/images_digests.json | grep pause | grep -oE 'sha256:\w*')
      

      Проверка:

      echo $CE_SANDBOX_IMAGE
      

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

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

      CE_K8S_API_PROXY=$(kubectl exec ce-image -- cat deckhouse/candi/images_digests.json | grep kubernetesApiProxy | grep -oE 'sha256:\w*')
      

      Проверка:

      echo $CE_K8S_API_PROXY
      

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

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

      CE_REGISTRY_PACKAGE_PROXY=$(kubectl exec ce-image -- cat deckhouse/candi/images_digests.json | grep registryPackagesProxy | grep -oE 'sha256:\w*')
      

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

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

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

      Image is up to date for sha256:8127efa0f903a7194d6fb7b810839279b9934b200c2af5fc416660857bfb7832
      
    • Получите значение CE_MODULES:

      CE_MODULES=$(kubectl exec ce-image -- ls -l deckhouse/modules/ | grep -oE "\d.*-\w*" | awk {'print $9'} | cut -c5-)
      

      Проверка:

      echo $CE_MODULES
      

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

      common priority-class deckhouse external-module-manager registrypackages ...
      
    • Получите значение USED_MODULES:

      USED_MODULES=$(kubectl get modules | grep Enabled | awk {'print $1'})
      

      Проверка:

      echo $USED_MODULES
      

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

      admission-policy-engine cert-manager chrony ...
      
    • Получите значение MODULES_WILL_DISABLE:

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

      Проверка:

      echo $MODULES_WILL_DISABLE
      

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

      node-local-dns registry-packages-proxy
      

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

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

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

    echo $MODULES_WILL_DISABLE
    

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

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

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

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

    Defaulted container "deckhouse" out of: deckhouse, kube-rbac-proxy, init-external-modules (init)
    Module node-local-dns disabled
    
  4. Создайте ресурс NodeGroupConfiguration:

    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'
    
        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
    
        sed -i 's|image: .*|image: registry.deckhouse.ru/deckhouse/ce@$CE_K8S_API_PROXY|' /var/lib/bashible/bundle_steps/051_pull_and_configure_kubernetes_api_proxy.sh
        sed -i 's|crictl pull .*|crictl pull registry.deckhouse.ru/deckhouse/ce@$CE_K8S_API_PROXY|' /var/lib/bashible/bundle_steps/051_pull_and_configure_kubernetes_api_proxy.sh
    
    EOF
    

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

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

    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-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.
    
  5. Актуализируйте секрет доступа к registry Deckhouse, выполнив следующую команду:

    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 -
    
  6. Примените образ Deckhouse CE. В переменную введите последнюю версию Deckhouse:

    kubectl -n d8-system exec svc/deckhouse-leader -c deckhouse -- kubectl -n d8-system set image deployment/deckhouse deckhouse=registry.deckhouse.ru/deckhouse/ce:<DECKHOUSE_VERSION>
    
  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
    

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

    kubectl -n d8-system exec deploy/deckhouse -- deckhouse-controller module enable registry-packages-proxy
    
  9. Удалите временные файлы, ресурс NodeGroupConfiguration и переменные:

    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
    

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

    kubectl delete ngc del-temp-config.sh
    

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

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

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

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

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

    LICENSE_TOKEN=<PUT_YOUR_LICENSE_TOKEN_HERE>
    AUTH_STRING="$(echo -n license-token:${LICENSE_TOKEN} | base64 )"
    
  2. Cоздайте ресурс NodeGroupConfiguration для переходной авторизации в registry.deckhouse.ru:

    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'
    
        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
    
    EOF
    

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

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

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

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

    kubectl run ee-image --image=registry.deckhouse.ru/deckhouse/ee/install:<DECKHOUSE_VERSION> --command sleep -- infinity
    

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

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

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

      EE_SANDBOX_IMAGE=$(kubectl exec ee-image -- cat deckhouse/candi/images_digests.json | grep pause | grep -oE 'sha256:\w*')
      

      Проверка:

      echo $EE_SANDBOX_IMAGE
      

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

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

      EE_K8S_API_PROXY=$(kubectl exec ee-image -- cat deckhouse/candi/images_digests.json | grep kubernetesApiProxy | grep -oE 'sha256:\w*')
      

      Проверка:

      echo $EE_K8S_API_PROXY
      

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

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

      EE_REGISTRY_PACKAGE_PROXY=$(kubectl exec ee-image -- cat deckhouse/candi/images_digests.json | grep registryPackagesProxy | grep -oE 'sha256:\w*')
      

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

      crictl pull registry.deckhouse.ru/deckhouse/ee@$EE_REGISTRY_PACKAGE_PROXY
      

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

      Image is up to date for sha256:8127efa0f903a7194d6fb7b810839279b9934b200c2af5fc416660857bfb7832
      
  4. Создайте ресурс NodeGroupConfiguration:

    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'
    
        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
    
        sed -i 's|image: .*|image: registry.deckhouse.ru/deckhouse/ee@$EE_K8S_API_PROXY|' /var/lib/bashible/bundle_steps/051_pull_and_configure_kubernetes_api_proxy.sh
        sed -i 's|crictl pull .*|crictl pull registry.deckhouse.ru/deckhouse/ee@$EE_K8S_API_PROXY|' /var/lib/bashible/bundle_steps/051_pull_and_configure_kubernetes_api_proxy.sh
    
    EOF
    

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

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

    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-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.
    
  5. Актуализируйте секрет доступа к registry Deckhouse, выполнив следующую команду:

    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 -
    
  6. Примените образ Deckhouse EE. В переменную введите последнюю версию Deckhouse:

    kubectl -n d8-system exec svc/deckhouse-leader -c deckhouse -- kubectl -n d8-system set image deployment/deckhouse deckhouse=registry.deckhouse.ru/deckhouse/ee:<DECKHOUSE_VERSION>
    
  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 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
    
  9. Удалите временные файлы, ресурс NodeGroupConfiguration и переменные:

    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
    

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

    kubectl delete ngc del-temp-config.sh
    

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

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

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

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

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

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

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

    LICENSE_TOKEN=<PUT_YOUR_LICENSE_TOKEN_HERE>
    AUTH_STRING="$(echo -n license-token:${LICENSE_TOKEN} | base64 )"
    
  2. Cоздайте ресурс NodeGroupConfiguration для переходной авторизации в registry.deckhouse.ru:

    sudo /opt/deckhouse/bin/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'
    
        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
    
    EOF
    

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

    sudo /opt/deckhouse/bin/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-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.
    
  3. Запустите временный под Deckhouse SE, чтобы получить актуальные дайджесты и список модулей. В переменную введите последнюю версию Deckhouse:

    sudo /opt/deckhouse/bin/kubectl run se-image --image=registry.deckhouse.ru/deckhouse/se/install:<DECKHOUSE_VERSION> --command sleep -- infinity
    

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

    sudo /opt/deckhouse/bin/kubectl get deckhousereleases
    
  4. После перехода пода в статус Running выполните следующие команды:

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

      SE_SANDBOX_IMAGE=$(sudo /opt/deckhouse/bin/kubectl exec se-image -- cat deckhouse/candi/images_digests.json | grep pause | grep -oE 'sha256:\w*')
      

      Проверка:

      echo $SE_SANDBOX_IMAGE
      

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

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

      SE_K8S_API_PROXY=$(sudo /opt/deckhouse/bin/kubectl exec se-image -- cat deckhouse/candi/images_digests.json | grep kubernetesApiProxy | grep -oE 'sha256:\w*')
      

      Проверка:

      echo $SE_K8S_API_PROXY
      

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

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

      SE_REGISTRY_PACKAGE_PROXY=$(sudo /opt/deckhouse/bin/kubectl exec se-image -- cat deckhouse/candi/images_digests.json | grep registryPackagesProxy | grep -oE 'sha256:\w*')
      

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

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

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

      Image is up to date for sha256:7e9908d47580ed8a9de481f579299ccb7040d5c7fade4689cb1bff1be74a95de
      
    • Получите значение SE_MODULES:

      SE_MODULES=$(sudo /opt/deckhouse/bin/kubectl exec se-image -- ls -l deckhouse/modules/ | grep -oE "\d.*-\w*" | awk {'print $9'} | cut -c5-)
      

      Проверка:

      echo $SE_MODULES
      
      common priority-class deckhouse external-module-manager ...
      
    • Получите значение USED_MODULES:

      USED_MODULES=$(sudo /opt/deckhouse/bin/kubectl get modules | grep Enabled | awk {'print $1'})
      

      Проверка:

      echo $USED_MODULES
      

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

      admission-policy-engine cert-manager chrony ...
      
    • Сформируйте список модулей, которые должны быть отключены:

      MODULES_WILL_DISABLE=$(echo $USED_MODULES | tr ' ' '\n' | grep -Fxv -f <(echo $SE_MODULES | tr ' ' '\n'))
      
  5. Убедитесь, что используемые в кластере модули поддерживаются в SE-редакции. Посмотреть список модулей, которые не поддерживаются SE-редакцией и будут отключены:

    echo $MODULES_WILL_DISABLE
    

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

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

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

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

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

    sudo /opt/deckhouse/bin/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'
    
        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
    
        sed -i 's|image: .*|image: registry.deckhouse.ru/deckhouse/se@$SE_K8S_API_PROXY|' /var/lib/bashible/bundle_steps/051_pull_and_configure_kubernetes_api_proxy.sh
        sed -i 's|crictl pull .*|crictl pull registry.deckhouse.ru/deckhouse/se@$SE_K8S_API_PROXY|' /var/lib/bashible/bundle_steps/051_pull_and_configure_kubernetes_api_proxy.sh
    
    EOF
    

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

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

    sudo /opt/deckhouse/bin/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-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.
    
  7. Актуализируйте секрет доступа к registry Deckhouse, выполнив следующую команду:

    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 | sudo /opt/deckhouse/bin/kubectl -n d8-system exec -i svc/deckhouse-leader -c deckhouse -- kubectl replace -f -
    
  8. Примените образ Deckhouse SE. В переменную введите последнюю версию Deckhouse:

    sudo /opt/deckhouse/bin/kubectl -n d8-system exec -i svc/deckhouse-leader -c deckhouse -- kubectl -n d8-system set image deployment/deckhouse deckhouse=registry.deckhouse.ru/deckhouse/se:<DECKHOUSE_VERSION>
    

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

    sudo /opt/deckhouse/bin/kubectl get deckhousereleases
    
  9. Дождитесь перехода пода Deckhouse в статус Ready и убедитесь в выполнении всех задач в очереди. Если во время обновления возникает ошибка ImagePullBackOff, подождите, пока под перезапустится автоматически.

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

    sudo /opt/deckhouse/bin/kubectl -n d8-system get po -l app=deckhouse
    

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

    sudo /opt/deckhouse/bin/kubectl -n d8-system exec deploy/deckhouse -c deckhouse -- deckhouse-controller queue list
    
  10. Проверьте, не осталось ли в кластере подов с адресом registry для Deckhouse EE:

    sudo /opt/deckhouse/bin/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
    
  11. Удалите временные файлы, ресурс NodeGroupConfiguration и переменные:

    sudo /opt/deckhouse/bin/kubectl delete ngc containerd-se-config.sh se-set-sha-images.sh
    sudo /opt/deckhouse/bin/kubectl delete pod se-image
    sudo /opt/deckhouse/bin/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
    

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

    sudo /opt/deckhouse/bin/kubectl delete ngc del-temp-config.sh
    

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

  • Инструкция подразумевает использование публичного адреса 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 возможна временная недоступность компонентов кластера.

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

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

      kubectl -n d8-system exec -ti svc/deckhouse-leader -c deckhouse -- deckhouse-controller edit cluster-configuration
      
    2. Измените параметр kubernetesVersion на значение "1.27" (в кавычках).
    3. Сохраните изменения. Узлы кластера начнут последовательно обновляться.
    4. Дождитесь окончания обновления. Отслеживать ход обновления можно с помощью команды kubectl get no. Обновление можно считать завершенным, когда в выводе команды у каждого узла кластера в колонке VERSION появится обновленная версия.
  2. Подготовьте переменные с токеном лицензии и создайте 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
    

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

    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]: 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.
    
  3. Выполните следующие команды для запуска временного пода Deckhouse CSE для получения актуальных дайджестов и списка модулей:

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

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

    CSE_DECKHOUSE_INIT_CONTAINER=$(kubectl exec cse-image -- cat deckhouse/candi/images_digests.json | jq -r ".common.init")
    
  4. Убедитесь, что используемые в кластере модули поддерживаются в Deckhouse CSE. Например, на текущий момент в Deckhouse CSE отсутствует модуль cert-manager. Поэтому, перед отключением модуля cert-manager необходимо перевести режим работы HTTPS некоторых компонентов (например user-authn или prometheus) на альтернативные варианты работы, либо изменить глобальный параметр отвечающий за режим работы HTTPS в кластере.

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

    echo $MODULES_WILL_DISABLE
    

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

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

    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 и выполнения всех задач в очереди.

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

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

    kubectl get modules
    
  5. Создайте 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]: 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.
    
  6. Актуализируйте секрет доступа к registry Deckhouse CSE, выполнив следующую команду:

    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 | sudo /opt/deckhouse/bin/kubectl -n d8-system exec -i svc/deckhouse-leader -c deckhouse -- kubectl replace -f -
    
  7. Измените образ Deckhouse на образ Deckhouse CSE:

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

    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:

    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
    
  8. Дождитесь перехода пода 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
    
  9. Проверьте, не осталось ли в кластере подов с адресом 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, заново включите данный модуль (в Deckhouse CSE этот модуль по умолчанию выключен):

    kubectl -n d8-system exec deploy/deckhouse -- deckhouse-controller module enable chrony
    
  10. Очистите временные файлы, ресурс NodeGroupConfiguration и переменные:

    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:

    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 в этом случае будут проставлены автоматически.

Используйте для запуска Deckhouse только узлы с типом CloudStatic или Static. Также избегайте использования для запуска Deckhouse группы узлов (NodeGroup), содержащей только один узел.

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

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