Облачная платформаAdvanced

Как определить коренную причину, если нагрузка аномальна?

Язык статьи: Русский
Показать оригинал
Страница переведена автоматически и может содержать неточности. Рекомендуем сверяться с английской версией.

Если нагрузка аномальна, сначала можно проверить события pod, чтобы определить причину, а затем исправить её.

Определение причины

Шаг 1: Проверьте базовый статус нагрузки (быстро определите тип исключения)

  1. Войдите в CCE console и нажмите название кластера, чтобы открыть консоль кластера.
  2. В панели навигации выберите Workloads и выберите пространство имён в левом верхнем углу страницы.
  3. Найдите целевую нагрузку и проверьте её статус. Ниже приведены сценарии, охватывающие основные состояния нагрузки:

    • Not ready: Проверьте наличие исключений pod. Подробности см. в Step 2: Check for Под Exceptions (Locate the Root Cause of Workload Exceptions).
    • Being processed: Дождитесь завершения операции. Если проблема сохраняется длительное время, выполните шаги устранения неполадок для сценария Not ready.
    • Running: Действия не требуются. Однако, если нагрузка работает, но недоступна, проверьте, нормально ли функционирует внутрикластерный доступ. Подробности см. в Step 3: Check for Access Exceptions (Workload Is Normal But Cannot Be Accessed).

Шаг 2: Проверьте исключения Под (определите коренную причину исключений нагрузки)

Просмотрите события pod, чтобы определить причину. Обратитесь к Viewing Под Events для получения соответствующего решения в зависимости от конкретного события.

Статусы pod, перечисленные в таблице ниже, получены из поля STATUS в выводе команды kubectl get pod.

Note

STATUS — более детальный статус, генерируемый kubectl на основе state.Phase, state.Conditions и status.ContainerStatuses.

Под Status

Description

Reference

Pending

Не удалось запланировать pod.

Что делать, если планирование Pod не удалось?

Pending

Не удалось смонтировать том хранения к pod.

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

FailedPullImage

ImagePullBackOff

Не удалось загрузить образ контейнера.

Снова не удалось загрузить образ контейнера.

Что делать, если Pod не может загрузить образ?

CreateContainerError

CrashLoopBackOff

container не удалось запустить.

container не удалось перезапустить.

Что делать, если запуск Pod не удался?

Evicted

pod неоднократно evicted.

Что делать, если pod не удалось evicted?

Creating

The pod is stuck in the Creating state.

Что делать, если workload остаётся в состоянии Creating?

Terminating

The pod is stuck in the Terminating state.

Что делать, если pod остаётся в состоянии Terminating?

Stopped

The pod is in the Stopped state.

Что делать, если workload находится в состоянии Stopped, вызванном удалением pod?

Шаг 3: Проверка исключений доступа (нагрузка в норме, но недоступна)

Если нагрузка работает, но недоступна, выполните следующие шаги по устранению неполадок:

  1. Получите IP-адрес pod в консоли CCE или выполнив команду kubectl.
  2. Войдите в узел или контейнер кластера, вручную вызовите API с помощью curl и проверьте, правильно ли настроен порт контейнера.
  3. Если {container-IP}:{port} недоступен, войдите в сервисный контейнер и попытайтесь получить доступ к 127.0.0.1:{port}.

Просмотр событий Pod

Метод 1

В консоли CCE нажмите имя рабочей нагрузки, чтобы перейти на страницу деталей рабочей нагрузки, найдите строку, содержащую аномальный pod, и выберите More > View Events в столбце Operation.

Метод 2

Используйте команду kubectl:

kubectl describe pod {pod-name}

Отображается информация, аналогичная следующей:

...
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning FailedScheduling 49s default-scheduler 0/2 nodes are available: 2 Insufficient cpu.
Warning FailedScheduling 49s default-scheduler 0/2 nodes are available: 2 Insufficient cpu.