Metrics-server#

Metrics-server - API-сервер, который сохраняет и предоставляет данные метрик DropApp. Он используется для мониторинга ресурсов кластера, таких как CPU, память и ресурсы сети в режиме реального времени.

Metrics Server собирает метрики ресурсов из kubelets и предоставляет их API-серверу DropApp через Metrics API для использования горизонтального или вертикального автомасштабирования. Доступ к Metrics API также можно получить с помощью команды kubectl top, что упрощает отладку конвейеров автоматического масштабирования.

Metrics Server не предназначен для целей, не связанных с автоматическим масштабированием, в частности, для пересылки метрик решениям для мониторинга. В таких случаях следует собирать метрики напрямую с kubelet.

Metrics Server обладает следующими ключевыми свойствами:

  • единое развертывание, которое работает на большинстве кластеров;

  • сбор метрик каждые 15 секунд;

  • эффективность использования ресурсов при использовании - 1 milli CPU и 2 МБ памяти для каждого узла в кластере;

  • масштабируемая поддержка кластеров до 5000 узлов.

Таблица. Флаги для настройки кластера.

Синтаксис параметра

Описание

--kubelet-preferred-address-types-

Приоритет типов адресов узлов, используемых при определении адреса для подключения к конкретному узлу (по умолчанию Hostname,InternalDNS,InternalIP,ExternalDNS,ExternalIP)

--kubelet-insecure-tls-

Не выполнять проверку ЦС обслуживания сертификатов, представленных kubelets. Только для целей тестирования

--requestheader-client-ca-file-

Указать пакет корневого сертификата для проверки клиентских сертификатов по входящим запросам

Получите полный список флагов конфигурации Metrics Server, выполнив команду:

docker run --rm registry.k8s.io/metrics-server/metrics-server:v0.6.3 --help

Предварительные требования#

Предварительные требования для запроса Metrics API:

  • развернут кластер DropApp;

  • включен уровень агрегации kube-apiserver;

  • включена аутентификация и авторизация Webhook на узлах;

  • подписан сертификат kubelet (или проверка сертификата отключена при помощи команды --kubelet-insecure-tls);

  • реализован RPC средой выполнения контейнера;

  • Сеть поддерживает следующую связь плоскости управления и сервер метрик. Узел плоскости управления должен получить доступ к IP-адресу Metrics Server и порту 10250 (или IP-адресу узла и пользовательскому порту, если hostNetwork включен), а cервер метрик для kubelet должен быть доступен на всех узлах. Серверу метрик необходимо получить доступ к адресу узла и порту kubelet. Адреса и порты настраиваются в kubelet и публикуются как часть объекта Node. Адреса .status.addresses и порт в pod .status.daemonEndpoints.kubeletEndpoint.port (по умолчанию 10250) уже настроены. Сервер метрик выберет адрес первого узла на основе списка, предоставленного kubelet-preferred-address-types флагом командной строки (по умолчанию Internal IP,External IP, Hostname в манифестах).

Выполнение запроса#

  1. Для запроса Metrics API для kube-scheduler, содержащегося в namespace kube-systemи переданного jq для облегчения чтения, можно использовать следующий запрос:

    kubectl get --raw /api/v1/namespaces/kube-system/pods/<pod-name>/metrics --certificate-authority=/path/to/ca.crt --key=/path/to/key.key --kubeconfig=/path/to/kubeconfig.yml --server=https://kubernetes.default --token=<token> | jq -r -f <path/to/jq_script.jq>

    Где:

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

    • certificate-authority и --key указывают на путь к сертификату и ключу, используемым для аутентификации;

    • kubeconfig указывает на путь к файлу kubeconfig, содержащему учетные данные для доступа к API;

    • server указывает на адрес сервера, на котором находится kube-scheduler;

    • token указывает на токен аутентификации, используемый для доступа к API;

    • | jq-r -f указывает на выполнение скрипта jq, который обрабатывает полученные данные и выводит их в нужном формате;

    • <path/to/jq_script.jq> указывает на путь до скрипта jq.

    Обратите внимание, что в данном примере предполагается, что у администратора присутствуют необходимые учетные данные и сертификаты для доступа к API.

  2. Отследите загруженность узлов в кластере, введите команду:

    kubectl top nodes

    Данная команда позволяет вывести список самых ресурсоемких узлов в кластере DropApp. Ресурсоемкость узлов измеряется в терминах потребления памяти и процессора. Команда отправляет запросы на сервер для получения информации о потреблении ресурсов узлами. Затем она выводит эту информацию в виде таблицы с указанием имени узла, его потребления памяти и процессора, а также других важных показателей.

    Вывод будет следующим:

    NAME               CPU(cores)       CPU%    MEMORY(bytes)   MEMORY%
Control plane      83m              2%      1989Mi          26%
Worker1            20m              1%      1889Mi          50% 
Worker2            21m              1%      1289Mi          47%

    Вывод отображает информацию о загрузке ресурсов (CPU и памяти) для разных компонентов кластера DropApp. Каждая строка представляет собой информацию о конкретном компоненте:

    • NAME - имя компонента.

    • CPU(cores) - количество ядер процессора, используемых компонентом.

    • CPU% - процент использования процессора компонентом.

    • MEMORY(bytes) - объем используемой памяти компонентом в байтах.

    • MEMORY% - процент используемой памяти компонентом.