На странице представлены часто задаваемые вопросы по настройке и использованию Deckhouse Kubernetes Platform.

Общее

Как принудительно обновить модуль?

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

Аннотация применяет релиз немедленно, не дожидаясь окна обновлений. Требования из spec.requirements при этом сохраняются — если они не выполняются, релиз не будет применен.

Пример установки аннотации для модуля console:

d8 k annotate mr console-v1.43.3 modules.deckhouse.io/apply-now="true"

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

apiVersion: deckhouse.io/v1alpha1
kind: ModuleRelease
metadata:
  name: console-v1.43.3
  annotations:
    modules.deckhouse.io/apply-now: "true"
...

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

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

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

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

d8 k 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"
...

Что делать, если при включенном VPN контейнер с установщиком не может получить доступ к сети?

Если на компьютере, с которого выполняется bootstrap кластера, включен VPN, контейнер с установщиком (включая графический инсталлятор) может потерять доступ к сети. Из-за этого, например, веб-интерфейс графического инсталлятора может не открываться в браузере.

Решить проблему можно одним из следующих способов:

  • Отключите VPN на компьютере и перезапустите контейнер с установщиком.

  • Если отключить VPN нельзя (например, bootstrap кластера выполняется в сети VPN), используйте при запуске контейнера с установщиком параметр --network host (для Docker Desktop на Mac OS параметр доступен, начиная с версии 4.34.0). Это позволит контейнеру получить доступ к сети.

    Пример запуска контейнера с установщиком при включённом VPN, с использованием параметра --network host:

    docker run --network host --pull=always -it -v "$PWD/config.yml:/config.yml" -v "$HOME/.ssh/:/tmp/.ssh/" -v "$PWD/dhctl-tmp:/tmp/dhctl" registry.deckhouse.ru/deckhouse/ce/install:early-access bash

    Пример запуска графического инсталлятора при включённом VPN, с использованием параметра --network host:

    docker run --network host --rm --pull always -v $HOME/.d8installer:$HOME/.d8installer -v /var/run/docker.sock:/var/run/docker.sock -p 127.0.0.1:8080:8080 registry.deckhouse.ru/deckhouse/installer:latest -r $HOME/.d8installer

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

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

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

По умолчанию канал обновлений для модулей наследуется от канала обновлений DKP (указывается в параметре releaseChannel ModuleConfig deckhouse). Подробнее про каналы обновлений — в разделе «Каналы обновлений».

Для модулей из источника канал обновлений задается с помощью ModuleUpdatePolicy, который затем привязывается к модулю через параметр updatePolicy в ModuleConfig.

Чтобы сменить канал обновлений у модуля из источника, выполните следующие шаги:

  1. Определите политику обновления модуля.

    Создайте ModuleUpdatePolicy, в котором укажите канал обновлений в параметре releaseChannel.

    Пример ModuleUpdatePolicy:

    apiVersion: deckhouse.io/v1alpha2
kind: ModuleUpdatePolicy
metadata:
  name: my-module-policy
spec:
  releaseChannel: Alpha
  # При необходимости, укажите режим обновления и окна обновления.
  # update:
  #   mode: AutoPatch
  #   windows: []

    Убедитесь, что политика создана:

    d8 k get mup my-module-policy

    Пример ответа:

    NAME               RELEASE CHANNEL   UPDATE MODE
my-module-policy   Alpha             AutoPatch

  2. Свяжите политику обновления с модулем.

    Укажите имя созданной политики обновления в параметре updatePolicy ModuleConfig соответствующего модуля.

    Для редактирования ModuleConfig используйте команду (укажите имя модуля):

    d8 k edit mc my-module

    Пример ModuleConfig:

    apiVersion: deckhouse.io/v1alpha1
kind: ModuleConfig
metadata:
  name: my-module
spec:
  enabled: true
  # Имя ModuleUpdatePolicy
  updatePolicy: my-module-policy

