From 6d1f57ebc33eb856571fb6e8cf9f48a232fdc5a6 Mon Sep 17 00:00:00 2001
From: Maciej Filocha <maciej.filocha@gmail.com>
Date: Tue, 16 Feb 2021 08:52:32 +0100
Subject: [PATCH] Synchronize Polish localization with upstream
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Polish translation synchronized up to fa83273ca52656c3d6ad5acb67db05a82d2d3bbc.
Co-authored-by: Karol Pucyński <9209870+kpucynski@users.noreply.github.com>
Co-authored-by: Michał Sochoń <kaszpir@gmail.com>
---
.../docs/concepts/overview/kubernetes-api.md | 107 +++++++++++-------
content/pl/docs/reference/_index.md | 4 +-
2 files changed, 70 insertions(+), 41 deletions(-)
diff --git a/content/pl/docs/concepts/overview/kubernetes-api.md b/content/pl/docs/concepts/overview/kubernetes-api.md
index cd376dab1d..731b22cacc 100644
--- a/content/pl/docs/concepts/overview/kubernetes-api.md
+++ b/content/pl/docs/concepts/overview/kubernetes-api.md
@@ -4,7 +4,7 @@ content_type: concept
weight: 30
description: >
API Kubernetesa służy do odpytywania i zmiany stanu obiektów Kubernetesa.
- Sercem warstwy sterowania Kubernetesa jest serwer API i udostępniane przez niego HTTP API. Przez ten serwer odbywa się komunikacja pomiędzy użytkownikami, różnymi częściami składowymi klastra oraz komponentami zewnętrznymi.
+ Sercem warstwy sterowania Kubernetesa jest serwer API i udostępniane po HTTP API. Przez ten serwer odbywa się komunikacja pomiędzy użytkownikami, różnymi częściami składowymi klastra oraz komponentami zewnętrznymi.
card:
name: concepts
weight: 30
@@ -14,13 +14,16 @@ card:
Sercem {{< glossary_tooltip text="warstwy sterowania" term_id="control-plane" >}} Kubernetes
jest {{< glossary_tooltip text="serwer API" term_id="kube-apiserver" >}}. Serwer udostępnia
-API poprzez HTTP, umożliwiając wzajemną komunikację pomiędzy użytkownikami, częściami składowymi klastra i komponentami zewnętrznymi.
+API poprzez HTTP, umożliwiając wzajemną komunikację pomiędzy użytkownikami, częściami składowymi klastra
+i komponentami zewnętrznymi.
-API Kubernetes pozwala na sprawdzanie i zmianę stanu obiektów (przykładowo: pody, _Namespaces_, _ConfigMaps_, _Events_).
+API Kubernetesa pozwala na sprawdzanie i zmianę stanu obiektów
+(przykładowo: pody, _Namespaces_, _ConfigMaps_, _Events_).
Większość operacji może zostać wykonana poprzez
interfejs linii komend (CLI) [kubectl](/docs/reference/kubectl/overview/) lub inne
-programy, takie jak [kubeadm](/docs/reference/setup-tools/kubeadm/), które używają
+programy, takie jak
+[kubeadm](/docs/reference/setup-tools/kubeadm/), które używają
API. Możesz też korzystać z API bezpośrednio przez wywołania typu REST.
Jeśli piszesz aplikację używającą API Kubernetesa,
@@ -66,54 +69,77 @@ Aby wybrać format odpowiedzi, użyj nagłówków żądania zgodnie z tabelą:
</tbody>
</table>
-W Kubernetesie zaimplementowany jest alternatywny format serializacji na potrzeby API oparty o Protobuf,
-który jest przede wszystkim przeznaczony na potrzeby wewnętrznej komunikacji w klastrze
-i opisany w [design proposal](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/protobuf.md).
-Pliki IDL dla każdego ze schematów można znaleźć w pakietach Go, które definiują obiekty API.
+W Kubernetesie zaimplementowany jest alternatywny format serializacji na potrzeby API oparty o
+Protobuf, który jest przede wszystkim przeznaczony na potrzeby wewnętrznej komunikacji w klastrze.
+Więcej szczegółów znajduje się w dokumencie [Kubernetes Protobuf serialization](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/protobuf.md).
+oraz w plikach *Interface Definition Language* (IDL) dla każdego ze schematów
+zamieszczonych w pakietach Go, które definiują obiekty API.
-## Zmiany API
+## Przechowywanie stanu
+
+Kubernetes przechowuje serializowany stan swoich obiektów w
+{{< glossary_tooltip term_id="etcd" >}}.
+
+## Grupy i wersje API
+
+Aby ułatwić usuwanie poszczególnych pól lub restrukturyzację reprezentacji zasobów, Kubernetes obsługuje
+równocześnie wiele wersji API, każde poprzez osobną ścieżkę API,
+na przykład: `/api/v1` lub `/apis/rbac.authorization.k8s.io/v1alpha1`.
+
+Rozdział wersji wprowadzony jest na poziomie całego API, a nie na poziomach poszczególnych zasobów lub pól,
+aby być pewnym, że API odzwierciedla w sposób przejrzysty i spójny zasoby systemowe
+i ich zachowania oraz pozwala na kontrolowany dostęp do tych API, które są w fazie wycofywania
+lub fazie eksperymentalnej.
+
+Aby ułatwić rozbudowę API Kubernetes, wprowadziliśmy
+[*grupy API*](https://git.k8s.io/community/contributors/design-proposals/api-machinery/api-group.md), które mogą
+być [włączane i wyłączane](/docs/reference/using-api/#enabling-or-disabling).
+
+Zasoby API są rozróżniane poprzez przynależność do grupy API, typ zasobu, przestrzeń nazw (_namespace_,
+o ile ma zastosowanie) oraz nazwę. Serwer API może przeprowadzać konwersję między
+różnymi wersjami API w sposób niewidoczny dla użytkownika: wszystkie te różne wersje
+reprezentują w rzeczywistości ten sam zasób. Serwer API może udostępniać te same dane
+poprzez kilka różnych wersji API.
+
+Załóżmy przykładowo, że istnieją dwie wersje `v1` i `v1beta1` tego samego zasobu.
+Obiekt utworzony przez wersję `v1beta1` może być odczytany,
+zaktualizowany i skasowany zarówno przez wersję
+`v1beta1`, jak i `v1`.
+
+## Trwałość API
Z naszego doświadczenia wynika, że każdy system, który odniósł sukces, musi się nieustająco rozwijać w miarę zmieniających się potrzeb.
Dlatego Kubernetes został tak zaprojektowany, aby API mogło się zmieniać i rozrastać.
Projekt Kubernetes dąży do tego, aby nie wprowadzać zmian niezgodnych z istniejącymi aplikacjami klienckimi
i utrzymywać zgodność przez wystarczająco długi czas, aby inne projekty zdążyły się dostosować do zmian.
-W ogólności, nowe zasoby i pola definiujące zasoby API są dodawane stosunkowo często. Usuwanie zasobów lub pól
-jest regulowane przez [API deprecation policy](/docs/reference/using-api/deprecation-policy/).
-Definicja zmiany zgodnej (kompatybilnej) oraz metody wprowadzania zmian w API opisano w szczegółach
-w [API change document](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md).
+W ogólności, nowe zasoby i pola definiujące zasoby API są dodawane stosunkowo często.
+Usuwanie zasobów lub pól jest regulowane przez
+[API deprecation policy](/docs/reference/using-api/deprecation-policy/).
-## Grupy i wersje API
+Po osiągnięciu przez API statusu ogólnej dostępności (_general availability_ - GA),
+oznaczanej zazwyczaj jako wersja API `v1`, bardzo zależy nam na utrzymaniu jej zgodności w kolejnych wydaniach.
+Kubernetes utrzymuje także zgodność dla wersji _beta_ API tam, gdzie jest to możliwe:
+jeśli zdecydowałeś się używać API w wersji beta, możesz z niego korzystać także później,
+kiedy dana funkcjonalność osiągnie status stabilnej.
-Aby ułatwić usuwanie poszczególnych pól lub restrukturyzację reprezentacji zasobów, Kubernetes obsługuje
-równocześnie wiele wersji API, każde poprzez osobną ścieżkę API, na przykład: `/api/v1` lub
-`/apis/rbac.authorization.k8s.io/v1alpha1`.
-
-Rozdział wersji wprowadzony jest na poziomie całego API, a nie na poziomach poszczególnych zasobów lub pól, aby być pewnym,
-że API odzwierciedla w sposób przejrzysty i spójny zasoby systemowe i ich zachowania i pozwala
-na kontrolowany dostęp do tych API, które są w fazie wycofywania lub fazie eksperymentalnej.
-
-Aby ułatwić rozbudowę API Kubernetes, wprowadziliśmy [*grupy API*](https://git.k8s.io/community/contributors/design-proposals/api-machinery/api-group.md),
-które mogą być [włączane i wyłączane](/docs/reference/using-api/#enabling-or-disabling).
-
-Zasoby API są rozróżniane poprzez przynależność do grupy API, typ zasobu, przestrzeń nazw (_namespace_,
-o ile ma zastosowanie) oraz nazwę. Serwer API może obsługiwać
-te same dane poprzez różne wersje API i przeprowadzać konwersję między
-różnymi wersjami API w sposób niewidoczny dla użytkownika. Wszystkie te różne wersje
-reprezentują w rzeczywistości ten sam zasób. Załóżmy przykładowo, że istnieją dwie
-wersje `v1` i `v1beta1` tego samego zasobu. Obiekt utworzony przez
-wersję `v1beta1` może być odczytany, zaktualizowany i skasowany zarówno przez wersję
-`v1beta1`, jak i `v1`.
+{{< note >}}
+Mimo, że Kubernetes stara się także zachować zgodność dla API w wersji _alpha_, zdarzają się przypadki,
+kiedy nie jest to możliwe. Jeśli korzystasz z API w wersji alfa, przed aktualizacją klastra do nowej wersji
+zalecamy sprawdzenie w informacjach o wydaniu, czy nie nastąpiła jakaś zmiana w tej części API.
+{{< /note >}}
Zajrzyj do [API versions reference](/docs/reference/using-api/#api-versioning)
-po szczegółowe informacje, jak definiuje się poziomy wersji API.
+po szczegółowe definicje różnych poziomów wersji API.
+
+
## Rozbudowa API
-API Kubernetesa można rozbudowywać (rozszerzać) na dwa sposoby:
+API Kubernetesa można rozszerzać na dwa sposoby:
-1. [Definicje zasobów własnych](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
- pozwalają deklaratywnie określać, jak serwer API powinien dostarczać wybrane zasoby API.
+1. [Definicje zasobów własnych (_custom resources_)](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
+ pozwalają deklaratywnie określać, jak serwer API powinien dostarczać wybrane przez Ciebie zasoby API.
1. Można także rozszerzać API Kubernetesa implementując
[warstwę agregacji](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/).
@@ -121,6 +147,9 @@ API Kubernetesa można rozbudowywać (rozszerzać) na dwa sposoby:
- Naucz się, jak rozbudowywać API Kubernetesa poprzez dodawanie własnych
[CustomResourceDefinition](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/).
-- [Controlling API Access](/docs/reference/access-authn-authz/controlling-access/) opisuje
+- [Controlling Access To The Kubernetes API](/docs/concepts/security/controlling-access/) opisuje
sposoby, jakimi klaster zarządza dostępem do API.
-- Punkty dostępowe API _(endpoints)_, typy zasobów i przykłady zamieszczono w [API Reference](/docs/reference/kubernetes-api/).
+- Punkty dostępowe API _(endpoints)_, typy zasobów i przykłady zamieszczono w
+ [API Reference](/docs/reference/kubernetes-api/).
+- Aby dowiedzieć się, jaki rodzaj zmian można określić jako zgodne i jak zmieniać API, zajrzyj do
+ [API changes](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#readme).
diff --git a/content/pl/docs/reference/_index.md b/content/pl/docs/reference/_index.md
index bfc120218c..cf461cf7f2 100644
--- a/content/pl/docs/reference/_index.md
+++ b/content/pl/docs/reference/_index.md
@@ -8,13 +8,13 @@ content_type: concept
<!-- overview -->
-Tutaj znajdziesz dokumentację źródłową Kubernetes.
+Tutaj znajdziesz dokumentację źródłową Kubernetesa.
<!-- body -->
## Dokumentacja API
-* [Dokumentacja źródłowa API Kubernetesa {{< latest-version >}}](/docs/reference/generated/kubernetes-api/{{< latest-version >}}/)
+* [Dokumentacja źródłowa API Kubernetesa {{< param "version" >}}](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
* [Using The Kubernetes API](/docs/reference/using-api/) - ogólne informacje na temat API Kubernetesa.
## Biblioteki klientów API