Практическое руководство по аудиту ресурсов кластера Kubernetes

В этой статье мы разберем практические методы анализа ресурсного профиля кластера Kubernetes. Я покажу вам, как использовать встроенные инструменты для получения реальной картины потребления CPU и памяти вашими подами, и сравнить эти данные с заданными ограничениями. Эти знания критически важны для оптимизации производительности и затрат на инфраструктуру.

Зачем нужен аудит ресурсов?

Представьте ситуацию: ваши поды "падают" с ошибками OutOfMemory (OOM), планировщик не может разместить новые поды из-за нехватки ресурсов, или, наоборот, кластер простаивает с низкой утилизацией. Все эти проблемы связаны с неправильной настройкой ресурсных лимитов и запросов (requests/limits).

Регулярный аудит ресурсов помогает:

Устранить проблемы производительности
Сократить затраты на инфраструктуру
Обеспечить стабильность работы приложений

Подготовка к аудиту

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

Проверить наличие Metrics Server можно командой:

kubectl get apiservice v1beta1.metrics.k8s.io

Если статус показывает True, можно приступать к работе. Если Metrics Server отсутствует, не переживайте — я покажу альтернативные способы получения метрик. Вы можете использовать Prometheus для долгосрочного анализа, если он пресутсвуют внутри вашей инфраструктуры .

Метод 1: kubectl top pods — быстрый обзор нагрузки

Команда kubectl top — это ваш первый инструмент для получения мгновенного снимка потребления ресурсов. Она работает через Metrics API и обращается к данным, собираемым kubelet'ами на каждом узле.

Базовое использование

# Показать использование ресурсов всех подов во всех namespace'ах
kubectl top pods --all-namespaces

# Показать детализацию по контейнерам
kubectl top pods --all-namespaces --containers

# Показать использование ресурсов узлов
kubectl top nodes

Практические примеры

Давайте разберем несколько крутых сценариев:

# Найти топ-10 подов по потреблению памяти в конкретном namespace
kubectl top pods -n production | sort -k3 -hr | head -10

# Показать только поды, потребляющие больше 500m CPU (милликор)
kubectl top pods --all-namespaces | awk 'NR==1 || $3 > 500'

Что показывают эти метрики:

CPU — текущее потребление в ядрах (1000m = 1 ядро)
Memory — рабочий набор памяти (working set) в мебибайтах

Важно понимать: kubectl top показывает моментальный снимок, а не среднее значение за период. Для получения более репрезентативных данных запускайте команду несколько раз в разное время.

Метод 2: Прямое обращение к kubelet Summary API

Если Metrics Server недоступен или вы хотите получить более детальную информацию, можно обратиться напрямую к Summary API kubelet'а.

Получение данных

Так как приведённая ниже команда может выполнить сбор summary статистики только с одного узла, то провести процедуру необходимо будет на всех узлах кластера с вашими pods.

# На узле кластера
curl -s http://127.0.0.1:8001/api/v1/nodes/$(hostname)/proxy/stats/summary > /tmp/summary.json

Парсинг JSON-ответа

Summary API возвращает подробную статистику в JSON формате. Вот простой Python-скрипт для извлечения ключевых метрик:

#!/usr/bin/env python3
import json
import sys

def parse_kubelet_stats(filename):
    with open(filename, 'r') as f:
        data = json.load(f)

    print(f'{"POD NAME":40} {"CPU (cores)":>12} {"Memory (MiB)":>15}')
    print("-" * 70)

    for pod in data.get("pods", []):
        pod_name = pod["podRef"]["name"]

        total_cpu = 0.0
        total_memory = 0.0

        for container in pod.get("containers", []):
            cpu_usage = container.get("cpu", {}).get("usageNanoCores", 0)
            memory_usage = container.get("memory", {}).get("workingSetBytes", 0)

            total_cpu += cpu_usage / 1e9         # nanocores → cores
            total_memory += memory_usage / (1024 * 1024)  # bytes → MiB

        print(f'{pod_name:40} {total_cpu:12.3f} {total_memory:15.0f}')

if __name__ == "__main__":
    # Если имя файла передано аргументом — используем его, иначе — /tmp/summary.json
    filename = sys.argv[1] if len(sys.argv) > 1 else "/tmp/summary.json"
    parse_kubelet_stats(filename)

Преимущества метода

