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

• 1: Метрики SLI компонентів Kubernetes
• 2: Дані метрик вузла
• 3: Метрики Pod та Контейнерів CRI
• 4: Kubernetes z-pages
• 5: Довідник Метрик Kubernetes

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

Типово Kubernetes 1.32 публікує метрики Індикаторів Рівня Обслуговування (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.

Що далі

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

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 z-pages

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

z-pages

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

• z-pages
  • statusz
  • 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

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

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

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

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

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

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

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

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

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

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