Kubernetes – słownik pojęć
O Kubernetes dowiedziałem się jakiś czas temu. Ktoś coś gdzieś powiedział, ja coś przeczytałem, wykonałem cztery polecenia i cieszyłem się z działającego czegoś, czego zbytnio nie rozumiałem. Oczywiście starałem się wiedzę nadrobić i byłem wstanie po kilku dniach powiedzieć, co i jak. Aż do teraz nie wiedziałem, jak dużo nie wiedziałem :)
Do jednego projektu potrzebujemy wykorzystać k8s (skrót, który też wytłumaczę), a co za tym idzie, trzeba dobrze zaplanować to, co i jak chce się tworzyć. Przynajmniej zrobić bazę, by potem móc ją doszlifowywać. Tutaj na szczęście Internet przybył mi z pomocą i zarówno Sebastian jak i Łukasz polecili bardzo fajną książkę: Kubrenetes Up And Running, która na kilka rzeczy otworzyła mi oczy – baa, nawet czytając przytakiwałem mówiąc “to ma ręce i nogi”. Jednak czułem niedosyt. Było tam używane słownictwo, którego nie rozumiałem, a które nawet jak było wytłumaczone, to w późniejszych rozdziałach, przez co zrozumienie było dużo trudniejsze.
By więc komuś zaoszczędzić kłopotu, kilka najważniejszych pojęć k8s zebrałem w jednym miejscu :) Nie koncentrowałem się na opisaniu wszystkich możliwych słów i wyrażeń. Np. brak tutaj label i innych, mimo że czasami schodzę dość nisko w słowach kluczowych.
Kubernetes
To platforma do zarządzania i skalowania containers (kontenerami). W skrócie za pomocą k8s możemy stworzyć sobie rozwiązanie które będzie pilnowało odpowiedniej liczby instancji naszej aplikacji, do tego doda load balancer, a wszystko w oparciu o kontenery. Do tego k8s jest wpierany przez większość chmur publicznych w mniejszym lub w większym stopniu.
Jako, że k8s zarządza kontenerami, to jego nazwa też nie jest od czapy i znaczy: sternik. A jak wiemy, kontenery lubią być przewożone na olbrzymich statkach, którymi ktoś musi sterować. Trafne i ładne to określenie, dużo lepsze od swarm, które używane jest przez Docker do określenia “podobnej” platformy.
k8s
Jest to dość “proste”: K od Kubernetes, 8 od 8 znaków pomiędzy K i S, no i S na końcu jako końcowy znak. To takie sk8, ale bez fonetyczności tylko po prostu prawdziwy skrót – 8 znaków ;)
Object/Resource (obiekt/zasób)
Przy pracy z k8s, dość często możemy zdania typu: stwórz obiekt albo wykorzystaj zasób. Może to być męczące i możemy się tutaj często mylić. Jeżeli nie ma podanego innego kontekstu niż k8s, to wszystkie te określenia tyczą się tego samego – wykorzystanie type w deklaratywnym określeniu stanu rozwiązania.
Taki type to może być np.: NodePort, ReplicaSet, Ingress, Deployment, Service czy też zwykły Pod. To nie jest zamknięta lista, może być tego dużo więcej, jako że k8s można rozszerzać. Przykładem tutaj jest właśnie Ingress, która domyślnie nie istnieje załadowana.
Stworzenie obiektu równa się z wykonaniem albo odpowiedniej komendy w linii poleceń albo stworzenie pliku yaml, w którym deklarujemy nowy obiekt za pomocą atrybutu type.
Containter (kontener)
Jeżeli wywodzicie się ze świata dockerowego, to kontener tutaj znaczy dosłownie to samo. Jest to działająca instancja danego obrazu. Możemy do zadeklarować w yamlu k8s po podaniu atrybutu containers.
Cluster (klaster)
Zbiór paru lub więcej node (“komputerów” czy to wirtualnych czy fizycznych), na których działa agent k8s. Jeden z tych nodów nazywany jest Master Node.
Master Node
Node składających się z trzech usług: API (apiserver), zarządzą kontrolerów (controller-manager) i scheduler. Bardzo często, jak ktoś piszę apiserver, to ma na myśli Master Node i vice versa.
apiserver
Całe API kubernetes dostępne do wykorzystania. Jak wykonujemy jakieś polecenie na k8s to właśnie idzie to przez apiserver.
controller-manager
Pętla, która jest odpowiedzialna za to, by sprawdzać stan klastra za pomocą apiserver i doprowadzać aktualny stan do tego, który my chcemy osiągnąć (jest on opisany np. w yaml).
Scheduler
Odpowiedzialny jest za znalezienie Node dla danego Poda, który został albo utworzony deklaratywnie (yaml) albo imperatywnie (command line). Oczywiście jest to dużo bardziej zaawansowane niż: wybierz pierwszy lepszy. Sprawdzane są wszystkie parametry i wszystkie wartości minimalne, jakie podaje Pod.
Node
Element w sieci k8s, który może być zarówno wirtualną, czy też fizyczną maszyną, na której będą instalowane Pody.
agent/kubelet
Byt będący na każdym z node. Upewnia się także, że wszystkie kontenery działają w danym Pod.
Pod
Najmniejsza jednostka w kubernetes. To ona odpowiedzialna jest za deklarowanie kontenerów odpalanych na tym samym host/node. Ogólnie kiedy ktoś mówi o Pod, to ma namyśli przynajmniej jeden działający kontener. Mimo że Pody są najważniejszymi obiektami i są najwyżej w hierarchii, to podlegają one pewnemu ustrukturyzowaniu. Każdy klaster może mieć ~5000 node, wszystkie nody nie mogą mieć więcej niż 150 000 Podów. Zaś te Pody nie mogą mieć więcej niż 300 000 kontenerów. Istnieje też takie ograniczenie, że nie więcej niż 100 Podów per node.
Znów nazwa nawiązuje trochę do Dockera – Docker ma w logo wieloryba, Pod zaś nawiązuje do pod of whales.
Pody należy traktować jako coś, czego można się szybko pozbyć. Nie jest to coś, co ma długo żyć i cieszyć się starością.
Namespace
Byt grupujący wszystkie obiekty/zasoby/kontrolery pod jedną nazwą/grupą. Dla przykładu, namespace może być wykorzystywany do zarządzani środowiskami: dev, test i prod. Domyślnie wszystko jest tworzone w przestrzeni nazwy default.
Namespace działa tak samo jak w .NET (no ok, prawie tak samo) i do naszego obiektu dodaje odpowiednie wartości. Do każdego z obiektów możemy odwołać się za pomocą fully qualified name
:
[pod-ip-address|host-name].NAMESPACE.[pod|svc].cluster.local
Service (usługa)
Byt grupujący wiele Podów w logiczną całość. Np. jeden pod musi kontaktować się z drugim. Dzięki Service jest to możliwe. Dodatkowo Service umożliwia wystawienie danego kontenera na świat zewnętrzny – czyli przypisanie np. adresu publicznego IP. Do service można zaliczyć takie typy jak ClusterIP, LoadBalancer czy NodePort.
ClusterIP
Udostępnia usługę wewnętrznie – i tylko klaster może się z nią skontaktować.
LoadBalancer
Udostępnia naszą usługę na zewnątrz, wykorzystując load balancer udostępniony przez danego dostawcę chmury (Azure, AWS, Google itp.).
NodePort
Udostępnia port danej usługi (dokładniej wszystkich nodów pod daną usługą). Mając taki statyczny port, możemy później się do niego podpinać, czy też nawet udostępniać połączenie za pomocą mappingu.
Deployment
Daje możliwość tworzenia deklaratywnych aktualizacji naszych Podów. Co to znaczy? A tylko tyle, że mając taki dokument możemy tworzyć szablony (templates) kontenerów, które mają zostać utworzone i ile ma być instancji oraz jak mają być tworzone, aktualizowane itp. Kubernetes się tym zajmie.
Plusem jest możliwość wycofywania zmian. Pod spodem deployment wykorzystuje ReplicaSet. Celem deployment jest zastąpienie ReplicationController.
ReplicationController
Stary model tworzenia i deployowania rozwiązań na Kubernetes. Jest on już wycofywany i zastępowany ReplicaSet.
ReplicaSet
ReplicaSet upewnia się, że dany stan naszego rozwiązania jest taki, jak go opisaliśmy – czy mamy odpowiednią liczbę podów. Elementem nadrzędnym wykorzystującym ReplicaSet i dającym więcej możliwości, jest deploymnet.
Ingress
Byt robiący jako proxy do naszych usług, deploymentów. Umożliwia nam pod jednym adresem IP podpięcie wielu elementów naszego rozwiązania Kubernetes. Dzięki temu oficjalnie mamy jeden adres IP, a korzystamy z kilku lub nawet kilkunastu deploymentów.
Podsumowanie
Czy to wszystko? Oj nie. Jednak mnie kiedyś bardzo by to pomogło i mam nadzieję, że Tobie również :)