Sirmax в 11:36, 9 января 2024

2024-01-09T11:36:05Z

← Предыдущая		Версия 11:36, 9 января 2024
Строка 2:		Строка 2:
	[[Категория:K8s_Вопросы_И_Ответы]]		[[Категория:K8s_Вопросы_И_Ответы]]
	[[Категория:Требуется форматирование текста]]		[[Категория:Требуется форматирование текста]]
		+
		+	=Ресурсы в Kubernetes - CPU=
		+
		+
		+	Итак, что имеется в виду под CPU когда мы говорим о Kubernetes?
		+	<BR>
		+	Один CPU это эквивалент “одного процессорного ядра”, предоставляемого операционной системой рабочего узла,
		+	вне зависимости от того, какое это ядро - физическое (physical core), поток физического ядра (hyper-thread),
		+	виртуальное ядро (например, EC2 vCPU, которое по сути, тоже является потоком физичекого ядра).
		+	<BR>
		+	В отличие от ограничений (limits) по памяти, лимиты по CPU с точки зрения Kubernetes являются “сжимаемыми”,
		+	следовательно может работать так называемый CPU Throttling - снижение частоты процессора,
		+	и, как следствие, производительности. Когда вы устанавливаете значение limits для CPU:
		+	<PRE>
		+	...
		+	resources:
		+	limits:
		+	cpu: "1"
		+	memory: 2Gi
		+	...
		+	</PRE>
		+	вы на самом деле указываете время использования процессора (CPU time) на всех доступных процессорных ядрах рабочего узла (ноды),
		+	а не “привязываете” свой контейнер к конкретному ядру (или группе ядер).
		+	<BR>
		+	Это значит, что даже если вы указываете в .limits.cpu число меньшее общего количества ядер ноды, то контейнер все равно будет “видеть”
		+	и использовать все ядра, ограничиваясь только временем их использования.
		+	<BR>
		+	К примеру, если контейнеру, который запускается на рабочем узле с общим количеством ядер 8,
		+	в значении CPU limits установить 4, то контейнер будет использовать эквивалент 4-х ядер, распределенных по всем 8 CPU ноды.
		+
		+	<BR>
		+	В данном примере максимально допустимое использование процессора (CPU usage) на рабочем узле будет равняться 50%.
		+	<BR>
		+	Как это выглядит с точки зрения Docker?
		+	<BR>
		+	Kubernetes управляет ограничениями CPU передавая параметры cpu-period и cpu-quota.
		+	Параметр cpu-period определяет период времени, в течении которого отслеживается использование
		+	процессора (CPU utilisation) контейнером и он всегда равен 100000µs (100ms).
		+	<BR>
		+	Параметр cpu-quota - это общее количество процессорного времени, которое контейнер может использовать в каждом cpu-period‘е.
		+	Эти два параметра влияют на работу CFS (абсолютно честного планировщика ядра, Completely Fair Scheduler).
		+	<BR>
		+	Конкретный пример соответствия значений CPU limits значениям cpu-quota в конфигурации Docker:
		+
		+	* limits 1: cpu-quota=100000
		+	* limits 4: cpu-quota=400000
		+	* limits 0.5: cpu-quota=50000
		+
		+	Здесь
		+	* limits 1 означает, что каждые 100ms контейнером могут использоваться 100% эквивалента 1 процессорного ядра рабочего узла,
		+	* limits 4 указывает, что контейнер может использовать 400% эквивалента 1 ядра (ну или 100% процессорных 4-х ядер) и т.д. Не забываем, что это использование “размазывается” на все доступные ядра рабочей ноды, без привязки к конкретным ядрам. Благодаря работе “абсюлютно честного планировщика” (CFS), любому контейнеру, превышающему свою квоту в данный период (имеется в виду cpu-period рассмотренный выше), будет запрещено использовать процессор до наступления следующего периода.
		+	<BR>
		+	<BR>
		+	Напомню, что вы можете указать сколько процессорных ядер (CPU) необходимо для работы вашему
		+	контейнеру с помощью параметра requests - это значение (важно!) <BR>
		+	учитывается планировщиком Kubernetes при размещении контейнера на рабочих узлах кластера <BR>
		+	(общее значение параметров CPU requests всех контейнеров на конкретном рабочем узле не может быть
		+	больше, чем общее количество процессорных ядер данной ноды).
		+	<BR>
		+	<BR>
		+	Таким образом, при использовании requests, вам гарантирован эквивалент количества указанных CPU, но что произойдет,
		+	если рабочий узел кластера будет находиться под чрезмерной нагрузкой
		+	(использование процессора на 100% или внезапные скачки LA)?
		+	<BR>
		+	<BR>
		+	В этом случае приоритет использования процессорного времени будет вычисляться исходя из значения,
		+	указанного в CPU requests и умноженного на 1024 - результат будет передан Docker’у как параметр cpu-shares.
		+	Это так называемый “вес” - если все контейнеры данного рабочего узла имеют одинаковый вес, то они будут иметь одинаковый приоритет
		+	при планировании и использовании процессорного времени при чрезмерной нагрузке;
		+	если у контейнеров рабочего узла вес разный, то контейнер с большим весом будет иметь высший приоритет и получит больше процессорного времени при чрезмерной нагрузке процессора на рабочей ноде.
		+	<BR>
		+	<BR>
		+	В предыдущей статье мы уже упоминали о QoS (классах качества сервиса) - они справедливы и в контексте CPU.
		+	<BR>
		+	Используя класс Burstable вы можете получить дополнительные периоды времени использования CPU (при условии, что эти же ресурсы не требуются другим контейнерам).
		+	Потенциально, это позволяет более эффективно использовать ресурсы кластера, правда, за счет большей
		+	непредсказуемости - повышенное использование CPU одним контейнером на рабочем узле повлияет на “соседей”,
		+	работающих на той же ноде кластера.
		+	<BR>
		+	<BR>
		+	Опять же, если вы новичок в Kubernetes, лучше всего обеспечить класс сервиса Guaranteed QoS,
		+	устанавливая значения requests и limits одинаковыми. Когда вы соберете больше данных (метрик)
		+	и лучше разберетесь с использованием процессорных ресурсов контейнерами, есть смысл начать использовать класс
		+	сервиса Burstable QoS для обдуманной оптимизации расходов на инфраструктуру.
		+	<BR>
		+	<BR>
		+	Сколько CPU стоит выделить контейнеру при написании манифеста?
		+	<BR>
		+	К сожалению, не существует универсального ответа на этот вопрос - все зависит от характеристик вашего приложения,
		+	требуемой производительности, места размещения контейнера, стоимости и т. д.
		+	<BR>
		+	Но если вы достаточно хорошо знаете, как работает ваше приложение “под капотом” и при наличии приличных инструментов
		+	для сбора и анализа метрик (например, Prometheus) можно подобрать оптимальную конфигурацию.
		+	<BR>
		+	В крайнем случае, можно даже получить кое-какие цифры для анализа выполнив внутри контейнера команду:
		+	<BR>
		+	<PRE>
		+	cat /sys/fs/cgroup/cpu,cpuacct/cpu.stat
		+
		+	nr_periods 345489
		+	nr_throttled 502
		+	throttled_time 109456473902
		+	</PRE>
		+	Так можно получить общее количество периодов запуска, количество раз, когда производительность процессора для данного контейнера была принудительно снижена (CPU Throttled) и общее время троттлинга в наносекундах.

Sirmax: Новая страница: «Категория:K8s Категория:K8s_Вопросы_И_Ответы Категория:Требуется форматирование текс...»

2024-01-09T08:34:34Z

Новая страница: «Категория:K8s Категория:K8s_Вопросы_И_Ответы Категория:Требуется форматирование текс...»

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

[[Категория:K8s]]
[[Категория:K8s_Вопросы_И_Ответы]]
[[Категория:Требуется форматирование текста]]

K8s Q A CPU - История изменений

Sirmax в 11:36, 9 января 2024

Sirmax: Новая страница: «Категория:K8s Категория:K8s_Вопросы_И_Ответы Категория:Требуется форматирование текс...»