Метрики для компонентів системи Kubernetes

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

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

Метрики в Kubernetes

У більшості випадків метрики доступні на точці доступу /metrics HTTP сервера. Для компонентів, які типово не показують цю точку, її можна активувати за допомогою прапорця --bind-address.

Приклади таких компонентів:

У промисловому середовищі ви, можливо, захочете налаштувати Prometheus Server або інший інструмент збору метрик для їх періодичного отримання і доступу у якомусь виді бази даних часових рядів.

Зверніть увагу, що kubelet також викладає метрики на /metrics/cadvisor, /metrics/resource та /metrics/probes. Ці метрики не мають того самого життєвого циклу.

Якщо ваш кластер використовує RBAC, для читання метрик потрібна авторизація через користувача, групу або ServiceAccount з ClusterRole, що дозволяє доступ до /metrics. Наприклад:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: prometheus
rules:
  - nonResourceURLs:
      - "/metrics"
    verbs:
      - get

Життєвий цикл метрик

Метрики альфа → Метрики бета → Стабільні метрики → Застарілі метрики → Приховані метрики → Видалені метрики

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

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

Стабільні метрики гарантують, що їх формат залишиться незмінним. Це означає що:

  • Стабільні метрики, які не мають позначки "DEPRECATED", не будуть змінені чи вилучені.
  • Тип стабільних метрик не буде змінений.

Метрики, які позначені як застарілі, заплановані для видалення, але все ще доступні для використання. Ці метрики мають анотацію щодо версії, у якій вони стали застарілими.

Наприклад:

  • Перед застарінням

    # HELP some_counter this counts things
# TYPE some_counter counter
some_counter 0

  • Після застаріння

    # HELP some_counter (Deprecated since 1.15.0) this counts things
# TYPE some_counter counter
some_counter 0

Приховані метрики більше не публікуються для збирання, але все ще доступні для використання. Застаріла метрика стає прихованою метрикою через певний проміжок часу, залежно від її рівня стабільності: * СТАБІЛЬНІ метрики стають прихованими після мінімум 3 випусків або 9 місяців, залежно від того, що триває довше. * БЕТА метрики стають прихованими після мінімум 1 випуску або 4 місяців, залежно від того, що триває довше. * АЛЬФА метрики можуть бути приховані або видалені в тому ж випуску, в якому вони стали застарілими.

Щоб використовувати приховану метрику, будь ласка, звертайтесь до розділу Показ прихованих метрик.

Видалені метрики більше не публікуються і не можуть бути використані.

Показ прихованих метрик

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

Прапорець show-hidden-metrics-for-version приймає версію, для якої ви хочете показати метрики, які стали застарілими у цьому релізі. Версія зазначається як x.y, де x — головна версія, y — мінорна версія. Версія виправлення не потрібна, хоча метрика може бути застарілою в випуску виправлення, причина в тому, що політика застарілих метрик працює з мінорними релізами.

Прапорець може приймати лише попередню мінорну версію як своє значення. Якщо ви хочете показати всі метрики, приховані в попередньому випуску, ви можете встановити прапорець show-hidden-metrics-for-version на попередню версію. Використання занадто старої версії не допускається, оскільки це порушує політику виведення метрик з обігу.

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

  • Якщо метрика A є ALPHA, вона може бути прихована в 1.29.
  • Якщо метрика A є BETA, вона буде прихована щонайменше у версії 1.30. Якщо ви оновлюєте систему до версії 1.30 і все ще потребуєте A, ви повинні використовувати прапорець командного рядка --show-hidden-metrics-for-version=1.29.
  • Якщо метрика A є STABLE, вона буде прихована в 1.32 не раніше. Якщо ви оновлюєте до 1.32 і все ще потребуєте A, ви повинні використовувати прапор командного рядка --show-hidden-metrics-for-version=1.31.

Метрики компонентів

Метрики kube-controller-manager

Метрики менеджера контролера надають важливі відомості про продуктивність та стан контролера. Ці метрики включають загальні метрики часу виконання мови програмування Go, такі як кількість go_routine, а також специфічні для контролера метрики, такі як час виконання запитів до etcd або час виконання API Cloudprovider (AWS, GCE, OpenStack), які можна використовувати для оцінки стану кластера.

Починаючи з Kubernetes 1.7, доступні докладні метрики Cloudprovider для операцій зберігання для GCE, AWS, Vsphere та OpenStack. Ці метрики можуть бути використані для моніторингу стану операцій з постійними томами.

Наприклад, для GCE ці метрики називаються:

cloudprovider_gce_api_request_duration_seconds { request = "instance_list"}
cloudprovider_gce_api_request_duration_seconds { request = "disk_insert"}
cloudprovider_gce_api_request_duration_seconds { request = "disk_delete"}
cloudprovider_gce_api_request_duration_seconds { request = "attach_disk"}
cloudprovider_gce_api_request_duration_seconds { request = "detach_disk"}
cloudprovider_gce_api_request_duration_seconds { request = "list_disk"}

Метрики kube-scheduler

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.21 [beta]

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

kube-scheduler ідентифікує ресурсні запити та обмеження для кожного Podʼа; коли запит або обмеження не дорівнює нулю, kube-scheduler повідомляє про метричні часові ряди. Часові ряди мають мітки:

  • простір імен
  • імʼя Podʼа
  • вузол, на якому запущений Pod, або пустий рядок, якщо він ще не запущений
  • пріоритет
  • призначений планувальник для цього Podʼа
  • назва ресурсу (наприклад, cpu)
  • одиниця ресурсу, якщо відома (наприклад, core)

