Модуль 3.4: Моніторинг застосунків

Складність: [QUICK] — Базові команди, концептуальне розуміння

Час на виконання: 25–30 хвилин

Передумови: Модуль 3.1 (Проби), розуміння запитів/лімітів ресурсів

Що ви зможете робити

Після завершення цього модуля ви зможете:

Діагностувати тиск на ресурси за допомогою kubectl top pods та kubectl top nodes
Пояснити зв’язок між запитами ресурсів, лімітами та фактичними метриками використання
Налаштувати metrics-server та перевірити, що він збирає дані з вузлів кластера
Оцінити чи потребує застосунок більше ресурсів на основі спостережуваного споживання CPU та пам’яті

Чому цей модуль важливий

Моніторинг показує, як ваші застосунки працюють прямо зараз. Тоді як логування показує, що сталося, моніторинг показує поточний стан — використання CPU, споживання пам’яті та чи ваш застосунок перевантажений.

Іспит CKAD перевіряє:

Використання kubectl top для метрик ресурсів
Розуміння реального використання ресурсів порівняно із запитами/лімітами
Базові концепції моніторингу (не повне налаштування Prometheus)

Аналогія з приладовою панеллю

Моніторинг — як приладова панель автомобіля. Вам не потрібно заглядати під капот, щоб дізнатися, що бензин на межі (пам’ять) або двигун перегрівається (високий CPU). Швидкий погляд каже, чи все гаразд, чи потрібно вжити заходів.

Metrics Server

Kubernetes типово не збирає метрики. Metrics Server — це легкий компонент, що надає метрики ресурсів.

Перевірка, чи працює Metrics Server

# Перевірити deployment metrics-server
k get deployment -n kube-system metrics-server

# Або перевірити, чи працює `top`
k top nodes

Що надає Metrics Server

Поточне використання CPU та пам’яті на вузол
Поточне використання CPU та пам’яті на під
Дані для рішень Horizontal Pod Autoscaler

Чого він не надає

Історичні дані
Метрики рівня застосунку
Власні метрики

Команди kubectl top

Метрики вузлів

# Усі вузли
k top nodes

# Вивід:
# NAME       CPU(cores)   CPU%   MEMORY(bytes)   MEMORY%
# node-1     250m         12%    1024Mi          25%
# node-2     500m         25%    2048Mi          50%

Метрики подів

# Усі поди в поточному просторі імен
k top pods

# Усі поди в усіх просторах імен
k top pods -A

# Поди в конкретному просторі імен
k top pods -n kube-system

# Сортувати за CPU
k top pods --sort-by=cpu

# Сортувати за пам'яттю
k top pods --sort-by=memory

# Конкретний під
k top pod my-pod

Метрики контейнерів

# Показати метрики на контейнер
k top pods --containers

# Вивід:
# POD          NAME      CPU(cores)   MEMORY(bytes)
# my-pod       app       100m         128Mi
# my-pod       sidecar   10m          32Mi

Розуміння виводу метрик

Одиниці CPU

Значення	Опис
`1`	1 повне ядро CPU
`1000m`	1000 мілі-ядер = 1 ядро
`500m`	0.5 ядра (половина ядра)
`100m`	0.1 ядра (10% ядра)

Одиниці пам’яті

Значення	Опис
`128Mi`	128 мебібайтів
`1Gi`	1 гібібайт (1024 Mi)
`256M`	256 мегабайтів

Читання виводу

NAME        CPU(cores)   CPU%     MEMORY(bytes)   MEMORY%
my-pod      100m         10%      256Mi           12%

100m CPU: Під використовує 100 мілі-ядер (10% одного ядра)
256Mi MEMORY: Під використовує 256 мебібайтів RAM
Відсотки: На основі ємності вузла (вузли) або запитів (поди)

Метрики проти запитів/лімітів

Порівняння

