--- title: "Рабочие нагрузки" weight: 55 description: > Поймите под, самый маленький развертываемый вычислительный объект в Kubernetes, и абстракции более высокого уровня, которые помогут вам их запускать. no_list: true card: title: Рабочие нагрузки и поды name: concepts weight: 60 --- Рабочая нагрузка — это приложение, работающее в Kubernetes. Независимо от того, представляет ли ваша рабочая нагрузка один компонент или несколько, которые работают вместе, в Kubernetes вы запускаете ее внутри набора [_подов_](/docs/concepts/workloads/pods). В Kubernetes под представляет собой набор работающих {{< glossary_tooltip text="контейнеров" term_id="container" >}} в кластере. Поды Kubernetes имеют определенный [жизненный цикл](/docs/concepts/workloads/pods/pod-lifecycle/). Например, если у вас запущен под в кластере, то критическая ошибка на {{< glossary_tooltip text="узле" term_id="node" >}}, где этот модуль работает, означает, что все поды на этом узле выходят из строя. Kubernetes считает этот уровень сбоя безвозвратным: потребуется создать новый под для восстановления, даже если узел позже станет работоспособным. Однако, чтобы значительно облегчить жизнь, не нужно непосредственно контролировать каждый под. Вместо этого можно использовать _ресурсы рабочей нагрузки_, которые управляют набором подов за вас. Эти ресурсы настраивают {{< glossary_tooltip term_id="controller" text="контроллеры" >}}, которые обеспечивают запуск нужного количества модулей нужного типа в соответствии с указанным вами состоянием. Kubernetes предоставляет несколько встроенных ресурсов для рабочих нагрузок: * Деплоймент ([Deployment](/docs/concepts/workloads/controllers/deployment/)) и [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/) (замена устаревшего ресурса {{< glossary_tooltip text="ReplicationController" term_id="replication-controller" >}}). 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. Например, если вы хотите запустить группу подов для своего приложения, но хотите свернуть работу в случае, когда не все поды доступны (возможно, для распределенной задачи с высокой пропускной способностью), можно реализовать или установить расширение, которое предоставляет эту функцию. ## {{% heading "whatsnext" %}} В дополнение к информации о каждом виде 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).