Інструментування

• 1: Метрики SLI компонентів Kubernetes
• 2: Дані метрик вузла
• 3: Метрики Pod та Контейнерів CRI
• 4: Підтримка нативних гістограм для метрик Kubernetes
• 5: Розуміння метрик Pressure Stall Information (PSI)
• 6: Kubernetes z-pages
• 7: Довідник Метрик Kubernetes

1 - Метрики SLI компонентів Kubernetes

Типово Kubernetes 1.36 публікує метрики Індикаторів Рівня Обслуговування (SLI) для кожного компонентного бінарного файлу Kubernetes. Ця точка доступу метрики відкривається на порту HTTPS кожного компонента за шляхом /metrics/slis. Функціональна можливість ComponentSLIs типово увімкнена для кожного компонента Kubernetes починаючи з версії v1.27.

Метрики SLI

З увімкненими метриками SLI кожен компонент Kubernetes відкриває дві метрики, позначені для кожної перевірки стану:

• вимірювач (gauge, який представляє поточний стан перевірки стану)
• лічильник (counter, який записує накопичувальні підрахунки, спостережені для кожного стану перевірки стану)

Ви можете використовувати інформацію метрики для розрахунку статистики доступності кожного компонента. Наприклад, сервер API перевіряє стан etcd. Ви можете визначити та повідомити, наскільки доступним чи недоступним був etcd — як повідомляє його клієнт, сервер API.

Дані вимірювача Prometheus виглядають так:

# HELP kubernetes_healthcheck [ALPHA] Ця метрика записує результат однієї перевірки стану.
# TYPE kubernetes_healthcheck gauge
kubernetes_healthcheck{name="autoregister-completion",type="healthz"} 1
kubernetes_healthcheck{name="autoregister-completion",type="readyz"} 1
kubernetes_healthcheck{name="etcd",type="healthz"} 1
kubernetes_healthcheck{name="etcd",type="readyz"} 1
kubernetes_healthcheck{name="etcd-readiness",type="readyz"} 1
kubernetes_healthcheck{name="informer-sync",type="readyz"} 1
kubernetes_healthcheck{name="log",type="healthz"} 1
kubernetes_healthcheck{name="log",type="readyz"} 1
kubernetes_healthcheck{name="ping",type="healthz"} 1
kubernetes_healthcheck{name="ping",type="readyz"} 1

Дані лічильника виглядають так:

# HELP kubernetes_healthchecks_total [ALPHA] Ця метрика записує результати всіх перевірок стану.
# TYPE kubernetes_healthchecks_total counter
kubernetes_healthchecks_total{name="autoregister-completion",status="error",type="readyz"} 1
kubernetes_healthchecks_total{name="autoregister-completion",status="success",type="healthz"} 15
kubernetes_healthchecks_total{name="autoregister-completion",status="success",type="readyz"} 14
kubernetes_healthchecks_total{name="etcd",status="success",type="healthz"} 15
kubernetes_healthchecks_total{name="etcd",status="success",type="readyz"} 15
kubernetes_healthchecks_total{name="etcd-readiness",status="success",type="readyz"} 15
kubernetes_healthchecks_total{name="informer-sync",status="error",type="readyz"} 1
kubernetes_healthchecks_total{name="informer-sync",status="success",type="readyz"} 14
kubernetes_healthchecks_total{name="log",status="success",type="healthz"} 15
kubernetes_healthchecks_total{name="log",status="success",type="readyz"} 15
kubernetes_healthchecks_total{name="ping",status="success",type="healthz"} 15
kubernetes_healthchecks_total{name="ping",status="success",type="readyz"} 15

Використання цих даних

Точка доступу метрик компонентів SLI призначена для збору даних з високою частотою. Збір даних з високою частотою означає, що ви отримуєте більш точний сигнал вимірювача, який можна потім використовувати для розрахунку SLO. Точка доступу /metrics/slis надає необроблені дані, необхідні для розрахунку SLO доступності для відповідного компонента Kubernetes.

2 - Дані метрик вузла

kubelet збирає статистичні дані метрик на рівні вузла, томів, pod та контейнерів, і надає цю інформацію через Summary API.

Ви можете надіслати запит з проксі до Summary API через сервер API Kubernetes.

Ось приклад запиту до Summary API для вузла з іменем minikube:

kubectl get --raw "/api/v1/nodes/minikube/proxy/stats/summary"

Ось той самий виклик API за допомогою curl:

# Спочатку потрібно запустити "kubectl proxy"
# Змініть 8080 на порт, який призначає "kubectl proxy"
curl http://localhost:8080/api/v1/nodes/minikube/proxy/stats/summary

Джерело метрик Summary API

Стандартно, Kubernetes отримує дані метрик вузлів, використовуючи вбудований cAdvisor, який працює в kubelet. Якщо ви увімкнете функціональну можливість PodAndContainerStatsFromCRI у вашому кластері та використовуєте середовище виконання контейнерів, яке підтримує доступ до статистики через Інтерфейс Виконання Контейнерів (CRI), тоді kubelet отримує дані метрик на рівні Pod та контейнерів за допомогою CRI, а не через cAdvisor.

Pressure Stall Information (PSI)

У Kubernetes ви можете налаштувати kubelet для збору інформації про використання ядром Linux Pressure Stall Information (PSI) щодо використання CPU, памʼяті та вводу-виводу. Інформація збирається на рівні вузлів, podʼів та контейнерів. Докладну схему див. у Summary API. Починаючи з Kubernetes v1.36, функціональна можливість KubeletPSI заблокована в значенні true і не може бути вимкнена. Інформація також доступна у Prometheus метриках.

Для того, щоб зрозуміти метрики PSI, ви можете ознайомитися зі статею Розуміння метрик PSI.

Вимоги

Pressure Stall Information вимагає:

• Ядро Linux версії 4.20 чи новіше.
• cgroup v2

Що далі

На сторінках завдань для Виправлення неполадок у кластерах обговорюється, як використовувати конвеєр метрик, який залежить від цих даних.

3 - Метрики Pod та Контейнерів CRI

kubelet збирає метрики Pod та контейнерів через cAdvisor. Як альфа-функція, Kubernetes дозволяє налаштувати збір метрик Pod та контейнерів через Інтерфейс Виконання Контейнерів (CRI). Ви повинні увімкнути функціональну можливість PodAndContainerStatsFromCRI та використовувати сумісну реалізацію CRI (containerd >= 1.6.0, CRI-O >= 1.23.0), щоб використовувати механізм збору через CRI.

Метрики Pod та Контейнерів CRI

З увімкненим PodAndContainerStatsFromCRI, kubelet опитує підлегле середовище виконання контейнерів для отримання статистики Pod та контейнерів замість того, щоб безпосередньо перевіряти хост-систему за допомогою cAdvisor. Переваги використання середовища виконання контейнерів для цієї інформації, на відміну від прямого збору за допомогою cAdvisor, включають:

• Потенційне покращення продуктивності, якщо середовище виконання контейнерів вже збирає цю інформацію під час нормальної роботи. У цьому випадку дані можуть бути повторно використані замість того, щоб бути знову агрегованими kubelet.

• Це ще більше розʼєднує kubelet і середовище виконання контейнерів, дозволяючи збирати метрики для середовищ виконання контейнерів, які не запускають процеси безпосередньо на хості з kubelet, де вони спостережувані за допомогою cAdvisor (наприклад: середовища виконання контейнерів, що використовують віртуалізацію).

4 - Підтримка нативних гістограм для метрик Kubernetes

Компоненти Kubernetes можуть експонувати метрики гістограм у форматі Prometheus Native Histogram, поряд із класичним форматом гістограм. Нативні гістограми використовують експоненційні межі кошиків замість фіксованих меж, що забезпечує значну ефективність зберігання, покращену продуктивність запитів та більш детальне відображення розподілів.

Перш ніж почати

Щоб використовувати нативні гістограми, вам потрібно мати:

• Kubernetes v1.36 або новішу версію з увімкненою функціональною можливістю NativeHistograms.
• Prometheus 2.40 або новішу версію для збору та зберігання нативних гістограм. Рекомендується Prometheus 3.0+ для конфігурації на рівні завдань.

Що таке нативні гістограми?

Класичні гістограми Prometheus використовують фіксовані межі кошиків (наприклад, [0.005, 0.01, 0.025, 0.05, 0.1, 0.25, 0.5, 1, 2.5, 5, 10] секунд). Кожен кошик створює окрему часову серію (_bucket, _count, _sum), що може призвести до:

• Високих витрат на зберігання у великих масштабах, оскільки кожна гістограма генерує багато часових серій.
• Проблем з точністю, оскільки дані в межах широкого кошика є невідрізненими. Наприклад, запит, що виконується за 1 мкс, і запит, що виконується за 4 мс, обидва потрапляють у той самий кошик le="0.005".

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

