Merge pull request #26567 from mfilocha/synchronize-pl-1.20a
Synchronize Polish localization with upstream
This commit is contained in:
Kubernetes Prow Robot
GitHub
commit
572b62b938
|
|
@ -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).
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
Loading…
Reference in New Issue