Для управления рабочей нагрузки использовать “голые” поды не рекомендуется, т.к. если нода кластера, на которой запущен под, упадет, то под не будет перераспределен на другую ноду. Кроме того, большинство приложений должны быть запущены в нескольких экземплярах исходя из требований горизонтальной масштабируемости и отказоустойчивости. Для того чтобы следить за этим, используются объекты и соответствующие им встроенные контроллеры Kubernetes для управления рабочей нагрузки.
Deployment – это объект Kubernetes, который описывает в скольких экземплярах запущен сервис, а также стратегию обновления на новую версию.
Контроллер, который реализует поведение этого объекта, встроен в Kubernetes, и работает в рамках компонента kube-controller-manager. Но слово контроллер зачастую опускают в речи, и говорят "деплоймент создал еще одну поду" или "деплоймент обновился" и т.д. Такие легкости в обращении с терминологией вполне допустимы и являются общепринятыми.
Давайте посмотрим, как выглядит описание объекта типа Deployment.
Как и у любого объекта Kubernetes, у него есть ряд общих для всех полей, это apiVersion, kind, metadata, spec.
В spec находится спецификация деплоймента:
· replicas — желаемое количество экземпляров сервиса
· selector — селектор для подов, которые будут находиться под управлением деплоймента
· strategy — стратегия обновления и ее настройки
· template — это шаблон пода, по которому будут создаваться поды
Встроенный контроллер деплоймента решает следующие задачи:
00001. Следит, чтобы количество доступных подов было равно требуемому (значение параметра replicas).
00002. Обеспечивает процесс обновления версии приложения.
Поддержание требуемого количества подов
При создании объекта типа Deployment, встроенный контроллер поднимает нужное количество подов, используя шаблон из спецификации. Если мы изменим спецификацию объекта Deployment, и поменяем параметр replicas, например, с 2 до 3, то тогда деплоймент обнаруживает, что желаемое количество реплик отличается от реального, и добавит еще один под по шаблону. Похожий процесс происходит и при даунскейле, т.е. если уменьшить количество реплик.
В случае, если с подом случается что-то нехорошее, например, упала нода, на которой под был запущен, или кто-то под удалил, деплоймент понимает, что желаемое количество реплик отличается от реального, и поднимает недостающую поду по шаблону.
Стратегии обновления
При любом изменении в шаблоне, встроенный контроллер начинает процесс обновления деплоймента. Для этого все поды со старым шаблоном удаляются, а с новым шаблоном — создаются. Встроенный контроллер поддерживает 2 стратегии обновления:
· Recreate - пересоздание. Сначала все старые поды удаляются. Как только поды были удалены, создаются новые в нужном количестве. Такая стратегия приводит к простою приложения, поэтому используется редко.
· RollingUpdate - постепенное обновление. Удаляются старые поды и создаются новые постепенно, так, чтобы в любой момент времени несколько под были доступны.
У стратегии RollingUpdate есть две настройки, которые позволяют регулировать, сколько подов минимально должно быть доступно, и на сколько мы можем превысить количество подов во время обновления.
· spec.strategy.rollingUpdate.maxUnavailable - это опциональное поле в описании настроек стратегии RollingUpdate. Оно описывает максимальное количество подов, которое может быть недоступно во время процесса обновления в виде процента от общего количества, либо в абсолютном выражении. Например, если значение этого параметра выставлено в 30%, то это означает, что контроллер сразу же может потушить 30% старых под, не дожидаясь, пока поднимутся новые, и, как только новые поды буду подниматься и готовы принимать трафик, контроллер и дальше может старые тушить, оставляя общее количество доступных под не меньше 70%.
· spec.strategy.rollingUpdate.maxSurge - это опциональное поле в описании настроек стратегии RollingUpdate. Оно описывает, на какое количество под контроллер может превысить желаемое значение реплик (экземпляров) во время обновления. Оно может выражаться как в процентах от общего количества, так и в абсолютном выражении. Например, если значение этого параметра выставлено в 30%, то это означает, что контроллер может, не дожидаясь момента, как будут удалены старые поды, создать новых под столько, чтобы общее количество старых и новых не превышало 130% от желаемого числа под.
Ссылки:
· Deployment (англ)
#kubernetes
#pod
#container
#devops