kubernetes/понимание пределов ресурсов ЦП

Question

Исходя из многих лет работы узлов/рельсов приложений на голом металле; я использовал, чтобы иметь возможность запускать столько приложений, сколько захотелось на одной машине (скажем, 2Go в цифровом океане может легко обрабатывать 10 приложений без беспокойства, основываясь на правильной оптимизации или довольно небольшом количестве трафика)

Дело в том, что с использованием кубернетов игра звучит совсем по-другому. Я установил кластер «начальный» с 2 стандартными vm (3.75Go).

Назначенный лимит на размещение со следующим:

 resources: 
      requests: 
      cpu: "64m" 
      memory: "128Mi" 
      limits: 
      cpu: "128m" 
      memory: "256Mi" 

Тогда свидетелями следующее:

Namespace  Name   CPU Requests CPU Limits Memory Requests Memory Limits 
---------  ----   ------------ ---------- --------------- ------------- 
default   api    64m (6%)  128m (12%) 128Mi (3%)  256Mi (6%) 

Что это 6% относится к?

Пытался снизить предел процессора, к примеру, 20Mi ... приложение запускает (очевидно, недостаточно ресурсов). Документы говорят, что это процент CPU. Итак, 20% от машины 3.75Go? Тогда откуда взялись эти 6%?

Затем увеличенный размер пула узлов до n1-standard-2, тот же самый блок эффективно охватывает 3% узла. Это звучит логично, но на что это на самом деле ссылается?

По-прежнему интересно, какие показатели должны учитываться для этой части.

При запуске приложения требуется большой объем памяти, но тогда он использует только минимальную долю этого 6%. Я тогда чувствую, что-то недоразумение, или злоупотребляя его все

Спасибо за любые опытные советы/советы, чтобы лучше понять Best (запросы CPU)

Answer 1

6% ЦП означает 6% ЦП узлов время зарезервировано для этого контейнера. Поэтому он гарантировал, что он всегда получает в аренду это количество процессорного времени. Он все равно может разразиться до 12% (пределы ЦП), если осталось время процессора.

Это означает, что если предел очень низок, для запуска приложения потребуется больше времени. Поэтому liveness probe может убить стручок, прежде чем он будет готов, потому что приложение заняло слишком много времени. Чтобы решить эту проблему, вам, возможно, придется увеличить initialDelaySeconds или timeoutSeconds зонда живой активности.

---

Также обратите внимание, что запросы ресурсов и лимиты определяют, сколько ресурсов выделяется вам, а не фактическое использование.

• Запрос на ресурс - это то, что гарантированно получит ваш блок на узле. Это означает, что сумма запрошенных ресурсов не должна превышать общий объем CPU/памяти на этом узле.
• Предел ресурса - это верхний предел того, что разрешено использовать вашему контейнеру. Это означает, что сумма этих ресурсов может быть выше, чем фактический доступный процессор/память.

Поэтому проценты говорят вам, сколько ЦП и память об общих ресурсах, которые выделяет ваш блок.

Ссылка на документы: https://kubernetes.io/docs/user-guide/compute-resources/

Некоторые другие известные вещи:

• Если ваш стручок использует больше памяти, чем определено в пределе, он получает OOMKilled (из памяти).
• Если ваш блок использует больше памяти, чем определено в запросах, а узел запускает нашу память, модуль может получить OOMKilled, чтобы гарантировать, что другие контейнеры выживут, которые используют меньше, чем запрашиваемая память.
• Если вашему приложению требуется больше процессора, чем требуется, он может разразиться до предела.
• Вы никогда не будете убиты, потому что он использует слишком много CPU.

Answer 2

Согласно docs, запросы CPU (и пределы) всегда фракции доступных процессорных ядер на узле, который стручок запланирован на (с resources.requests.cpu из "1" смысл резервирования одного ядра процессора исключительно для одного стручка). Разрешены фракции, поэтому запрос ЦП "0.5" зарезервирует половину процессора для одного контейнера.

Для удобства Kubernetes позволяет задавать запросы/ограничения ресурсов процессора в millicores:

Выражение 0.1 эквивалентно выражению 100m, который может быть прочитан как «сто millicpu» (некоторые может сказать «сто милликор», и это понимается как одно и то же, говоря о Кубернете). Запрос с десятичной точкой, например 0.1, преобразуется в API 100m, а точность 1m недопустима.

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

Итак, запросив 64m процессорного времени при развертывании, вы запрашиваете на самом деле 64/1000 = 0,064 = 6,4% от одного из значений времени ядра процессора узла. Вот откуда вы пришли 6%. При обновлении до виртуальной машины с большим количеством процессорных ядер количество доступных ресурсов ЦП увеличивается, поэтому на машине с двумя доступными ядрами процессора запрос на 6,4% от один время процессора будет выделять 3,2% от CPU время два CPU.