Диагностика

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

Поды остаются в состоянии Pending

Команда d8 k -n code get pods показывает один или несколько подов в состоянии Pending.

Причина. Ни один StorageClass не подходит под gitaly.persistence.storageClass (либо в кластере нет StorageClass по умолчанию), либо ни у одного узла не хватает CPU и памяти для запросов ресурсов пода.

Решение. Прочитайте события пода:

d8 k -n code describe pod <POD_NAME>

Событие FailedScheduling с упоминанием PersistentVolumeClaim указывает на StorageClass; проверьте его командой d8 k get storageclass. Событие FailedScheduling с упоминанием CPU или памяти указывает на ресурсы узла.

У Ingress нет адреса

Команда d8 k -n code get ingress не показывает значение в колонке ADDRESS.

Причина. global.ingress.class не совпадает ни с одним Ingress-контроллером, установленным в кластере, либо у Service самого контроллера ещё нет внешнего адреса.

Решение. Убедитесь, что Ingress-контроллер запущен и что имя его класса совпадает с global.ingress.class. Если Service контроллера имеет тип LoadBalancer, проверьте, что инфраструктура выделила ему адрес.

TLS-сертификат не выпущен

При открытии global.hosts.domain браузер сообщает, что сертификат недействителен или самоподписан.

Причина. Secret, указанный в global.ingress.tls.secretName, не существует в пространстве имён code, либо не содержит сертификат, действительный для global.hosts.domain.

Решение. Проверьте Secret и содержащийся в нём сертификат:

d8 k -n code get secret <TLS_SECRET_NAME> -o yaml

Убедитесь, что субъект сертификата и альтернативные имена (Subject Alternative Names) покрывают global.hosts.domain.

Отказ в подключении к базе данных

Поды перезапускаются, а в их логах видно сообщение PG::ConnectionBad: could not connect to server: Connection refused.

Причина. global.psql.host или global.psql.port не позволяют подключиться к внешнему серверу PostgreSQL, либо сетевые политики блокируют подключение из пространства имён релиза.

Решение. Проверьте доступность сервера из кластера и убедитесь, что база данных из global.psql.database и роль из global.psql.username существуют на сервере.

Учётные данные объектного хранилища отклонены

Загрузка файлов и артефактов завершается ошибкой, а в логах подов виден отказ в доступе от объектного хранилища.

Причина. Secret, указанный в global.appConfig.object_store.connection.secretName, содержит устаревший адрес, регион или ключ доступа, либо бакет не существует.

Решение. Сверьте содержимое Secret с консолью провайдера объектного хранилища и убедитесь, что бакет существует, а у учётных данных есть право на запись в него.

Задача миграций завершается ошибкой

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

Причина. PostgreSQL ещё не доступен, учётные данные в global.psql.password.secretName неверны, либо релиз пропустил версию Deckhouse Code, от которой зависит более поздняя миграция.

Решение. Прочитайте лог задачи:

d8 k -n code logs job/<MIGRATIONS_JOB_NAME>

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

Helm upgrade завершается по тайм-ауту

Команда helm upgrade завершается с сообщением Error: UPGRADE FAILED: timed out waiting for the condition.

Причина. Под или задача миграций не перешли в готовое или завершённое состояние за время ожидания Helm — обычно из-за одной из причин выше.

Решение. Проверьте поды и задачи релиза:

d8 k -n code get pods,jobs

Устраните причину, затем выполните helm upgrade повторно, добавив --timeout, если релизу действительно требуется больше времени.