• ~10x зменшення кількості часових серій для кожної метрики гістограми, що значно зменшує обсяг зберігання Prometheus і покращує продуктивність запитів.
• Більш детальна роздільна здатність для виявлення регресій продуктивності та встановлення точних порогів SLO.

Як це працює

Коли функціональна можливість NativeHistograms увімкнена, компоненти Kubernetes одночасно експонують метрики гістограм у класичному та нативному форматах (подвійна експозиція). Формат, що повертається, залежить від заголовка Accept у HTTP-запиті (узгодження вмісту Prometheus). Prometheus автоматично встановлює цей заголовок на основі вашої конфігурації збору; вам потрібно враховувати це лише при безпосередньому запиті до точки доступу /metrics.

• Текстовий формат (Accept: text/plain, OpenMetrics 1.0): Повертає лише класичні кошики гістограм. Зворотно сумісний з усіма наявними інструментами.

  # Classic histogram buckets (always present)
  apiserver_request_duration_seconds_bucket{le="0.005"} 1000
  apiserver_request_duration_seconds_bucket{le="0.01"} 2000
  ...
  apiserver_request_duration_seconds_bucket{le="+Inf"} 10000
  apiserver_request_duration_seconds_count 10000
  apiserver_request_duration_seconds_sum 450.5
  

• Формат Protobuf (Accept: application/vnd.google.protobuf): Містить як класичні кошики, так і дані нативних гістограм. Prometheus автоматично запитує цей формат, коли scrape_native_histograms: true встановлено в конфігурації збору Prometheus для відповідного завдання збору.

Ця стратегія подвійної експозиції забезпечує:

• Наявні інфопанелі та сповіщення продовжують працювати без змін.
• Користувачі можуть поступово переносити запити на нативні гістограми.
• Prometheus зберігає той формат, який він налаштований збирати.

Увімкнення нативних гістограм

Увімкнення нативних гістограм є двоетапним процесом: увімкніть функціональну можливість на компонентах Kubernetes і налаштуйте Prometheus для збору нативних гістограм.

Крок 1: Увімкніть функціональну можливість Kubernetes

Увімкніть функціональну можливість NativeHistograms на компонентах Kubernetes, з яких ви хочете експонувати нативні гістограми:

--feature-gates=NativeHistograms=true

Ця функціональна можливість застосовується до наступних компонентів:

• kube-apiserver
• kube-controller-manager
• kube-scheduler
• kubelet
• kube-proxy

Метрики кожного компонента є незалежними; ви можете увімкнути або вимкнути функціональну можливість для кожного компонента окремо.

Крок 2: Налаштуйте Prometheus

Конфігурація Prometheus залежить від вашої версії Prometheus.

Для Prometheus 3.x використовуйте конфігурацію на рівні завдання для точного контролю:

scrape_configs:
  - job_name: 'kubernetes-apiservers'
    scrape_native_histograms: true            # Використовує нативні гістограми
    always_scrape_classic_histograms: true    # Зберігає класичний формат під час міграції

Встановіть обидві опції в true під час періоду міграції. Це дозволяє збирати нативні гістограми, зберігаючи класичні гістограми для наявних інформаційних панелей.

Міграція інформаційних панелей та сповіщень

Під час міграції з класичних запитів гістограм на нативні гістограми, дотримуйтесь цього робочого процесу:

1. Увімкніть обидва формати: Встановіть scrape_native_histograms: true та always_scrape_classic_histograms: true у конфігурації збору Prometheus.

2. Міграція запитів: Оновіть запити інформаційних панелей та вирази сповіщень з класичних функцій гістограм на еквіваленти нативних гістограм.

   Класичний запит:

   histogram_quantile(0.99, rate(apiserver_request_duration_seconds_bucket[5m]))
   

   Запит для нативних гістограм:

   histogram_quantile(0.99, rate(apiserver_request_duration_seconds[5m]))
   

3. Перевірка на staging: Перевірте всі інформаційні панелі та сповіщення з запитами нативних гістограм перед впровадженням в експлуатацію.

4. Вимкнення класичного збору: Після завершення та перевірки міграції встановіть always_scrape_classic_histograms: false, щоб зменшити обсяг зберігання.

Вимкнення нативних гістограм

Ви можете вимкнути нативні гістограми в будь-який час, використовуючи один із двох підходів:

• На стороні Prometheus (найшвидший, не потребує перезапуску Kubernetes; тільки Prometheus 3.x): Встановіть scrape_native_histograms: false для кожного завдання збору. Prometheus відновлює збір класичного формату на наступному інтервалі збору.

• Функціональна можливість Kubernetes: Перезапустіть компонент з --feature-gates=NativeHistograms=false. Після перезапуску буде доступний тільки класичний формат гістограм.

Коли нативні гістограми вимкнено, точка доступу метрик повертається до класичного формату гістограм. Історичні дані нативних гістограм у Prometheus залишаються доступними для запитів.

Усунення несправностей

• Інформаційні панелі не відображають дані після увімкнення нативних гістограм: Це відбувається, коли Prometheus налаштовано з scrape_native_histograms: true, але always_scrape_classic_histograms: false (зазвичай), і ваші інформаційні панелі все ще використовують класичні запити гістограм (наприклад, histogram_quantile(..._bucket...)).

  Виправлення: Встановіть always_scrape_classic_histograms: true, щоб відновити збір класичного формату під час міграції інформаційних панелей.

• Збільшення використання памʼяті після увімкнення нативних гістограм: Невелике збільшення памʼяті очікується для зберігання кошиків нативних гістограм, обмежене максимумом 160 кошиків на гістограму. Відстежуйте process_resident_memory_bytes для виявлення несподіваних збільшень.

  Виправлення: Якщо тиск на памʼять значний, вимкніть збір нативних гістограм у Prometheus (scrape_native_histograms: false) або вимкніть функціональну можливість Kubernetes.

• Логи Prometheus повідомляють про невідомий формат метрик: Ваша версія Prometheus занадто стара, щоб розуміти нативні гістограми.

  Виправлення: Оновіть Prometheus до версії 2.40+ або вимкніть нативні гістограми в Kubernetes.

• Не впевнені, чи нативні гістограми експонуються: Перевірте стан функціональної можливості, виконавши запит kubernetes_feature_enabled{name="NativeHistograms"} у Prometheus. Значення 1 вказує на те, що функціональна можливість увімкнена. Ви також можете безпосередньо запитати кінцеву точку метрик у форматі protobuf:

  curl -H "Accept: application/vnd.google.protobuf;proto=io.prometheus.client.MetricFamily;encoding=delimited" \
    https://<component-address>/metrics
  

  Відповідь повинна містити кодування нативних гістограм для метрик гістограм.

Посилання

• Прочитайте документацію Prometheus про нативні гістограми для отримання деталей про формат нативних гістограм та функції запитів.
• Див. довідник метрик Kubernetes для повного списку метрик, які експонуються компонентами Kubernetes.

5 - Розуміння метрик Pressure Stall Information (PSI)

Kubernetes дозволяє налаштувати kubelet для збору інформації про тиск на ресурси в Linux Pressure Stall Information (PSI) про використання CPU, памʼяті та вводу-виводу. Інформація збирається на рівні вузлів, podʼів та контейнерів. Починаючи з Kubernetes v1.36, функціональна можливість KubeletPSI заблокована в значенні true і не може бути вимкнена.

Метрики PSI надаються через два різні джерела:

• Summary API kubelet, який надає дані PSI на рівні вузлів, podʼів та контейнерів.
• Точка доступу /metrics/cadvisor на kubelet, яка надає метрики PSI у форматі Prometheus.

Вимоги

Pressure Stall Information вимагає наступного на ваших вузлах Linux:

• Ядро Linux має бути версії 4.20 чи новіше.
• Ядро має бути скомпільоване з параметром CONFIG_PSI=y. Що у більшість сучасних дистрибутивів є стандартно увімкненим. Ви можете перевірити конфігурацію вашого ядра, виконавши команду zgrep CONFIG_PSI /proc/config.gz.
• Деякі дистрибутиви Linux можуть скомпілювати PSI в ядро, але мати його стандартно вимкненим. Якщо це так, вам потрібно увімкнути його під час завантаження, додавши параметр psi=1 до командного рядка ядра.
• Вузол має використовувати cgroup v2.

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

Метрики Pressure Stall Information (PSI) надаються для трьох ресурсів: CPU, памʼяті та вводу-виводу. Вони поділяються на два основних типи тиску: some та full.

• some: Це значення вказує на те, що деякі завдання (одне або кілька) заблоковані на ресурсі. Наприклад, якщо деякі завдання чекають на ввід-вивід, ця метрика зросте. Це може бути раннім показником конкуренції за ресурси.
• full: Це значення вказує на те, що всі не-очікувальні завдання заблоковані на ресурсі одночасно. Це свідчить про більш серйозний дефіцит ресурсів, коли вся система не може рухатись далі.