resources:
  requests:
    cpu: "100m"      # Гарантований мінімум
    memory: "128Mi"
  limits:
    cpu: "500m"      # Максимально дозволено
    memory: "256Mi"

# Фактичне використання з метрик
k top pod my-pod
# CPU: 50m, Memory: 100Mi

# Інтерпретація:
# - Використовує 50m CPU (в межах запиту 100m, значно нижче ліміту 500m)
# - Використовує 100Mi RAM (в межах запиту 128Mi, нижче ліміту 256Mi)

Перевірка стану за метриками

# Перевірити, чи поди наближаються до лімітів
k top pods

# Порівняти з визначеними лімітами
k get pod my-pod -o jsonpath='{.spec.containers[*].resources}'

Шаблони моніторингу

Швидка перевірка стану

# Стан вузлів
k top nodes

# Стан подів, відсортований за використанням ресурсів
k top pods --sort-by=cpu
k top pods --sort-by=memory

Пошук ресурсних «пожирачів»

# Найбільші споживачі CPU
k top pods -A --sort-by=cpu | head -10

# Найбільші споживачі пам'яті
k top pods -A --sort-by=memory | head -10

Аналіз на рівні контейнерів

# Побачити, який контейнер у поді споживає найбільше ресурсів
k top pods --containers -l app=myapp

Візуалізація ресурсів

┌─────────────────────────────────────────────────────────────┐
│                  Рівні використання ресурсів                 │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  Приклад використання пам'яті:                              │
│                                                             │
│  |                                                          │
│  |  ▓▓▓▓▓▓▓▓▓▓ Ліміт: 256Mi (макс. до OOMKill)             │
│  |                                                          │
│  |  ████████ Запит: 128Mi (гарантовано)                    │
│  |                                                          │
│  |  ████ Поточне: 64Mi (з k top)                           │
│  |                                                          │
│  └──────────────────────────────────────────────           │
│                                                             │
│  Стан: Здоровий (використання < запит)                      │
│                                                             │
│  ─────────────────────────────────────────────             │
│                                                             │
│  |                                                          │
│  |  ▓▓▓▓▓▓▓▓▓▓ Ліміт: 256Mi                                │
│  |                                                          │
│  |  ████████████████ Поточне: 200Mi (з k top)              │
│  |                                                          │
│  |  ████████ Запит: 128Mi                                  │
│  |                                                          │
│  └──────────────────────────────────────────────           │
│                                                             │
│  Стан: Попередження (використання > запит, наближення       │
│  до ліміту)                                                 │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Концепції, що стосуються іспиту

Що потрібно знати

kubectl top — Перегляд поточного використання ресурсів
Metrics Server — Необхідний для роботи kubectl top
Інтерпретація ресурсів — Розуміння мілі-ядер та одиниць пам’яті

Що НЕ потрібно знати (для CKAD)

Налаштування та конфігурація Prometheus
Дашборди Grafana
Власні метрики та API метрик
Запити PromQL

Чи знали ви?

Metrics Server збирає дані кожні 15 секунд типово. Дані не в реальному часі, але дуже свіжі.
kubectl top показує поточне використання, а не історичне. Для тенденцій потрібні зовнішні інструменти моніторингу.
HPA (Horizontal Pod Autoscaler) покладається на Metrics Server для прийняття рішень про масштабування на основі використання CPU/пам’яті.
Metrics Server зберігає дані лише в пам’яті. Коли він перезапускається, усі історичні дані втрачаються.

Типові помилки

Помилка	Чому це шкодить	Рішення
Запуск `k top` без metrics server	Команда не працює	Спочатку встановіть metrics server
Плутати запити з фактичним використанням	Хибне планування ємності	Використовуйте `k top` для реального використання
Ігнорування подів з високим споживанням пам’яті	Несподіваний OOMKill	Сортуйте за пам’яттю, стежте за тенденціями
Не перевіряєте на рівні контейнерів	Пропуск проблем sidecar	Використовуйте прапорець `--containers`
Очікування історичних даних	`k top` показує лише зараз	Використовуйте Prometheus для історії

