Workload

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 Kubernetes uruchamiasz go wewnątrz zestawu podów. Pod reprezentuje zestaw uruchomionych kontenerów na Twoim klastrze.

Pody mają zdefiniowany cykl życia. Na przykład, gdy Pod działa w twoim klastrze, krytyczna awaria na węźle, 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ą kontrolery, 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 i ReplicaSet (zastępując przestarzały zasób ReplicationController). 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 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. 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 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, może pomóc w zarządzaniu węzłem, lub może zapewniać opcjonalne funkcje, które ulepszają platformę kontenerową.
• Job i CronJob oferują różne sposoby definiowania zadań, które uruchamiają się do zakończenia, a następnie zatrzymują. Możesz użyć Job, aby zdefiniować zadanie, które uruchamia się do zakończenia, tylko raz. Możesz użyć CronJob, 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, 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

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ść.

Workload API umożliwia zdefiniowanie grupy Podów oraz zastosowanie do niej zaawansowanych polityk planowania, takich jak gang scheduling. 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
• Uruchom aplikację stanową jako pojedynczą instancję lub jako zestaw zreplikowany
• Uruchamianie zadań automatycznych za pomocą CronJob

Aby dowiedzieć się więcej o mechanizmach Kubernetesa służących do oddzielania kodu od konfiguracji, odwiedź Konfiguracja.

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) porządkuje obiekty z klastra po usunięciu ich zasobu właściciela.
• Kontroler czasu życia po zakończeniu (time-to-live after finished) 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 lub, tylko dla aplikacji webowych, używając Ingress.