Кожен тип тиску надає чотири метрики: avg10, avg60, avg300 та total. Значення avg представляють відсоток часу, протягом якого завдання були заблоковані за 10-секундними, 60-секундними та 5-хвилинними ковзаючими середніми. Значення total є кумулятивним лічильником в мікросекундах, що показує загальний час, протягом якого завдання були заблоковані.

Розглянемо, наприклад, наступний запит до Summary API: kubectl get --raw "/api/v1/nodes/$(kubectl get nodes -o jsonpath='{.items[0].metadata.name}')/proxy/stats/summary" | jq '.pods[].containers[] | select(.name=="<CONTAINER_NAME>") | {name, cpu: .cpu.psi, memory: .memory.psi, io: .io.psi}'. Це повертає інформацію у форматі JSON, як показано нижче.

{
  "name": "<CONTAINER_NAME>",
  "cpu": {
    "full": {
      "total": 0,
      "avg10": 0,
      "avg60": 0,
      "avg300": 0
    },
    "some": {
      "total": 35232438,
      "avg10": 0.74,
      "avg60": 0.52,
      "avg300": 0.21,
    },
  },
  "memory": {
    "full": {
      "total": 539105,
      "avg10": 0,
      "avg60": 0,
      "avg300": 0
    },
    "some": {
      "total": 658164,
      "avg10": 0.01,
      "avg60": 0.01,
      "avg300": 0.00,
    },
    }
  },
  "io": {
    "full": {
      "total": 33190987,
      "avg10": 0.31,
      "avg60": 0.22,
      "avg300": 0.05,
    },
    "some": {
      "total": 40809937,
      "avg10": 0.52,
      "avg60": 0.45,
      "avg300": 0.12,
    }
  }
}

Це простий сценарій сплеску. Значення avg10 для cpu.some рівне 0.74 вказує на те, що за останні 10 секунд принаймні одне завдання в цьому контейнері було заблоковане на CPU протягом 0.74% часу (0.0074 секунди або 74 мілісекунди). Оскільки avg10 (0.74) значно перевищує avg300 (0.21) для того ж ресурсу, це свідчить про недавній сплеск конкуренції за ресурси, а не про тривалу проблему. Якщо спостерігати за цими метриками постійно і значення avg300 також зросте, можна діагностувати більш серйозну, тривалу проблему.

Крім того, зверніть увагу, що в цьому прикладі cpu.some показує тиск, тоді як cpu.full залишається на рівні 0.00. Це означає, що хоча деякі процеси були затримані в очікуванні часу на CPU, контейнер в цілому все ще просувався вперед. Ненульове значення full вказувало б на те, що всі неактивні завдання були заблоковані одночасно, що є набагато більшою проблемою. Хоча не так зрозуміло для людини, значення total рівне 35232438 представляє кумулятивний час блокування в мікросекундах, що дозволяє виявляти сплески затримки, які інакше можуть не відображатися в середніх значеннях.

Як останнє зауваження, при спостереженні високого тиску на I/O разом з низьким тиском на памʼять, це може вказувати на те, що застосунок очікує на пропускну здатність диска, а не через нестачу доступної оперативної памʼяті. Вузол не перевантажений по памʼяті, і можна розслідувати іншу діагностику для споживання диска.

Приклад сценаріїв

Ви можете використовувати простий Pod з інструментом для стрес-тестування, щоб згенерувати тиск на ресурси та спостерігати за метриками PSI. У наступних прикладах використовується образ контейнера agnhost, який включає інструмент stress.

Генерація тиску на CPU

Створіть Pod, який генерує тиск на CPU за допомогою утиліти stress. Це навантаження створить сильне навантаження на один CPU-ядро.

Створіть файл з назвою cpu-pressure-pod.yaml:

apiVersion: v1
kind: Pod
metadata:
  name: cpu-pressure-pod
spec:
  restartPolicy: Never
  containers:
  - name: cpu-stress
    image: registry.k8s.io/e2e-test-images/agnhost:2.47
    args:
    - "stress"
    - "--cpus"
    - "1"
    resources:
      limits:
        cpu: "500m"
      requests:
        cpu: "500m"

Застосуйте його до вашого кластера: kubectl apply -f cpu-pressure-pod.yaml

Спостереження за тиском на CPU

Після запуску Podʼа ви можете спостерігати за тиском на CPU через Summary API або через точку моніторингу метрик Prometheus.

Використовуючи Summary API:

Спостерігайте за підсумковими статистиками для вашого вузла. У окремому терміналі виконайте:

