Kubernetes #3

Dobra, wiemy już mniej więcej z jakich klocków definiujemy nasze konfigi i myślę, że to idealny moment, aby przejść do architektury Kubernetesa, a dokładnie jej składowych. Mamy za sobą kilka akapitów o tym, po co i dlaczego, teraz czas na to, jak to działa.

Zacznijmy od tego, że Kubernetes jest systemem klastrowym i w środowiskach produkcyjnych działa w konfiguracji składającej się z więcej niż jednego węzła. Można oczywiście do celów testowych uruchomić sobie jedno klastrowy węzeł. Generalnie jednak spotkacie dwa rodzaje węzłów K8S – Master i Node (nazywany również Worker). 

Węzły typu Master to tzw. control plane – podejmują one główne decyzje dotyczące klastra (np. decydują, gdzie mają wylądować kontenery) oraz wykrywają i odpowiadają na różne zdarzenia (np. uruchomienie kolejnego poda, aby utrzymać zgodność ze zadeklarowaną przez nas konfiguracją). Zazwyczaj węzły typu Master działają tylko po to, aby zarządzać i niej jest wskazane (ale możliwe) uruchamianie na nich kontenerów z aplikacjami produkcyjnymi. Przy projektowaniu rozwiązania produkcyjnego, w pełnym HA należy rozważyć min. 3 węzły typu Master umieszczone na różnych fizycznych lub wirtualnych maszynach. Podstawowe elementy, jakie wchodzą w skład węzła typu Master to:

1. Kube-apiserver– Jest to komponent, który wystawia API Kubenrnetesa, jest to front-end dla control plane K8S. Został zaprojektowany w taki sposób, że skaluje się horyzontalnie, to znaczy, gdy potrzebujemy więcej pary stawiamy kolejne instancje. 
2. Etcd– Jest to rozproszony, wysoko dostępny key value store (czyli swoista baza danych) Kubernetesa, w której trzyma on wszystkie swoje dane. W związku z czym warto mieć backup etcd swojego klastra.  
3. Kube-scheduler – Element ten pochłonięty jest analizą nowo powoływanych Podów, które nie mają przypisanego twardo węzła klastra i ewentualnie jak najszybciej go wskazują. Czynniki, które są brane pod uwagę podczas orkiestracji uruchamiania, to własne lub zbiorowe wymagania Poda dot. sprzętu, oprogramowania, polityk, limitów, zasad przypisania (affinity rules) i rozdzielności (anty affinity rules) umiejscowienia danych itd.  
4. Kube–controller-manager – Komponent działający na węzłach Master odpowiedzialny za uruchamianie kontrolerów. Do zadań kontrolerów należą: 
5. Node controller– odpowiedzialny za monitorowanie stanów węzłów i reagowania w przypadku awarii któregoś z nich. 
6. Replication controller – odpowiedzialny za zarządzanie i utrzymanie konkretnej ilości Podów dla każdego obiektu replikacji w systemie.  
7. Endpoints controller– zajmuje się uruchamianiem obiektów typu Endpoint (np. łączy serwis z Podem). 
8. Service Account & TokenControllers– tworzy domyślne konta i tokeny dla API dla nowych namespace. 

Na węzeł typu Node / Worker, który odwala czarną robotę i na którym uruchamiane są aplikacje w podach składają się następujące elementy: 

1. Kubelet – jest to agent, który działa na każdym węźle klastra. Jego zadaniem jest zapewnienie działania dla każdego kontenera znajdującego się w Podzie.  
2. Kube-proxy – umożliwia powołanie warstwy abstrakcji, jaką jest zarządzanie siecią w obrębie hosta i obsługę niezbędnych połączeń. 
3. Container Runtime – jest to oprogramowanie odpowiedzialne za uruchamianie kontenerów, może to być Docker, ale nie tylko, bo dostępne też jest rkt, runc, lub inna zgodna ze specyfikacją OCI implementacja. 

Powyższe elementy składają się na platformę zwaną Kubernetes. Teraz przejdźmy do tego, jak z nią rozmawiać. Można oczywiście z palca, ale to nie jest koszerne, użyjmy do tego następującego prostego kodu zapisanego w pliku .yaml:

apiVersion: v1
kind: Pod
metadata:
name: cmentarnapolka
spec:  # specification of the pod’s contents
restartPolicy: Never
containers:
 – name: rybipuzon
 image: “ubuntu”
 command: [“/bin/echo”, “Wojek”, “Vernon”]

Pole metadata name z wartością “cemntarnapolka” będzie nazwą Poda, a w jego środku będzie działać jeden kontener o nazwie rybibuzon, oparty o obraz ubuntu, w którym wykonana zostanie komenda echo wyświetlająca słowa Wójek Vernon. Logiczne nie? Uruchamia się to za pomocą następującego one-linera, lub dorzuca się do pipeline CI/CD:

kubectl create -f ./cemntarna-polka.yaml

Można to oczywiście rozbudowywać. Ubierać w ReplicaSet pozwalające na skalowanie ilości Podów, czyli np. gdy wieczorem zwiększa nam się ilość klientów, podbijamy przy pomocy tego mechanizmu ilość instancji danej aplikacji do 9, 20 lub 1000 – zależenie od potrzeb. A tym z kolei można zarządzać przy pomocy Deploymentów.

Mamy wiele możliwości, aby uruchomić nowoczesny portal do transoceanicznych korepetycji z dopiero co pełnoletnimi Paniami i Panami. Jak do tego podejść krok po korku, już w kolejnej odsłonie naszego cyklu, gdzie zainstalujemy klaster Kubernetesa, a później uruchomimy na nim aplikację, korzystając ze wspomnianych mechanizmów.