Тест

Яка команда показує використання CPU та пам’яті на під?

Відповідь
`kubectl top pods`
Що означає 250m CPU?

Відповідь
250 мілі-ядер, що дорівнює 0.25 ядра CPU (25% одного ядра).
Як побачити використання ресурсів на контейнер у подах з кількома контейнерами?

Відповідь
`kubectl top pods --containers`
Що станеться, якщо metrics server не встановлено?

Відповідь
`kubectl top` завершиться з помилкою, оскільки немає джерела даних метрик.

Практична вправа

Завдання: Моніторити використання ресурсів запущених застосунків.

Підготовка:

# Створити deployment з відомим використанням ресурсів
cat << 'EOF' | k apply -f -
apiVersion: apps/v1
kind: Deployment
metadata:
  name: monitor-demo
spec:
  replicas: 3
  selector:
    matchLabels:
      app: monitor-demo
  template:
    metadata:
      labels:
        app: monitor-demo
    spec:
      containers:
      - name: nginx
        image: nginx
        resources:
          requests:
            cpu: 50m
            memory: 64Mi
          limits:
            cpu: 100m
            memory: 128Mi
EOF

Частина 1: Базовий моніторинг

# Перевірити, чи працює metrics server
k top nodes

# Переглянути метрики подів
k top pods -l app=monitor-demo

# Сортувати за CPU
k top pods --sort-by=cpu

Частина 2: Порівняння із запитами

# Отримати запити ресурсів
k get pods -l app=monitor-demo -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.containers[*].resources}{"\n"}{end}'

# Порівняти з фактичним використанням
k top pods -l app=monitor-demo

Очищення:

k delete deploy monitor-demo

Практичні вправи

Вправа 1: Метрики вузлів (Ціль: 1 хвилина)

# Перевірити використання ресурсів вузлів
k top nodes

# Визначити вузол з найвищим CPU
k top nodes --sort-by=cpu

Вправа 2: Метрики подів (Ціль: 2 хвилини)

# Створити тестові поди
k run drill2a --image=nginx
k run drill2b --image=nginx

# Перевірити їхні метрики
k top pods

# Очищення
k delete pod drill2a drill2b

Вправа 3: Метрики контейнерів (Ціль: 2 хвилини)

# Створити під з кількома контейнерами
cat << 'EOF' | k apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: drill3
spec:
  containers:
  - name: nginx
    image: nginx
  - name: sidecar
    image: busybox
    command: ['sleep', '3600']
EOF

# Переглянути метрики на контейнер
k top pods drill3 --containers

# Очищення
k delete pod drill3

Вправа 4: Сортований вивід (Ціль: 2 хвилини)

# Отримати поди, відсортовані за використанням пам'яті
k top pods -A --sort-by=memory

# Отримати поди, відсортовані за використанням CPU
k top pods -A --sort-by=cpu

Вправа 5: Системні поди (Ціль: 2 хвилини)

# Перевірити використання ресурсів подів kube-system
k top pods -n kube-system

# Сортувати за CPU, щоб знайти найактивніші
k top pods -n kube-system --sort-by=cpu

Вправа 6: Повний процес моніторингу (Ціль: 4 хвилини)

Сценарій: Дослідити високе використання ресурсів у deployment.

# Створити deployment з кількома репліками
k create deploy drill6 --image=nginx --replicas=5

# Зачекати на поди
k get pods -l app=drill6 -w

# Перевірити загальне використання ресурсів deployment
k top pods -l app=drill6

# Знайти найбільшого споживача
k top pods -l app=drill6 --sort-by=cpu

# Перевірити на рівні контейнерів
k top pods -l app=drill6 --containers

# Порівняти з ємністю вузла
k top nodes

# Очищення
k delete deploy drill6

Наступний модуль

Модуль 3.5: Застарівання API — Обробка змін версій API та застарівань.