При изменении канала обновлений модуля, его установленная версия изменится согласно настроенному режиму обновления.

Чтобы посмотреть текущий канал обновлений модуля и другую информацию о его состоянии в кластере, используйте соответствующий объект Module.

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

d8 k get module my-module -o yaml

Используемая политика обновления будет указана в поле properties.updatePolicy, текущий канал обновлений — в поле properties.releaseChannel. Пример вывода:

apiVersion: deckhouse.io/v1alpha1
kind: Module
metadata:
  name: my-module
  # ...
properties:
  # ...
  releaseChannel: Alpha # Канал обновлений модуля.
  updatePolicy: my-module-policy # Политика обновлений модуля.
  version: v1.16.10  # Версия модуля.
  # ...

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

В некоторых случаях может возникнуть проблема с автоматическим скачиванием образа и переустановкой модуля. Среди этих случаев:

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

При этом модуль может находиться в статусе Ready. А ошибка возникает в подах модуля. Чтобы найти проблемный под используйте команду:

d8 k -n d8-<module-name> get pods

У проблемного пода будет статус, отличающийся от Running.

Для просмотра информации о поде используйте команду:

d8 k -n d8-<module-name> describe pod <pod-name>

Пример сообщения об ошибке в поде при проблеме со скачиванием образа и переустановкой модуля:

Failed to pull image "registry.deckhouse.ru/deckhouse/ce/modules/console@sha256:a12b4f8de1d997005155d0ba0a7c968a015dd8d18bb5d54645ddb040ddab1ef4": rpc error: code = NotFound desc = failed to pull and unpack image "registry.deckhouse.ru/deckhouse/ce/modules/console@sha256:a12b4f8de1d997005155d0ba0a7c968a015dd8d18bb5d54645ddb040ddab1ef4": failed to resolve reference ...

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

  1. Получите список релизов модуля:

    d8 k get mr -l module=my-module

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

    NAME               PHASE        UPDATE POLICY   TRANSITIONTIME   MESSAGE
my-module-v3.7.4   Superseded                   5d23h
my-module-v3.7.5   Deployed                     5d23h

    Найдите в списке релиз модуля, развернутый в кластере (он должен иметь статус Deployed).

  2. Добавьте к развернутому релизу аннотацию modules.deckhouse.io/reinstall=true:

    d8 k annotate mr my-module-v3.7.5 modules.deckhouse.io/reinstall=true

После добавления аннотации образ модуля заново скачивается из хранилища образов, модуль валидируется с текущими настройками из ModuleConfig и устанавливается в кластер. После успешной переустановки аннотация автоматически удаляется из ModuleRelease.

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

d8 k -n d8-<module-name> get pods

Все поды модуля должны иметь статус Running. Пример:

NAME                                READY   STATUS    RESTARTS   AGE
backend-567d6c6cdc-g5qgt            1/1     Running   0          2d2h
frontend-7c8b567759-h8jdf           1/1     Running   0          2d2h
observability-gw-86cf75f5d6-7xljh   1/1     Running   0          2d2h

Кластер и инфраструктура

Что делать в случае проблем с добавлением узла в кластер через Cluster API Provider Static?

Если при добавлении узла в кластер через Cluster API Provider Static (CAPS) он остается в статусе Pending или в Bootstrapping, выполните следующие действия:

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

  2. На узле, с добавлением которого возникла проблема, проверьте наличие в authorized_keys публичного ключа, соответствующего приватному из SSHCredentials. Пример команды для проверки:

    cat ~/.ssh/authorized_keys

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

  4. Проверьте статус службы bashible.service на узле, с добавлением которого возникла проблема:

    systemctl status bashible.service

    Он должен быть в статусе active (running). Если сервис находится в статусе inactive или failed — служба не запустилась. Это указывает на проблему в процессе настройки.

  5. Если указанные выше шаги не помогли устранить проблему, удалите из кластера проблемный узел и его ресурс StaticInstance, чтобы система попыталась создать их заново. Для этого:

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

      d8 k get nodes

    • Найдите соответствующий ресурс StaticInstance:

      d8 k get staticinstances -n <namespace-name>

    • Удалите проблемный узел:

      d8 k delete node <node-name>

    • Удалите соответствующий ресурс StaticInstance:

      d8 k delete staticinstances -n <namespace-name> <static-instance-name>

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

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

  1. Сделайте резервную копию etcd и папки /etc/kubernetes.
  2. Скопируйте полученный архив за пределы кластера (например, на локальную машину).
  3. Убедитесь, что в кластере нет алертов, которые могут помешать обновлению master-узлов.

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

    d8 s queue list

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

    Summary:
- 'main' queue: empty.
- 88 other queues (0 active, 88 empty): 0 tasks.
- no tasks to handle.

  5. На локальной машине запустите контейнер установщика Deckhouse соответствующей редакции и версии (измените адрес container registry при необходимости):

    DH_VERSION=$(d8 k -n d8-system get deployment deckhouse -o jsonpath='{.metadata.annotations.core\.deckhouse\.io\/version}') 
DH_EDITION=$(d8 k -n d8-system get deployment deckhouse -o jsonpath='{.metadata.annotations.core\.deckhouse\.io\/edition}' | tr '[:upper:]' '[:lower:]' ) 
docker run --pull=always -it -v "$HOME/.ssh/:/tmp/.ssh/" \
  registry.deckhouse.ru/deckhouse/${DH_EDITION}/install:${DH_VERSION} bash

  6. В контейнере с инсталлятором выполните следующую команду, чтобы проверить состояние перед началом работы:

    dhctl terraform check --ssh-agent-private-keys=/tmp/.ssh/<SSH_KEY_FILENAME> --ssh-user=<USERNAME> \
  --ssh-host <MASTER-NODE-0-HOST> --ssh-host <MASTER-NODE-1-HOST> --ssh-host <MASTER-NODE-2-HOST>

    Ответ должен сообщить, что Terraform не нашел расхождений и изменений не требуется.

  7. В контейнере с инсталлятором выполните команду для редактирования конфигурации кластера (укажите адреса всех master-узлов в параметре --ssh-host):

    dhctl config edit provider-cluster-configuration --ssh-agent-private-keys=/tmp/.ssh/<SSH_KEY_FILENAME> --ssh-user=<USERNAME> \
  --ssh-host <MASTER-NODE-0-HOST> --ssh-host <MASTER-NODE-1-HOST> --ssh-host <MASTER-NODE-2-HOST>

  8. Отредактируйте параметр instanceClass нужной группы узлов, изменив тип инстанса, и сохраните изменения. Пример настроек для masterNodeGroup провайдера Yandex Cloud:

    masterNodeGroup:
 replicas: 3  # требуемое количество master-узлов
 instanceClass:
   cores: 4      # изменить количество CPU
   memory: 8192  # изменить объем памяти (в MB)
   # другие параметры инстанса...
   externalIPAddresses:
   - "Auto"      # для каждого master-узла
   - "Auto"
   - "Auto"

  9. В контейнере с инсталлятором выполните следующую команду, чтобы провести обновление узлов:

    Внимательно изучите действия, которые планирует выполнить converge, когда запрашивает подтверждение.

    При выполнении команды узлы будут заменены на новые с подтверждением на каждом узле. Замена будет выполняться по очереди в обратном порядке (2,1,0).

    dhctl converge --ssh-agent-private-keys=/tmp/.ssh/<SSH_KEY_FILENAME> --ssh-user=<USERNAME> \
  --ssh-host <MASTER-NODE-0-HOST> --ssh-host <MASTER-NODE-1-HOST> --ssh-host <MASTER-NODE-2-HOST>

    Следующие действия (п. 9-12) выполняйте поочередно на каждом master-узле, начиная с узла с наивысшим номером (с суффиксом 2) и заканчивая узлом с наименьшим номером (с суффиксом 0).

  10. На созданном узле откройте журнал systemd-юнита bashible.service. Дождитесь окончания настройки узла — в журнале должно появиться сообщение nothing to do:

    journalctl -fu bashible.service

  11. Проверьте, что узел etcd отобразился в списке узлов кластера:

    for pod in $(d8 k -n kube-system get pod -l component=etcd,tier=control-plane -o name); do
  d8 k -n kube-system exec "$pod" -- etcdctl --cacert /etc/kubernetes/pki/etcd/ca.crt \
  --cert /etc/kubernetes/pki/etcd/ca.crt --key /etc/kubernetes/pki/etcd/ca.key \
  --endpoints https://127.0.0.1:2379/ member list -w table
  if [ $? -eq 0 ]; then
    break
  fi
