Частые вопросы

Если после создания объекта в системе (например, 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?

Для просмотра состояния всех очередей заданий 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'

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

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

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

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

О проблемах с нагрузкой и потреблением памяти 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 выполните команду:

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

Если при добавлении узла в кластер через 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, выполните следующие шаги:

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. Перейдите к обновлению следующего узла.