Хабрахабр

Автомасштабирование и управление ресурсами в Kubernetes (обзор и видео доклада)

27 апреля на конференции Стачка-2019, в рамках секции «DevOps», прозвучал доклад «Автомасштабирование и управление ресурсами в Kubernetes». В нём рассказывается о том, как с помощью K8s обеспечить высокую доступность приложений и гарантировать их максимальную производительность.

Поехали! По традиции рады представить видео с докладом (44 минуты, гораздо информативнее статьи) и основную выжимку в текстовом виде.

Разберём тему доклада по словам и начнём с конца.

Kubernetes

Пусть у нас на хосте есть Docker-контейнеры. Зачем? Для обеспечения повторяемости и изоляции, которые в свою очередь позволяют сделать просто и хорошо деплой, CI/CD. Таких машин с контейнерами у нас много.

Что в этом случае даёт Kubernetes?

  1. Мы перестаём думать про эти машины и начинаем работать с «облаком», кластером из контейнеров или pod'ов (групп из контейнеров).
  2. Более того, мы не думаем даже про отдельные pod'ы, а управляем ещё большими группами. Такие высокоуровневые примитивы позволяют нам сказать, что есть шаблон для запуска некой рабочей нагрузки, а вот нужное количество экземпляров для её запуска. Если мы впоследствии поменяем шаблон — поменяются и все экземпляры.
  3. С помощью декларативного API мы вместо выполнения последовательности конкретных команд описываем «устройство мира» (в YAML), который создаётся Kubernetes'ом. И снова: при изменениях описания будет меняться и его реально отображение.

Управление ресурсами

CPU

Пусть мы запускаем на сервере nginx, php-fpm и mysql. У этих служб в действительности будет ещё больше работающих процессов, каждый из которых требует вычислительных ресурсов:


(числа на слайде — «попугаи», абстрактная потребность каждого процесса в вычислительных мощностях)

Простой и очевидный способ сделать это — поместить каждую группу в контейнер: Чтобы с этим можно было удобно работать, логично объединить процессы по группам (например, все процессы nginx в одну группу «nginx»).

Их появление стало возможным благодаря трём ключевым возможностям в ядре, реализованным уже достаточно давно: capabilities, namespaces и cgroups. Чтобы продолжить, необходимо вспомнить, что же такое контейнер (в Linux). А дальнейшему развитию способствовали другие технологии (включая удобные «оболочки» типа Docker):