done

  12. Убедитесь, что control-plane-manager функционирует на узле.

    d8 k -n kube-system wait pod --timeout=10m --for=condition=ContainersReady \
  -l app=d8-control-plane-manager --field-selector spec.nodeName=<MASTER-NODE-N-NAME>
  13. Перейдите к обновлению следующего узла.

Что делать, если после добавления объекта не создаются порождаемые им ресурсы?

Если после создания объекта в системе (например, dexAuthenticator) нужные ресурсы не появились, выполните следующие шаги:

  1. Проверьте, есть ли в кластере критические алерты, которые могут блокировать создание нужных объектов. Для этого используйте команду:

    d8 k get clusteralerts.deckhouse.io

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

    NAME               ALERT                                           SEVERITY   AGE   LAST RECEIVED   STATUS
012f602592aa7a91   K8SSchedulerTargetDown                          3          16h   54s             firing
0836dc893d5ecc65   KubernetesDeploymentReplicasUnavailable         5          15h   62s             firing
08742f87d62d0063   NTPDaemonOnNodeDoesNotSynchronizeTime           5          16h   46s             firing
172cfd38d2f7fd19   D8DeckhouseQueueIsHung                          7          12h   66s             firing
1c5705daf731f5cf   D8StrongholdNoActiveNodes                       3          16h   55s             firing
1d2c2f7d69f69f4b   D8DeckhouseIsNotOnReleaseChannel                9          12h   53s             firing
205a551243d795f3   D8LogShipperAgentNotScheduledInCluster          7          15h   63s             firing
2e34039aa7a3018e   D8NodeIsNotUpdating                             9          12h   47s             firing
31baf9a70d657275   D8StrongholdClusterNotHealthy                   7          16h   55s             firing

    Подробнее об алертах — в разделе «Список алертов».

  2. Проверьте очередь заданий Deckhouse:

    d8 s queue list

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

    Summary:
- 'main' queue: empty.
- 88 other queues (0 active, 88 empty): 0 tasks.
- no tasks to handle.

    Если в очереди много необработанных или долго выполняющихся заданий, это может говорить о проблемах.

  3. Проанализируйте логи и события DKP:

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

      d8 k -n d8-system logs -f -l app=deckhouse

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

      {"level":"info","logger":"addon-operator","msg":"ConvergeModules task for OperatorStartup in phase '', trigger is Operator-Startup","binding":"ConvergeModules","event.type":"OperatorStartup","queue":"main","task.flow":"start","task.id":"fde0eb3b-5c3e-4da6-a0d8-a52f8ae03428","time":"2025-11-26T08:29:33Z"}
{"level":"warn","logger":"addon-operator.converge-modules","msg":"ConvergeModules: functional scheduler not finished","binding":"ConvergeModules","event.type":"OperatorStartup","queue":"main","task.id":"fde0eb3b-5c3e-4da6-a0d8-a52f8ae03428","time":"2025-11-26T08:29:33Z"}

      При анализе логов особое внимание обращайте на предупреждения (WARNING) и сообщения об ошибках (ERROR).

    • Для просмотра событий используйте команду:

      d8 k -n d8-system get events

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

      LAST SEEN   TYPE      REASON              OBJECT                                          MESSAGE
