представлять
Ошибки нехватки памяти (OOM) и дросселирование ЦП являются основными проблемами при обработке ресурсов в облачных приложениях при использовании Kubernetes.
почему это?
Требования к ЦП и памяти в облачных приложениях становятся все более важными, поскольку они напрямую связаны с вашими затратами на облачные вычисления.
С помощью ограничений и запросов вы можете настроить, как модули должны распределять память и ресурсы ЦП, чтобы предотвратить нехватку ресурсов и скорректировать затраты на облако.
Поды могут быть вытеснены из-за вытеснения или давления на узел, если у узла недостаточно ресурсов.
Когда процессу не хватает памяти (OOM), он завершается, потому что у него нет необходимых ресурсов.
Если потребление ЦП превышает фактический предел, процесс начнет регулироваться.
Но как заранее отслеживать, насколько pod Kubernetes близок к OOM и троттлингу ЦП?
Кубернетес ООМ
Каждому контейнеру в поде для работы требуется память.
Ограничения Kubernetes устанавливаются для каждого контейнера в определении Pod или Deployment.
Во всех современных системах Unix есть способ убивать процессы, если им нужно освободить память. Это будет помечено как ошибка 137 илиOOMKilled.
State: Running
Started: Thu, 10 Oct 2019 11:14:13 +0200
Last State: Terminated
Reason: OOMKilled
Exit Code: 137
Started: Thu, 10 Oct 2019 11:04:03 +0200
Finished: Thu, 10 Oct 2019 11:14:11 +0200
Этот код выхода 137 означает, что процесс использовал больше памяти, чем разрешено, и должен быть завершен.
Это функция, присутствующая в Linux, когда ядро oom_scoreустанавливает значение для процессов, запущенных в системе. Кроме того, он позволяет установить oom_score_adj значение с именем , которое Kubernetes использует для обеспечения качества обслуживания. У него также есть OOM Killerфункция, которая будет подвергать цензуре процессы и убивать те, которые используют больше памяти, чем должно быть ограничено.
Обратите внимание, что в Kubernetes процесс может достичь любого из следующих ограничений:
-
Предел Kubernetes, установленный для контейнера.
-
Kubernetes ResourceQuota, установленный в пространстве имен.
-
Фактический объем памяти узла.
перерасход памяти
Лимиты могут быть выше, чем запросы, поэтому сумма всех лимитов может быть выше, чем мощность узла. Это называется чрезмерным использованием, и это очень распространено. На самом деле может закончиться нехватка памяти в узле, если все контейнеры используют больше памяти, чем запрошено. Обычно это приводит к тому, что некоторые модули убиваются, чтобы освободить часть памяти.
Мониторинг OOM Kubernetes
При использовании экспортера узлов с Prometheus существует метрика, называемая node_vmstat_oom_kill.Важно отслеживать, когда происходят завершения OOM, но вы можете знать о таких событиях заранее, прежде чем они произойдут.
Вместо этого вы можете проверить, насколько процесс близок к ограничениям Kubernetes:
(sum by (namespace,pod,container)
(rate(container_cpu_usage_seconds_total{container!=""}[5m])) / sum by
(namespace,pod,container)
(kube_pod_container_resource_limits{resource="cpu"})) > 0.8
Регулировка ЦП Kubernetes
Дросселирование ЦП — это замедление процесса, когда он вот-вот достигнет определенных пределов ресурсов.
Как и в случае с памятью, эти пределы могут быть следующими:
-
Предел Kubernetes, установленный для контейнера.
-
Kubernetes ResourceQuota, установленный в пространстве имен.
-
Фактический объем памяти узла.
Рассмотрим следующую аналогию. У нас есть шоссе с некоторым движением, где:
-
Процессор - это путь.
-
Транспортные средства представляют собой процессы, и каждое транспортное средство имеет свой размер.
-
Несколько каналов представляют несколько ядер.
-
Запрос будет на выделенную дорогу, такую как велосипедная дорожка.
Троттлинг здесь проявляется как пробка: в итоге все процессы запустятся, но все будет медленнее.
Процессы ЦП в Kubernetes
Процессоры обрабатываются с помощью общих ресурсов в Kubernetes . Каждое ядро ЦП делится на 1024 доли, которые затем распределяются между всеми запущенными процессами с помощью функции cgroups (группы управления) ядра Linux.
Если ЦП может обрабатывать все текущие процессы, никаких действий не требуется. Если процесс использует более 100 % ресурсов ЦП, общие ресурсы установлены. Как и любое ядро Linux, Kubernetes использует механизм CFS (Completely Fair Scheduler), поэтому процессы с большим количеством общих ресурсов получают больше процессорного времени.
В отличие от памяти, Kubernetes не убивает модули для регулирования.
Статистику ЦП можно посмотреть в /sys/fs/cgroup/cpu/cpu.stat
чрезмерное использование ЦП
Как мы видели в статье Лимиты и запросы, установка лимитов или запросов важна, когда мы хотим ограничить потребление ресурсов процессом. Однако будьте осторожны, чтобы общее количество запросов не превышало фактический размер ЦП, так как это означает, что каждый контейнер должен иметь определенный объем ЦП.
Мониторинг троттлинга ЦП Kubernetes
Вы можете проверить, насколько процесс близок к лимиту Kubernetes:
(sum by (namespace,pod,container)(rate(container_cpu_usage_seconds_total
{container!=""}[5m])) / sum by (namespace,pod,container)
(kube_pod_container_resource_limits{resource="cpu"})) > 0.8
Если мы хотим отслеживать объем дросселирования, происходящего в кластере, cadvisor предоставляет container_cpu_cfs_throttled_periods_totalи container_cpu_cfs_periods_totalС помощью этих двух можно легко рассчитать процент дросселирования всех циклов процессора.
Лучшие практики
Обратите внимание на лимиты и запросы
Ограничения — это способ установить максимальное ограничение ресурсов в узле, но к ним нужно относиться с осторожностью, так как вы можете закончить процесс дросселированием или прекращением.
подготовиться к выселению
Установив очень низкий запрос, вы можете подумать, что это предоставит вашему процессу наименьшее количество ресурсов ЦП или памяти. Но kubeletмодули с более высоким использованием, чем запрошено, выселяются первыми, поэтому вы помечаете их как первые уничтоженные!
Если вам нужно защитить определенные поды от вытеснения (когда kube-schedulerнеобходимо выделить новые поды), назначьте приоритет наиболее важным процессам.
Дросселирование — тихий враг
Устанавливая нереалистичные ограничения или чрезмерные обязательства, вы можете не осознавать, что ваш процесс регулируется, а производительность страдает. Проактивно отслеживайте загрузку ЦП и узнавайте свои фактические ограничения в контейнерах и пространствах имен.
Подведем итог
Вот шпаргалка по управлению ресурсами Kubernetes для ЦП и памяти. Это резюмирует текущую статью и эти статьи из той же серии: