From 7a9c47c8b496492a59b865128fc6bb7ee6e3e842 Mon Sep 17 00:00:00 2001 From: dkarczmarski Date: Mon, 17 Feb 2025 07:44:39 +0100 Subject: [PATCH 1/3] [pl] docs/concepts/workloads/controllers/_index.md --- .../concepts/workloads/controllers/_index.md | 61 +++++++++++++++++++ 1 file changed, 61 insertions(+) create mode 100644 content/pl/docs/concepts/workloads/controllers/_index.md diff --git a/content/pl/docs/concepts/workloads/controllers/_index.md b/content/pl/docs/concepts/workloads/controllers/_index.md new file mode 100644 index 0000000000000..0e53e337a5232 --- /dev/null +++ b/content/pl/docs/concepts/workloads/controllers/_index.md @@ -0,0 +1,61 @@ +--- +title: "Zarządzanie Workloadem" +weight: 20 +simple_list: true +--- + +Kubernetes udostępnia kilka wbudowanych interfejsów API do deklaratywnego +zarządzania Twoim +{{< glossary_tooltip text="workloadem" term_id="workload" >}} oraz jego komponentami. + +Twoje aplikacje działają jako kontenery wewnątrz +{{< glossary_tooltip term_id="Pod" text="Podów" >}}; jednakże zarządzanie pojedynczymi Podami byłoby +dużym wysiłkiem. Na przykład, jeśli Pod ulegnie awarii, prawdopodobnie +będziesz chciał uruchomić nowy Pod, aby go zastąpić. Kubernetes może to zrobić za Ciebie. + +Używasz API Kubernetesa aby utworzyć {{< glossary_tooltip text="obiekt" term_id="object" >}} +workloadu, który reprezentuje wyższy poziom abstrakcji niż +Pod, a następnie {{< glossary_tooltip text="płaszczyzna sterowania" term_id="control-plane" >}} +Kubernetesa automatycznie zarządza obiektami Pod w Twoim +imieniu, na podstawie specyfikacji zdefiniowanego przez Ciebie obiektu tego workloadu. + +Wbudowane interfejsy API do zarządzania workloadami to: + +[Deployment](/docs/concepts/workloads/controllers/deployment/) (oraz pośrednio +[ReplicaSet](/docs/concepts/workloads/controllers/replicaset/)), to najczęstszy +sposób uruchamiania aplikacji w klastrze. Deployment jest odpowiedni do zarządzania +obciążeniem aplikacji bezstanowej w klastrze, gdzie każdy Pod w Deployment jest +wymienny i może być zastąpiony w razie potrzeby. (Deploymenty zastępują przestarzałe +{{< glossary_tooltip text="ReplicationController" term_id="replication-controller" >}} API). + +[StatefulSet](/docs/concepts/workloads/controllers/statefulset/) pozwala +na zarządzanie jednym lub wieloma Podami – wszystkie uruchamiają ten sam +kod aplikacji – gdzie Pody opierają się na posiadaniu unikalnej tożsamości. +Jest to inne niż w przypadku Deployment, gdzie oczekuje się, że Pody są +wymienne. Najczęstszym zastosowaniem StatefulSet jest możliwość powiązania +jego Podów z ich trwałą pamięcią masową. Na przykład, można uruchomić +StatefulSet, który kojarzy każdy Pod z [PersistentVolume](/docs/concepts/storage/persistent-volumes/). +Jeśli jeden z Podów w StatefulSet ulegnie awarii, +Kubernetes tworzy zastępczy Pod, który jest połączony z tym samym PersistentVolume. + +[DaemonSet](/docs/concepts/workloads/controllers/daemonset/) definiuje Pody, +które zapewniają funkcje lokalne dla określonego +{{< glossary_tooltip text="węzła" term_id="node" >}}; na przykład sterownik, który umożliwia kontenerom na tym +węźle dostęp do systemu przechowywania danych. DaemonSet jest wykorzystywany w +sytuacjach, gdy sterownik lub inna usługa na poziomie węzła musi działać na +konkretnym węźle. Każdy Pod w DaemonSet pełni rolę podobną do demona systemowego na +klasycznym serwerze Unix / POSIX. DaemonSet może być kluczowy dla działania twojego +klastra, na przykład jako wtyczka, która pozwala temu węzłowi uzyskać dostęp do +[sieci klastrowej](/docs/concepts/cluster-administration/networking/#how-to-implement-the-kubernetes-network-model), +może pomóc w zarządzaniu węzłem albo +zapewnia mniej istotne funkcje, które wzbogacają używaną platformę kontenerową. Możesz uruchamiać +DaemonSety (i ich pody) na każdym węźle w twoim klastrze, lub tylko +na podzbiorze (na przykład instalując sterownik GPU tylko na węzłach, które mają zainstalowany GPU). + +Możesz użyć [Job](/docs/concepts/workloads/controllers/job/) i/lub +[CronJob](/docs/concepts/workloads/controllers/cron-jobs/) do zdefiniowania zadań, które +działają do momentu ukończenia, a następnie się zatrzymują. `Job` reprezentuje +jednorazowe zadanie, podczas gdy każdy `CronJob` powtarza się zgodnie z harmonogramem. + +Inne tematy w tej sekcji: + From 126615abf0884d38696fb113a0c025ad1e9747c8 Mon Sep 17 00:00:00 2001 From: dkarczmarski Date: Wed, 19 Feb 2025 08:04:38 +0100 Subject: [PATCH 2/3] [pl] docs/concepts/workloads/controllers/_index.md --- content/pl/docs/concepts/workloads/controllers/_index.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/content/pl/docs/concepts/workloads/controllers/_index.md b/content/pl/docs/concepts/workloads/controllers/_index.md index 0e53e337a5232..8292ab541962e 100644 --- a/content/pl/docs/concepts/workloads/controllers/_index.md +++ b/content/pl/docs/concepts/workloads/controllers/_index.md @@ -9,13 +9,13 @@ zarządzania Twoim {{< glossary_tooltip text="workloadem" term_id="workload" >}} oraz jego komponentami. Twoje aplikacje działają jako kontenery wewnątrz -{{< glossary_tooltip term_id="Pod" text="Podów" >}}; jednakże zarządzanie pojedynczymi Podami byłoby -dużym wysiłkiem. Na przykład, jeśli Pod ulegnie awarii, prawdopodobnie +{{< glossary_tooltip term_id="Pod" text="Podów" >}}; jednakże zarządzanie pojedynczymi Podami wiąże się z dużym +wysiłkiem. Na przykład, jeśli Pod ulegnie awarii, prawdopodobnie będziesz chciał uruchomić nowy Pod, aby go zastąpić. Kubernetes może to zrobić za Ciebie. Używasz API Kubernetesa aby utworzyć {{< glossary_tooltip text="obiekt" term_id="object" >}} workloadu, który reprezentuje wyższy poziom abstrakcji niż -Pod, a następnie {{< glossary_tooltip text="płaszczyzna sterowania" term_id="control-plane" >}} +Pod, a następnie {{< glossary_tooltip text="warstwa sterowania" term_id="control-plane" >}} Kubernetesa automatycznie zarządza obiektami Pod w Twoim imieniu, na podstawie specyfikacji zdefiniowanego przez Ciebie obiektu tego workloadu. From 419fcda9a7786d254f857bda1101a583ea5c3094 Mon Sep 17 00:00:00 2001 From: dkarczmarski Date: Wed, 19 Feb 2025 08:17:07 +0100 Subject: [PATCH 3/3] [pl] docs/concepts/workloads/controllers/_index.md --- .../pl/docs/concepts/workloads/controllers/_index.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/content/pl/docs/concepts/workloads/controllers/_index.md b/content/pl/docs/concepts/workloads/controllers/_index.md index 8292ab541962e..355615763b5c6 100644 --- a/content/pl/docs/concepts/workloads/controllers/_index.md +++ b/content/pl/docs/concepts/workloads/controllers/_index.md @@ -9,8 +9,8 @@ zarządzania Twoim {{< glossary_tooltip text="workloadem" term_id="workload" >}} oraz jego komponentami. Twoje aplikacje działają jako kontenery wewnątrz -{{< glossary_tooltip term_id="Pod" text="Podów" >}}; jednakże zarządzanie pojedynczymi Podami wiąże się z dużym -wysiłkiem. Na przykład, jeśli Pod ulegnie awarii, prawdopodobnie +{{< glossary_tooltip term_id="Pod" text="Podów" >}}; jednakże zarządzanie pojedynczymi Podami wiąże się z +dużym wysiłkiem. Na przykład, jeśli jeden Pod ulegnie awarii, prawdopodobnie będziesz chciał uruchomić nowy Pod, aby go zastąpić. Kubernetes może to zrobić za Ciebie. Używasz API Kubernetesa aby utworzyć {{< glossary_tooltip text="obiekt" term_id="object" >}} @@ -23,9 +23,9 @@ Wbudowane interfejsy API do zarządzania workloadami to: [Deployment](/docs/concepts/workloads/controllers/deployment/) (oraz pośrednio [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/)), to najczęstszy -sposób uruchamiania aplikacji w klastrze. Deployment jest odpowiedni do zarządzania -obciążeniem aplikacji bezstanowej w klastrze, gdzie każdy Pod w Deployment jest -wymienny i może być zastąpiony w razie potrzeby. (Deploymenty zastępują przestarzałe +sposób uruchamiania aplikacji w klastrze. Deployment jest odpowiedni do +zarządzania aplikacją bezstanową w klastrze, gdzie każdy Pod w Deployment jest wymienny i może +być zastąpiony w razie potrzeby. (Deploymenty zastępują przestarzałe {{< glossary_tooltip text="ReplicationController" term_id="replication-controller" >}} API). [StatefulSet](/docs/concepts/workloads/controllers/statefulset/) pozwala