11m         Warning   Unhealthy           pod/deckhouse-5886c9bd77-vgdbw                  Readiness probe failed: HTTP probe failed with statuscode: 500
7m22s       Normal    SuccessfulDelete    replicaset/deckhouse-5886c9bd77                 Deleted pod: deckhouse-5886c9bd77-vgdbw
7m20s       Normal    Scheduled           pod/deckhouse-6bc5c4494-fwx6z                   Successfully assigned d8-system/deckhouse-6bc5c4494-fwx6z to sandbox1-master-0
7m20s       Normal    Pulling             pod/deckhouse-6bc5c4494-fwx6z                   Pulling image "dev-registry.deckhouse.io/sys/deckhouse-oss@sha256:17ac07634e17422df52720264cddec3916ed6985a77782dc8a24fe5352290e6e"

    При анализе событий особое внимание обращайте на те, у которых тип Warning.

Deckhouse

Как узнать версию DKP на каждом из каналов обновлений?

Актуальная информация о версиях DKP на разных каналах обновлений доступна на сайте releases.deckhouse.ru.

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

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

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

d8 s queue list

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

Summary:
- 'main' queue: empty.
- 88 other queues (0 active, 88 empty): 0 tasks.
- no tasks to handle.

Как посмотреть состояние очереди заданий main?

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

d8 s queue main

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

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

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

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

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

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

  • Проверьте корректность разрешения 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:

    d8 k -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-адреса хранилища образов DKP

Далее описан пример, когда настройки 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. Имя registry.deckhouse.ru.company.my разрешится в IP-адрес 10.0.0.100, так как в DNS-зоне company.my настроено разрешение wildcard-записей *.company.my в адрес 10.0.0.100. В результате к хосту registry.deckhouse.ru будет невозможно подключиться и скачать информацию о доступных обновлениях Deckhouse.

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

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

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

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

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

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

Если алерт DeckhouseUpdating перестал отображаться, это означает, что обновление завершено.

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

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

d8 k -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 минут, это может говорить о наличии проблем в работе DKP. Необходима диагностика.
  • Если под не находится в статусе Running, это может говорить о наличии проблем в работе DKP. Необходима диагностика.

Если что-то пошло не так

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

    d8 k -n d8-system logs -f -l app=deckhouse | jq -Rr 'fromjson? | .msg'

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

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

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

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

Что делать при наличии проблем с обновлением DKP?

Обновление Deckhouse Kubernetes Platform не проходит, один или несколько подов Deckhouse в нерабочем состоянии

Если обновление Deckhouse Kubernetes Platform не проходит, один или несколько подов Deckhouse в пространстве имен d8-system находятся в нерабочем состоянии, выполните следующие действия:

  1. Проверьте логи Deckhouse с помощью команды:

    d8 k -n d8-system logs -f -l app=deckhouse | jq -Rr 'fromjson? | .msg'

    При наличии проблем информация о них будет в выводе. При анализе логов особое внимание обращайте на предупреждения (WARNING) и сообщения об ошибках (ERROR).

  2. Проверьте события подов Deckhouse с помощью команды:

    d8 k -n d8-system describe po -l app=deckhouse | awk '
/^Name:/ { 
    pod = $2; 
    print "=== " pod " ==="; 
    in_events = 0 
}
/Events:/ { 
    in_events = 1; 
    next 
}
in_events && /^$/ { 
    in_events = 0; 
    print "---" 
}
in_events && !/^Events:/ { 
    print $0 
}
' | sed '/^---$/N;/^\n$/D'

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

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

    Type     Reason     Age                      From     Message
----     ------     ----                     ----     -------
Warning  Unhealthy  4m44s (x1918 over 154m)  kubelet  Readiness probe failed: HTTP probe failed with statuscode: 500

Обновление DKP висит в статусе Release is suspended

