Привет У меня вопрос Равны ли запросы для Cgroups CPU shares при

работе Kubernetes на нодах с разным количеством ядер (используя Docker)?
Я провел пару экспериментов
На 8 ядерной системе и на 4 ядерной выставлял 100m реквест CPU для контейнера в Kubernetes
в обоих случаях он прокидывался в итоге до уровня cgroups одинаково (как собственно я и ожидал)
cpu.shares=102
В документации Kubernetes в разделе “Meaning of CPU” написано
https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/#meaning-of-cpu

CPU is always requested as an absolute quantity, never as a relative quantity; 0.1 is the same amount of CPU on a single-core, dual-core, or 48-core machine.

Что меня немного смутило, но чуть ниже есть еще раздел
“How Pods with resource limits are run”
https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/#how-pods-with-resource-limits-are-run

И там пишут про трансформацию:
When using Docker:
- The spec.containers[].resources.requests.cpu is converted to its core value, which is potentially fractional, and multiplied by 1024. The greater of this number or 2 is used as the value of the --cpu-shares flag in the docker run command.

Из чего я сделал вывод что
0.1 is the same amount of CPU on a single-core, dual-core, or 48-core machine

0.1 в любой ситуации преобразуется в 100m (это я проверял тоже) и в шары везде протечет значение 102 . Получается имелось в виду что при задании реквествов тебе не надо что-то считать, но т.к. shares используется в расчете как коэффициенты:
Шара – это относительный числовой параметр; его значение имеет смысл только в сравнении со значениями других шар, входящих в ту же cgroup

то в итоге все равно мы на разных системах будем получать разную мощность при одинаковых реквестах.

Если кто-то детально изучал вопрос, помогите пожалуйста

Реевесты - это в первую очередь количество ресурсов для аллокатора. На хостах из него выводится только относительный приоритет сигрупп в потреблении cpu (исходя из соотношения между реквестами разных контейнеров). При этом эти веса начинают работать только если cpu всем не хватает. Если нужно жестко управлять ресурсами, доступными контейнерам, используй limits.

Вот это правильно заданный вопрос - моё почтение! :) А вот что меня смущает, что куб считает cpu threads за полноценные ядра при планировании ресурсов. Где-то читал что для того же Golang это может быть проблема на нагруженной системе, так как он будет планировать тред на одни и те же физические ядра, что сведет на нет плюсы многопоточности для математики, которая не ходит в память.