# Замініть <node-name> на імʼя вузла у вашому кластері
kubectl get --raw "/api/v1/nodes/<node-name>/proxy/stats/summary" | jq '.pods[] | select(.podRef.name | contains("cpu-pressure-pod"))'

Ви побачите, що метрики PSI some для CPU зростають у виводі Summary API. Значення avg10 для тиску some повинно перевищити нуль, що вказує на те, що завдання витрачають час на блокування на CPU.

Використовуючи точку моніторингу метрик Prometheus:

Надіщліть запит до точки /metrics/cadvisor, щоб побачити метрику container_pressure_cpu_waiting_seconds_total.

# Замініть <node-name> на імʼя вузла, на якому працює Pod
kubectl get --raw "/api/v1/nodes/<node-name>/proxy/metrics/cadvisor" | \
    grep 'container_pressure_cpu_waiting_seconds_total{container="cpu-stress"}'

Вихідні дані повинні показувати зростаюче значення, що вказує на те, що контейнер витрачає час на блокування в очікуванні ресурсів CPU.

Очищення

Вилучіть Pod, коли закінчите:

kubectl delete pod cpu-pressure-pod

Генерація тиску на памʼять

Цей приклад створює Pod, який безперервно записує у файли в записуваному шарі контейнера, що призводить до зростання кешу сторінок ядра та примусового відновлення памʼяті, що генерує тиск.

Створіть файл з назвою memory-pressure-pod.yaml:

apiVersion: v1
kind: Pod
metadata:
  name: memory-pressure-pod
spec:
  restartPolicy: Never
  containers:
  - name: memory-stress
    image: registry.k8s.io/e2e-test-images/agnhost:2.47
    command: ["/bin/sh", "-c"]
    args:
    - "i=0; while true; do dd if=/dev/zero of=testfile.$i bs=1M count=50 &>/dev/null; i=$(((i+1)%5)); sleep 0.1; done"
    resources:
      limits:
        memory: "200M"
      requests:
        memory: "200M"

Застосуйте його до кластера: kubectl apply -f memory-pressure-pod.yaml

Спостереження за тиском на памʼять

Використовуючи Summary API:

У виводі підсумків ви спостерігатимете зростання метрик PSI full для памʼяті, що вказує на те, що система зазнає значного тиску на памʼять.

# Замініть <node-name> на імʼя вузла у вашому кластері
kubectl get --raw "/api/v1/nodes/<node-name>/proxy/stats/summary" | jq '.pods[] | select(.podRef.name | contains("memory-pressure-pod"))'

Використовуючи точку моніторингу метрик Prometheus:

Надіщліть запит до точки доступу /metrics/cadvisor, щоб побачити метрику container_pressure_memory_waiting_seconds_total.

# Замініть <node-name> на імʼя вузла, на якому працює Pod
kubectl get --raw "/api/v1/nodes/<node-name>/proxy/metrics/cadvisor" | \
    grep 'container_pressure_memory_waiting_seconds_total{container="memory-stress"}'

У виводі ви спостерігатимете зростання значення метрики, що вказує на те, що система зазнає значного тиску на памʼять.

Очищення

Вилучіть Pod, коли закінчите:

kubectl delete pod memory-pressure-pod

Генерація тиску на I/O

Цей Pod генерує тиск на I/O, безперервно записуючи файл на диск і використовуючи sync для скидання даних з памʼяті, що створює затримки I/O.

Створіть файл з назвою io-pressure-pod.yaml:

apiVersion: v1
kind: Pod
metadata:
  name: io-pressure-pod
spec:
  restartPolicy: Never
  containers:
  - name: io-stress
    image: registry.k8s.io/e2e-test-images/agnhost:2.47
    command: ["/bin/sh", "-c"]
    args:
      - "while true; do dd if=/dev/zero of=testfile bs=1M count=128 &>/dev/null; sync; rm testfile &>/dev/null; done"

Застосуйте це до вашого кластера: kubectl apply -f io-pressure-pod.yaml

Спостереження за тиском на I/O

Використовуючи Summary API:

Ви побачите, що деякі метрики PSI для I/O зростають, оскільки Pod безперервно записує на диск.

# Замініть <node-name> на імʼя вузла у вашому кластері
kubectl get --raw "/api/v1/nodes/<node-name>/proxy/stats/summary" | jq '.pods[] | select(.podRef.name | contains("io-pressure-pod"))'

Використовуючи точку моніторингу метрик Prometheus:

Надіщліть запит до точки доступу /metrics/cadvisor, щоб побачити метрику container_pressure_io_waiting_seconds_total.