Состояние релиза Release is suspended говорит о том, что он был отложен, и на данный момент недоступен (не рекомендуется) для установки. В таком случае предлагается оставаться на последнем доступном релизе, либо на установленном в данный момент (он будет иметь статус Deployed).

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

d8 k get deckhousereleases.deckhouse.io

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

NAME       PHASE        TRANSITIONTIME   MESSAGE
v1.69.13   Skipped      3h46m
v1.69.14   Skipped      3h46m
v1.69.15   Skipped      3h46m
v1.69.16   Superseded   160m
v1.70.12   Suspended    49d              Release is suspended
v1.70.13   Skipped      36d
v1.70.14   Skipped      34d
v1.70.15   Skipped      28d
v1.70.16   Skipped      19d
v1.70.17   Deployed     160m
v1.71.3    Suspended    14d              Release is suspended

Идентификация и доступ

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

Если вы изменили настройки DexProvider в модуле user-authn и при этом наблюдается одна из следующих проблем:

  • не видно никаких изменений (настройки не применяются);
  • при попытке входа в веб-интерфейс платформы с любым типом авторизации возникает ошибка 500 Internal Server Error без подробного описания.

Выполните следующие действия:

  1. Проверьте статус подов деплоймента dex:

    d8 k -n d8-user-authn get pod

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

    NAME                                    READY   STATUS    RESTARTS   AGE
dex-5ddb779b7d-6pbhs                    2/2     Running   0          20h
kubeconfig-generator-7c46977b9f-5kdmc   1/1     Running   0          20h

    Если модуль работает нормально и в DexProvider указана корректная конфигурация, все поды будут в статусе Running.

  2. Посмотрите логи проблемного пода:

    d8 k -n d8-user-authn logs dex-<pod-name>

    На основе информации из логов исправьте конфигурацию в ресурсе DexProvider и дождитесь перезапуска подов dex. В течение нескольких минут поды перезапустятся автоматически, а веб-интерфейс платформы (находится по адресу console.<ШАБЛОН_ИМЕН_КЛАСТЕРА>) станет доступен и в нем отразятся внесенные изменения в ресурс DexProvider.

Kubernetes и планировщик

Что делать при высокой нагрузке на API-сервер?

О проблемах с нагрузкой и потреблением памяти API-сервером могут говорить следующие признаки:

  • kubectl (d8) долго отвечает или не отвечает совсем (команды выполняются медленно или не выполняются);
  • в кластере происходит пересоздание подов без явных причин.

При наличии этих признаков выполните следующие действия:

  1. Проверьте потребление ресурсов подами API-сервера. Для этого используйте команду:

    d8 k -n kube-system top po -l component=kube-apiserver

    Обратите внимание на потребление памяти (MEMORY) и CPU.

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

    NAME                               CPU(cores)   MEMORY(bytes)
kube-apiserver-sandbox1-master-0   251m         1476Mi

  2. Проверьте метрики в Grafana.

    Для просмотра метрик откройте дашборд «Home» → «Dashboards» → «Kubernetes Cluster» → «Control Plane Status». Изучите графики, связанные с API-сервером («Kube-apiserver CPU Usage», «Kube-apiserver Memory Usage», «Kube-apiserver latency» и т.д.).

  3. Изучите аудит-логи API-сервера, чтобы выявить источник высокого потребления памяти. Одна из частых причин высокого потребления памяти — большое количество запросов.

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

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

d8 k get nodes

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

NAME                   STATUS   ROLES                  AGE    VERSION
frontend-0             Ready    frontend               118d   v1.31.9
master-0               Ready    control-plane,master   118d   v1.31.9
master-1               Ready    control-plane,master   118d   v1.31.9
master-2               Ready    control-plane,master   118d   v1.31.9
system-0               Ready    system                 118d   v1.31.9
system-1               Ready    system                 118d   v1.31.9
worker-0               Ready    worker                 37d    v1.31.9
worker-1               Ready    worker                 19d    v1.31.9