IKuznetsov: Новая страница: « = Эффективные ресурсы подов = Запросы и лимиты ресурсов для '''CPU''' и памяти можно задавать на уровне контейнера, на уровне init-контейнера, а начиная с '''Kubernetes''' 1.34 — на уровне пода. Поскольку разные типы контейнеров работают в разное время, вычисление эффе...»

2026-09-21T10:47:39Z

Новая страница: « = Эффективные ресурсы подов = Запросы и лимиты ресурсов для '''CPU''' и памяти можно задавать на уровне контейнера, на уровне init-контейнера, а начиная с '''Kubernetes''' 1.34 — на уровне пода. Поскольку разные типы контейнеров работают в разное время, вычисление эффе...»

Новая страница

= Эффективные ресурсы подов =
Запросы и лимиты ресурсов для '''CPU''' и памяти можно задавать на уровне контейнера, на уровне init-контейнера, а начиная с '''Kubernetes''' 1.34 — на уровне пода. Поскольку разные типы контейнеров работают в разное время, вычисление эффективного лимита на уровне пода нелинейно: простое суммирование всех лимитов контейнеров даёт неверный результат во многих реальных подах.

'''Ключ-АСТРОМ''' вычисляет правильное эффективное значение во время приёма данных и корректирует метрику так, чтобы агрегированные представления по подам, рабочим нагрузкам, пространствам имён и кластерам всегда отражали то, что '''Kubernetes''' фактически применяет.

Применяется только к мониторингу Latest. Требуется мониторинг '''Kubernetes''' через '''АктивныйШлюз'''.

Если сервисная сетка, такая как '''Istio''', настроена на использование нативных sidecar-контейнеров, эти sidecar-контейнеры принимаются и суммируются корректно в '''АктивныйШлюз''' версии 1.339+. Поды, использующие более ранние версии '''Istio''' (до 1.24 или с 1.24 по 1.26 без явной настройки), использовали app-контейнеры для прокси, которые уже учитывались. Обновление '''Istio''' до версии 1.27+ (где нативные sidecar-контейнеры используются по умолчанию) без одновременного обновления до '''АктивныйШлюз''' версии 1.339+ приведёт к тому, что ресурсы sidecar-контейнеров будут отсутствовать в метрике.
{| class="wikitable"
!Сценарий
!'''АктивныйШлюз''' версии 1.339+
!'''АктивныйШлюз''' версии 1.343+
!'''АктивныйШлюз''' версии 1.345+
|-
|App-контейнеры
|✓
|✓
|✓
|-
|Нативные sidecar-контейнеры (restartPolicy: Always)
|✓
|✓
|✓
|-
|Init-контейнеры (добавлена компенсирующая дельта)
|—
|✓
|✓
|-
|Ресурсы уровня пода (spec.resources) — '''Kubernetes''' 1.34+ (добавлена компенсирующая дельта)
|—
|—
|✓
|-
|Накладные расходы пода (overhead в RuntimeClass) (добавлена компенсирующая дельта)
|—
|—
|✓
|}

== Как Kubernetes вычисляет эффективные лимиты подов ==
'''Kubernetes''' определяет три типа контейнеров с различными окнами жизненного цикла. Поскольку они работают не одновременно, их вклад в ресурсы нельзя просто суммировать.

Следующий пример показывает под с двумя init-контейнерами и одним app-контейнером. <code>kubectl describe pod</code> сообщает лимиты каждого контейнера по отдельности; он не вычисляет эффективный лимит на уровне пода.<pre>
Init Containers:
init-step-1:
Limits: cpu: 50m memory: 32Mi

init-step-2:
Limits: cpu: 100m memory: 60Mi

Containers:
app:
Limits: cpu: 4m memory: 32Mi
</pre>Эффективный лимит необходимо вывести вручную:

* '''CPU''': MAX(MAX(50m, 100m), 4m) = 100m
* Память: MAX(MAX(32Mi, 60Mi), 32Mi) = 60Mi

{| class="wikitable"
!Тип
!Когда работает
!Вклад в эффективный лимит пода
|-
|App-контейнер
|Весь жизненный цикл пода
|Добавляется к SUM фазы выполнения
|-
|Нативный sidecar-контейнер (restartPolicy: Always)
|Запускается во время init-фазы, работает весь жизненный цикл пода
|Добавляется к SUM фазы выполнения
|-
|Init-контейнер
|Последовательно до запуска app-контейнеров, затем завершается
|Вносит вклад в MAX init-фазы
|-
|<code>spec.resources</code> уровня пода
|Н/Д — бюджет, применяемый ко всему поду
|Может ограничить эффективный лимит; может увеличить эффективный запрос
|}
Нативные sidecar-контейнеры — это init-контейнеры с <code>restartPolicy: Always</code>, доступные с '''Kubernetes''' 1.29. В отличие от классических init-контейнеров, они не завершаются до запуска приложения — они сохраняются на весь жизненный цикл пода и работают одновременно с app-контейнерами.

Эффективный лимит пода для ресурса:<pre>
effective limit = MAX(
SUM(app containers + sidecar containers), // running phase
MAX(each init container + sidecars running before it) // init phase
)
</pre>Если задан лимит на уровне пода и он ниже суммы фазы выполнения, '''Kubernetes''' применяет ограничение на уровне пода.

Спецификация ресурсов на уровне пода (<code>spec.resources</code>, feature gate PodLevelResources) — это бета-функция, включённая по умолчанию с версии '''Kubernetes''' 1.34. Некоторые веб-консоли и <code>kubectl describe node</code> пока не учитывают ресурсы уровня пода при отображении; значения там могут не отражать то, что применяет '''Kubernetes'''.

== Как Ключ-АСТРОМ обеспечивает точность ==
'''Ключ-АСТРОМ''' хранит метрики ресурсов на уровне контейнера (<code>dt.kubernetes.container.limits_cpu</code>, <code>dt.kubernetes.container.requests_memory</code> и так далее), чтобы сохранить гранулярность по контейнерам. Для большинства подов агрегирование этих метрик по контейнерам даёт правильный итог по поду.

Когда простое агрегирование дало бы неверный эффективный лимит, во время приёма данных в ту же метрику добавляется компенсирующая дельта. Эта дельта делает агрегированный итог правильным, не изменяя отдельные точки данных контейнеров.

Используя тот же пример пода, запрос <code>dt.kubernetes.container.limits_cpu</code> по контейнеру показывает:
{| class="wikitable"
!k8s.container.name
!k8s.container.type
!cpu_millicore
!mem_mib
|-
|app
|app
|4
|32
|-
|(компенсирующая дельта)
|—
|96
|28
|-
|Итого (сумма)
|
|100
|60
|}
Строка компенсирующей дельты не имеет имени или типа контейнера. Суммирование по всем строкам даёт правильный эффективный лимит пода, который применяет '''Kubernetes'''.

Значение дельты:

* Положительное, когда пик init-фазы (init-контейнеры + уже работающие sidecar-контейнеры) превышает сумму фазы выполнения, или когда запрос уровня пода выше суммы контейнеров.
* Отрицательное, когда лимит '''CPU''' или памяти уровня пода ограничивает итог ниже суммы контейнеров. Это применяется только к лимитам; '''Kubernetes''' не позволяет запросам уровня пода быть ниже суммы контейнеров.

Точка данных компенсирующей дельты не имеет размерности <code>dt.smartscape.container</code>. Её <code>dt.smartscape_source.type</code> — <code>K8S_POD</code>, даже когда дельта происходит из init-контейнера. Это позволяет при необходимости отличать её в запросах.

Нативные sidecar-контейнеры не требуют компенсирующей дельты. Поскольку они работают весь жизненный цикл пода, их вклад линеен и суммируется напрямую со значениями app-контейнеров.

== Проверка расчёта ==
Чтобы проверить, сохраняются ли точки данных компенсирующей дельты, выполните запрос по размерностям, связанным с контейнером. <code>k8s.cluster.name</code> и подобные атрибуты — это свойства сущности, а не размерности метрики; используйте поля <code>dt.smartscape.*</code> для группировки и идентификации дельт. Строки, где <code>dt.smartscape.container</code> отсутствует, — это точки данных компенсирующей дельты.<pre>
timeseries sum(dt.kubernetes.container.limits_memory),
by: { dt.smartscape.k8s_pod, dt.smartscape.container, k8s.container.type }
</pre>Чтобы ограничить конкретной рабочей нагрузкой, начните с метрики и присоедините контекст сущности из Smartscape. Присвойте псевдонимы полям <code>k8s.*</code> внутри подзапроса lookup.<pre>
timeseries sum(dt.kubernetes.container.limits_memory),
by: { dt.smartscape.k8s_pod, dt.smartscape.container, k8s.container.type }
| lookup [
smartscapeNodes "*"
| filter type == "K8S_POD"
| fields id, cluster = k8s.cluster.name, ns = k8s.namespace.name, wl = k8s.workload.name
], sourceField: dt.smartscape.k8s_pod, lookupField: id
| fieldsAdd cluster = lookup.cluster, ns = lookup.ns, wl = lookup.wl
| filter cluster == "<cluster-name>" and ns == "<namespace>" and wl == "<workload>"
| fields dt.smartscape.k8s_pod, dt.smartscape.container, k8s.container.type, cluster, ns, wl
</pre>Если компенсирующая дельта отсутствует, проверьте версию '''АктивныйШлюз''' и значения свойств.

Эффективные ресурсы подов - История изменений