Рабочие нагрузки

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

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

Однако, чтобы значительно облегчить жизнь, не нужно непосредственно контролировать каждый под. Вместо этого можно использовать ресурсы рабочей нагрузки, которые управляют набором подов за вас. Эти ресурсы настраивают контроллеры, которые обеспечивают запуск нужного количества модулей нужного типа в соответствии с указанным вами состоянием.

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

• Деплоймент (Deployment) и ReplicaSet (замена устаревшего ресурса ReplicationController). Deployment хорошо подходит для управления неизменными (stateless) приложениями в кластере, то есть для случаев, когда любой под в деплойменте не содержит изменяемых данных и может быть заменен при необходимости.
• StatefulSet позволяет запускать один или несколько связанных подов, которые как-то отслеживают состояние (являются stateful). Например, если ваше приложение записывает постоянные данные, вы можете использовать StatefulSet, который сопоставляет каждый под с PersistentVolume. Ваш код, работающий в подах этого StatefulSet, может копировать данные в другие поды в том же StatefulSet, чтобы повысить общую отказоустойчивость.
• DaemonSet создает поды, которые предоставляют инструменты, которые доступны локально для узлов. Каждый раз, когда вы добавляете в кластер узел, соответствующий спецификации DaemonSet, слой управления (control plane) планирует (т.е. запускает) под с этим DaemonSet на новом узле. Каждый под в DaemonSet выполняет работу, аналогичную работе системного демона на классическом сервере Unix/POSIX. DaemonSet может иметь основополагающее значение для работы вашего кластера, например, в случае плагина для запуска сети кластера (cluster networking). Этот ресурс может помочь управлять узлом или предоставить дополнительные возможности для используемой контейнерной платформы.
• Job и CronJob предоставляют различные способы запуска задач, которые выполняются до своего завершения, а затем останавливаются. Job используется для задачи, которая выполняется только один раз. Вы можете использовать CronJob для запуска этого же задания несколько раз по расписанию.

В экосистеме вокруг проекта Kubernetes можно найти сторонние ресурсы для рабочих нагрузок, которые предоставляют дополнительные функции. Используя custom resource definition, вы можете добавить сторонний ресурс рабочей нагрузки, если нужно определенное поведение, не являющееся частью стандартного Kubernetes. Например, если вы хотите запустить группу подов для своего приложения, но хотите свернуть работу в случае, когда не все поды доступны (возможно, для распределенной задачи с высокой пропускной способностью), можно реализовать или установить расширение, которое предоставляет эту функцию.

Что дальше

В дополнение к информации о каждом виде API для управления рабочей нагрузкой вы можете прочитать, как выполнять конкретные задачи:

• Запустите stateless-приложение, используя деплоймент
• Запустите stateful-приложение в единственном экземпляре или в виде множества реплик
• Запустите задачи автоматизации с помощью CronJob

Чтобы узнать о механизмах отделения кода от конфигурации в Kubernetes, посетите раздел Configuration.

Есть два вспомогательных концепта, которые дают представление о том, как Kubernetes управляет подами для приложений:

• Сборщик мусора (Garbage collection) вычищает объекты из вашего кластера после удаления ресурса-владельца.
• Контроллер времени существования после завершения (time-to-live after finished controller) удаляет задания (Jobs) по истечении определенного времени с момента их завершения.

После запуска вашего приложения можно сделать его доступным в интернете с помощью Service или, только в случае веб-приложения, используя Ingress.