# Замініть <node-name> на імʼя вузла, на якому працює Pod
kubectl get --raw "/api/v1/nodes/<node-name>/proxy/metrics/cadvisor" | \
    grep 'container_pressure_io_waiting_seconds_total{container="io-stress"}'

Ви побачите, що значення метрики зростає, оскільки Pod безперервно записує на диск.

Очищення

Вилучіть Pod, коли закінчите:

kubectl delete pod io-pressure-pod

Що далі

Сторінки завдань для Усунення несправностей кластерів містять опис того, як використовувати конвеєр метрик, який спирається на ці дані.

6 - Kubernetes z-pages

Компоненти ядра Kubernetes можуть надавати набір z-endpoints, щоб полегшити користувачам налагодження кластера та його компонентів. Ці точки доступу мають використовуватися виключно для перевірки людиною для отримання інформації про налагодження двійкового коду компонента у реальному часі. У Kubernetes 1.36 це бета функція, і формат відповіді може змінитися у майбутніх випусках.

z-pages

Kubernetes v1.36 дозволяє увімкнути z-pages, які допоможуть вам усунути проблеми з компонентами основної панелі управління. Ці спеціальні налагоджувальні точки доступу надають внутрішню інформацію про запущені компоненти. У Kubernetes 1.36 компоненти обслуговують такі точки доступу (якщо їх увімкнено):

• z-pages
  • statusz
    • statusz (структуровано)
  • flagz
    • flagz (структуровано)

statusz

Увімкнена за допомогою функціональної можливості ComponentStatusz, точка доступу /statusz показує високорівневу інформацію про компонент, таку як версія Kubernetes, версія емуляції, час запуску тощо.

Відповідь у вигляді простого тексту /statusz від сервера API виглядає приблизно так:

kube-apiserver statusz
Warning: This endpoint is not meant to be machine parseable, has no formatting compatibility guarantees and is for debugging purposes only.

Started: Wed Oct 16 21:03:43 UTC 2024
Up: 0 hr 00 min 16 sec
Go version: go1.23.2
Binary version: 1.32.0-alpha.0.1484+5eeac4f21a491b-dirty
Emulation version: 1.32.0-alpha.0.1484
Paths: /healthz /livez /metrics /readyz /statusz /version

statusz (структуровано)

Починаючи з Kubernetes v1.35, точка доступу /statusz підтримує структурований формат відповіді з версіями, якщо запит надсилається з відповідним заголовком Accept. Без заголовка Accept точка доступу типово повертає відповідь у форматі простого тексту.

Щоб отримати структуровану відповідь, використовуйте:

Accept: application/json;v=v1beta1;g=config.k8s.io;as=Statusz

Приклад структурованої відповіді:

{
  "kind": "Statusz",
  "apiVersion": "config.k8s.io/v1beta1",
  "metadata": {
    "name": "kube-apiserver"
  },
  "startTime": "2025-10-29T00:30:01Z",
  "uptimeSeconds": 856,
  "goVersion": "go1.23.2",
  "binaryVersion": "1.35.0",
  "emulationVersion": "1.35",
  "paths": [
    "/healthz",
    "/livez",
    "/metrics",
    "/readyz",
    "/statusz",
    "/version"
  ]
}

Схема config.k8s.io/v1beta1 для структурованої відповіді /statusz виглядає наступним чином:

// Statusz — це схема config.k8s.io/v1beta1 для точки доступу /statusz.
type Statusz struct {
	// Kind є "Statusz".
	Kind string `json:"kind"`
	// APIVersion — це версія обʼєкта, наприклад, "config.k8s.io/v1beta1".
	APIVersion string `json:"apiVersion"`
	// Стандартні метадані обʼєкта.
	// +опціонально
	Metadata metav1.ObjectMeta `json:"metadata,omitempty"`
	// StartTime — час, коли було розпочато процес компонента.
	StartTime metav1.Time `json:"startTime"`
	// UptimeSeconds — це тривалість у секундах, протягом якої компонент працював безперервно.
	UptimeSeconds int64 `json:"uptimeSeconds"`
	// GoVersion — це версія мови програмування Go, яка використовується для створення бінарного файлу.
	// Не гарантується, що формат буде однаковим для різних збірок Go.
	// +опціонально
	GoVersion string `json:"goVersion,omitempty"`
	// BinaryVersion — це версія бінарного файлу компонента.
	// Формат не обовʼязково відповідає семантичному версіонуванню і може бути довільним рядком.
	BinaryVersion string `json:"binaryVersion"`
	// EmulationVersion — це версія API Kubernetes, яку емулює цей компонент.
	// якщо присутня, форматується як "<major>.<minor>"
	// +опціонально
	EmulationVersion string `json:"emulationVersion,omitempty"`
	// MinimumCompatibilityVersion — це мінімальна версія API Kubernetes, з якою компонент призначений для роботи.
	// якщо присутня, форматується як "<major>.<minor>"
	// +опціонально
	MinimumCompatibilityVersion string `json:"minimumCompatibilityVersion,omitempty"`
	// Шляхи містять відносні URL-адреси інших важливих точок доступу, доступних тільки для читання, для налагодження та усунення несправностей.
	// +опціонально
	Paths []string `json:"paths,omitempty"`
}

