Maciej Filocha
5cf5bf210c
Update Polish localization up to 99bfbd5ffe.
Part 1.
Co-authored-by: Karol Pucyński <9209870+kpucynski@users.noreply.github.com>
6.4 KiB
title, content_type, weight, description, card
| title | content_type | weight | description | card | ||||
|---|---|---|---|---|---|---|---|---|
| API Kubernetesa | concept | 30 | 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 {{< 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 Kubernetes 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 lub inne programy, takie jak 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, warto rozważyć użycie jednej z bibliotek klienckich.
Specyfikacja OpenAPI
Pełną specyfikację API udokumentowano za pomocą OpenAPI.
Serwer API Kubernetes API udostępnia specyfikację OpenAPI poprzez ścieżkę /openapi/v2.
Aby wybrać format odpowiedzi, użyj nagłówków żądania zgodnie z tabelą:
| Nagłówek | Dopuszczalne wartości | Uwagi |
|---|---|---|
Accept-Encoding |
gzip |
pominięcie tego nagłówka jest dozwolone |
Accept |
application/com.github.proto-openapi.spec.v2@v1.0+protobuf |
głównie do celu komunikacji wewnątrz klastra |
application/json |
domyślne | |
* |
udostępnia application/json |
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. Pliki IDL dla każdego ze schematów można znaleźć w pakietach Go, które definiują obiekty API.
Zmiany 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. Definicja zmiany zgodnej (kompatybilnej) oraz metody wprowadzania zmian w API opisano w szczegółach w API change document.
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 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, które mogą być włączane i wyłączane.
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 po szczegółowe informacje, jak definiuje się poziomy wersji API.
Rozbudowa API
API Kubernetesa można rozbudowywać (rozszerzać) na dwa sposoby:
- Definicje zasobów własnych pozwalają deklaratywnie określać, jak serwer API powinien dostarczać wybrane zasoby API.
- Można także rozszerzać API Kubernetesa implementując warstwę agregacji.
{{% heading "whatsnext" %}}
- Naucz się, jak rozbudowywać API Kubernetesa poprzez dodawanie własnych CustomResourceDefinition.
- Controlling API 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.