Merge pull request #26567 from mfilocha/synchronize-pl-1.20a
Synchronize Polish localization with upstreampull/26635/head
commit
572b62b938
|
@ -4,7 +4,7 @@ content_type: concept
|
||||||
weight: 30
|
weight: 30
|
||||||
description: >
|
description: >
|
||||||
API Kubernetesa służy do odpytywania i zmiany stanu obiektów Kubernetesa.
|
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:
|
card:
|
||||||
name: concepts
|
name: concepts
|
||||||
weight: 30
|
weight: 30
|
||||||
|
@ -14,13 +14,16 @@ card:
|
||||||
|
|
||||||
Sercem {{< glossary_tooltip text="warstwy sterowania" term_id="control-plane" >}} Kubernetes
|
Sercem {{< glossary_tooltip text="warstwy sterowania" term_id="control-plane" >}} Kubernetes
|
||||||
jest {{< glossary_tooltip text="serwer API" term_id="kube-apiserver" >}}. Serwer udostępnia
|
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
|
Większość operacji może zostać wykonana poprzez
|
||||||
interfejs linii komend (CLI) [kubectl](/docs/reference/kubectl/overview/) lub inne
|
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.
|
API. Możesz też korzystać z API bezpośrednio przez wywołania typu REST.
|
||||||
|
|
||||||
Jeśli piszesz aplikację używającą API Kubernetesa,
|
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>
|
</tbody>
|
||||||
</table>
|
</table>
|
||||||
|
|
||||||
W Kubernetesie zaimplementowany jest alternatywny format serializacji na potrzeby API oparty o Protobuf,
|
W Kubernetesie zaimplementowany jest alternatywny format serializacji na potrzeby API oparty o
|
||||||
który jest przede wszystkim przeznaczony na potrzeby wewnętrznej komunikacji w klastrze
|
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).
|
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).
|
||||||
Pliki IDL dla każdego ze schematów można znaleźć w pakietach Go, które definiują obiekty API.
|
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.
|
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ć.
|
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
|
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.
|
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
|
W ogólności, nowe zasoby i pola definiujące zasoby API są dodawane stosunkowo często.
|
||||||
jest regulowane przez [API deprecation policy](/docs/reference/using-api/deprecation-policy/).
|
Usuwanie zasobów lub pól jest regulowane przez
|
||||||
Definicja zmiany zgodnej (kompatybilnej) oraz metody wprowadzania zmian w API opisano w szczegółach
|
[API deprecation policy](/docs/reference/using-api/deprecation-policy/).
|
||||||
w [API change document](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md).
|
|
||||||
|
|
||||||
## 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
|
{{< note >}}
|
||||||
równocześnie wiele wersji API, każde poprzez osobną ścieżkę API, na przykład: `/api/v1` lub
|
Mimo, że Kubernetes stara się także zachować zgodność dla API w wersji _alpha_, zdarzają się przypadki,
|
||||||
`/apis/rbac.authorization.k8s.io/v1alpha1`.
|
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.
|
||||||
Rozdział wersji wprowadzony jest na poziomie całego API, a nie na poziomach poszczególnych zasobów lub pól, aby być pewnym,
|
{{< /note >}}
|
||||||
ż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`.
|
|
||||||
|
|
||||||
Zajrzyj do [API versions reference](/docs/reference/using-api/#api-versioning)
|
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
|
## 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/)
|
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 zasoby API.
|
pozwalają deklaratywnie określać, jak serwer API powinien dostarczać wybrane przez Ciebie zasoby API.
|
||||||
1. Można także rozszerzać API Kubernetesa implementując
|
1. Można także rozszerzać API Kubernetesa implementując
|
||||||
[warstwę agregacji](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/).
|
[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
|
- Naucz się, jak rozbudowywać API Kubernetesa poprzez dodawanie własnych
|
||||||
[CustomResourceDefinition](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/).
|
[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.
|
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 -->
|
<!-- overview -->
|
||||||
|
|
||||||
Tutaj znajdziesz dokumentację źródłową Kubernetes.
|
Tutaj znajdziesz dokumentację źródłową Kubernetesa.
|
||||||
|
|
||||||
<!-- body -->
|
<!-- body -->
|
||||||
|
|
||||||
## Dokumentacja API
|
## 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.
|
* [Using The Kubernetes API](/docs/reference/using-api/) - ogólne informacje na temat API Kubernetesa.
|
||||||
|
|
||||||
## Biblioteki klientów API
|
## Biblioteki klientów API
|
||||||
|
|
Loading…
Reference in New Issue