# Workload

> Poznaj Pody – podstawowy element obliczeniowy w Kubernetes – oraz mechanizmy ułatwiające ich wdrażanie.

---

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

---

Workload to ogólne określenie aplikacji działającej na Kubernetesie.
Niezależnie od tego, czy Twój workload jest pojedynczym komponentem, czy kilkoma współpracującymi ze sobą,
na Kubernetesie uruchamiasz go wewnątrz zestawu
[_podów_](/docs/concepts/workloads/pods). Pod reprezentuje zbiór składający się z jednego lub więcej
uruchomionych <a class='glossary-tooltip' title='A lightweight and portable executable image that contains software and all of its dependencies.' data-bs-toggle='tooltip' data-bs-placement='top' href='/pl/docs/concepts/containers/' target='_blank' aria-label='kontenerów'>kontenerów</a> na Twoim klastrze.

Pody mają [zdefiniowany cykl życia](/docs/concepts/workloads/pods/pod-lifecycle/). Na
przykład, gdy Pod działa w twoim klastrze, krytyczna awaria na
<a class='glossary-tooltip' title='A node is a worker machine in Kubernetes.' data-bs-toggle='tooltip' data-bs-placement='top' href='/pl/docs/concepts/architecture/nodes/' target='_blank' aria-label='węźle'>węźle</a>, na którym ten Pod działa, oznacza, że wszystkie Pody na tym węźle
przestają działać. Kubernetes traktuje ten typ awarii jako ostateczny: przywrócenie działania
wymaga utworzenia nowego Poda, nawet jeśli węzeł później zostanie przywrócony do pełnej sprawności.

Jednak, aby znacznie ułatwić sobie życie, nie musisz zarządzać każdym
Podem bezpośrednio. Zamiast tego, możesz użyć obiektów dedykowanych do obsługi _workload-ów_,
które zarządzają zestawem Podów w Twoim imieniu. Te zasoby konfigurują
<a class='glossary-tooltip' title='A control loop that watches the shared state of the cluster through the apiserver and makes changes attempting to move the current state towards the desired state.' data-bs-toggle='tooltip' data-bs-placement='top' href='/pl/docs/concepts/architecture/controller/' target='_blank' aria-label='kontrolery'>kontrolery</a>, które
zapewniają, że odpowiednia liczba Podów działa, zgodnie z tym, co zdefiniowałeś.

Kubernetes udostępnia kilka wbudowanych typów obiektów przeznaczonych do obsługi   _workload-ów_:

* [Deployment](/docs/concepts/workloads/controllers/deployment/) i
  [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/) (zastępując przestarzały zasób
  <a class='glossary-tooltip' title='A (deprecated) API object that manages a replicated application.' data-bs-toggle='tooltip' data-bs-placement='top' href='/pl/docs/reference/glossary/?all=true#term-replication-controller' target='_blank' aria-label='ReplicationController'>ReplicationController</a>). Deployment
  jest odpowiedni do zarządzania bezstanowym workloadem aplikacji w
  klastrze, gdzie każdy Pod w Deployment jest wymienny i może być zastąpiony, jeśli to konieczne.
* [StatefulSet](/docs/concepts/workloads/controllers/statefulset/) pozwala na
  uruchomienie jednego lub więcej powiązanych Podów, które przechowują stan i potrafią go
  odtwarzać. Na przykład, jeśli Twój workload zapisuje dane w sposób trwały, możesz
  uruchomić StatefulSet, który wiąże każdy Pod z [PersistentVolume](/docs/concepts/storage/persistent-volumes/).
  Twój kod, działający w ramach Podów dla tego StatefulSet, może
  replikować dane do innych Podów w tym samym StatefulSet, aby poprawić ogólną odporność na awarie.
