# Робочі навантаження > Отримайте розуміння про Podʼи, найменші обʼєкти виконання в Kubernetes, та вищі рівні абстракції, які допомагають вам їх запускати. --- LLMS index: [llms.txt](/llms.txt) --- Робоче навантаження є застосунком, який запущено в Kubernetes. Неважливо, чи є ваше робоче навантаження одним компонентом, чи кількома, які працюють разом, в Kubernetes ви запускаєте його всередині набору [_Podʼів_](/docs/concepts/workloads/pods). В Kubernetes Pod представляє набір з одного чи більше запущених у вашому кластері. Podʼи Kubernetes мають [визначений життєвий цикл](/docs/concepts/workloads/pods/pod-lifecycle/). Наприклад, як тільки Pod запущено у вашому кластері, будь-яка критична помилка на , де запущено цей Pod, означає, що всі Podʼи на цьому вузлі зазнають збою. Kubernetes розглядає цей рівень збою як кінцевий: вам потрібно створити новий Pod, щоб відновити роботу, навіть якщо вузол пізніше відновить свою роботу. Однак, щоб значно полегшити роботу, вам не потрібно керувати кожним Pod окремо. Замість цього, ви можете використовувати _ресурси робочого навантаження_, які керують набором Podʼів за вас. Ці ресурси налаштовують , які переконуються, що правильна кількість Podʼів потрібного виду працює, щоб відповідати стану, який ви вказали. Kubernetes надає кілька вбудованих ресурсів робочого навантаження: * [Deployment](/docs/concepts/workloads/controllers/deployment/) та [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/) (що є заміною застарілого типу ресурсу ). Deployment є хорошим вибором для керування робочим навантаженням, яке не зберігає стану, де будь-який Pod у Deployment може бути замінений, якщо це потрібно. * [StatefulSet](/docs/concepts/workloads/controllers/statefulset/) дозволяє вам запускати один або кілька повʼязаних Podʼів, які відстежують стан певним чином. Наприклад, якщо ваше робоче навантаження постійно записує дані, ви можете запустити StatefulSet, який поєднує кожен Pod з [PersistentVolume](/docs/concepts/storage/persistent-volumes/). Ваш код, який працює в Pod для цього StatefulSet, може реплікувати дані на інші Podʼи в цьому StatefulSet, щоб покращити загальну надійність. * [DaemonSet](/docs/concepts/workloads/controllers/daemonset/) визначає Podʼи, які надають можливості, що є локальними для вузлів. Кожного разу, коли ви додаєте вузол до свого кластера, який відповідає специфікації в DaemonSet, панель управління планує Pod для цього DaemonSet на новому вузлі. Кожен Pod в DaemonSet виконує роботу, схожу на роботу системного демона у класичному Unix/POSIX сервері. DaemonSet може бути фундаментальним для роботи вашого кластера, як, наприклад, втулок [мережі кластера](/docs/concepts/cluster-administration/networking/#how-to-implement-the-kubernetes-network-model), він може допомогти вам керувати вузлом, або надати додаткову поведінку, яка розширює платформу контейнерів, яку ви використовуєте. * [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/) для запуску того ж Job кілька разів згідно з розкладом. В екосистемі Kubernetes ви можете знайти ресурси робочого навантаження від сторонніх розробників, які надають додаткові можливості. Використовуючи [визначення власних ресурсів](/docs/concepts/extend-kubernetes/api-extension/custom-resources/), ви можете додати ресурс робочого навантаження від стороннього розробника, якщо ви хочете використовувати конкретну функцію, яка не є частиною основної функціональності Kubernetes. Наприклад, якщо ви хочете запустити групу Podʼів для вашого застосунку, але зупинити роботу, якщо не всі Podʼи доступні (можливо, для якогось розподіленого завдання великого обсягу), ви можете реалізувати або встановити розширення, яке надає цю функцію. ## Розміщення Workload {#workload-placement}

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.35 [alpha](стандартно вимкнено)

В той час як звичайні ресурси робочого навантаження (наприклад, Deployments та Jobs) керують життєвим циклом Podʼів, ви можете мати складні вимоги до планування, де групи Podʼів мають бути розглянуті як єдиний обʼєкт. [Workload API](/docs/concepts/workloads/workload-api/) дозволяє визначати `PodGroupTemplates` для групування Podʼів та застосування до них розширених політик планування, таких як [групове планування](/docs/concepts/scheduling-eviction/gang-scheduling/). Контролери створюють обʼєкти [PodGroup](/docs/concepts/workloads/podgroup-api/) з цих шаблонів під час виконання, а `Pods` посилаються на свій `PodGroup` через поле `spec.schedulingGroup`. Це особливо корисно для пакетної обробки та робочих навантажень машинного навчання, де необхідне розміщення "все або нічого". ## Що далі Так само як і дізнаючись про кожний різновид API для керування робочим навантаженням, ви можете дізнатись, як виконати конкретні завдання: * [Запуск застосунку stateless використовуючи Deployment](/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 для відокремлення коду від конфігурації, відвідайте сторінку [Конфігурація](/docs/concepts/configuration/). Існують два концепти, які надають фонову інформацію про те, як Kubernetes керує Podʼами для застосунків: * [Збір сміття](/docs/concepts/architecture/garbage-collection/) приводить до ладу обʼєкти у вашому кластері після того, як їх _власний ресурс_ був видалений. * [Контролер _time-to-live after finished_](/docs/concepts/workloads/controllers/ttlafterfinished/) видаляє Jobʼи після того, як минув визначений час з моменту їх завершення. Як тільки ваш застосунок працює, ви, можливо, захочете зробити його доступним в Інтернеті як [Service](/docs/concepts/services-networking/service/) або, для вебзастосунків, використовуючи [Ingress](/docs/concepts/services-networking/ingress/). --- Section pages: - [Podʼи](/uk/docs/concepts/workloads/pods/) - [Workload API](/uk/docs/concepts/workloads/workload-api/) - [Керування навантаженням](/uk/docs/concepts/workloads/controllers/) - [PodGroup API](/uk/docs/concepts/workloads/podgroup-api/) - [Управління робочими навантаженнями](/uk/docs/concepts/workloads/management/) - [Автомасштабування робочих навантажень](/uk/docs/concepts/workloads/autoscaling/): З автомасштабуванням ви можете автоматично оновлювати ваші робочі навантаження різними способами. Це дозволяє вашому кластеру еластичніше та ефективніше реагувати на зміни попиту на ресурси. - [Горизонтальне автомасштабування Podʼів](/uk/docs/concepts/workloads/autoscaling/horizontal-pod-autoscale/) - [Менеджери ресурсів](/uk/docs/concepts/workloads/resource-managers/) - [Вертикальне автоматичне масштабування Podʼів](/uk/docs/concepts/workloads/autoscaling/vertical-pod-autoscale/)