Работает даже без Metrics Server
Предоставляет более детальную статистику
Включает метрики файловой системы и сети
Не требует дополнительных компонентов в кластере

Ограничения

Показывает данные только с одного узла
Требует сетевого доступа к kubelet API
Нужны соответствующие права доступа (RBAC)

Метод 3: Анализ requests и limits через kubectl describe

Теперь перейдем к анализу того, что было заявлено в спецификациях подов. Это критически важно для понимания разрыва между фактическим и планируемым потреблением ресурсов.

Получение информации о конкретном поде

# Детальная информация о поде
kubectl describe pod <pod-name> -n <namespace>

# Извлечение только секции Resources
kubectl describe pod <pod-name> -n <namespace> | grep -A 10 "Limits:\|Requests:"

# Либо выполните поиск сразу по всем
kubectl describe pods --all-namespaces \
  | grep -E -A2 -B2 "Namespace:|Name:|Container:|Limits:|Requests:"

Метод 4: Использование docker stats для детальной диагностики

Если на узлах кластера используется Docker runtime, команда docker stats предоставляет детальную статистику контейнеров в реальном времени.

Основные команды

# Показать статистику всех запущенных контейнеров
docker stats

# Получить единичный снимок (без постоянного обновления)
docker stats --no-stream

# Показать статистику конкретных контейнеров
docker stats --no-stream $(docker ps --format "table {{.Names}}" | grep k8s)

Интерпретация вывода

Docker stats показывает следующие метрики:

CPU % — процент использования CPU
MEM USAGE/LIMIT — текущее использование памяти и лимит
MEM % — процент от доступной памяти системы
NET I/O — сетевой трафик
BLOCK I/O — дисковые операции

Для containerd runtime

Если используется containerd, аналогичную информацию можно получить командой:

# Список всех задач
ctr -n k8s.io tasks list

# Метрики конкретной задачи
ctr -n k8s.io tasks metrics <task-id>

Практический пример: комплексный аудит

Давайте проведем пошаговый аудит реального namespace:

Шаг 1: Простой скрипт для сбора фактических метрик при наличии Metric Server

#!/bin/bash

# Одноразовый снимок «сейчас» в current_usage.txt
echo "TIMESTAMP              NAME                          CONTAINER             CPU(cores)   MEMORY(bytes)" > current_usage.txt
kubectl top pods --all-namespaces --containers --no-headers \
  | awk -v D="$(date -Iseconds)" \
        '{ printf "%-24s %-28s %-20s %12s %12s\n", D, $1, $2, $3, $4 }' \
  >> current_usage.txt

# Сбор в течение часа каждые 5 минут в usage_log.txt
echo "TIMESTAMP              NAME                          CONTAINER             CPU(cores)   MEMORY(bytes)" > usage_log.txt
for i in {1..12}; do
  kubectl top pods --all-namespaces --containers --no-headers \
    | awk -v D="$(date -Iseconds)" \
          '{ printf "%-24s %-28s %-20s %12s %12s\n", D, $1, $2, $3, $4 }' \
    >> usage_log.txt
  sleep 300
done

Шаг 2: Извлечение requests/limits

kubectl describe pods --all-namespaces \
  | grep -E -A2 -B2 "Namespace:|Name:|Container:|Limits:|Requests:"

Интерпретация результатов и рекомендации

Типичные проблемы и их решения

Завышенные requests
- Симптомы: низкая утилизация узлов, проблемы с планированием
- Решение: уменьшить requests на основе фактического потребления
Заниженные limits
- Симптомы: частые OOM kills, нестабильная работа приложений
- Решение: увеличить limits с учетом пиковых нагрузок
Отсутствие requests/limits
- Симптомы: непредсказуемое поведение кластера
- Решение: установить базовые значения, использовать LimitRange

Заключение

Регулярный аудит ресурсов кластера Kubernetes — это не разовая задача, а постоянный процесс оптимизации. Используя описанные методы, вы сможете:

Выявить неэффективное использование ресурсов
Предотвратить проблемы с производительностью
Оптимизировать затраты на инфраструктуру
Обеспечить стабильную работу приложений

Помните: мониторинг ресурсов должен сочетаться с пониманием специфики ваших приложений. Не всегда математически оптимальные значения являются лучшими с точки зрения надежности системы.

Начните с базового аудита раз в неделю, постепенно автоматизируя процесс и внедряя более сложные инструменты мониторинга по мере роста вашего кластера.