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
@@ -14,8 +14,6 @@ z których każda zawiera sekwencję odpowiednich kroków.
|
||||
Przed zapoznaniem się z samouczkami warto stworzyć zakładkę do
|
||||
[słownika](/docs/reference/glossary/), aby móc się później do niego na bieżąco odwoływać.
|
||||
|
||||
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## Podstawy
|
||||
@@ -64,13 +62,8 @@ Przed zapoznaniem się z samouczkami warto stworzyć zakładkę do
|
||||
|
||||
* [Using Source IP](/docs/tutorials/services/source-ip/)
|
||||
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
Jeśli chciałbyś napisać nowy samouczek, odwiedź
|
||||
[Content Page Types](/docs/contribute/style/page-content-types/),
|
||||
gdzie znajdziesz dodatkowe informacje o tym typie strony.
|
||||
|
||||
|
||||
|
||||
@@ -63,7 +63,7 @@ W tym samouczku wykorzystamy obraz kontenera, który korzysta z NGINX, aby wyśw
|
||||
|
||||
## Stwórz Deployment
|
||||
|
||||
[*Pod*](/docs/concepts/workloads/pods/pod/) w Kubernetes to grupa jednego lub wielu kontenerów
|
||||
[*Pod*](/docs/concepts/workloads/pods/) w Kubernetes to grupa jednego lub wielu kontenerów
|
||||
połączonych ze sobą na potrzeby administrowania i dostępu sieci. W tym samouczku Pod
|
||||
zawiera tylko jeden kontener. [*Deployment*](/docs/concepts/workloads/controllers/deployment/)
|
||||
w Kubernetes monitoruje stan twojego Poda
|
||||
@@ -115,7 +115,9 @@ wykorzystując podany obraz Dockera.
|
||||
kubectl config view
|
||||
```
|
||||
|
||||
{{< note >}}Więcej informacji na temat polecenia `kubectl` znajdziesz w [przeglądzie kubectl](/docs/user-guide/kubectl-overview/).{{< /note >}}
|
||||
{{< note >}}
|
||||
Więcej informacji na temat polecenia `kubectl` znajdziesz w [przeglądzie kubectl](/docs/reference/kubectl/overview/).
|
||||
{{< /note >}}
|
||||
|
||||
## Stwórz Serwis
|
||||
|
||||
|
||||
@@ -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>
|
||||
|
||||
Reference in New Issue
Block a user