Polish translation update 2020-08-12

Synchronize Polish translation with upstream changes up to fcd8af988c.

Co-authored-by: Karol Pucyński
Co-authored-by: Michał Sochoń
This commit is contained in:
Maciej Filocha
2020-08-12 10:38:46 +02:00
parent fcd8af988c
commit 402d9459e7
14 changed files with 61 additions and 129 deletions
@@ -20,7 +20,7 @@ weight: 20
<div class="row">
<div class="col-md-12">
<p>
Pod to podstawowy element odpowiedzialny za uruchomienie aplikacji na Kubernetesie. Każdy pod to część składowa całościowego obciążenia Twojego klastra. <a href="/docs/concepts/workloads/pods/pod-overview/#understanding-pods">Dowiedz się więcej na temat Podów</a>.
Pod to podstawowy element odpowiedzialny za uruchomienie aplikacji na Kubernetesie. Każdy pod to część składowa całościowego obciążenia Twojego klastra. <a href="/docs/concepts/workloads/pods/">Dowiedz się więcej na temat Podów</a>.
</p>
</div>
</div>
@@ -28,7 +28,7 @@ weight: 10
<div class="col-md-8">
<h3>Kubernetes Services - przegląd</h3>
<p><a href="/docs/concepts/workloads/pods/pod-overview/">Pody</a> Kubernetes są nietrwałe. Pody mają swój <a href="/docs/concepts/workloads/pods/pod-lifecycle/">cykl życia</a>. Jeśli węzeł roboczy ulegnie awarii, tracone są wszystkie pody działające na węźle. <a href="/docs/concepts/workloads/controllers/replicaset/">ReplicaSet</a> będzie próbował automatycznie doprowadzić klaster z powrotem do pożądanego stanu tworząc nowe pody i w ten sposób zapewnić działanie aplikacji. Innym przykładem może być system na back-endzie przetwarzania obrazów posiadający 3 repliki. Każda z tych replik jest wymienna - system front-endu nie powinien musieć pilnować replik back-endu ani tego, czy któryś z podów przestał działać i został odtworzony na nowo. Nie należy jednak zapominać o tym, że każdy Pod w klastrze Kubernetes ma swój unikatowy adres IP, nawet pody w obrębie tego samego węzła, zatem powinna istnieć metoda automatycznego uzgadniania zmian pomiędzy podami, aby aplikacja mogła dalej funkcjonować.</p>
<p><a href="/docs/concepts/workloads/pods/">Pody</a> Kubernetes są nietrwałe. Pody mają swój <a href="/docs/concepts/workloads/pods/pod-lifecycle/">cykl życia</a>. Jeśli węzeł roboczy ulegnie awarii, tracone są wszystkie pody działające na węźle. <a href="/docs/concepts/workloads/controllers/replicaset/">ReplicaSet</a> będzie próbował automatycznie doprowadzić klaster z powrotem do pożądanego stanu tworząc nowe pody i w ten sposób zapewnić działanie aplikacji. Innym przykładem może być system na back-endzie przetwarzania obrazów posiadający 3 repliki. Każda z tych replik jest wymienna - system front-endu nie powinien musieć pilnować replik back-endu ani tego, czy któryś z podów przestał działać i został odtworzony na nowo. Nie należy jednak zapominać o tym, że każdy Pod w klastrze Kubernetes ma swój unikatowy adres IP, nawet pody w obrębie tego samego węzła, zatem powinna istnieć metoda automatycznego uzgadniania zmian pomiędzy podami, aby aplikacja mogła dalej funkcjonować.</p>
<p>Serwis w Kubernetes jest abstrakcyjnym obiektem, która definiuje logiczny zbiór podów oraz politykę dostępu do nich. Serwisy pozwalają na swobodne łączenie zależnych podów. Serwis jest zdefiniowany w YAMLu <a href="/docs/concepts/configuration/overview/#general-configuration-tips">(zalecane)</a> lub w JSONie - tak, jak wszystkie obiekty Kubernetes. Zbiór podów, które obsługuje Serwis, jest zazwyczaj określany przez <i>LabelSelector</i> (poniżej opisane jest, w jakich przypadkach możesz potrzebować zdefiniować Serwis bez specyfikowania <code>selektora</code>).</p>
@@ -40,7 +40,7 @@ weight: 10
</ul>
</div>
<div class="content__box content__box_fill">
<p><i> Od samego początku w ramach Deploymentu można uruchomić wiele instancji — skorzystaj z parametru --replicas polecenia kubectl run</i></p>
<p><i> Od samego początku w ramach Deploymentu można uruchomić wiele instancji — skorzystaj z parametru --replicas polecenia kubectl create deployment</i></p>
</div>
</div>
</div>