To wielostronicowy widok tej sekcji do wydrukowania. Kliknij aby wydrukować.

Wróć do zwykłego widoku tej strony.

Przegląd

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.

Jak zmieniały sie metody wdrożeń

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.

Co dalej?

1 - Składniki Kubernetesa

Omówienie głównych elementów tworzących klaster Kubernetesa.

Ta strona zawiera wysokopoziomy przegląd niezbędnych komponentów, które tworzą klaster Kubernetesa.

Komponenty Kubernetesa

Komponenty klastra Kubernetesa

Składniki Kubernetesa

Klaster Kubernetesa składa się z warstwy sterowania oraz jednego lub więcej węzłów roboczych. Oto krótki przegląd głównych komponentów:

Części składowe warstwy sterowania

Zarządzanie ogólnym stanem klastra:

kube-apiserver
Podstawowy komponent udostępniający interfejs API Kubernetesa przez HTTP
etcd
Stabilna i wysoko dostępna baza danych typu klucz-wartość, wykorzystywana do przechowywania stanu całego klastra Kubernetesa.
kube-scheduler
Wyszukuje Pody, które nie zostały jeszcze przypisane do węzła, i przydziela każdy Pod do odpowiedniego węzła.
kube-controller-manager
Uruchamia kontrolery realizujące logikę działania API Kubernetesa.
cloud-controller-manager (opcjonalne)
Zapewnia integrację klastra Kubernetesa z infrastrukturą dostarczaną przez zewnętrznych dostawców chmurowych.

Składniki węzłów

Działa na każdym węźle klastra, odpowiada za utrzymanie aktywnych podów oraz zapewnienie środowiska uruchomieniowego Kubernetesa:

kubelet
Odpowiada za nadzorowanie, czy pody oraz ich kontenery są uruchomione i działają zgodnie z oczekiwaniami.
kube-proxy (opcjonalne)
Utrzymuje reguły sieciowe na węzłach w celu obsługi komunikacji z usługami (ang. Service).
Środowisko uruchomieniowe kontenerów
Oprogramowanie odpowiedzialne za uruchamianie kontenerów. Przeczytaj Środowiska uruchomieniowe kontenerów, aby dowiedzieć się więcej.

Klaster może wymagać dodatkowego oprogramowania na każdym węźle; możesz na przykład uruchomić systemd na węzłach z systemem Linux do monitorowania i zarządzania lokalnymi usługami.

Dodatki (Addons)

Dodatki rozszerzają funkcjonalność Kubernetesa. Oto kilka ważnych przykładów:

DNS
Umożliwia rozpoznawanie nazw DNS dla usług i komponentów działających w całym klastrze
Web UI (Dashboard)
Umożliwia zarządzanie klastrem Kubernetesa poprzez webowy interfejs.
Monitorowanie zasobów kontenera
Służy do monitorowania zasobów kontenerów poprzez gromadzenie i zapisywanie danych o ich wydajności.
Logowanie na poziomie klastra
Umożliwia zbieranie i przechowywanie logów z kontenerów w centralnym systemie logowania dostępnym na poziomie całego klastra.

Elastyczność architektury

Dzięki elastycznej architekturze Kubernetesa można dostosować sposób wdrażania i zarządzania poszczególnymi komponentami do konkretnych wymagań - od prostych klastrów deweloperskich po złożone systemy produkcyjne na dużą skalę.

Szczegółowe informacje o każdym komponencie oraz różnych sposobach konfiguracji architektury klastra znajdziesz na stronie Architektura klastra.

2 - API Kubernetesa

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
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. 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.33 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:

{
    "paths": {
        ...,
        "api/v1": {
            "serverRelativeURL": "/openapi/v3/api/v1?hash=CC0E9BFD992D8C59AEC98A1E2336F899E8318D3CF4C68944C3DEC640AF5AB52D864AC50DAA8D145B3494F75FA3CFF939FCBDDA431DAD3CA79738B297795818CF"
        },
        "apis/admissionregistration.k8s.io/v1": {
            "serverRelativeURL": "/openapi/v3/apis/admissionregistration.k8s.io/v1?hash=E19CC93A116982CE5422FC42B590A8AFAD92CDE9AE4D59B5CAAD568F083AD07946E6CB5817531680BCE6E215C16973CD39003B0425F3477CFD854E89A9DB6597"
        },
        ....
    }
}

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
Nagłówek Dopuszczalne wartości Uwagi
Accept-Encoding gzip pominięcie tego nagłówka jest dozwolone
Accept application/com.github.proto-openapi.spec.v3@v1.0+protobuf głównie do celu komunikacji wewnątrz klastra
application/json domyślne
* udostępnia application/json

Przechowywanie stanu

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.

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 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.

Zajrzyj do API versions reference po szczegółowe definicje różnych poziomów wersji API.

Rozbudowa API

API Kubernetesa można rozszerzać na dwa sposoby:

  1. Definicje zasobów własnych (custom resources) pozwalają deklaratywnie określać, jak serwer API powinien dostarczać wybrane przez Ciebie zasoby API.
  2. Można także rozszerzać API Kubernetesa implementując warstwę agregacji.

Co dalej?