Kubernetes to przenośna, rozszerzalna platforma oprogramowania open-source służąca do zarządzania zadaniami i serwisami uruchamianymi w kontenerach. Umożliwia ich deklaratywną konfigurację i automatyzację. Kubernetes posiada duży i dynamicznie rozwijający się ekosystem. Szeroko dostępne są usługi, wsparcie i dodatkowe narzędzia.
Na tej stronie znajdziesz ogólne informacje o Kubernetesie.
Kubernetes to przenośna, rozszerzalna platforma oprogramowania open-source służąca do zarządzania zadaniami i serwisami uruchamianymi w kontenerach,
która umożliwia deklaratywną konfigurację i automatyzację. Ekosystem Kubernetesa jest duży i dynamicznie się rozwija.
Usługi dla Kubernetesa, wsparcie i narzędzia są szeroko dostępne.
Nazwa Kubernetes pochodzi z języka greckiego i oznacza sternika albo pilota.
Skrót K8s powstał poprzez zastąpienie ośmiu liter pomiędzy "K" i "s".
Google otworzyło projekt Kubernetes publicznie w 2014. Kubernetes korzysta z
piętnastoletniego doświadczenia Google w uruchamianiu wielkoskalowych serwisów
i łączy je z najlepszymi pomysłami i praktykami wypracowanymi przez społeczność.
Trochę historii
Aby zrozumieć, dlaczego Kubernetes stał się taki przydatny, cofnijmy sie trochę w czasie.
Era wdrożeń tradycyjnych:
Na początku aplikacje uruchamiane były na fizycznych serwerach. Nie było możliwości separowania zasobów poszczególnych aplikacji,
co prowadziło do problemów z alokacją zasobów.
Przykładowo, kiedy wiele aplikacji jest uruchomionych na jednym fizycznym serwerze,
część tych aplikacji może zużyć większość dostępnych zasobów, powodując spowolnienie działania innych.
Rozwiązaniem tego problemu mogło być uruchamianie każdej aplikacji na osobnej maszynie.
Niestety, takie podejście ograniczało skalowanie, ponieważ większość zasobów nie była w pełni wykorzystywana,
a utrzymanie wielu fizycznych maszyn było kosztowne.
Era wdrożeń w środowiskach wirtualnych: Jako rozwiązanie zaproponowano wirtualizację, która umożliwia
uruchamianie wielu maszyn wirtualnych (VM) na jednym procesorze fizycznego serwera. Wirtualizacja pozwala
izolować aplikacje pomiędzy maszynami wirtualnymi, zwiększając w ten sposób bezpieczeństwo, jako że informacje
związane z jedną aplikacją nie są w łatwy sposób dostępne dla pozostałych.
Wirtualizacja pozwala lepiej wykorzystywać zasoby fizycznego serwera i lepiej skalować,
ponieważ aplikacje mogą być łatwo dodawane oraz aktualizowane, pozwala ograniczyć koszty sprzętu
oraz ma wiele innych zalet.
Za pomocą wirtualizacji można udostępnić wybrane zasoby fizyczne jako klaster maszyn wirtualnych "wielokrotnego użytku".
Każda maszyna wirtualna jest pełną maszyną zawierającą własny system operacyjny
pracujący na zwirtualizowanej warstwie sprzętowej.
Era wdrożeń w kontenerach: Kontenery działają w sposób zbliżony do maszyn wirtualnych,
ale mają mniejszy stopnień wzajemnej izolacji, współdzieląc ten sam system operacyjny.
Kontenery określane są mianem "lekkich". Podobnie, jak maszyna wirtualna,
kontener posiada własny system plików, udział w zasobach procesora, pamięć, przestrzeń procesów itd.
Ponieważ kontenery są definiowane rozłącznie od leżących poniżej warstw infrastruktury,
mogą być łatwiej przenoszone pomiędzy chmurami i różnymi dystrybucjami systemu operacyjnego.
Kontenery zyskały popularność ze względu na swoje zalety, takie jak:
Szybkość i elastyczność w tworzeniu i instalacji aplikacji:
obraz kontenera buduje się łatwiej niż obraz VM.
Ułatwienie ciągłego rozwoju, integracji oraz wdrażania aplikacji (Continuous development, integration, and deployment):
obrazy kontenerów mogą być budowane w sposób wiarygodny i częsty.
W razie potrzeby, przywrócenie poprzedniej wersji aplikacji jest stosunkowo łatwie (ponieważ obrazy są niezmienne).
Rozdzielenie zadań Dev i Ops: obrazy kontenerów powstają w fazie build/release,
a nie w trakcie procesu instalacji,
oddzielając w ten sposób aplikacje od infrastruktury.
Obserwowalność obejmuje nie tylko informacje i metryki z poziomu systemu operacyjnego,
ale także poprawność działania samej aplikacji i inne sygnały.
Spójność środowiska na etapach rozwoju oprogramowania, testowania i działania w trybie produkcyjnym:
działa w ten sam sposób na laptopie i w chmurze.
Możliwość przenoszenia pomiędzy systemami operacyjnymi i platformami chmurowymi: Ubuntu, RHEL, CoreOS,
prywatnymi centrami danych, największymi dostawcami usług chmurowych czy gdziekolwiek indziej.
Zarządzanie, które w centrum uwagi ma aplikacje: Poziom abstrakcji przeniesiony jest z warstwy systemu operacyjnego
działającego na maszynie wirtualnej na poziom działania aplikacji, która działa na systemie operacyjnym używając zasobów logicznych.
Luźno powiązane, rozproszone i elastyczne "swobodne" mikro serwisy: Aplikacje podzielone są na mniejsze, niezależne komponenty,
które mogą być dynamicznie uruchamiane i zarządzane -
nie jest to monolityczny system działający na jednej, dużej maszynie dedykowanej na wyłączność.
Izolacja zasobów: wydajność aplikacji możliwa do przewidzenia
Wykorzystanie zasobów: wysoka wydajność i upakowanie.
Do czego potrzebujesz Kubernetesa i jakie są jego możliwości
Kontenery są dobrą metodą na opakowywanie i uruchamianie aplikacji.
W środowisku produkcyjnym musisz zarządzać kontenerami, w których działają aplikacje i pilnować, aby nie było żadnych przerw w ich dostępności.
Przykładowo, kiedy jeden z kontenerów przestaje działać, musi zostać wymieniony.
Nie byłoby prościej, aby takimi działaniami zajmował się jakiś system?
I tu właśnie przychodzi z pomocą Kubernetes!
Kubernetes zapewnia środowisko do uruchamiania systemów rozproszonych o wysokiej niezawodności.
Kubernetes obsługuje skalowanie aplikacji, przełączanie w sytuacjach awaryjnych, różne scenariusze wdrożeń itp.
Przykładowo, Kubernetes w łatwy sposób może zarządzać wdrożeniem nowej wersji oprogramowania zgodnie z metodyką canary deployments.
Kubernetes zapewnia:
Detekcję nowych serwisów i balansowanie ruchu
Kubernetes może udostępnić kontener używając nazwy DNS lub swojego własnego adresu IP.
Jeśli ruch przychodzący do kontenera jest duży, Kubernetes może balansować obciążenie i przekierować ruch sieciowy,
aby zapewnić stabilność całej instalacji.
Zarządzanie obsługą składowania danych
Kubernetes umożliwia automatyczne montowanie systemów składowania danych dowolnego typu —
lokalnych, od dostawców chmurowych i innych.
Automatyczne wdrożenia i wycofywanie zmian
Możesz opisać oczekiwany stan instalacji za pomocą Kubernetesa,
który zajmie się doprowadzeniem w sposób kontrolowany stanu faktycznego do stanu oczekiwanego.
Przykładowo, przy pomocy Kubernetesa możesz zautomatyzować proces tworzenia nowych kontenerów
na potrzeby swojego wdrożenia, usuwania istniejących i przejęcia zasobów przez nowe kontenery.
Automatyczne zarządzanie dostępnymi zasobami
Twoim zadaniem jest dostarczenie klastra maszyn, które Kubernetes może wykorzystać do uruchamiania zadań w kontenerach.
Określasz zapotrzebowanie na moc procesora i pamięć RAM dla każdego z kontenerów.
Kubernetes rozmieszcza kontenery na maszynach w taki sposób, aby jak najlepiej wykorzystać dostarczone zasoby.
Samoczynne naprawianie
Kubernetes restartuje kontenery, które przestały działać, wymienia je na nowe, wymusza wyłączenie kontenerów,
które nie odpowiadają na określone zapytania o stan
i nie rozgłasza powiadomień o ich dostępności tak długo, dopóki nie są gotowe do działania.
Zarządzanie informacjami poufnymi i konfiguracją
Kubernetes pozwala składować i zarządzać informacjami poufnymi, takimi jak hasła, tokeny OAuth czy klucze SSH.
Informacje poufne i zawierające konfigurację aplikacji mogą być dostarczane i zmieniane bez konieczności ponownego budowania obrazu kontenerów
i bez ujawniania poufnych danych w ogólnej konfiguracji oprogramowania.
Czym Kubernetes nie jest
Kubernetes nie jest tradycyjnym, zawierającym wszystko systemem PaaS (Platform as a Service).
Ponieważ Kubernetes działa w warstwie kontenerów, a nie sprzętu, posiada różne funkcjonalności ogólnego zastosowania,
wspólne dla innych rozwiązań PaaS, takie jak: instalacje (deployments), skalowanie i balansowanie ruchu,
umożliwiając użytkownikom integrację rozwiązań służących do logowania, monitoringu i ostrzegania.
Co ważne, Kubernetes nie jest monolitem i domyślnie dostępne rozwiązania są opcjonalne i działają jako wtyczki.
Kubernetes dostarcza elementy, z których może być zbudowana platforma deweloperska,
ale pozostawia użytkownikowi wybór i elastyczność tam, gdzie jest to ważne.
Kubernetes:
Nie ogranicza typów aplikacji, które są obsługiwane. Celem Kubernetesa jest możliwość obsługi bardzo różnorodnego typu zadań,
włączając w to aplikacje bezstanowe (stateless), aplikacje ze stanem (stateful) i ogólne przetwarzanie danych.
Jeśli jakaś aplikacja może działać w kontenerze, będzie doskonale sobie radzić w środowisku Kubernetesa.
Nie oferuje wdrażania aplikacji wprost z kodu źródłowego i nie buduje aplikacji.
Procesy Continuous Integration, Delivery, and Deployment (CI/CD) są zależne od kultury pracy organizacji,
jej preferencji oraz wymagań technicznych.
Nie dostarcza serwisów z warstwy aplikacyjnej, takich jak warstwy pośrednie middleware (np. broker wiadomości),
środowiska analizy danych (np. Spark), bazy danych (np. MySQL),
cache ani klastrowych systemów składowania danych (np. Ceph) jako usług wbudowanych.
Te składniki mogą być uruchamiane na klastrze Kubernetes i udostępniane innym aplikacjom przez przenośne rozwiązania,
takie jak Open Service Broker.
Nie wymusza użycia konkretnych systemów zbierania logów, monitorowania ani ostrzegania.
Niektóre z tych rozwiązań są udostępnione jako przykłady. Dostępne są też mechanizmy do gromadzenia i eksportowania różnych metryk.
Nie dostarcza, ani nie wymusza języka/systemu używanego do konfiguracji (np. Jsonnet).
Udostępnia API typu deklaratywnego, z którego można korzystać za pomocą różnych metod wykorzystujących deklaratywne specyfikacje.
Nie zapewnia, ani nie wykorzystuje żadnego ogólnego systemu do zarządzania konfiguracją,
utrzymaniem i samo-naprawianiem maszyn.
Co więcej, nie jest zwykłym systemem planowania (orchestration). W rzeczywistości, eliminuje konieczność orkiestracji.
Zgodnie z definicją techniczną, orkiestracja to wykonywanie określonego ciągu zadań: najpierw A, potem B i następnie C. Dla kontrastu,
Kubernetes składa się z wielu niezależnych, możliwych do złożenia procesów sterujących,
których zadaniem jest doprowadzenie stanu faktycznego do stanu oczekiwanego. Nie ma znaczenia, w jaki sposób przechodzi się od A do C.
Nie ma konieczności scentralizowanego zarządzania. Dzięki temu otrzymujemy system, który jest potężniejszy,
bardziej odporny i niezawodny i dający więcej możliwości rozbudowy.
Klaster Kubernetesa tworzą: komponenty warstwy sterowania oraz zbiór maszyn nazywanych węzłami.
W wyniku instalacji Kubernetesa otrzymujesz klaster.
Klaster Kubernetes to zestaw maszyn roboczych, nazywanych węzłami, na których uruchamiane są aplikacje w kontenerach. Każdy klaster musi posiadać przynajmniej jeden węzeł.
Na węźle (lub węzłach) roboczych rozmieszczane są pody,
które są częściami składowymi aplikacji.
Warstwa sterowania zarządza
węzłami roboczymi i podami należącymi do klastra. W środowisku produkcyjnym warstwa sterowania
rozłożona jest zazwyczaj na kilka maszyn, a klaster uruchomiony jest na wielu węzłach zapewniając
większą niezawodność i odporność na awarie.
W tym dokumencie opisujemy składniki niezbędne do zbudowania kompletnego, poprawnie działającego klastra Kubernetesa.
Części składowe klastra Kubernetes
Części składowe warstwy sterowania
Komponenty warstwy sterowania podejmują ogólne decyzje dotyczące klastra (np. zlecanie zadań), a także wykrywają i reagują na zdarzenia w klastrze (przykładowo, start nowego poda, kiedy wartość replicas dla deploymentu nie zgadza się z faktyczną liczbą replik).
Komponenty warstwy sterowania mogą być uruchomione na dowolnej maszynie w klastrze. Dla uproszczenia jednak skrypty instalacyjne zazwyczaj startują wszystkie składniki na tej samej maszynie, a jednocześnie nie pozwalają na uruchamianie na niej kontenerów użytkowników. Na stronie Creating Highly Available clusters with kubeadm znajdziesz opis konfiguracji warstwy sterowania działającej na wielu maszynach.
kube-apiserver
Serwer API jest składnikiem
warstwy sterowania Kubernetesa, który udostępnia API.
Server API służy jako front-end warstwy sterowania Kubernetes.
Podstawową implementacją serwera API Kubernetesa jest kube-apiserver.
kube-apiserver został zaprojektowany w taki sposób, aby móc skalować się horyzontalnie — to oznacza, że zwiększa swoją wydajność poprzez dodawanie kolejnych instancji.
Można uruchomić kilka instancji kube-apiserver i rozkładać między nimi ruch od klientów.
etcd
Magazyn typu klucz-wartość (key/value store), zapewniający spójność i wysoką dostępność, używany do przechowywania wszystkich danych o klastrze Kubernetes.
Jeśli Twój klaster Kubernetes używa etcd do przechowywania swoich danych, upewnij się, że masz opracowany plan tworzenia
kopii zapasowych tych danych.
Szczegółowe informacje na temat etcd można znaleźć w oficjalnej dokumentacji.
kube-scheduler
Składnik warstwy sterowania, który śledzi tworzenie nowych
podów i przypisuje im węzły,
na których powinny zostać uruchomione.
Przy podejmowaniu decyzji o wyborze węzła brane pod uwagę są wymagania
indywidualne i zbiorcze odnośnie zasobów, ograniczenia wynikające z polityk
sprzętu i oprogramowania, wymagania affinity i anty-affinity, lokalizacja danych,
zależności między zadaniami i wymagania czasowe.
kube-controller-manager
Składnik warstwy sterowania odpowiedzialny za uruchamianie kontrolerów.
Z poziomu podziału logicznego, każdy kontroler jest oddzielnym procesem, ale w celu zmniejszenia złożoności, wszystkie kontrolery są skompilowane do jednego programu binarnego i uruchamiane jako jeden proces.
Przykładowe kontrolery:
Node controller: Odpowiada za rozpoznawanie i reagowanie na sytuacje, kiedy węzeł staje się z jakiegoś powodu niedostępny.
Job controller: Czeka na obiekty typu Job, które definiują zadania uruchamiane jednorazowo
i startuje Pody, odpowiadające za ich wykonanie tych zadań.
EndpointSlice controller: Dostarcza informacji do obiektów typu EndpointSlice (aby zapewnić połaczenie pomiędzy Serwisami i Podami).
ServiceAccount controllers: Tworzy domyślne konta dla nowych przestrzeni nazw (namespaces).
cloud-controller-manager
Element składowy warstwy sterowania Kubernetesa,
który zarządza usługami realizowanymi po stronie chmur obliczeniowych. Cloud controller manager umożliwia
połączenie Twojego klastra z API operatora usług chmurowych i rozdziela składniki operujące na platformie
chmurowej od tych, które dotyczą wyłącznie samego klastra.
cloud-controller-manager uruchamia jedynie kontrolery właściwe dla konkretnego dostawcy usług chmurowych.
Jeśli uruchamiasz Kubernetesa we własnym centrum komputerowym lub w środowisku szkoleniowym na swoim
komputerze, klaster nie będzie miał cloud controller managera.
Podobnie jak w przypadku kube-controller-manager, cloud-controller-manager łączy w jednym pliku binarnym
kilka niezależnych pętli sterowania. Można go skalować horyzontalnie
(uruchomić więcej niż jedną instancję), aby poprawić wydajność lub zwiększyć odporność na awarie.
Następujące kontrolery mogą zależeć od dostawców usług chmurowych:
Node controller: Aby sprawdzić u dostawcy usługi chmurowej, czy węzeł został skasowany po tym, jak przestał odpowiadać
Route controller: Aby ustawić trasy (routes) w niższych warstwach infrastruktury chmurowej
Service controller: Aby tworzyć, aktualizować i kasować cloud load balancers
Składniki węzłów
Składniki węzłów uruchomiane są na każdym węźle. Utrzymują pody w działaniu i ustawiają środowisko uruchomieniowe Kubernetes.
kubelet
Agent, który działa na każdym węźle klastra. Odpowiada za uruchamianie kontenerów w ramach poda.
Kubelet korzysta z dostarczanych (różnymi metodami) PodSpecs i gwarantuje, że kontenery opisane przez te PodSpecs są uruchomione i działają poprawnie. Kubelet nie zarządza kontenerami, które nie zostały utworzone przez Kubernetesa.
kube-proxy
kube-proxy to proxy sieciowe, które uruchomione jest na każdym
węźle klastra
i uczestniczy w tworzeniu
serwisu.
kube-proxy
utrzymuje reguły sieciowe na węźle. Dzięki tym regułom
sieci na zewnątrz i wewnątrz klastra mogą komunikować się
z podami.
kube-proxy używa warstwy filtrowania pakietów dostarczanych przez system operacyjny, o ile taka jest dostępna.
W przeciwnym przypadku, kube-proxy samo zajmuje sie przekazywaniem ruchu sieciowego.
Container runtime
Container runtime to oprogramowanie zajmujące się uruchamianiem kontenerów.
Dodatki korzystają z podstawowych obiektów Kubernetes (DaemonSet, Deployment, itp.), aby rozszerzyć funkcjonalności klastra. Ponieważ są to funkcjonalności obejmujące cały klaster, zasoby te należą do przestrzeni nazw (namespace)kube-system.
Wybrane dodatki opisano poniżej. Rozszerzona lista dostępnych dodatków jest w części Dodatki.
DNS
Mimo, że inne dodatki nie są bezwzględnie wymagane, wszystkie klastry Kubernetes powinny mieć cluster DNS, ponieważ wiele przykładów z niego korzysta.
Cluster DNS to serwer DNS, który uzupełnienia inne serwery DNS z twojego środowiska, dostarczając informacje o rekordach DNS dla usług Kubernetes.
Kontenery uruchomione przez Kubernetes automatycznie przeszukują ten serwer DNS.
Interfejs użytkownika (Dashboard)
Dashboard to webowy interfejs ogólnego zastosowania przeznaczony dla użytkowników klastra Kubernetes. Umożliwia zarządzanie i rozwiązywanie problemów związanych z aplikacjami uruchamianymi na klastrze, a także z samym klastrem.
Monitorowanie zasobów w kontenerach
Container Resource Monitoring zapisuje serie czasowe podstawowych metryk kontenerów w centralnej bazie danych i oferuje interfejs użytkownika do przeglądania tych danych.
Logowanie na poziomie klastra
Mechanizm logowania na poziomie klastra odpowiada za zapisywanie logów pochodzących z poszczególnych kontenerów do wspólnego magazynu, który posiada interfejs do przeglądania i przeszukiwania.
API Kubernetesa służy do odpytywania i zmiany stanu obiektów Kubernetesa. 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.
Sercem warstwy sterowania Kubernetes
jest serwer API. 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 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 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 Kubernetesa udostępnia specyfikację OpenAPI poprzez
ścieżkę /openapi/v2. Aby wybrać format odpowiedzi,
użyj nagłówków żądania zgodnie z tabelą:
Dopuszczalne wartości nagłówka żądania dla zapytań OpenAPI v2
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.
oraz w plikach Interface Definition Language (IDL) dla każdego ze schematów
zamieszczonych w pakietach Go, które definiują obiekty API.
OpenAPI V3
STATUS FUNKCJONALNOŚCI:Kubernetes v1.24 [beta]
Kubernetes v1.31 publikuje (na razie w wersji roboczej) własne API zgodnie ze specyfikacją OpenAPI v3.
Ta funkcjonalność jest w wersji beta i jest domyślnie włączona.
Funkcjonalności w wersji beta można wyłączać poprzez
feature gate o nazwie OpenAPIV3
składnika kube-apiserver.
Pod adresem /openapi/v3 można znaleźć listę wszystkich
dostępnych grup/wersji. Zwracane wartości są dostępne tylko w formacie JSON. Grupy/wersje
opisane są następującym schematem:
Względne adresy URL wskazują na niezmieniające się opisy OpenAPI,
aby umożliwić trzymanie cache po stronie klienta. Serwer API zwraca
również odpowiednie nagłówki HTTP dla cache (Expires ustawione na 1 rok wprzód,
Cache-Control jako immutable). Wysłanie zapytania do nieaktualnego URL
spowoduje przekierowanie przez serwer API do wersji najnowszej.
Serwer API Kubernetesa udostępnia specyfikację OpenAPI v3
pod adresem /openapi/v3/apis/<group>/<version>?hash=<hash>,
zgodnie z podziałem na grupy i wersje.
Tabela poniżej podaje dopuszczalne wartości nagłówków żądania.
Dopuszczalne wartości nagłówka żądania dla zapytań OpenAPI v3
Kubernetes przechowuje serializowany stan swoich obiektów w
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.
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, do czasu aż wersja v1beta1 będzie przestarzała i usunięta.
Wtedy możesz dalej korzystać i modyfikować obiekt poprzez wersję 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.
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.
Informacja:
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.
