kubernetes / понимание ограничений ресурсов ЦП

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

дело в том, что с помощью kubernetes игра звучит совсем по-другому. Я установил кластер "начало работы" с 2 стандартными vm (3.75 Go).

назначено ограничение на развертывание следующим образом :

        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.75 Go machine ? Тогда откуда эти 6%?

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

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

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

Спасибо за любые опытные советы/советы, чтобы иметь лучшее понимание Лучший

8
google-cloud-platform kubernetes

2 ответов

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

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

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

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

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

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

некоторые другие примечательные вещи:

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

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

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

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

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

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

7