kubectl top и Metrics Server в Kubernetes

Логотип Kubernetes

kubectl top показывает базовую загрузку CPU и памяти для узлов и Pod’ов, но перед этим нужно установить Metrics Server в кластер. В статье описаны установка через манифест или Minikube, типичные команды kubectl top, фильтры и сортировка, а также оперативные советы и чек-листы для отладки.

Быстрые ссылки

Добавление Metrics Server в Kubernetes
Получение метрик через kubectl top
Сортировка списка объектов
Фильтрация объектов
Получение метрик для конкретного ресурса
Когда это не подходит и альтернативы
Итог и рекомендации

Почему это важно

Мониторинг использования ресурсов в кластере помогает отслеживать производительность и понимать, эффективно ли работают ваши приложения. kubectl top быстро показывает базовые показатели прямо в терминале. Это удобно при расследовании всплесков загрузки и при проверке текущего состояния кластера.

Важно понять: kubectl top не собирает метрики сам по себе. Он обращается к API Metrics Server, который агрегирует метрики с узлов и Pod’ов и предоставляет их по HTTP API.

Добавление Metrics Server в Kubernetes

Большинство дистрибутивов Kubernetes не включают Metrics Server по умолчанию. Проверить наличие поддержки просто — попробуйте выполнить:

$ kubectl top node

Если в кластере нет Metrics API, вы увидите ошибку вида:

error: Metrics API not available

Это значит, что компонент не установлен или недоступен.

Metrics Server поддерживается сообществом Kubernetes SIG. Его можно установить двумя основными способами: применив официальный YAML-манифест или используя Helm-чарт. В руководстве мы применяем манифест.

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

$ kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml

Ожидаемые объекты, которые появятся в кластере:

serviceaccount/metrics-server created
clusterrole.rbac.authorization.k8s.io/system:aggregated-metrics-reader created
clusterrole.rbac.authorization.k8s.io/system:metrics-server created
rolebinding.rbac.authorization.k8s.io/metrics-server-auth-reader created
clusterrolebinding.rbac.authorization.k8s.io/metrics-server:system:auth-delegator created
clusterrolebinding.rbac.authorization.k8s.io/system:metrics-server created
service/metrics-server created
deployment.apps/metrics-server created
apiservice.apiregistration.k8s.io/v1beta1.metrics.k8s.io created

После применения манифеста Metrics Server начнёт собирать и выставлять метрики. Если установка завершается с ошибкой, проверьте соответствие требований проекта и ограничения окружения. Некоторые managed-сервисы и специфические сетевые конфигурации требуют дополнительных флагов или патчей.

Пример для Minikube — включение через addons:

$ minikube addons enable metrics-server

Вы увидите сообщение о включении аддона и используемом образе.

Важно: некоторые окружения (особенно с самоподписанными сертификатами API-сервера или с ограниченными RBAC) потребуют подправить манифест — например, разрешить insecure TLS или настроить правильные subjectAltName в сертификатах. В таких случаях читайте документацию проекта Metrics Server.

Получение метрик с помощью kubectl top

После установки можно использовать следующие команды.

Получить метрики по узлам:

$ kubectl top node

Пример вывода:

NAME       CPU(cores)   CPU%   MEMORY(bytes)   MEMORY%
minikube   249m         3%     847Mi           2%

Получить метрики по Pod’ам в текущем namespace:

$ kubectl top pod

Пример вывода:

NAME      CPU(cores)   MEMORY(bytes)
nginx     120m         8Mi

По умолчанию команда показывает объекты в текущем namespace. Чтобы указать namespace, используйте флаг –namespace:

$ kubectl top pod --namespace demo-app

Чтобы просмотреть все Pod’ы во всех неймспейсах, добавьте –all-namespaces.

Отметка: метрики могут появляться с задержкой — несколько минут после старта Pod’а. Это нормально: в pipeline Metrics Server есть буферизация и агрегация, чтобы снизить нагрузку на кластер.

Пояснение единиц: в поле CPU выводятся millicores (m). 1000m = 1 ядро (100%). 500m = 50% одного ядра, 2000m = 2 ядра и т.д.

Сортировка списка объектов

Чтобы быстро найти самые «тяжёлые» Pod’ы или узлы, используйте флаг –sort-by с параметром cpu или memory:

$ kubectl top pod --sort-by=memory

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

Фильтрация списка объектов

Как и в других командах kubectl, доступен –selector для фильтрации по меткам:

$ kubectl top pod --selector application=demo-app

Поддерживаются операторы =, == и !=. Можно комбинировать условия через запятую: application=demo-app,version!=1. В вывод попадут только объекты, соответствующие всем условиям.

Получение метрик для конкретного ресурса

Можно запросить метрики для одного узла или одного Pod’а, передав его имя:

$ kubectl top node minikube

NAME       CPU(cores)   CPU%   MEMORY(bytes)   MEMORY%
minikube   245m         3%     714Mi           2%

Аналогично для Pod’а:

$ kubectl top pod nginx-1

Когда kubectl top и Metrics Server не подходят