* [DaemonSet](/docs/concepts/workloads/controllers/daemonset/) definiuje Pody,
  które zapewniają funkcje lokalne dla węzłów. Za każdym razem, gdy dodajesz węzeł do
  swojego klastra, który pasuje do specyfikacji w DaemonSet, warstwa sterowania zleca uruchomienie
  Poda dla tego DaemonSet na nowym węźle. Każdy Pod w DaemonSet
  wykonuje zadanie podobne do demona systemowego na klasycznym serwerze Unix / POSIX.
  DaemonSet może być fundamentalny dla działania twojego klastra, na przykład jako
  wtyczka do uruchamiania [infrastuktury sieciowej klastra](/docs/concepts/cluster-administration/networking/#how-to-implement-the-kubernetes-network-model),
  może pomóc w
  zarządzaniu węzłem, lub może zapewniać opcjonalne funkcje, które ulepszają platformę kontenerową.
* [Job](/docs/concepts/workloads/controllers/job/) i
  [CronJob](/docs/concepts/workloads/controllers/cron-jobs/) oferują różne sposoby
  definiowania zadań, które uruchamiają się do zakończenia, a następnie
  zatrzymują. Możesz użyć [Job](/docs/concepts/workloads/controllers/job/),
  aby zdefiniować zadanie, które uruchamia się do zakończenia, tylko
  raz. Możesz użyć [CronJob](/docs/concepts/workloads/controllers/cron-jobs/),
  aby uruchomić to samo zadanie (Job) wielokrotnie według harmonogramu.

W szerszym ekosystemie Kubernetesa można znaleźć definicje zadań od firm trzecich, które
zapewniają dodatkowe zachowania. Korzystając z [Custom Resource Definition](/docs/concepts/extend-kubernetes/api-extension/custom-resources/),
można dodać definicję zadania od firmy
trzeciej, jeśli chcesz uzyskać określone działanie, które nie jest częścią podstawowej wersji
Kubernetesa. Na przykład, jeśli chcesz uruchomić grupę Podów dla swojej aplikacji, ale
zatrzymać pracę, jeśli _wszystkie_ Pody nie są dostępne (może dla jakiegoś zadania
wysokoprzepustowego rozproszonego), to można zaimplementować lub zainstalować rozszerzenie, które oferuje tę funkcję.

## Rozmieszczanie workloadów {#workload-placement}








  <div class="feature-state-notice feature-alpha" title="Bramka funkcji: GenericWorkload">
              <span class="feature-state-name">STATUS FUNKCJONALNOŚCI:</span> 
              <code>Kubernetes v1.35 [alpha]</code>(domyślnie wyłączone)</div>


Podczas gdy standardowe zasoby workloadów (takie jak Deploymenty czy Joby) zarządzają cyklem życia Podów, w niektórych
przypadkach możesz mieć złożone wymagania dotyczące harmonogramowania, w których grupy Podów muszą być traktowane jako jedna całość.

Za pomocą [Workload API](/docs/concepts/workloads/workload-api/) można definiować
`PodGroupTemplates`, które grupują Pody i umożliwiają zastosowanie wobec nich zaawansowanych mechanizmów
harmonogramowania, takich jak [gang scheduling](/docs/concepts/scheduling-eviction/gang-scheduling/).
W trakcie działania systemu kontrolery generują z tych szablonów obiekty
[PodGroup](/docs/concepts/workloads/podgroup-api/), natomiast każdy `Pod` wskazuje swoją grupę `PodGroup`
poprzez pole `spec.schedulingGroup`. Jest to szczególnie przydatne dla workloadów związanych z
przetwarzaniem wsadowym i uczeniem maszynowym, gdzie wymagane jest rozmieszczenie "wszystko albo nic".

## Co dalej?

Oprócz przeczytania informacji o każdym rodzaju API do zarządzania workloadami,
możesz dowiedzieć się, jak wykonywać konkretne zadania:

* [Uruchom aplikację bezstanową za pomocą Deployment](/docs/tasks/run-application/run-stateless-application-deployment/)
* Uruchom aplikację stanową jako [pojedynczą instancję](/docs/tasks/run-application/run-single-instance-stateful-application/)
  lub jako [zestaw zreplikowany](/docs/tasks/run-application/run-replicated-stateful-application/)
* [Uruchamianie zadań automatycznych za pomocą CronJob](/docs/tasks/job/automated-tasks-with-cron-jobs/)

Aby dowiedzieć się więcej o mechanizmach Kubernetesa służących do
oddzielania kodu od konfiguracji, odwiedź [Konfiguracja](/docs/concepts/configuration/).

Istnieją dwie wspomagające koncepcje, które dostarczają
informacji o tym, jak Kubernetes zarządza Podami dla aplikacji:
* [Mechanizm usuwania zbędnych obiektów (ang. Garbage collection)](/docs/concepts/architecture/garbage-collection/)
  porządkuje obiekty z klastra po usunięciu ich _zasobu właściciela_.
* [_Kontroler czasu życia po zakończeniu_ (time-to-live after finished)](/docs/concepts/workloads/controllers/ttlafterfinished/)
  usuwa zadania (Jobs) po upływie określonego czasu od ich zakończenia.

Gdy Twoja aplikacja jest uruchomiona, możesz chcieć udostępnić ją w internecie jako
[Service](/docs/concepts/services-networking/service/) lub, tylko dla
aplikacji webowych, używając [Ingress](/docs/concepts/services-networking/ingress).

---

Section pages:

- [Pod](/pl/docs/concepts/workloads/pods/)
- [Zarządzanie Workloadem](/pl/docs/concepts/workloads/controllers/)