Проверка работы кластера в OKD

Для диагностики и устранения ошибок системы откройте приложение OKD:

В приложении доступно:

• просмотр объёма потребления системных ресурсов контейнерами;

• проверка работы подов на каждом узле кластера и аудит их логов;

• проверка доступа к источнику данных;

• проверка событий кластера.

Просмотр объёма потребления системных ресурсов контейнерами

Для просмотра объёма потребления ресурсов центрального процессора (CPU) и оперативной памяти (RAM) контейнерами откройте подраздел «Monitoring > Dashboards» и выберите аналитическую панель «Kubernetes/Compute Resources/Namespace (Pods)» в раскрывающемся списке «Dashboards»:

По умолчанию на диаграмме отображается статистика объёма потребления системных ресурсов по всем подам. Для отображения статистики по конкретному поду наведите курсор на точку диаграммы. После чего будет отображена всплывающая подсказка с наименованием пода и значением объёма потребления соответствующего ресурса.

Примеры диаграмм:

• объём потребления ресурсов CPU разными подами:

• объём потребления ресурсов RAM разными подами:

• информация об ограничениях подов для CPU:

• информация об ограничениях подов для RAM:

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

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

1. Откройте подраздел «Compute > Nodes»:

В таблице отображается список узлов кластера с системными характеристиками.

2. Щёлкните по наименованию узла кластера в столбце «Name» для детализации данных по конкретному узлу кластера.

3. Перейдите на вкладку «Pods»:

На вкладке отображается таблица со списком подов.

4. Проанализируйте работу подов по параметрам (столбцам):

•  Status. Текущее состояние пода:

• Running. Выполнение процессов;

• Completed. Процессы выполнены;

• Error. Ошибка;

• Pending. Ожидание;

• Ready. Количество запущенных контейнеров в формате: <количество запущенных контейнеров>/<общее количество контейнеров>.

Работа пода считается некорректной:

• если состояние пода «Running», но запущены не все контейнеры;

• если состояние пода «Error» или «Pending».

5. Перезапустите под при обнаружении некорректной работы.

Если после перезапуска пода сохраняется некорректное поведение, то проведите аудит логов пода.

Для аудита логов пода на вкладке «Pods»:

1. Щёлкните по наименованию пода в столбце «Name» для детализации данных по конкретному поду.

Совет. Рекомендуется проверить следующие поды: fmp-api, fmp-auth, fmp-dashboard, fmp-rpc, fmp-web.

2. Перейдите на вкладку «Logs»:

3. Отсортируйте логи пода по времени их выполнения с помощью команды:

kubectl logs <наименование пода> -n <пространство имён сервера мобильной платформы> | sort -k 23

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

4. Проанализируйте логи пода. Пример логов, которые указывают на корректную работу контейнеров пода fmp-api (также актуально для fmp-auth, fmp-dashboard, fmp-rpc, fmp-web):

{"request_id"="-","ip": "10.129.2.28", "timestamp": "[08/Sep/2022:10:54:06 +0000]", "http_method: "GET", "URN": "/metrics", "query_string": "", "response_status": 200, "response_length": 1948, "response_time": 0.045690}

Расшифровка примера:

{"request_id"="<идентификатор запроса>", "ip": "<IP-адрес клиента>", "timestamp": "<время отправки ответа клиенту>", "http_method: "<HTTP-метод запроса>", "URN": "<URN>", "query_string": "значения GET-параметров", "response_status": <статус ответа>, "response_length": <длина ответа>, "response_time": <время обработки ответа>}

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

Если с сервера мобильной платформы возвращается ответ с кодом ошибки 502, то проанализируйте логи пода fmp-nginx, характеризующие работу прокси-сервиса nginx.

Проверка доступа к источнику данных

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

• с мобильного устройства;

• с помощью инструмента curl.

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

• из контейнера. Рассмотрим отправку запроса к источнику данных на примере API-метода rpc, для этого:

1. Откройте подраздел «Compute > Nodes».

2. Выберите конкретный узел кластера, в данном случае fmp-rpc.

3. Перейдите на вкладку «Terminal»:

4. Отправьте запрос к источнику данных и сравните результат с ожидаемым.

• с сервера мобильной платформы.

Примечание. Если запрос выполняется только из контейнера, то возможно прокси-сервисы (nginx, ingres кластера и другие) работают некорректно. Для выявления такого сервиса отправьте запрос к каждому из уровней проксирования. Если запрос не выполняется из контейнера, то проверьте таймауты.

Таймауты, указанные на прокси-сервере и фреймворке, должны соответствовать реальному времени выполнения запроса. Проверьте установленные таймауты на прокси-сервере до кластера, на кластере (Ingress Controller) и на источнике данных. Если таймауты указаны корректно, то проверьте события кластера.

Проверка событий кластера

Для проверки и анализа событий кластера выполните одно из действий:

• откройте подраздел «Home > Events»:

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

kubectl get events -n <пространство имён сервера мобильной платформы>

После выполнения действия будет получена информация о событиях кластера. Для получения подробной информации о расшифровке событий кластера обратитесь к документации OKD.