Нужна историческая метрика: Metrics Server держит только текущие (агрегированные) значения и не хранит долгую историю. Если вам нужна ретроспектива, используйте Prometheus или другой TSDB.
Тонкая кастомная телеметрия: для метрик прикладного уровня (latency, бизнес-метрики) потребуется отдельный сборщик.
Высокая детализация по контейнерам и cAdvisor: Metrics Server предоставляет ограниченный набор метрик. Для расширенных метрик контейнеров используйте kube-state-metrics + Prometheus.

Альтернативы для сбора и хранения метрик:

Prometheus + node-exporter + kube-state-metrics — полная система мониторинга и алертинга.
Metrics Server + Prometheus Adapter — если нужен API под HPA и Prometheus как источник.
Managed monitoring (Stackdriver, Datadog, New Relic) — для SaaS-решений.

Практические подсказки и эвристики

Проверка состояния Metrics Server:

kubectl get deployment metrics-server -n kube-system
kubectl describe pod -l k8s-app=metrics-server -n kube-system
kubectl logs -l k8s-app=metrics-server -n kube-system

Частая проблема: TLS-ошибки и неопознанные APIService. В этом случае проверьте apiservice:

kubectl get apiservice v1beta1.metrics.k8s.io -o yaml

Если вы используете кастомный kubelet с отключённым /metrics/resource, Metrics Server не сможет собрать данные.
Нагрузку на кластер снижает увеличение интервалов агрегации или настройка мастера сбора на каждом узле.

Чек-листы по ролям

DevOps / SRE

Установить Metrics Server в staging.
Проверить доступность API: kubectl top node
Настроить RBAC и NetworkPolicy для безопасности.
Документировать изменение в runbook.

Разработчик

Убедиться, что приложение имеет метки для фильтрации.
Использовать kubectl top pod –selector в локальной отладке.

Платформенная команда

Решить: хранить ли метрики долгое время и какой бекенд использовать.
Настроить alert’ы при достижении порогов CPU/Memory.

Инцидентный план (короткий)

Увидели всплеск CPU в kubectl top или в системе мониторинга.
Определить источник: kubectl top pod –all-namespaces –sort-by=cpu
Если Pod аномально ест CPU — получить логи: kubectl logs pod -n NAMESPACE
Если проблема воспроизводится, масштабировать Deployment или перезапустить Pod.
Добавить временное ограничение ресурса (requests/limits) при необходимости.
Зафиксировать RCA и обновить playbook.

Критерии приёмки

kubectl top node возвращает список узлов без ошибок.
kubectl top pod возвращает метрики для Pod’ов в целевом namespace.
Latency запроса к metrics API не критична для операций (несколько секунд).
Для production: настроен оповещательный механизм при низком свободном ресурсе.

Безопасность и приватность

Метрики содержат сведённые данные о загрузке, но не включают чувствительную бизнес-информацию. Тем не менее, ограничьте доступ к API Metrics Server через RBAC.
Если используете внешние SaaS-решения для хранения метрик, проверьте условия обработки данных и соответствие требованиям локального законодательства о защите данных.

Примеры команд и полезные сниппеты

Посмотреть самые ресурсоёмкие Pod’ы по CPU во всех неймспейсах:

kubectl top pod --all-namespaces --sort-by=cpu | head -n 20

Проверить метрики конкретного Pod’а и его контейнеров (если доступно):

kubectl top pod nginx-1 --containers

Включить аддон на Minikube:

minikube addons enable metrics-server

Добавление поля requests/limits для пода (пример фрагмента манифеста):

resources:
  requests:
    cpu: "100m"
    memory: "128Mi"
  limits:
    cpu: "500m"
    memory: "512Mi"

Когда ничего не помогает — отладка глубже

Проверьте, что kubelet на каждом узле экспортирует метрики ресурса. Если kubelet настроен с флагами, запрещающими экспорт, Metrics Server не соберёт данные.
Убедитесь, что NetworkPolicy не блокирует связь между Metrics Server и kubelet.
Проверьте логи Metrics Server на предмет ошибок сериализации или авторизации.

Решение типичных ошибок

error: Metrics API not available — Metrics Server не установлен или apiservice не создан.
apiservice.status.conditions: False — проверьте связи TLS и авторизацию.
Пустые метрики для новых Pod’ов — дождитесь завершения агрегации (несколько минут).

Модель принятия решений (Mermaid)

flowchart TD
  A[Нужно увидеть использование CPU/Memory] --> B{Требуется история метрик?}
  B -- Да --> C[Использовать Prometheus]
  B -- Нет --> D[Metrics Server + kubectl top]
  D --> E{Поддерживается ли окружение?}
  E -- Нет --> C
  E -- Да --> F[Установить Metrics Server]
  F --> G[Запросы kubectl top]

Итог

kubectl top вместе с Metrics Server — простой и быстрый способ получать текущие значения CPU и памяти для узлов и Pod’ов. Это полезный инструмент для быстрой диагностики и оперативных проверок. Для долговременного хранения метрик и сложного алертинга лучше использовать полноценное решение на базе Prometheus.

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

Краткие рекомендации