whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Polish translation update 2020-08-12

Browse Source 
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
Download Patch File Download Diff File Expand all files Collapse all files
content/pl/docs/tutorials/kubernetes-basics/expose/expose-intro.html
+1 -1
View File
@@ -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>