Як тільки Pod досягає завершення (має restartPolicy Never або OnFailure і перебуває в стані Succeeded або Failed, або був видалений і всі контейнери мають стан завершення), часова послідовність більше не повідомляється, оскільки тепер планувальник вільний для розміщення інших Podʼів для запуску. Дві метрики називаються kube_pod_resource_request та kube_pod_resource_limit.

Метрики доступні за адресою HTTP /metrics/resources. Вони та вимагають авторизації для точки доступу /metrics/resources, яка зазвичай надається за допомогою ClusterRole з дієсловом get для URL /metrics/resources, що не є ресурсом.

В Kubernetes 1.21 вам потрібно використовувати прапорець --show-hidden-metrics-for-version=1.20, щоб показати ці альфа-метрики.

Метрики kubelet Pressure Stall Information (PSI)

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.36 [stable](стандартно увімкнено)

Якщо в ядрі увімкнено PSI (версія 4.20 або пізніша), kubelet збирає інформацію про затримки під тиском (PSI) щодо використання процесора, памʼяті та вводу-виводу. Інформація збирається на рівні вузла, pod та контейнера.

Метрики Prometheus: Експонуються через точку доступу /metrics/cadvisor у вигляді накопичувальних лічильників (сум), що відображають загальний час затримки у секундах. Метрики доступні в точці доступу з такими назвами:

container_pressure_cpu_stalled_seconds_total
container_pressure_cpu_waiting_seconds_total
container_pressure_memory_stalled_seconds_total
container_pressure_memory_waiting_seconds_total
container_pressure_io_stalled_seconds_total
container_pressure_io_waiting_seconds_total

Summary API: Експонується через точку доступу /stats/summary, надаючи як накопичувальні totals, так і ковзні середні (avg10, avg60, avg300) у форматі JSON. Ці середні значення представляють відсоток часу, протягом якого завдання були затримані на ресурсі протягом відповідних інтервалів у 10 секунд, 60 секунд та 5 хвилин.

Ці метрики також нативно експортуються через відповідний файл вузла в /proc/pressure/ — cpu, memory та io у наступному форматі:

some avg10=0.00 avg60=0.00 avg300=0.00 total=0
full avg10=0.00 avg60=0.00 avg300=0.00 total=0

Як можна інтерпретувати ці метрики разом? Візьмемо, наприклад, наступний запит з Summary API:

NODE=$(kubectl get nodes -o jsonpath='{.items[0].metadata.name}')

kubectl get --raw "/api/v1/nodes/${NODE}/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 представляє кумулятивний час затримки в мікросекундах, що дозволяє виявляти сплески затримок, які інакше можуть не відображатися в середніх значеннях. Вони також корисні для систем моніторингу, таких як Prometheus, для точного розрахунку швидкостей зростання за певні часові вікна. Як останнє зауваження, при спостереженні високого тиску на I/O разом з низьким тиском на памʼять, це може вказувати на те, що застосунок очікує на пропускну здатність диска, а не через нестачу доступної оперативної памʼяті. Вузол не перевантажений з точки зору використання памʼяті, тому можна розглянути інший варіант діагностики щодо використання дискового простору.

Метрики PSI відкривають більш надійний спосіб моніторингу реального часу конкуренції за ресурси на всіх рівнях для кожного cgroup, що відкриває можливість динамічно керувати робочими навантаженнями по всій системі. Ви можете дізнатися більше про метрики PSI в Understand PSI Metrics.

Вимоги

Pressure Stall Information вимагає:

Вимкнення метрик

Ви можете явно вимкнути метрики за допомогою прапорця командного рядка --disabled-metrics. Це може бути бажано, наприклад, якщо метрика викликає проблеми з продуктивністю. Вхідні дані — це список вимкнених метрик (тобто --disabled-metrics=метрика1,метрика2).

Забезпечення послідовності метрик

Метрики з нескінченними розмірами можуть викликати проблеми з памʼяттю в компонентах, які їх інструментують. Щоб обмежити використання ресурсів, ви можете використовувати опцію командного рядка --allow-metric-labels, щоб динамічно налаштувати список дозволених значень міток для метрики.

На стадії альфа, цей прапорець може приймати лише серію зіставлень як список дозволених міток метрики. Кожне зіставлення має формат <metric_name>,<label_name>=<allowed_labels>, де <allowed_labels> — це розділені комами допустимі назви міток.

Загальний формат виглядає так:

--allow-metric-labels <metric_name>,<label_name>='<allow_value1>, <allow_value2>...', <metric_name2>,<label_name>='<allow_value1>, <allow_value2>...', ...

Ось приклад:

--allow-metric-labels number_count_metric,odd_number='1,3,5', number_count_metric,even_number='2,4,6', date_gauge_metric,weekend='Saturday,Sunday'

Крім того, що це можна вказати з командного рядка, теж саме можна зробити за допомогою конфігураційного файлу. Ви можете вказати шлях до цього файлу конфігурації, використовуючи аргумент командного рядка --allow-metric-labels-manifest для компонента. Ось приклад вмісту цього конфігураційного файлу:

"metric1,label2": "v1,v2,v3"
"metric2,label1": "v1,v2,v3"

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

Що далі

Востаннє змінено May 15, 2026 at 6:30 PM PST: [uk] Ukrainian translation (all-in-one) (3f52b3b106)