Процессы, объединённые в группы, как мы того хотели, — это и есть контрольные группы. В контексте доклада нас интересует только cgroups, потому что именно контрольные группы — та часть функциональных возможностей контейнеров (Docker'а и т.п.), что реализует управление ресурсами.

Вернёмся к потребностям в CPU у этих процессов, а теперь уже — у групп процессов:


(повторюсь, что все числа — абстрактное выражение потребности в ресурсах)

Что будет происходить в таком случае? При этом у самого CPU есть некий конечный ресурс (в примере это 1000), которого всем может не хватать (сумма потребностей всех групп — 150+850+460=1460).

Но в первом случае их больше нужного (333>150), поэтому излишек (333-150=183) остаётся в резерве, который тоже равно распределяется между двумя другими контейнерами: Ядро начинает раздавать ресурсы и делает это «честно», выдавая одинаковое количество ресурсов каждой группе.

Таков результат действий «честного» планировщика в Linux — CFS. В итоге: первому контейнеру хватило ресурсов, второму — сильно не хватило, третьему — немного не хватило. Например, так: Его работу можно регулировать с помощью назначения веса каждому из контейнеров.

Все ресурсы контейнера распределяются между процессами поровну. Посмотрим на случай нехватки ресурсов у второго контейнера (php-fpm). В результате, master-процесс работает хорошо, а все worker'ы тормозят, получив менее половины от нужного:

Веса, которые мы назначаем контейнерам, в дальнейшем будем назвать request'ами. Так работает планировщик CFS. дальше. Почему именно так — см.

Как известно, все дороги ведут в Рим, а в случае компьютера — в CPU. Взглянем на всю ситуацию с другой стороны. Самый простой способ управления ресурсами — «светофорный»: выдали одному процессу фиксированное время доступа к CPU, затем — следующему и т.п. CPU один, задач много — нужен светофор.

Запомним его просто как лимиты. Этот подход называется жёстким квотированием (hard limiting). Однако, если раздать всем контейнерами лимиты, возникает проблема: mysql ехал по дороге и в какой-то момент его потребность в CPU закончилась, но все остальные процессы вынуждены ждать, пока CPU простаивает.

Вернёмся к ядру Linux и его взаимодействию с CPU — общая картина получается следующей:

У cgroup есть две настройки — по сути это две простые «крутилки», позволяющие определять:

  1. вес для контейнера (request'ы) — это shares;
  2. процент от общего времени CPU для работы над задачами контейнера (лимиты) — это quota.

В чём мерить CPU?

Есть разные пути:

  1. Что такое попугаи, никто не знает — нужно каждый раз договариваться.
  2. Проценты понятнее, но относительны: 50% от сервера с 4 ядрами и с 20 ядрами ­— совершенно разные вещи.
  3. Можно использовать уже упомянутые веса, которые знает Linux, но они тоже относительны.
  4. Самый адекватный вариант — мерить вычислительные ресурсы в секундах. Т.е. в секундах процессорного времени по отношению к секундам реального времени: выдали 1 секунду процессорного времени в 1 реальную секунду — это одно ядро CPU целиком.

Чтобы стало говорить еще проще, измерять стали прямо в ядрах, подразумевая под ними то самое время CPU относительно реального. Поскольку Linux понимает веса, а не такое процессорное время/ядра, понадобился механизм перевода из одного в другое.

Рассмотрим простой пример с сервером с 3 ядрами CPU, где трём pod'ам будут выбраны такие веса (500, 1000 и 1500), которые легко конвертируются в соответствующие части выделенных им ядер (0,5, 1 и 1,5).

Но важный момент происходит тогда, когда на этом сервере появится четвёртый pod, вес у которого пусть для удобства будет 3000. Если взять второй сервер, где ядер будет вдвое больше (6), и разместить там те же pod'ы, распределение ядер легко посчитать простым умножением на 2 (1, 2 и 3 соответственно). Он забирает себе часть ресурсов CPU (половину ядер), а у остальных pod'ов они пересчитываются (уменьшатся вдвое):

Kubernetes и ресурсы CPU

В Kubernetes ресурсы CPU принято измерять в миллиядрах, т.е. в качестве базового веса берётся 0,001 ядра. (То же самое в терминологии Linux/cgroups называют CPU share, хотя, если говорить точнее, то 1000 миллиядер = 1024 CPU shares.) K8s следит за тем, чтобы не размещать на сервере больше pod'ов, чем есть ресурсов CPU для суммы весов всех pod'ов.

При добавлении сервера в кластер Kubernetes сообщается, сколько у него доступно ядер CPU. Как это происходит? Таким образом, pod будет определён на сервер, где ядер достаточно. А при создании нового pod'а планировщик Kubernetes знает, сколько ядер потребуется этому pod'у.

у pod'а не определено количество нужных ему ядер)? Что же произойдёт, если не указан request (т.е. Давайте разберёмся, как Kubernetes вообще считает ресурсы.

У pod'а можно указать и request'ы (планировщик CFS), и лимиты (помните светофор?):

  • Если они указаны равные, то pod'у назначается QoS-класс guaranteed. Такое количество всегда доступных для него ядер гарантируется.
  • Если request меньше лимита — QoS-класс burstable. Т.е. мы ожидаем, что pod, например, всегда использует 1 ядро, однако это значение не является для него ограничением: иногда pod может использовать и больше (когда на сервере есть свободные ресурсы для этого).
  • Есть ещё QoS-класс best effort — к нему относятся те самые pod'ы, для которых не указан request. Ресурсы им выдаются в последнюю очередь.

Память

С памятью ситуация подобная, но немного иная — всё-таки природа у этих ресурсов разная. В целом же аналогия такова:

Пусть pod'ы живут на сервере, изменяя потребляемую память, пока один из них не станет таким большим, что память закончится. Давайте посмотрим, как в памяти реализуются request'ы. В этом случае появляется OOM killer и убивает самый большой процесс:

Для этого используется параметр oom_score_adj. Нас это не всегда устраивает, поэтому есть возможность регулировать, какие процессы для нас важны и не должны убиваться.

Вернёмся к QoS-классам CPU и проведём аналогию со значениями oom_score_adj, определяющими для pod'ов приоритеты по потреблению памяти:

  • Самое низкое значение oom_score_adj у pod'а — -998 — означает, что такой pod должен убиваться в самую последнюю очередь, это guaranteed.
  • Самое высокое — 1000 — это best effort, такие pod'ы убиваются раньше всех.
  • Для расчёта остальных значений (burstable) есть формула, суть которой сводится к тому, что чем больше pod запросил ресурсов, тем меньше шансов, что его убьют.

С ней всё проще: мы просто назначаем максимальное количество выдаваемой памяти, и здесь (в отличие от CPU) нет вопроса, в чём её (память) измерять. Вторая «крутилка» — limit_in_bytes — для лимитов.

Итого

Каждому pod'у в Kubernetes задаются requests и limits — оба параметра для CPU и для памяти:

  1. на основании requests работает планировщик Kubernetes, который распределяет pod'ы по серверам;
  2. на основании всех параметров определяется QoS-класс pod'а;
  3. на основании CPU requests расчитываются относительные веса;
  4. на основании CPU requests настраивается CFS-планировщик;
  5. на основании memory requests настраивается OOM killer;
  6. на основании CPU limits настраивается «светофор»;
  7. на основании memory limits настраивается лимит на cgroup'у.

В целом эта картинка отвечает на все вопросы, как происходит основная часть управления ресурсами в Kubernetes.

Автомасштабирование

K8s cluster-autoscaler

Представим себе, что весь кластер уже занят и должен быть создан новый pod. Пока pod не может появиться, он висит в статусе Pending. Чтобы он всё-таки появился, мы можем подключить новый сервер к кластеру или же… поставить cluster-autoscaler, который сделает это за нас: закажет виртуальную машину у облачного провайдера (запросом по API) и подключит её к кластеру, после чего pod будет добавлен.

Однако, как и везде, здесь не без нюансов… Это и есть автомасштабирование кластера Kubernetes, которое замечательно (по нашему опыту) работает.

Проблема в том, что мигрировать pod'ы (для освобождения хостов) очень технически сложно и дорого по ресурсам. Пока мы увеличивали размеры кластера, всё было хорошо, но что происходит, когда кластер стал освобождаться? В Kubernetes работает совсем другой подход.

У него 6 pod'ов: сейчас это по 2 на каждый сервер. Рассмотрим кластер из 3 серверов, в котором есть Deployment. Для этого воспользуемся командой kubectl drain, которая: Мы по какой-то причине захотели выключить один из серверов.

  • запретит отправлять новые pod'ы на этот сервер;
  • удалит существующие pod'ы на сервере.

Поскольку Kubernetes следит за поддержанием числа pod'ов (6), он просто пересоздаст их на других узлах, но не на отключаемом, поскольку он уже помечен как недоступный для размещения новых pod'ов. Это основополагающая механика для Kubernetes.

В аналогичной ситуации для StatefulSet (вместо Deployment) действия будут иными. Однако и здесь есть нюанс. И мы снова решаем отключить один сервер. Теперь у нас уже stateful-приложение — например, три pod'а с MongoDB, у одного из которых возникла какая-то проблема (данные испортились или иная ошибка, не позволяющая корректно запуститься pod'у). Что произойдёт?

Однако этого не происходит — благодаря PodDisruptionBudget. MongoDB мог бы умереть, поскольку ему необходим кворум: для кластера из трёх инсталляций хотя бы две должны функционировать. Зная, что один из pod'ов с MongoDB уже не работает, и увидев, что для MongoDB в PodDisruptionBudget установлен minAvailable: 2, Kubernetes не даст удалить pod. Этот параметр определить минимально необходимое количество работающих pod'ов.

Итог: для того, чтобы корректно работало перемещение (а на самом деле — пересоздание) pod'ов при освобождении кластера, необходимо настраивать PodDisruptionBudget.

Горизонтальное масштабирование

Рассмотрим другую ситуацию. Есть приложение, запущенное как Deployment в Kubernetes. На его pod'ы (например, их три) приходит пользовательский трафик, а мы в них замеряем некий показатель (скажем, нагрузку на CPU). Когда нагрузка возрастает, мы это фиксируем по графику и увеличиваем количество pod'ов для распределения запросов.

Сегодня в Kubernetes это не нужно делать вручную: настраивается автоматическое увеличение/уменьшение количества pod'ов в зависимости от значений замеряемых показателей нагрузки.

Измерять можно очень многое: Главные вопросы здесь в том, что именно измерять и как интерпретировать полученные значения (для принятия решения об изменении числа pod'ов).

— я подробно рассказывал в докладе про Мониторинг и Kubernetes. Как делать это технически — собирать метрики и т.п. А основной совет для выбора оптимальных параметров — экспериментируйте!

На основании чего имеет смысл масштабировать, например, php-fpm? Есть метод USE (Utilization Saturation and Errors), смысл которого в следующем. А если worker'ы закончились и новые подключения не принимаются — это уже saturation. На основании того, что worker'ы заканчиваются, — это utilization. Оба этих параметра необходимо измерять, а в зависимости от значений и проводить масштабирование.

Вместо заключения

У доклада есть продолжение: про вертикальное масштабирование и про то, как правильно подбирать ресурсы. Об этом я расскажу в будущих роликах на нашем YouTube — подписывайтесь, чтобы не пропустить!

Видео и слайды

Видео с выступления (44 минуты):

Презентация доклада:

P.S.

Другие доклады про Kubernetes в нашем блоге:

Показать больше

Похожие публикации

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»