EKS Fargate. Serverless Kubernetes w AWS ?

Podstawowy paradygmat serverless to: pay-per-use. Czy Fargate w połączniu z Amazon EKS spełnia ten warunek? Nie. Czego byśmy nie zrobili, płacimy za master nody. OK, jedno mamy za sobą. Kubernetes, na dziś, to nie serverless. Jeden buzzword mniej.

Czym jest Kubernetes?

To jest, przynajmniej dla mnie, proste pytanie. Jest orkiestratorem, który chce nam, programistom, devopsom, zapewnić wygodę uruchamiania naszych aplikacji. W chmurze, on-premises. Gdziekolwiek. Ale skupmy się na chmurach. Na AWS.

Czym jest usługa EKS?

Elastic Kubernetes Service. Managed. Kolejne buzzwordy? Niekoniecznie…

Klaster Kubernetesa to, tak naprawdę dwa byty. Dwie części. Master, który wszystkim zarządza. I workernody (maszyny wirtualne), na których uruchamiamy nasze aplikacje. Tak naprawdę, ten master, to też serwer. Najlepiej, jeżeli jest zreplikowany.

I tu wchodzi EKS. Cały na biało 😉 Usługa, z punktu widzenia użytkownika, jest bardzo prosta. Jeżeli wejdziemy do konsoli AWS i stworzymy klaster w usłudze EKS, to tak naprawdę stworzymy Kubernetes Control Plane, czyli tego mastera, który będzie zarządzał naszym klastrem. Tak naprawdę stworzymy redundantne środowisko, składające się z trzech kopii zasobów zarządzających naszymi aplikacjami. Dostajemy high availibility za darmo. No, może nie za darmo, bo za nasz Control Plane płacimy, ale mamy pewność, że jeżeli nasze etcd zginie, to mamy jego kopię. Dodatkowo, nasze mastery skalują się w miarę potrzeb. Myślę, że warto więc zapłacić te kilkadziesiąt centów (teraz to 0,20$/h) za te rozwiązania. W tej cenie mamy też obsługę naszych masterów. Coś padnie, zgodnie z Shared Responsibility Model, zajmuje się tym AWS. Nie my. Jeden devops mniej. Albo jeden devops, który może zająć się ważniejszymi rzeczami. Brzmi dobrze?

Aplikacje

Mamy już maszynkę do zarządzania. Ale nie mamy czym zarządzać. Nasze aplikacje trzeba na czymś uruchomić. Potrzebujemy workerów. Pytanie: Czego potrzebujemy? Odpowiedź: Maszyn wirtualnych. Tak?
Do „wczoraj”, czyli do okresu przed re:Invent2019 odpowiedź brzmiała TAK. Teraz już niekoniecznie. Miód dla konsultanta, możemy odpowiedzieć ‚To zależy’.
Nasze aplikacje potrzebują zasobów. CPU, pamięć. Ale niekoniecznie maszyn wirtualnych.
Do „wczoraj” jako zasoby dla EKS mogliśmy podpinać maszyny wirtualne w ramach autoscaling groups. Działało? Tak. Wygodne? To zależy 😉

Jeżeli mamy stałe obciążenie naszych aplikacji, nie musimy martwić się o fluktuacje zapotrzebowania na CPU itp. to wszystko jest OK. Podpinamy 2, lub 3, lub 100 maszyn do naszego klastra i nasze serwisy pracują. A nasi użytkownicy są zadowoleni z krótkich czasów odpowiedzi.

Ale co jeżeli nadejdzie nasz Black Friday? Co jeżeli zapotrzebowanie na zasoby w naszych aplikacjach się zmienia?

Tu, z pomocą może przyjść nam właśnie Fargate, czyli usługa, która umożliwia uruchamianie kontenerów „bez serwerów”. Od dłuższego czasu dostępna w AWS dla usługi ECS, od teraz także dla EKS. Na czym polega? W skrócie na tym, że kontenery z naszymi aplikacjami uruchamiane są na zasobach, którymi w pełni zarządza AWS. My nie widzimy żadnych maszyn wirtualnych, wszystko dzieje się przezroczyście. Sprawdźmy jak to działa.

Fargate dla EKS

Klaster najprościej utworzyć za pomocą eksctl, które jest oficjalnym narzędziem CLI dla EKS.
W chwili obecnej Fargate dla EKS dostępny jest w czterech regionach:

• US East (Virginia),
• US East (Ohio),
• Europe (Ireland),
• Asia Pacific (Tokyo).

Wybieramy więc jeden z nich, w którym chcemy tworzyć klaster i wykonujemy polecenie:

eksctl create cluster --name nazwa_klastra --region nazwa_regionu --fargate

To proste polecenie, poza tym, że utworzy dla nas klaster w usłudze EKS (w tym przypadku oczywiście bez workernodów), wykona także kilka innych czynności.
Utworzona zostanie rola dla naszych podów, która umożliwi im między innymi na korzystanie z API AWS. Rolę taką można oczywiście utworzyć samemu.
Ważniejszy w tym przypadku jest tak zwany Fargate Profile, który umożliwia nam wybór, które z Podów mają być uruchamiane przy pomocy Fargate.

Sprawdźmy czy mamy jakieś nody:

kubectl get nodes

i pody

kubectl get pods --all-namespaces

Jak widać mamy już zdeployowany CoreDNS.

Fargate Profile

Ten profil to bardzo ważna rzecz jeżeli chodzi o Fargate i EKS. Za jego pomocą definiujemy, które Pody i z jakimi uprawnieniami będą uruchamiane w Fargate zamiast na maszynach EC2. Spróbujmy więc sobie taki profil zrobić. Ten utworzony przez eksctl usuwamy.
Klikamy Add Fargate profile i:

1. Ustawiamy rolę dla naszych podów
2. Wybieramy podsieci, w których mają się tworzyć pody.

Dodajemy tylko prywatne podsieci. Na chwile obecną nie ma możliwości uruchamiania podów w podsieciach publicznych.

Na następnym ekranie wizarda mamy bardzo ważną rzecz. Tutaj określamy, które pody mają być uruchamiane na Fargate, zamiast na maszynach wirtualnych.

Wyboru tego dokonujemy za pomocą dwóch rzeczy:

• namespace, która ma być uruchamiana na Fargate,
• selektory podów.

W naszym przypadku, chcemy uruchomić wszystko. Zarówno aplikacje, jak i deploymenty systemowe Kubernetesa. Dodamy więc dwie namespaces: default i kube-system. Selektory pozostawimy puste.

Na temat namespaces i selektorów nie będę pisał. Myślę, że wszyscy, którzy pracują z Kubernetesem wiedzą o co chodzi. Przechodzimy do następnego ekranu i klikamy Create.
Po chwili profil się utworzy. Dobrze jeszcze zrestartować pody z CodeDNS. Najprościej poprzez usunięcie istniejących. Tworzenie „noda” dla poda i samego poda, z tego co zaobserwowałem, zajmuje około 60 sekund.

Deployment

Klaster już działa, skonfigurowaliśmy go według potrzeb. Spróbujmy wykonać jakiś deployment. Posłużę się nieśmiertelnym nginx:

kubectl create deployment blog-demo-deployment --image=nginx

Moment później mamy już naszą aplikację gotową do działania

Spróbujmy jeszcze przeskalować nasz deployment:

kubectl scale deployment blog-demo-deployment --replicas=5

i zobaczyć jak zachowują się zarówno pody

jak i nody

Jeżeli wyskalujemy nasz deployment w dół, zasoby oczywiście zostaną po chwili usunięte.

Podsumowanie

Fargate dla EKS ma jeszcze trochę ograniczeń. Można korzystać na przykład tylko z Application Load Balancera. Network Load Balancer jest w roadmapie. Dostaniemy też tylko do 4vCPU i 30Gb pamięci na poda. Nie uruchomimy DaemonSeta, ani nic co potrzebuje persistent volumes.
Jak to wygląda cenowo? To zależy 😉 Płacimy oczywiście za sam klaster, czyli 0,20$ za godzinę. Ale w przypadku normalnego klastra jest tak samo. Dodatkowo za zasoby, które udostępni nam Fargate. Wychodzi to trochę drożej od maszyn EC2. Ale dostajemy dużą elastyczność, czyli coś co uruchamiamy tylko czasami, coś dla czego nie jesteśmy w stanie przewidzieć obciążenia jak najbardziej może wyjść nas taniej. No i mamy wygodę. Możemy oczywiście w jednym klastrze łączyć zarówno Fargate jak i klasyczne podejście.