Как посчитать размер ноды Kubernetes

Расчёт размера ноды Kubernetes: методология и инструменты

Под "размером ноды" в Kubernetes обычно понимают ресурсную ёмкость (capacity) и доступные ресурсы (allocatable) worker-ноды, а также фактическое потребление ресурсов подами. Это критически важно для планирования capacity, балансировки нагрузки и предотвращения сбоев.

Ключевые метрики для оценки размера

Основные измеряемые ресурсы:

• CPU: ядра и милли-ядра (m), лимиты и requests
• Memory (RAM): в байтах, гигабайтах, часто с учётом swap (обычно отключён)
• Ephemeral Storage: временное хранилище на ноде
• PID limit: ограничение по количеству процессов
• Network bandwidth: пропускная способность сети (косвенно)

Методы расчёта

1. Использование kubectl (базовый метод)

Просмотр общей ёмкости и аллокации ноды:

# Детальная информация о ресурсах ноды
kubectl describe node <node-name>

# Получить capacity и allocatable в структурированном виде (JSON)
kubectl get node <node-name> -o json | jq '.status.capacity, .status.allocatable'

# Сводка по всем нодам
kubectl top node

Пример вывода kubectl describe node:

Capacity:
  cpu:                8
  ephemeral-storage:  102164684Ki
  hugepages-1Gi:      0
  hugepages-2Mi:      0
  memory:             32860152Ki
  pods:               110
Allocatable:
  cpu:                7800m
  ephemeral-storage:  94145978648
  hugepages-1Gi:      0
  hugepages-2Mi:      0
  memory:             30782104Ki
  pods:               110

Разница между Capacity и Allocatable — это ресурсы, зарезервированные системой и kubelet'ом (через --system-reserved и --kube-reserved).

2. Мониторинг через метрики (продвинутый метод)

Использование Metrics Server и Prometheus для динамического отслеживания:

# Установка Metrics Server (если не установлен)
kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml

# Проверка метрик
kubectl top node --use-protocol-buffers

Для Prometheus запросы могут выглядеть так:

# Использование CPU на нодах
100 - (avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)

# Использование памяти
node_memory_MemTotal_bytes - node_memory_MemAvailable_bytes

# Использование диска
node_filesystem_size_bytes - node_filesystem_free_bytes

3. Расчёт через API Kubernetes программно

Пример на Python с использованием client-library:

from kubernetes import client, config

config.load_kube_config()
v1 = client.CoreV1Api()

node = v1.read_node_status("node-name")
capacity = node.status.capacity
allocatable = node.status.allocatable

print(f"CPU Capacity: {capacity['cpu']}")
print(f"Memory Allocatable: {allocatable['memory']}")
print(f"Pods Capacity: {capacity['pods']}")

Факторы, влияющие на "эффективный" размер ноды

1. System Reserved: ресурсы, зарезервированные для ОС и системных демонов
2. Kube Reserved: ресурсы для kubelet и container runtime
3. Eviction Thresholds: пороги выселения подов при нехватке ресурсов
4. DaemonSets: системные поды (kube-proxy, CNI, monitoring), работающие на каждой ноде
5. Node Affinity/Pod Disruption: влияют на фактическую доступность ресурсов

Практические рекомендации по capacity planning

• Золотое правило: никогда не планируйте использование более 80% ресурсов ноды
• Разделение ресурсов: учитывайте разницу между requests и limits подов
• Вертикальное автомасштабирование (VPA): может помочь оптимизировать requests
• Резерв для обработки пиков: оставляйте 10-20% CPU и памяти для непредвиденных нагрузок
• Учитывайте storage I/O и network bandwidth: особенно для stateful-нагрузок

Автоматизация мониторинга размера

Настройка алертинга на основе метрик (пример для Prometheus Alertmanager):

- alert: NodeHighMemoryUsage
  expr: (node_memory_MemTotal_bytes - node_memory_MemAvailable_bytes) / node_memory_MemTotal_bytes > 0.85
  for: 10m
  labels:
    severity: warning
  annotations:
    description: 'Node {{ $labels.instance }} memory usage is above 85%'

Инструменты для комплексного анализа

• kube-capacity: CLI-утилита для визуализации использования ресурсов
• kube-resource-report: генерация HTML-отчётов по использованию ресурсов
• Goldilocks: инструмент для настройки оптимальных requests/limits
• Vertical Pod Autoscaler: автоматическая настройка ресурсов подов

Важный нюанс: "размер" ноды — это не статическая величина, а динамический показатель, который зависит от текущей нагрузки, конфигурации кластера и политик планировщика. Регулярный мониторинг и анализ трендов потребления важнее разовых замеров.

Для production-кластеров рекомендую внедрить сквозной мониторинг ресурсов с историей и прогнозированием, чтобы своевременно масштабировать кластер и оптимизировать распределение workload'ов.