flagz

Увімкнена за допомогою функціональної можливості ComponentFlagz, точка доступу /flagz показує вам аргументи командного рядка, які було використано для запуску компонента.

Відповідь у вигляді простого тексту /flagz від сервера API виглядає приблизно так:

kube-apiserver flags
Warning: This endpoint is not meant to be machine parseable, has no formatting compatibility guarantees and is for debugging purposes only.

advertise-address=192.168.8.2
contention-profiling=false
enable-priority-and-fairness=true
profiling=true
authorization-mode=[Node,RBAC]
authorization-webhook-cache-authorized-ttl=5m0s
authorization-webhook-cache-unauthorized-ttl=30s
authorization-webhook-version=v1beta1
default-watch-cache-size=100

flagz (структуровано)

Починаючи з Kubernetes v1.35, точка доступу /flagz підтримує структурований формат відповіді з версіями, якщо запит надсилається з відповідним заголовком Accept. Без заголовка Accept точка доступу типово повертає відповідь у форматі простого тексту.

Щоб отримати структуровану відповідь, використовуйте:

Accept: application/json;v=v1beta1;g=config.k8s.io;as=Flagz

Example structured response:

{
  "kind": "Flagz",
  "apiVersion": "config.k8s.io/v1beta1",
  "metadata": {
    "name": "kube-apiserver"
  },
  "flags": {
    "advertise-address": "192.168.8.4",
    "allow-privileged": "true",
    "anonymous-auth": "true",
    "authorization-mode": "[Node,RBAC]",
    "enable-priority-and-fairness": "true",
    "profiling": "true",
    "default-watch-cache-size": "100"
  }
}

Схема config.k8s.io/v1beta1 для структурованої відповіді /flagz виглядає наступним чином:

// Flagz — це схема config.k8s.io/v1beta1 для точки доступу /flagz.
type Flagz struct {
	// Kind ' "Flagz".
	Kind string `json:"kind"`
	// APIVersion — це версія обʼєкта, наприклад, "config.k8s.io/v1beta1".
	APIVersion string `json:"apiVersion"`
	// Стандартні метадані обʼєкта.
	// +опціонально
	Metadata metav1.ObjectMeta `json:"metadata,omitempty"`
	// Flags містить прапорці командного рядка та їхні значення.
	// Ключі — це імена прапорців, а значення — це значення прапорців,
	// можливо, з вилученими конфіденційними значеннями.
	// +опціонально
	Flags map[string]string `json:"flags,omitempty"`
}

7 - Довідник Метрик Kubernetes

Метрики (v1.36)

Ця сторінка містить деталі метрик, які експортують різні компоненти Kubernetes. Ви можете запитувати точки доступу метрик для цих компонентів за допомогою HTTP-запиту та отримувати поточні дані метрик у форматі Prometheus.

Список стабільних метрик Kubernetes

Стабільні метрики дотримуються суворих API контрактів, і жодні мітки не можуть бути додані або видалені зі стабільних метрик протягом їхнього життєвого циклу.

Список бета-метрик Kubernetes

Бета-метрики дотримуються менш суворих API контрактів порівняно зі стабільними метриками. Жодні мітки не можуть бути видалені з бета-метрик протягом їхнього життєвого циклу, проте мітки можуть бути додані, поки метрика перебуває на етапі бета-тестування. Це забезпечує впевненість у тому, що бета-метрики підтримуватимуть існуючі панелі моніторингу та оповіщення, водночас дозволяючи вносити зміни в майбутньому.

Список альфа-метрик Kubernetes

Альфа-метрики не мають жодних гарантій API. Ці метрики слід використовувати на свій страх і ризик, наступні версії Kubernetes можуть взагалі вилучити ці метрики або мутувати API таким чином, щоб зламати наявні інформаційні панелі та сповіщення.