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

> Поймите под, самый маленький развертываемый вычислительный объект в Kubernetes, и абстракции более высокого уровня, которые помогут вам их запускать.

---

LLMS index: [llms.txt](/llms.txt)

---

Рабочая нагрузка — это приложение, работающее в Kubernetes.
Независимо от того, представляет ли ваша рабочая нагрузка один компонент
или несколько, которые работают вместе, в Kubernetes вы 
запускаете ее внутри набора [_подов_](/docs/concepts/workloads/pods).
В Kubernetes под представляет собой набор работающих
<a class='glossary-tooltip' title='Легковесный и переносимый исполняемый образ, содержащий программное обеспечение вместе со всеми его зависимостями.' data-bs-toggle='tooltip' data-bs-placement='top' href='/ru/docs/concepts/overview/what-is-kubernetes/#why-containers' target='_blank' aria-label='контейнеров'>контейнеров</a> в кластере.

Поды Kubernetes имеют определенный [жизненный цикл](/docs/concepts/workloads/pods/pod-lifecycle/).
Например, если у вас запущен под в кластере, то критическая ошибка на 
<a class='glossary-tooltip' title='Узел — рабочая машина в Kubernetes.' data-bs-toggle='tooltip' data-bs-placement='top' href='/ru/docs/concepts/architecture/nodes/' target='_blank' aria-label='узле'>узле</a>, где этот модуль работает,
означает, что все поды на этом узле выходят из строя. Kubernetes считает
этот уровень сбоя безвозвратным: потребуется создать новый под для восстановления,
даже если узел позже станет работоспособным.

Однако, чтобы значительно облегчить жизнь, не нужно 
непосредственно контролировать каждый под. Вместо этого можно использовать
_ресурсы рабочей нагрузки_, которые управляют набором подов за вас.
Эти ресурсы настраивают <a class='glossary-tooltip' title='Управляющий цикл, который отслеживает общее состояние кластера через API-сервер и вносит изменения, пытаясь привести текущее состояние к желаемому.' data-bs-toggle='tooltip' data-bs-placement='top' href='/ru/docs/concepts/architecture/controller/' target='_blank' aria-label='контроллеры'>контроллеры</a>,
которые обеспечивают запуск нужного количества модулей
нужного типа в соответствии с указанным вами состоянием.

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

* Деплоймент ([Deployment](/docs/concepts/workloads/controllers/deployment/)) и [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/)
  (замена устаревшего ресурса
  <a class='glossary-tooltip' title='A (deprecated) API object that manages a replicated application.' data-bs-toggle='tooltip' data-bs-placement='top' href='/ru/docs/reference/glossary/?all=true#term-replication-controller' target='_blank' aria-label='ReplicationController'>ReplicationController</a>).
  Deployment хорошо подходит для управления неизменными (stateless) приложениями
  в кластере, то есть для случаев, когда любой под 
  в деплойменте не содержит изменяемых данных 
  и может быть заменен при необходимости.
* [StatefulSet](/docs/concepts/workloads/controllers/statefulset/) позволяет запускать один или несколько
  связанных подов, которые как-то отслеживают состояние (являются stateful). Например, если ваше
  приложение записывает постоянные данные, вы можете использовать StatefulSet,
  который сопоставляет каждый под с [PersistentVolume](/docs/concepts/storage/persistent-volumes/).
  Ваш код, работающий в подах этого StatefulSet, может 
  копировать данные в другие поды в том же StatefulSet,
  чтобы повысить общую отказоустойчивость.
* [DaemonSet](/docs/concepts/workloads/controllers/daemonset/) создает поды, которые
  предоставляют инструменты, которые доступны локально для узлов.
  Каждый раз, когда вы добавляете в кластер узел,
  соответствующий спецификации DaemonSet,
  слой управления (control plane) планирует (т.е. запускает) под с этим DaemonSet 
  на новом узле. Каждый под в DaemonSet выполняет работу,
  аналогичную работе системного демона на классическом сервере Unix/POSIX.
  DaemonSet может иметь основополагающее значение для работы вашего кластера,
  например, в случае плагина для запуска сети кластера ([cluster networking](/ru/docs/concepts/cluster-administration/networking/#реализация-сетевой-модели-kubernetes)).
  Этот ресурс может помочь управлять узлом 
  или предоставить дополнительные возможности 
  для используемой контейнерной платформы.
* [Job](/docs/concepts/workloads/controllers/job/) и
  [CronJob](/docs/concepts/workloads/controllers/cron-jobs/) предоставляют различные
  способы запуска задач, которые выполняются до своего завершения, а затем останавливаются.
  [Job](/docs/concepts/workloads/controllers/job/) используется для задачи,
  которая выполняется только один раз. Вы можете
  использовать [CronJob](/docs/concepts/workloads/controllers/cron-jobs/) для запуска этого же задания
  несколько раз по расписанию.

В экосистеме вокруг проекта Kubernetes можно найти сторонние ресурсы для
рабочих нагрузок, которые предоставляют дополнительные функции. Используя
[custom resource definition](/docs/concepts/extend-kubernetes/api-extension/custom-resources/),
вы можете добавить сторонний ресурс рабочей нагрузки, если нужно определенное
поведение, не являющееся частью стандартного Kubernetes. Например, если вы хотите
запустить группу подов для своего приложения, но хотите свернуть работу в случае,
когда не все поды доступны (возможно, для распределенной задачи с высокой пропускной способностью),
можно реализовать или установить расширение, которое предоставляет эту функцию.

## Что дальше

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

* [Запустите stateless-приложение, используя деплоймент](/docs/tasks/run-application/run-stateless-application-deployment/)
* Запустите stateful-приложение в [единственном экземпляре](/docs/tasks/run-application/run-single-instance-stateful-application/)
  или в виде [множества реплик](/docs/tasks/run-application/run-replicated-stateful-application/)
* [Запустите задачи автоматизации с помощью CronJob](/docs/tasks/job/automated-tasks-with-cron-jobs/)

Чтобы узнать о механизмах отделения кода от конфигурации в Kubernetes, посетите
раздел [Configuration](/docs/concepts/configuration/).

Есть два вспомогательных концепта, которые дают представление о том,
как Kubernetes управляет подами для приложений:
* Сборщик мусора ([Garbage collection](/ru/docs/concepts/architecture/garbage-collection/)) вычищает объекты из
  вашего кластера после удаления _ресурса-владельца_.
* Контроллер времени существования после завершения ([_time-to-live after finished_ controller](/docs/concepts/workloads/controllers/ttlafterfinished/))
  удаляет задания (Jobs) по истечении определенного времени с момента их завершения.

После запуска вашего приложения можно сделать его доступным в интернете
с помощью [Service](/docs/concepts/services-networking/service/) или, только в случае веб-приложения,
используя [Ingress](/docs/concepts/services-networking/ingress).

---

Section pages:

- [Поды](/ru/docs/concepts/workloads/pods/)
- [Ресурсы рабочей нагрузки](/ru/docs/concepts/workloads/controllers/)