To wielostronicowy widok tej sekcji do wydrukowania. Kliknij aby wydrukować.
Dokumentacja
- 1: Kubernetes — Dokumentacja
- 2: Od czego zacząć
- 3: Pojęcia
- 3.1: Przegląd
- 3.1.1: Kubernetes — co to jest?
- 3.1.2: Składniki Kubernetesa
- 3.1.3: API Kubernetesa
- 4: Zadania
- 5: Samouczki
- 5.1: Hello Minikube
- 5.2: Naucz się podstaw
- 5.2.1: Tworzenie klastra
- 5.2.1.1: Jak użyć Minikube do stworzenia klastra
- 5.2.1.2: Interaktywny samouczek - Tworzenie klastra
- 5.2.2: Instalowanie aplikacji
- 5.2.2.1: Jak użyć kubectl do tworzenia Deploymentu
- 5.2.2.2: Interaktywny samouczek - Instalacja aplikacji
- 5.2.3: Poznawanie aplikacji
- 5.2.3.1: Pody i Węzły
- 5.2.3.2: Interaktywny samouczek - Poznaj swoją aplikację
- 5.2.4: Udostępnianie aplikacji
- 5.2.4.1: Jak używać Service do udostępniania aplikacji
- 5.2.4.2: Interaktywny samouczek - Udostępnianie aplikacji
- 5.2.5: Skalowanie aplikacji
- 5.2.5.1: Uruchamianie wielu instancji aplikacji
- 5.2.5.2: Interaktywny samouczek - Skalowanie aplikacji
- 5.2.6: Aktualizowanie aplikacji
- 5.2.6.1: Aktualizacje Rolling Update
- 5.2.6.2: Interaktywny samouczek - Aktualizowanie aplikacji
- 6: Materiały źródłowe
- 6.1: Słownik
- 7: Współtwórz dokumentację K8s
- 8:
1 - Kubernetes — Dokumentacja
1.1 - Dostępne wersje dokumentacji
Ten serwis zawiera dokumentację do bieżącej i czterech poprzednich wersji Kubernetesa.
2 - Od czego zacząć
Ten rozdział poświęcony jest różnym metodom konfiguracji i uruchomienia Kubernetesa. Instalując Kubernetesa, przy wyborze platformy kieruj się: łatwością w utrzymaniu, spełnianymi wymogami bezpieczeństwa, poziomem sterowania, dostępnością zasobów oraz doświadczeniem wymaganym do zarządzania klastrem.
Możesz pobrać Kubernetesa, aby zainstalować klaster na lokalnym komputerze, w chmurze czy w prywatnym centrum obliczeniowym.
Jeśli nie chcesz zarządzać klastrem Kubernetesa samodzielnie, możesz wybrać serwis zarządzany przez zewnętrznego dostawcę, wybierając na przykład spośród certyfikowanych platform. Dostępne są także inne standardowe i specjalizowane rozwiązania dla różnych środowisk chmurowych bądź bazujące bezpośrednio na sprzęcie fizycznym.
Środowisko do nauki
Do nauki Kubernetesa wykorzystaj narzędzia wspierane przez społeczność Kubernetesa lub inne narzędzia dostępne w ekosystemie, aby uruchomić klaster Kubernetesa na swoim komputerze lokalnym. Zapoznaj się z narzędziami instalacyjnymi.
Środowisko produkcyjne
Wybierając rozwiązanie dla środowiska produkcyjnego musisz zdecydować, którymi poziomami zarządzania klastrem (abstrakcjami) chcesz zajmować się sam, a które będą realizowane po stronie zewnętrznego operatora.
Do instalacji klastra Kubernetesa zarządzanego samodzielnie oficjalnym narzędziem jest kubeadm.
Co dalej?
- Pobierz Kubernetesa
- Pobierz i zainstaluj narzędzia, w tym
kubectl
- Wybierz środowisko uruchomieniowe dla kontenerów w nowym klastrze
- Naucz się najlepszych praktyk przy konfigurowaniu klastra
Na stronie Partnerów Kubernetesa znajdziesz listę dostawców posiadających certyfikację Kubernetes.
Kubernetes zaprojektowano w ten sposób, że warstwa sterowania wymaga do działania systemu Linux. W ramach klastra aplikacje mogą być uruchamiane na systemie Linux i innych, w tym Windows.
- Naucz się, jak zbudować klaster z węzłami Windows
3 - Pojęcia
Rozdział dotyczący pojęć ma za zadanie pomóc w zrozumieniu poszczególnych składowych systemu oraz obiektów abstrakcyjnych, których Kubernetes używa do reprezentacji klastra, a także posłużyć do lepszego poznania działania całego systemu.
3.1 - Przegląd
3.1.1 - Kubernetes — co to jest?
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. Serwisy Kubernetesa, wsparcie i narzędzia są szeroko dostępne.
Nazwa Kubernetes pochodzi z greki 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ła uruchamianie wielu maszyn wirtualnych (VM) na jednym procesorze fizycznego serwera. Wirtualizacja pozwalała izolować aplikacje pomiędzy maszynami wirtualnymi i osiągnąć pewien poziom bezpieczeństwa, jako że informacje związane z jedną aplikacją nie były 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 nie są związane z leżącymi poniżej warstwami 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. Wycofywanie zmian jest skuteczne i szybkie (ponieważ obrazy są niezmienne).
- Rozdzielenie zadań Dev i Ops: obrazy kontenerów powstają w fazie build/release, 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ć, inny musi zostać uruchomiony. Nie byłoby prościej, aby takimi działaniami zajmował się jakiś system?
I tu właśnie Kubernetes przychodzi z pomocą! Kubernetes dostarcza ś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 i 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?
- Dowiedz się o komponentach Kubernetesa
- Jesteś gotowy zacząć pracę?
3.1.2 - Składniki Kubernetesa
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 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 i 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 wirtualnych.
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ń.
- Endpoints controller: Dostarcza informacji do obiektów typu Endpoints (tzn. łączy ze sobą Serwisy i Pody).
- Service Account & Token controllers: Tworzy domyślne konta i tokeny dostępu API 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.
Kubernetes obsługuje różne container runtimes: containerd, CRI-O oraz każdą implementację zgodną z Kubernetes CRI (Container Runtime Interface).
Dodatki (Addons)
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.
Co dalej?
- Więcej o Węzłach
- Więcej o Kontrolerach
- Więcej o kube-scheduler
- Oficjalna dokumentacja etcd
3.1.3 - API Kubernetesa
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ą:
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
Kubernetes v1.23 [alpha]
Kubernetes v1.23 umożliwia (na razie w we wczesnej wersji roboczej) publikowanie swojego API jako OpenAPI v3.
Ta funkcjonalność jest w wersji alfa i jest domyślnie wyłączona.
Funkcjonalności w wersji alfa można włączać poprzez
feature gate o nazwie OpenAPIV3
składnika kube-apiserver.
Po włączeniu tej funkcjonalności, serwer API Kubernetesa udostępnia
zagregowaną specyfikację OpenAPI v3 dla odpowiednich grup i wersji poprzez ścieżkę
/openapi/v3/apis/<group>/<version>
. Tabela poniżej podaje dopuszczalne wartości
nagłówków żądania.
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 |
Poprzez ścieżkę /openapi/v3
można wyświetlić pełną listę
dostępnych grup i wersji. Formatem odpowiedzi jest tylko 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
.
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:
- Definicje zasobów własnych (custom resources) pozwalają deklaratywnie określać, jak serwer API powinien dostarczać wybrane przez Ciebie zasoby API.
- Można także rozszerzać API Kubernetesa implementując warstwę agregacji.
Co dalej?
- Naucz się, jak rozbudowywać API Kubernetesa poprzez dodawanie własnych CustomResourceDefinition.
- Controlling Access To The Kubernetes API 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.
- Aby dowiedzieć się, jaki rodzaj zmian można określić jako zgodne i jak zmieniać API, zajrzyj do API changes.
4 - Zadania
W tej części dokumentacji Kubernetesa znajdują się opisy sposobu realizacji różnych zadań. Przedstawione są one zazwyczaj jako krótka sekwencja kilku kroków związanych z pojedynczym zadaniem.
Jeśli chciałbyś stworzyć nową stronę poświęconą jakiemuś zadaniu, przeczytaj Jak przygotować propozycję zmian (PR).
5 - Samouczki
W tym rozdziale dokumentacji Kubernetes znajdziesz różne samouczki. Dzięki nim dowiesz się, jak osiągnąć złożone cele, które przekraczają wielkość pojedynczego zadania. Typowy samouczek podzielony jest na kilka części, z których każda zawiera sekwencję odpowiednich kroków. Przed zapoznaniem się z samouczkami warto stworzyć zakładkę do słownika, aby móc się później do niego na bieżąco odwoływać.
Podstawy
-
Podstawy Kubernetesa (PL) to interaktywny samouczek, który pomoże zrozumieć system Kubernetes i wypróbować jego podstawowe możliwości.
-
Hello Minikube (PL)
Konfiguracja
Aplikacje bezstanowe (Stateless Applications)
Aplikacje stanowe (Stateful Applications)
Serwisy
Bezpieczeństwo
- Apply Pod Security Standards at Cluster level
- Apply Pod Security Standards at Namespace level
- AppArmor
- seccomp
Co dalej?
Jeśli chciałbyś napisać nowy samouczek, odwiedź Content Page Types, gdzie znajdziesz dodatkowe informacje o tym typie strony.
5.1 - Hello Minikube
Ten samouczek pokaże, jak uruchomić przykładową aplikację na Kubernetesie przy użyciu minikube oraz Katacoda. Katacoda to darmowe środowisko Kubernetes dostępne bezpośrednio z przeglądarki web.
Cele
- Skonfiguruj przykładową aplikację do uruchomienia w minikube.
- Uruchom aplikację.
- Przejrzyj jej logi.
Nim zaczniesz
W tym samouczku wykorzystamy obraz kontenera, który korzysta z NGINX, aby wyświetlić z powrotem wszystkie przychodzące zapytania.
Stwórz klaster minikube
-
Kliknij w Launch Terminal
Informacja: Jeśli masz minikube zainstalowane lokalnie, uruchomminikube start
. Przed uruchomieniemminikube dashboard
, otwórz okno nowego terminala, uruchom w nimminikube dashboard
i przełącz się z powrotem do okna głównego terminala. -
Otwórz panel Kubernetesa w przeglądarce:
minikube dashboard
-
Tylko w Katacoda: Na górze okienka z terminalem kliknij na znak plus, a następnie wybierz Select port to view on Host 1.
-
Tylko w Katacoda: Wpisz
30000
i kliknij Display Port.
Polecenie dashboard
uruchamia dodatek panelu i otwiera proxy w domyślnej przeglądarce.
W panelu można tworzyć różne obiekty Kubernetesa, takie jak Deployment czy Serwis.
Jeśli pracujesz z uprawnieniami roota, skorzystaj z: Otwieranie panelu poprzez URL.
Panel jest domyślnie dostępny jedynie z wewnętrznej sieci Kubernetesa.
Polecenie dashboard
tworzy tymczasowe proxy, które udostępnia panel także poza tą wewnętrzną sieć.
Aby zatrzymać proxy, wciśnij Ctrl+C
i zakończ proces.
Panel ciągle działa na klastrze Kubernetesa, nawet po przerwaniu działania proxy.
Aby dostać się ponownie do panelu, trzeba stworzyć kolejne proxy poleceniem dashboard
.
Otwieranie panelu poprzez URL
Jeśli nie chcesz otwierać przeglądarki, uruchom panel z opcją --url
, aby wyświetlić URL:
minikube dashboard --url
Stwórz Deployment
Pod w Kubernetesie to grupa jednego lub wielu kontenerów połączonych ze sobą na potrzeby administrowania i dostępu sieci. W tym samouczku Pod zawiera tylko jeden kontener. Deployment w Kubernetesie monitoruje stan twojego Poda i restartuje należące do niego kontenery, jeśli z jakichś powodów przestaną działać. Użycie Deploymentu to rekomendowana metoda zarządzania tworzeniem i skalowaniem Podów.
-
Użyj polecenia
kubectl create
do stworzenia Deploymentu, który będzie zarządzał Podem. Pod uruchamia kontener wykorzystując podany obraz Dockera.kubectl create deployment hello-node --image=k8s.gcr.io/echoserver:1.4
-
Sprawdź stan Deploymentu:
kubectl get deployments
Wynik powinien wyglądać podobnie do:
NAME READY UP-TO-DATE AVAILABLE AGE hello-node 1/1 1 1 1m
-
Sprawdź stan Poda:
kubectl get pods
Wynik powinien wyglądać podobnie do:
NAME READY STATUS RESTARTS AGE hello-node-5f76cf6ccf-br9b5 1/1 Running 0 1m
-
Obejrzyj zdarzenia na klastrze:
kubectl get events
-
Sprawdź konfigurację
kubectl
:kubectl config view
Informacja: Więcej informacji na temat poleceniakubectl
znajdziesz w przeglądzie kubectl.
Stwórz Serwis
Domyślnie Pod jest dostępny tylko poprzez swój wewnętrzny adres IP
wewnątrz klastra Kubernetes. Aby kontener hello-node
był osiągalny spoza
wirtualnej sieci Kubernetesa, musisz najpierw udostępnić Pod
jako Serwis Kubernetes.
-
Udostępnij Pod w Internecie przy pomocy polecenia
kubectl expose
:kubectl expose deployment hello-node --type=LoadBalancer --port=8080
Opcja
--type=LoadBalancer
wskazuje, że chcesz udostępnić swój Serwis na zewnątrz klastra.Aplikacja, która jest umieszczona w obrazie kontenera
k8s.gcr.io/echoserver
, nasłuchuje jedynie na porcie TCP 8080. Jeśli użyłeśkubectl expose
do wystawienia innego portu, aplikacje klienckie mogą nie móc się podłączyć do tamtego innego portu. -
Sprawdź Serwis, który właśnie utworzyłeś:
kubectl get services
Wynik powinien wyglądać podobnie do:
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE hello-node LoadBalancer 10.108.144.78 <pending> 8080:30369/TCP 21s kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 23m
U dostawców usług chmurowych, którzy obsługują load balancers, zostanie przydzielony zewnętrzny adres IP na potrzeby serwisu. W minikube, typ
LoadBalancer
udostępnia serwis poprzez polecenieminikube service
. -
Uruchom poniższe polecenie:
minikube service hello-node
-
Tylko w Katacoda: Kliknij znak plus, a następnie Select port to view on Host 1.
-
Tylko w Katacoda: Wpisz
30369
(sprawdź numer portu obok8080
w opisie Serwisu) i kliknij Display PortOtworzy sie okno przeglądarki obsługującej twoją aplikację i wyświetli odpowiedź tej aplikacji.
Włącz dodatki
Narzędzie minikube dysponuje zestawem wbudowanych dodatków, które mogą być włączane, wyłączane i otwierane w lokalnym środowisku Kubernetes.
-
Lista aktualnie obsługiwanych dodatków:
minikube addons list
Wynik powinien wyglądać podobnie do:
addon-manager: enabled dashboard: enabled default-storageclass: enabled efk: disabled freshpod: disabled gvisor: disabled helm-tiller: disabled ingress: disabled ingress-dns: disabled logviewer: disabled metrics-server: disabled nvidia-driver-installer: disabled nvidia-gpu-device-plugin: disabled registry: disabled registry-creds: disabled storage-provisioner: enabled storage-provisioner-gluster: disabled
-
Włącz dodatek, na przykład
metrics-server
:minikube addons enable metrics-server
Wynik powinien wyglądać podobnie do:
The 'metrics-server' addon is enabled
-
Sprawdź Pody i Serwisy, który właśnie stworzyłeś:
kubectl get pod,svc -n kube-system
Wynik powinien wyglądać podobnie do:
NAME READY STATUS RESTARTS AGE pod/coredns-5644d7b6d9-mh9ll 1/1 Running 0 34m pod/coredns-5644d7b6d9-pqd2t 1/1 Running 0 34m pod/metrics-server-67fb648c5 1/1 Running 0 26s pod/etcd-minikube 1/1 Running 0 34m pod/influxdb-grafana-b29w8 2/2 Running 0 26s pod/kube-addon-manager-minikube 1/1 Running 0 34m pod/kube-apiserver-minikube 1/1 Running 0 34m pod/kube-controller-manager-minikube 1/1 Running 0 34m pod/kube-proxy-rnlps 1/1 Running 0 34m pod/kube-scheduler-minikube 1/1 Running 0 34m pod/storage-provisioner 1/1 Running 0 34m NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/metrics-server ClusterIP 10.96.241.45 <none> 80/TCP 26s service/kube-dns ClusterIP 10.96.0.10 <none> 53/UDP,53/TCP 34m service/monitoring-grafana NodePort 10.99.24.54 <none> 80:30002/TCP 26s service/monitoring-influxdb ClusterIP 10.111.169.94 <none> 8083/TCP,8086/TCP 26s
-
Wyłącz dodatek
metrics-server
:minikube addons disable metrics-server
Wynik powinien wyglądać podobnie do:
metrics-server was successfully disabled
Porządkujemy po sobie
Teraz jest czas na wyczyszczenie zasobów, które utworzyłeś w klastrze:
kubectl delete service hello-node
kubectl delete deployment hello-node
(Opcjonalnie) Zatrzymaj wirtualną maszynę Minikube (VM):
minikube stop
(Opcjonalnie) Skasuj Minikube VM:
minikube delete
Co dalej?
- Dowiedz się więcej o obiektach typu Deployment.
- Dowiedz się więcej o instalowaniu aplikacji.
- Dowiedz się więcej o obiektach typu Serwis.
5.2 - Naucz się podstaw
Podstawy Kubernetesa
Ten samouczek poprowadzi Cię przez podstawy systemu zarządzania zadaniami na klastrze Kubernetes. W każdym module znajdziesz najważniejsze informacje o głównych pojęciach i funkcjonalnościach Kubernetes oraz interaktywny samouczek online. Dzięki samouczkom nauczysz się zarządzać prostym klasterem i skonteneryzowanymi aplikacjami uruchamianymi na tym klastrze.
Nauczysz się, jak:
- Zainstalować skonteneryzowaną aplikację na klastrze.
- Wyskalować tę instalację.
- Zaktualizować aplikację do nowej wersji.
- Rozwiązywać problemy z aplikacją.
Ten samouczek korzysta z Katacoda do uruchomienia wirtualnego terminalu w przeglądarce. W terminalu dostępny jest Minikube, niewielka lokalna instalacja Kubernetes, która może być uruchamiana z dowolnego miejsca. Nie ma konieczności instalowania ani konfigurowania żadnego oprogramowania. Każdy z interaktywnych samouczków jest wykonywany bezpośrednio w przeglądarce.
Co Kubernetes może dla Ciebie zrobić?
Użytkownicy oczekują od współczesnych serwisów internetowych dostępności non-stop, a deweloperzy chcą móc instalować nowe wersje swoich serwisów kilka razy dziennie. Używając kontenerów można przygotowywać oprogramowanie w taki sposób, aby mogło być instalowane i aktualizowane nie powodując żadnych przestojów. Kubernetes pomaga uruchamiać te aplikacje w kontenerach tam, gdzie chcesz i kiedy chcesz i znajdować niezbędne zasoby i narzędzia wymagane do ich pracy. Kubernetes może działać w środowiskach produkcyjnych, jest otwartym oprogramowaniem zaprojektowanym z wykorzystaniem nagromadzonego przez Google doświadczenia w zarządzaniu kontenerami, w połączeniu z najcenniejszymi ideami społeczności.
5.2.1 - Tworzenie klastra
Poznaj klaster Kubernetesa i naucz się, jak stworzyć jego prostą wersję przy pomocy Minikube.
5.2.1.1 - Jak użyć Minikube do stworzenia klastra
Cele
- Nauczyć się, czym jest klaster Kubernetes.
- Nauczyć się, czym jest Minikube.
- Uruchomić klaster Kubernetes przy pomocy terminala online.
Klaster Kubernetes
Zadaniem Kubernetesa jest zarządzanie klastrem komputerów o wysokiej dostępności, działającego jako jedna całość. Kubernetes, poprzez swój system obiektów abstrakcyjnych, umożliwia uruchamianie aplikacji w kontenerach bez przypisywania ich do konkretnej maszyny. Aby móc korzystać z tego nowego modelu instalacji, aplikacje muszą być przygotowane w taki sposób, aby były niezależne od konkretnego serwera: muszą być skonteneryzowane. Aplikacje w kontenerach są bardziej elastyczne przy instalacji, niż to miało miejsce w poprzednich modelach, kiedy aplikacje były instalowane bezpośrednio na konkretne maszyny jako pakiety ściśle powiązane z tą maszyną. Kubernetes automatyzuje dystrybucję i zlecanie uruchamiania aplikacji na klastrze w bardziej efektywny sposób. Kubernetes jest platformą otwartego oprogramowania, gotowym do pracy w środowiskach produkcyjnych.
Klaster Kubernetes składa się z dwóch rodzajów zasobów:
- Warstwa sterowania koordynuje działanie klastra
- Na węzłach (nodes) uruchamiane są aplikacje
Podsumowanie:
- Klaster Kubernetes
- Minikube
Kubernetes to platforma oprogramowania typu open source, gotowa do pracy w środowiskach produkcyjnych, która zarządza rozmieszczeniem i uruchomieniem kontenerów zawierających aplikacje na klastrach komputerowych.
Schemat klastra
Warstwa sterowania odpowiada za zarządzanie klastrem. Warstwa sterowania koordynuje wszystkie działania klastra, takie jak zlecanie uruchomienia aplikacji, utrzymywanie pożądanego stanu aplikacji, skalowanie aplikacji i instalowanie nowych wersji.
Węzeł to maszyna wirtualna (VM) lub fizyczny serwer, który jest maszyną roboczą w klastrze Kubernetes. Na każdym węźle działa Kubelet, agent zarządzający tym węzłem i komunikujący się z warstwą sterowania Kubernetesa. Węzeł zawiera także narzędzia do obsługi kontenerów, takie jak containerd lub Docker. Klaster Kubernetes w środowisku produkcyjnym powinien składać się minimum z trzech węzłów, ponieważ w przypadku awarii jednego węzła traci się zarówno element etcd, jak i warstwy sterowania i w ten sposób minimalną nadmiarowość (redundancy). Dodanie kolejnych węzłów warstwy sterowania może temu zapobiec.
Warstwa sterowania zarządza klastrem i węzłami wykorzystywanymi do uruchamiania aplikacji.
Kiedy instalujesz aplikację na Kubernetesie, zlecasz warstwie sterowania uruchomienie kontenera z aplikacją. Warstwa sterowania zleca uruchomienie kontenera na węzłach klastra. Węzły komunikują się z warstwą sterowania przy użyciu API Kubernetesa, udostępnianego poprzez warstwę sterowania. Użytkownicy końcowi mogą korzystać bezpośrednio z API Kubernetesa do komunikacji z klastrem.
Klaster Kubernetes może być zainstalowany zarówno na fizycznych, jak i na maszynach wirtualnych. Aby wypróbować Kubernetesa, można też wykorzystać Minikube. Minikube to "lekka" implementacja Kubernetesa, która tworzy VM na maszynie lokalnej i instaluje prosty klaster składający się tylko z jednego węzła. Minikube jest dostępny na systemy Linux, macOS i Windows. Narzędzie linii poleceń Minikube obsługuje podstawowe operacje na klastrze, takie jak start, stop, prezentacja informacji jego stanie i usunięcie klastra. Na potrzeby tego samouczka wykorzystamy jednak terminal online z zainstalowanym już wcześniej Minikube.
Teraz, kiedy już wiesz, co to jest Kubernetes, przejdźmy do samouczka online i stwórzmy nasz pierwszy klaster!
5.2.1.2 - Interaktywny samouczek - Tworzenie klastra
5.2.2 - Instalowanie aplikacji
5.2.2.1 - Jak użyć kubectl do tworzenia Deploymentu
Cele
- Nauczyć się jak działa Deployment dla aplikacji.
- Zainstalować pierwszą aplikację używając kubectl.
Instalacje w Kubernetes
Mając działający klaster Kubernetes, można na nim zacząć instalować aplikacje. W tym celu należy skonfigurować Deployment. Deployment informuje Kubernetesa, jak tworzyć i aktualizować instancje Twojej aplikacji. Po stworzeniu Deploymentu, węzeł master Kubernetesa zleca uruchomienie tej aplikacji na indywidualnych węzłach klastra.
Po utworzeniu instancji aplikacji, Kubernetes Deployment Controller na bieżąco monitoruje te instancje. Jeśli węzeł, na którym działała jedna z instancji ulegnie awarii lub zostanie usunięty, Deployment Controller zamieni tę instancję z instancją na innym węźle klastra. W ten sposób działa samo naprawiający się mechanizm, który reaguje na awarie lub wyłączenia maszyn w klastrze.
W czasach przed wprowadzeniem takiej automatyzacji, skrypty instalacyjne używane były zazwyczaj do uruchomienia aplikacji, ale nie radziły sobie z awariami maszyn. Poprzez połączenie procesu instalacji i kontroli nad działaniem aplikacji na węzłach, Deployment Kubernetes oferuje fundamentalnie różne podejście do zarządzania aplikacjami.
Podsumowanie:
- Deployments
- Kubectl
Deployment odpowiada za stworzenie i aktualizacje instancji Twojej aplikacji
Instalacja pierwszej aplikacji w Kubernetes
Do tworzenia i zarządzaniem Deploymentem służy polecenie linii komend, Kubectl. Kubectl używa Kubernetes API do komunikacji z klasterem. W tym module nauczysz się najczęściej używanych poleceń Kubectl niezbędnych do stworzenia Deploymentu, który uruchomi Twoje aplikacje na klastrze Kubernetes.
Tworząc Deployment musisz określić obraz kontenera oraz liczbę replik, które mają być uruchomione. Te ustawienia możesz zmieniać później, aktualizując Deployment. Moduły 5 oraz 6 omawiają skalowanie i aktualizowanie Deploymentów.
Aby aplikacja mogła zostać uruchomiona w Kubernetes, musi być opakowana w jeden z obsługiwanych formatów kontenerów
Na potrzeby pierwszej instalacji użyjesz aplikacji hello-node zapakowaną w kontener Docker-a, która korzysta z NGINXa i powtarza wszystkie wysłane do niej zapytania. (Jeśli jeszcze nie próbowałeś stworzyć aplikacji hello-node i uruchomić za pomocą kontenerów, możesz spróbować teraz, kierując się instrukcjami samouczka Hello Minikube).
Teraz, kiedy wiesz, czym są Deploymenty, przejdźmy do samouczka online, żeby zainstalować naszą pierwszą aplikację!
5.2.2.2 - Interaktywny samouczek - Instalacja aplikacji
Pod to podstawowy element odpowiedzialny za uruchomienie aplikacji na Kubernetesie. Każdy pod to część składowa całościowego obciążenia Twojego klastra. Dowiedz się więcej na temat Podów.
5.2.3 - Poznawanie aplikacji
5.2.3.1 - Pody i Węzły
Cele
- Poznać Pody Kubernetes.
- Poznać węzły Kubernetes.
- Nauczyć się rozwiązywać problemy z aplikacjami.
Pody Kubernetes
Po stworzeniu Deploymentu w Module 2, Kubernetes stworzył Pod, który "przechowuje" instancję Twojej aplikacji. Pod jest obiektem abstrakcyjnym Kubernetes, który reprezentuje grupę jednego bądź wielu kontenerów (jak np. Docker) wraz ze wspólnymi zasobami dla tych kontenerów. Zasobami mogą być:
- Współdzielona przestrzeń dyskowa, np. Volumes
- Zasoby sieciowe, takie jak unikatowy adres IP klastra
- Informacje służące do uruchamiania każdego z kontenerów ⏤ wersja obrazu dla kontenera lub numery portów, które mają być użyte
Pod tworzy model specyficznego dla aplikacji "wirtualnego serwera" i może zawierać różne kontenery aplikacji, które są relatywnie blisko powiązane. Przykładowo, pod może zawierać zarówno kontener z Twoją aplikacją w Node.js, jak i inny kontener dostarczający dane, które mają być opublikowane przez serwer Node.js. Kontenery wewnątrz poda współdzielą adres IP i przestrzeń portów, zawsze są uruchamiane wspólnie w tej samej lokalizacji i współdzielą kontekst wykonawczy na tym samym węźle.
Pody są niepodzielnymi jednostkami na platformie Kubernetes. W trakcie tworzenia Deploymentu na Kubernetes, Deployment tworzy Pody zawierające kontenery (w odróżnieniu od tworzenia kontenerów bezpośrednio). Każdy Pod związany jest z węzłem, na którym zostało zlecone jego uruchomienie i pozostaje tam aż do jego wyłączenia (zgodnie z polityką restartowania) lub skasowania. W przypadku awarii węzła, identyczny pod jest skierowany do uruchomienia na innym węźle klastra.
Podsumowanie:
- Pody
- Węzły
- Główne polecenia Kubectl
Pod to grupa jednego lub wielu kontenerów aplikacji (jak np. Docker) zawierających współdzieloną przestrzeń dyskową (volumes), adres IP i informacje, jak mają być uruchamiane.
Schemat ogólny podów
Węzły
Pod jest uruchamiany na węźle (Node). Węzeł jest maszyną roboczą, fizyczną lub wirtualną, w zależności od klastra. Każdy z węzłów jest zarządzany przez warstwę sterowania (Control Plane). Węzeł może zawierać wiele podów. Warstwa sterowania Kubernetesa automatycznie zleca uruchomienie podów na różnych węzłach w ramach klastra. Automatyczne zlecanie uruchomienia bierze pod uwagę zasoby dostępne na każdym z węzłów.
Na każdym węźle Kubernetes działają co najmniej:
- Kubelet, proces odpowiedzialny za komunikację pomiędzy warstwą sterowania Kubernetesa i węzłami; zarządza podami i kontenerami działającymi na maszynie.
- Proces wykonawczy kontenera (np. Docker), który zajmuje się pobraniem obrazu dla kontenera z repozytorium, rozpakowaniem kontenera i uruchomieniem aplikacji.
Kontenery powinny być uruchamiane razem w jednym podzie, jeśli są ściśle ze sobą związane i muszą współdzielić zasoby, np. dysk.
Schemat węzła
Rozwiązywanie problemów przy pomocy kubectl
W module 2 używałeś narzędzia Kubectl. W module 3 będziemy go nadal używać, aby wydobyć informacje na temat zainstalowanych aplikacji i środowiska, w jakim działają. Najczęstsze operacje przeprowadzane są przy pomocy następujących poleceń kubectl:
- kubectl get - wyświetl informacje o zasobach
- kubectl describe - pokaż szczegółowe informacje na temat konkretnego zasobu
- kubectl logs - wyświetl logi z kontenera w danym podzie
- kubectl exec - wykonaj komendę wewnątrz kontenera w danym podzie
Korzystaj z tych poleceń, aby sprawdzić, kiedy aplikacja została zainstalowana, jaki jest jej aktualny status, gdzie jest uruchomiona i w jakiej konfiguracji.
Kiedy już wiemy więcej na temat części składowych klastra i podstawowych poleceń, przyjrzyjmy się naszej aplikacji.
Węzeł jest maszyną roboczą Kubernetes - fizyczną lub wirtualną, zależnie od klastra. Wiele podów może być uruchomionych na tym samym węźle.
5.2.3.2 - Interaktywny samouczek - Poznaj swoją aplikację
5.2.4 - Udostępnianie aplikacji
5.2.4.1 - Jak używać Service do udostępniania aplikacji
Cele
- Poznać Serwis w Kubernetesie
- Zrozumieć, jak obiekty Label i LabelSelector są powiązane z Serwisem
- Udostępnić aplikację na zewnątrz klastra Kubernetes korzystając z Serwisu
Kubernetes Services - przegląd
Pody Kubernetes są nietrwałe. Pody mają swój cykl życia. Jeśli węzeł roboczy ulegnie awarii, tracone są wszystkie pody działające na węźle. ReplicaSet będzie próbował automatycznie doprowadzić klaster z powrotem do pożądanego stanu tworząc nowe pody i w ten sposób zapewnić działanie aplikacji. Innym przykładem może być system na back-endzie przetwarzania obrazów posiadający 3 repliki. Każda z tych replik jest wymienna - system front-endu nie powinien musieć pilnować replik back-endu ani tego, czy któryś z podów przestał działać i został odtworzony na nowo. Nie należy jednak zapominać o tym, że każdy Pod w klastrze Kubernetes ma swój unikatowy adres IP, nawet pody w obrębie tego samego węzła, zatem powinna istnieć metoda automatycznego uzgadniania zmian pomiędzy podami, aby aplikacja mogła dalej funkcjonować.
Serwis w Kubernetes jest abstrakcyjnym obiektem, która definiuje logiczny zbiór podów oraz politykę dostępu do nich. Serwisy pozwalają na swobodne łączenie zależnych podów. Serwis jest zdefiniowany w YAMLu (zalecane) lub w JSONie - tak, jak wszystkie obiekty Kubernetes. Zbiór podów, które obsługuje Serwis, jest zazwyczaj określany przez LabelSelector (poniżej opisane jest, w jakich przypadkach możesz potrzebować zdefiniować Serwis bez specyfikowania selektora
).
Mimo, że każdy pod ma swój unikatowy adres IP, te adresy nie są dostępne poza klastrem, o ile nie zostaną wystawione za pomocą Serwisu. Serwis umożliwia aplikacji przyjmować ruch przychodzący. Serwisy mogą być wystawiane na zewnątrz na kilka różnych sposobów, poprzez określenie typu
w ServiceSpec:
- ClusterIP (domyślnie) - Wystawia serwis poprzez wewnętrzny adres IP w klastrze. W ten sposób serwis jest dostępny tylko wewnątrz klastra.
- NodePort - Wystawia serwis na tym samym porcie na każdym z wybranych węzłów klastra przy pomocy NAT. W ten sposób serwis jest dostępny z zewnątrz klastra poprzez
<NodeIP>:<NodePort>
. Nadzbiór ClusterIP. - LoadBalancer - Tworzy zewnętrzny load balancer u bieżącego dostawcy usług chmurowych (o ile jest taka możliwość) i przypisuje serwisowi stały, zewnętrzny adres IP. Nadzbiór NodePort.
- ExternalName - Przypisuje Service do
externalName
(np.foo.bar.example.com
), zwracając rekordCNAME
wraz z zawartością. W tym przypadku nie jest wykorzystywany proces przekierowania ruchu metodą proxy. Ta metoda wymagakube-dns
w wersji v1.7 lub wyższej lub CoreDNS w wersji 0.0.8 lub wyższej.
Więcej informacji na temat różnych typów serwisów znajduje się w samouczku Używanie adresu źródłowego (Source IP). Warto też zapoznać się z Łączeniem Aplikacji z Serwisami.
W pewnych przypadkach w serwisie nie specyfikuje się selector
. Serwis, który został stworzony bez pola selector
, nie utworzy odpowiedniego obiektu Endpoints. W ten sposób użytkownik ma możliwość ręcznego przyporządkowania serwisu do konkretnych endpoints. Inny przypadek, kiedy nie używa się selektora, ma miejsce, kiedy stosujemy type: ExternalName
.
Podsumowanie
- Otwarcie Poda na ruch z zewnątrz
- Rozkładanie ruchu pomiędzy poszczególne Pody
- Używanie etykiet
Serwis Kubernetesa to warstwa abstrakcji, która definiuje logiczny zbiór Podów i umożliwia kierowanie ruchu przychodzącego do Podów, jego równoważenie oraz service discovery.
Sewisy i Etykiety (Labels)
Serwis kieruje przychodzący ruch do grupy Podów. Serwisy są obiektami abstrakcyjnymi, dzięki którym pody mogą się psuć i być zastępowane przez Kubernetes nowymi bez ujemnego wpływu na działanie twoich aplikacji. Detekcją nowych podów i kierowaniem ruchu pomiędzy zależnymi podami (takimi, jak składowe front-end i back-end w aplikacji) zajmują się Serwisy Kubernetes.
Serwis znajduje zestaw odpowiednich Podów przy pomocy etykiet i selektorów, podstawowych jednostek grupujących, które umożliwiają operacje logiczne na obiektach Kubernetes. Etykiety to pary klucz/wartość przypisane do obiektów. Mogą być używane na różne sposoby:
- Dzielić obiekty na deweloperskie, testowe i produkcyjne
- Osadzać znaczniki (tags)określające wersje
- Klasyfikować obiekty przy użyciu znaczników
Obiekty mogą być oznaczane etykietami w momencie tworzenia lub później. Etykiety mogą być zmienianie w dowolnej chwili. Udostępnijmy teraz naszą aplikację przy użyciu Serwisu i oznaczmy ją odpowiednimi etykietami.
5.2.4.2 - Interaktywny samouczek - Udostępnianie aplikacji
5.2.5 - Skalowanie aplikacji
5.2.5.1 - Uruchamianie wielu instancji aplikacji
Cele
- Wyskaluj aplikację przy użyciu kubectl.
Skalowanie aplikacji
W poprzednim module stworzyliśmy Deployment i udostępniliśmy go publicznie korzystając z Serwisu. Deployment utworzył tylko jeden Pod, w którym uruchomiona jest nasza aplikacja. Wraz ze wzrostem ruchu, będziemy musieli wyskalować aplikację, aby była w stanie obsłużyć zwiększone zapotrzebowanie użytkowników.
Skalowanie polega na zmianie liczby replik w Deploymencie.
Podsumowanie:
- Skalowanie Deploymentu
Od samego początku w ramach Deploymentu można uruchomić wiele instancji — skorzystaj z parametru --replicas polecenia kubectl create deployment
Ogólnie o skalowaniu
Kiedy zwiększamy skalę Deploymentu, uruchomienie nowych Podów jest zlecane na Węzłach, które posiadają odpowiednio dużo zasobów. Operacja skalowania zwiększy liczbę Podów do oczekiwanej wartości. W Kubernetes możliwe jest również autoskalowanie Podów, ale jest ono poza zakresem niniejszego samouczka. Istnieje także możliwość skalowania do zera — w ten sposób zatrzymane zostaną wszystkie Pody należące do konkretnego Deploymentu.
Kiedy działa jednocześnie wiele instancji jednej aplikacji, należy odpowiednio rozłożyć ruch pomiędzy każdą z nich. Serwisy posiadają zintegrowany load-balancer, który dystrybuuje ruch na wszystkie Pody w Deployment wystawionym na zewnątrz. Serwis prowadzi ciągły monitoring Podów poprzez ich punkty dostępowe (endpoints), aby zapewnić, że ruch kierowany jest tylko do tych Podów, które są faktycznie dostępne.
Skalowanie polega na zmianie liczby replik w ramach Deploymentu.
Kiedy aplikacja ma uruchomioną więcej niż jedną instancję, można prowadzić ciągłe aktualizacje (Rolling updates) bez przerw w działaniu aplikacji. O tym będzie mowa w następnym module. Na razie przejdźmy do terminala online, aby przeprowadzić skalowanie aplikacji.
5.2.5.2 - Interaktywny samouczek - Skalowanie aplikacji
5.2.6 - Aktualizowanie aplikacji
5.2.6.1 - Aktualizacje Rolling Update
Cele
- Przeprowadzić płynną aktualizację przy użyciu kubectl.
Aktualizowanie aplikacji
Użytkownicy oczekują, że aplikacje są dostępne non-stop, a deweloperzy chcieliby móc wprowadzać nowe wersje nawet kilka razy dziennie. W Kubernetes jest to możliwe dzięki mechanizmowi płynnych aktualizacji (rolling updates). Rolling updates pozwala prowadzić aktualizację w ramach Deploymentu bez przerw w jego działaniu dzięki krokowemu aktualizowaniu kolejnych Podów. Nowe Pody uruchamiane są na Węzłach, które posiadają wystarczające zasoby.
W poprzednim module wyskalowaliśmy aplikację aby była uruchomiona na wielu instancjach. To niezbędny wymóg, aby móc prowadzić aktualizacje bez wpływu na dostępność aplikacji. Domyślnie, maksymalna liczba Podów, które mogą być niedostępne w trakcie aktualizacji oraz Podów, które mogą być tworzone, wynosi jeden. Obydwie opcje mogą być zdefiniowane w wartościach bezwzględnych lub procentowych (ogólnej liczby Podów). W Kubernetes, każdy aktualizacja ma nadany numer wersji i każdy Deployment może być wycofany do wersji poprzedniej (stabilnej).
Podsumowanie:
- Aktualizacja aplikacji
Rolling updates to metoda na aktualizację Deploymentów bez przerwy w ich dostępności poprzez stopniową zamianę kolejnych Podów na ich nowe wersje.
Ogólnie o Rolling updates
Podobnie, jak w przypadku skalowania aplikacji, jeśli Deployment jest udostępniony publicznie, Serwis będzie kierował ruch tylko do Podów, które są dostępne w trakcie aktualizacji. Dostępny Pod to taki, którego instancja jest dostępna dla użytkowników aplikacji.
Płynne aktualizacje pozwalają na:
- Promocję aplikacji z jednego środowiska do innego (poprzez aktualizację obrazu kontenera)
- Wycofywanie się do poprzedniej wersji
- Continuous Integration oraz Continuous Delivery aplikacji bez przerw w jej działaniu
Jeśli Deployment jest udostępniony publicznie, Serwis będzie kierował ruch w trakcie aktualizacji tylko do Podów, które są aktualnie dostępne.
W ramach tego interaktywnego samouczka zaktualizujemy aplikację do nowej wersji oraz wycofamy tę aktualizację.
5.2.6.2 - Interaktywny samouczek - Aktualizowanie aplikacji
6 - Materiały źródłowe
Tutaj znajdziesz dokumentację źródłową Kubernetesa.
Dokumentacja API
-
Glossary - Pełna, zestandaryzowana lista terminologii Kubernetesa
-
Using The Kubernetes API - ogólne informacje na temat API Kubernetesa
-
API access control - szczegóły dotyczące kontroli dostępu do API Kubernetesa
Oficjalnie wspierane biblioteki klienckie
Aby wywołać Kubernetes API z wybranego języka programowania, możesz skorzystać z bibliotek klienckich. Oficjalnie wspierane biblioteki to:
- Kubernetes Python client library
- Kubernetes Java client library
- Kubernetes JavaScript client library
- Kubernetes C# client library
- Kubernetes Haskell client library
Polecenia tekstowe (CLI)
- kubectl - Główne narzędzie tekstowe (linii poleceń) do zarządzania klastrem Kubernetes.
- JSONPath - Podręcznik składni wyrażeń JSONPath dla kubectl.
- kubeadm - Narzędzie tekstowe do łatwego budowania klastra Kubernetes spełniającego niezbędne wymogi bezpieczeństwa.
Komponenty
-
kubelet - Główny agent działający na każdym węźle. Kubelet pobiera zestaw definicji PodSpecs i gwarantuje, że opisane przez nie kontenery poprawnie działają.
-
kube-apiserver - REST API, które sprawdza poprawność i konfiguruje obiekty API, takie jak pody, serwisy czy kontrolery replikacji.
-
kube-controller-manager - Proces wykonujący główne pętle sterowania Kubernetes.
-
kube-proxy - Przekazuje bezpośrednio dane przepływające w transmisji TCP/UDP lub dystrybuuje ruch TCP/UDP zgodnie ze schematem round-robin pomiędzy usługi back-endu.
-
kube-scheduler - Scheduler odpowiada za dostępność, wydajność i zasoby.
-
Spis portów i protokołów, które muszą być otwarte dla warstwy sterowania i na węzłach roboczych.
API konfiguracji
W tej części zebrano "niepublikowane" API, które służą do konfiguracji komponentów Kubernetesa lub innych narzędzi. Choć większość tych API nie jest udostępniane przez serwer API w trybie RESTful, są one niezbędne dla użytkowników i administratorów w korzystaniu i zarządzaniu klastrem.
- kube-apiserver configuration (v1)
- kubelet configuration (v1alpha1) i kubelet configuration (v1beta1)
- kube-scheduler configuration (v1beta2) i kube-scheduler configuration (v1beta3)
- kube-proxy configuration (v1alpha1)
audit.k8s.io/v1
API- Client authentication API (v1beta1) i Client authentication API (v1)
- WebhookAdmission configuration (v1)
API konfiguracji dla kubeadm
Dokumentacja projektowa
Archiwum dokumentacji projektowej różnych funkcjonalności Kubernetes. Warto zacząć od Kubernetes Architecture oraz Kubernetes Design Overview.
6.1 - Słownik
7 - Współtwórz dokumentację K8s
Kubernetes zaprasza do współpracy wszystkich - zarówno nowicjuszy, jak i doświadczonych!
Tym serwisem www opiekuje się Kubernetes SIG Docs.
Współtwórcy dokumentacji Kubernetesa:
- Ulepszają istniejącą zawartość
- Tworzą nowe treści
- Tłumaczą dokumentację
- Zarządzają i publikują dokumentację w ramach cyklu wydawniczego Kubernetesa
Jak zacząć?
Każdy może otworzyć zgłoszenie dotyczące dokumentacji lub zaproponować zmianę poprzez
pull request (PR) do
repozytorium GitHub kubernetes/website
.
Aby móc sprawnie funkcjonować w społeczności Kubernetes,
wymagana jest pewna biegłość w korzystaniu z
git-a i
GitHub-a.
Aby zaangażować się w prace nad dokumentacją należy:
- Podpisać Contributor License Agreement CNCF.
- Zapoznać się z repozytorium dokumentacji i z generatorem statycznej strony www.
- Zrozumieć podstawowe procesy otwierania pull request oraz recenzowania zmian.
Schemat - Jak zacząć współpracę
To jest schemat postępowania dla osób, które chcą zacząć współtworzyć Kubernetesa. Przejdź część lub wszystkie kroki opisane w częściach Zapisz się
i Recenzuj
. Teraz już możesz tworzyć nowe PR, zgodnie z sugestiami w Otwórz PR
. I jak zawsze, pytania mile widziane!
Do realizacji niektórych zadań potrzeba wyższego poziomu zaufania i odpowiednich uprawnień w organizacji Kubernetes. Zajrzyj do Participating in SIG Docs po więcej szczegółów dotyczących ról i uprawnień.
Pierwsze kroki
Zapoznaj się z krokami opisanymi poniżej, aby się lepiej przygotować.
Schemat - Jak się przygotować
- Przeczytaj Contribution overview, aby dowiedzieć się o różnych sposobach współpracy.
- Zajrzyj do Contribute to kubernetes/website, aby znaleźć dobre zgłoszenie na początek.
- Otwórz pull request przy pomocy GitHub-a dotyczący zmiany istniejącej dokumentacji i dowiedz się, jak otwierać zgłoszenia przy GitHub-ie.
- Zrecenzuj pull requests innego członka społeczności Kubernetes pod kątem dokładności i stylu.
- Zapoznaj się z poradnikami Kubernetesa dotyczącymi zawartości i stylu, aby twoje uwagi były zgodne z tymi wytycznymi.
- Przeczytaj o różnych typach zawartości na stronie i skrótach Hugo.
Co dalej?
- Naucz się, jak pracować z lokalną kopią repozytorium.
- Udokumentuj nowe funkcjonalności.
- Włącz się w prace SIG Docs i zostań członkiem organizacji lub recenzentem.
- Pomagaj przy tłumaczeniu.
Włącz się w prace SIG Docs
SIG Docs to grupa, która publikuje i utrzymuje dokumentację Kubernetesa i jej stronę www. Zaangażowanie się w prace SIG Docs to doskonała okazja dla współtwórców Kubernetesa (rozwijających nowe funkcjonalności lub działających w innych obszarach), aby wywierać wpływ na cały projekt Kubernetes.
Aby włączyć się w komunikację w ramach SIG Docs, możesz:
- Dołączyć do kanału
#sig-docs
na komunikatorze Slack dla Kubernetesa. Nie zapomnij się przedstawić! - Zapisać się na listę
kubernetes-sig-docs
, na której prowadzone są dyskusje o szerszym zasięgu i zapisywane oficjalne decyzje. - Dołączyć do spotkania wideo SIG Docs odbywającego się co dwa tygodnie. Spotkania są zawsze zapowiadane na
#sig-docs
i dodawane do kalendarza spotkań społeczności Kubernetesa. Będziesz potrzebował komunikatora Zoom lub telefonu, aby się wdzwonić. - Dołączyć do spotkania SIG Docs na Slacku organizowanego w tych tygodniach, kiedy nie ma spotkania na Zoomie. Informacja o spotkaniu zawsze ogłaszana jest na
#sig-docs
. W rozmowach prowadzonych w różnych wątkach na tym kanale można brać udział do 24 godzin od chwili ogłoszenia.
Inne sposoby współpracy
- Odwiedź stronę społeczności Kubernetesa. Korzystaj z Twittera i Stack Overflow, dowiedz się o spotkaniach lokalnych grup Kubernetesa, różnych wydarzeniach i nie tylko.
- Przeczytaj ściągawkę dla współtwórców, aby zaangażować się w dalszy rozwój Kubernetesa.
- Odwiedź stronę Kubernetes Contributors i zajrzyj do dodatkowych zasobów.
- Przygotuj wpis na blogu lub case study.
7.1 - Tłumaczenie dokumentacji na język polski
Na tej stronie znajdziesz wskazówki i wytyczne przydatne przy tłumaczeniu dokumentacji Kubernetesa na język polski.
Dokumentem nadrzędnym jest angielski opis stylu dokumentacji.
Wskazówki ogólne
Staramy się, aby styl tłumaczenia był jak najbardziej naturalny. W przypadku dokumentacji technicznej może być to trudne zadanie, szczególnie gdy chcemy utrzymać precyzję tłumaczenia. Zależy nam na unikaniu sytuacji, kiedy tekst zaczyna sprawiać wrażenie przetłumaczonego maszynowo.
Pamiętajmy też, że oficjalna wykładnia zawsze znajduje się w tekście angielskim. Polskie tłumaczenie ma ułatwić pierwsze kroki osobom, które zaczynają swoją przygodę z Kubernetesem.
Wytyczne szczegółowe
Odmiana terminu Kubernetes
Kubernetes jest nazwą własną, liczba pojedyncza, rodzaj męski. Odmieniamy: Kubernetesa, Kubernetesem itp. W uzasadnionych przypadkach można stosować też "system Kubernetes".
Odmiana terminów Pod, Deployment
Odmieniamy zgodnie z ogólnymi zasadami - poda, deploymentu itp.
Ujednolicony słownik
W sieci dostępne są słowniki terminów informatycznych. Poniższa tabela zawiera słowa specyficzne dla Kubernetesa i inne często używane wyrażenia.
Termin angielski | Tłumaczenie |
---|---|
container | kontener |
control plane | warstwa sterowania |
Deployment | Deployment |
horizontal scaling | skalowanie horyzontalne |
Pod | Pod |
rolling update | aktualizacje stopniowe |
volume | volume (opcjonalnie: wolumin) |
worker node | węzeł roboczy |
8 -
Aby zastosować odpowiedni filtr, kliknij w etykietę lub użyj rozwijanej listy. Aby posortować rosnąco lub malejąco, kliknij w wybrany nagłówek tabeli.
Filtruj według pojęć:
Filtruj według obiektów:
Filtruj według poleceń: