Аудит Kubernetes

Глубокий анализ кластеров: ноды, поды, workloads, storage, метрики. Находим переплаты и показываем, где сэкономить.

Обзор

Oopps.ai обнаруживает Managed Kubernetes через облачный коннектор, получает kubeconfig через API провайдера или fallback-настройку и читает Kubernetes API. In-cluster агент — отдельный вариант для закрытого API master.

На основе собранных данных платформа формирует детальный отчёт с findings и рекомендациями по оптимизации. Каждый finding содержит приоритет, описание проблемы и расчётную экономию.

Что анализируется

Категория Что собирается Зачем
Nodes CPU/RAM capacity, allocatable, conditions Найти недогруженные ноды
Pods requests, limits; actual usage из metrics-server, если доступен Найти overrequested workloads
Workloads Deployments, StatefulSets, DaemonSets, Jobs Ранжировать по потреблению
Storage PVC, PV, StorageClasses, unbound volumes Найти неиспользуемые диски
Namespaces Суммарное потребление по namespace Top consumers

Как запустить аудит

Проверьте подключение

Выполните Коннекторы → ⋮ → Проверить, затем синхронизацию. Убедитесь, что нужный кластер появился в разделе Кластеры.

Запустите аудит

Перейдите в K8s Аудит. Повторная команда «Обновить данные из облака» в переключателе коннектора синхронизирует данные и запускает аудит обнаруженных кластеров.

Выберите кластер

После выполнения выберите общий отчёт или конкретный кластер в сохранённой истории аудитов.

Дождитесь результатов

Длительность зависит от размера и доступности кластеров. Не запускайте повторный аудит, пока текущий запрос ещё выполняется. По завершении проверьте отчёт и ошибки отдельных кластеров.

Отчёт аудита

После завершения аудита формируется структурированный отчёт, который включает следующие разделы:

Node Pool Analysis

Утилизация CPU и RAM по каждой ноде кластера. Платформа показывает текущую загрузку, allocatable ресурсы и даёт рекомендацию по right-sizing — уменьшить или увеличить пул нод.

Workload Rankings

Top-10 workloads по CPU и RAM consumption. Позволяет быстро понять, какие именно сервисы потребляют больше всего ресурсов и где стоит начать оптимизацию.

Namespace Totals

Расход ресурсов по namespace. Полезно для мультитенантных кластеров, где нужно понять, какой команде или проекту принадлежат основные затраты.

Storage Analysis

PVC usage, unbound volumes, неиспользуемые StorageClasses. Часто забытые PVC после удаления деплоев продолжают оплачиваться — платформа находит их.

Findings

Конкретные проблемы с приоритетом: critical, warning, info. Каждый finding содержит описание проблемы, затронутый ресурс и рекомендуемое действие.

Типы findings

Тип Описание Пример
Overrequested workload requests значительно больше actual usage Deployment nginx requests 4 CPU, uses 0.1
Underutilized node Нода загружена менее 30% Node pool с 8 CPU, используется 1.5
Unused PVC / Orphan PV Хранилище не используется workload либо PV потерял связь с PVC Проверить владельца и политику retention перед удалением
Missing limits Workload без resource limits Может забрать все ресурсы ноды

Требования

Примечание

Если metrics-server недоступен, конфигурационная часть аудита работает без actual usage. Prometheus/VictoriaMetrics — отдельный исторический источник: его опрашивает backend, а не агент версии 0.1.x.

Yandex Cloud: nodes требуют отдельного RBAC

Права cloud API на обнаружение кластера не гарантируют Kubernetes RBAC. Для прямого SaaS-аудита Yandex Cloud backend может потребовать k8s.cluster-api.cluster-admin; альтернатива для закрытого контура — in-cluster агент с отдельным ServiceAccount. Сравните варианты в руководстве по правам Yandex Cloud.

Что дальше?