Kubernetes – słownik pojęć

O Kubernetes dowiedziałem się jakieś 8 miesięcy temu. Ktoś coś gdzieś powiedział, ja przeczytałem coś, wykonałem 4 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, go też wytłumaczę), a co za tym idzie, trzeba dobrze zaplanować to co chce 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 używane słownictwo, którego nie rozumiałem, a które nawet jak było wytłumaczone to było to zrobione w późniejszych rozdziałach przez co zrozumienie wcześniejszych było dużo trudniejsze.

By więc komuś zaoszczędzić kłopotu, kilka najważniejszych pojęć k8s w jednym miejscu :) Polecam :) aaaa nie koncentrowałem się na opisaniu wszystkich, wszystkich możliwych słów i wyrażeń! Więc na przykład brak tutaj label i innych, mimo że czasami schodzę dość nisko w słowach kluczowych.

By także nie było to tylko i wyłącznie tekstowe, mały diagram pokazujący “strukturę” kuberenets:

Kubernetes

Jest 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 wielkich olbrzymich statkach, którymi ktoś musi sterować. Trafne i ładne to określenie, dużo lepsze od swarm który 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 dość mylić. Jeżeli nie ma podanego innego kontekstu niż k8s, to wszystkie te trzy określenia tyczą się tego samego – wykorzystanie type w deklaratywnym określeniu stanu rozwiązania.

Taki type może być na przykład: NodePort, ReplicaSet, Ingress, Deployment, Service czy też zwykły Pod. To nie jest zamknięta lista, tego może być 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 więc 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 na przykład w yaml).

Scheduler

Odpowiedzialny jest za znalezinie 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 Pod podaje.

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

Jet też ograniczenie, że nie więcej niż 100 podów per node.

Znów nazwa nawiązuje trochę do Dockera – Docker ma w logu wieloryba, pod zaś nawiązuje do pod of whales.

A ważna uwaga, traktować pody należy jako coś co 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ługę)

Byt grupujący wiele podów w logiczną całość. Na przykład jeden pod musi się z drugim kontaktować, dzięki Service jest to możliwe. Dodatkowo Service umożliwia wystawienie danego kontenera na świat zewnętrzny – czyli przypisanie na przykład adresu publicznego adresu 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 dostawcy 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 instancji ma ich być oraz jak mają być one tworzone, aktualizowane itp zaś kubernetes zajmie się tym.

Plusem jest możliwość wycofania 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

By 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 czemu oficjalnie mamy jeden adres IP a korzystamy z kilku lub nawet kilkunastu deploymentów.

Podsumowanie

Czy to wszystko? Oj nie :) jednak mnie by to bardzo pomogło i mam nadzieję, że wam również :) Jeżeli macie jakieś uwagi lub byście chcieli coś tutaj dodać, to dajcie znać! To nie jest zamknięta lista :)