Mięso od 16:24, za bardzo się rozgadaliśmy na wstęp! ;-)
Temat odcinka to Kubernetes z dwóch punktów widzenia – osoby piszącej aplikacji oraz osoby dostarczającej Kuberentes jako platformę. Ciekawe linki i inne znaleziska z tego odcinka:
Szymon Warda [SW]: Jestem ciekawy, jak reszta ludzi patrzy, bo patrząc na Kubernetesa z tych dwóch stron, możemy mieć różne kompletnie spojrzenia…
Łukasz Kałużny [ŁK]: Tak. I różne opinie.
SW: Tak. I często jak nie zdefiniujemy tego spojrzenia, to potem nie do końca wiadomo, z którego punktu się wychodzi. Dobra, to może, od czego się zaczęło? Kubernetes.
ŁK: Od site projectu w Google’u. I teraz, co ważne, wzoruje się na BORGu, czyli na internalowym systemie, internalowym workload schedulerze z Google’a. Panowie się nim inspirowali, wzorowali, nie wzięli kod base’u, czyli kawałek napisali. No i właśnie sam BORG służy już od dawien dawna do puszczania w dużej skali workloadów, jobów. I dużą odmianą od takiego Kubernetesa tam jest to, że używamy binare i fatbinare. Zamiast kontenerów schcedulujemy już binarki, no i to, co duże firmy chcą osiągnąć. Oni tym BORGiem chcieli osiągnąć jak największe utylizacje tych procesów, zrobić high-density. Czyli tam, gdzie u normalnych ludzi świeci się “critical”, u nich jest to normalne, dobrze doutylizowane serwery.
SW: Tak, ale ja mam dwie obserwacje. Bo tak naprawdę, jeżeli mówimy o BORGu, swoją drogą zdecydowanie Star Trek over Star Wars, dla tych, którzy łapią analogie, to takie samo podejście parę lat później zrobił Microsoft ze swoim serwisem Fabric’iem.
ŁK: Wiesz, co? Nie do końca. Serwis Fabric to też była pewna platforma i pierwszy koncept, i pierwszych Coat Base powstał w 2001 roku serwis Fabrica.
SW: Myślałem, że później.
ŁK: Nie, 2005 to już był działający produkt.
SW: OK, dobra, to ja skojarzyłem to z piątką.
ŁK: Tak, więc 2001. Projekt iHome, czyli robili Smart City Zenita. Ludzie o tym mówili, a oni robili software pod to.
SW: OK, dobra. Ale dla mnie przede wszystkim to drugie, a propos utylizacji, to z drugiej strony jak mówimy o utylizacji, to są niższe koszty, więc niższe koszty też dla nas, ale to też jest sposób, w jaki powstał cały ten cały Serverless, to jest sposób na dopchanie tych maszyn o dodatkowe 10% tak naprawdę, więc chmura jest biznesem. On musi się opłacać temu, kto wystawia i temu, kto kupuje. Pokazuje to, w jaki sposób przy tak dużej skali, jest próba wyniesienia pewnych serwisów do poziomu infrastruktury, żeby to było coś, co już jest zapewniane. Całe Discovery, o czym jeszcze będziemy mówili tak naprawdę, cała warstwa komunikacji synchronicznej… Jest pchanie dość mocne, OK, to nie powinno być powtarzane, reodkrywane w każdym projekcie.
ŁK: Tak, masz opis tak naprawdę, robisz abstrakcję tak naprawdę nad infrastrukturą i ją opisujesz, więc to jest troszeczkę chyba też w twoim tym, w jaki sposób utrzymać aplikację.
SW: Tak, w jaki sposób utrzymać. Czym mniej będzie elementów castomowych w danym systemie, tym łatwiej będzie ją utrzymać. Jeżeli Discovery zawsze wygląda tak, jest łatwiej. Nikt nie chce utrzymywać Service Discovery sprzed 15 lat, bo to działa inaczej niż teraz.
ŁK: Tak. Jak jesteśmy trochę przy utrzymaniu aplikacji historycznie, no to chyba dla mnie w sumie, jak dla ciebie - tu się zgadzamy. Z tego, co wiem, to jest sposób opisu.
SW: Fenomenalny! Tym mnie w ogóle kupił Kubernetes właśnie! I co jest ważne, to… Ten opis już mieliśmy w Docker Compose’ie, w pewien sposób. Nie był tak dobry.
ŁK: Tak, Docker Compose był jednostkowy, a w przypadku Kubernetesa to mamy coś, co ja na szkoleniach się staram wytłumaczyć, że mamy reconciliation loop, czyli mamy stan obecny i stan pożądany, czyli Kubernetes z tej perspektywy właśnie, jak zarządzamy aplikacją, on dąży do tego stanu, żeby był opisany przez nas manifest, czy to będzie Jan czy Jason, dążył właśnie tego stanu.
SW: Tak, dla mnie Compose się sprawdza fenomenalnie do stawiania projektów na jednej maszynie. Nastawianie na wielu? Nie, to nie działało aż tak dobrze. Compose restartami i tak dalej próbował dodać funkcjonalność, nie tylko jak system inicjalnie powinien wyglądać, ale jak powinien wyglądać przez cały swój cykl życia. Ale Kubernetes tu pozamiatał. I opis, i działanie selektorów i tak dalej, to po prostu działa dobrze.
ŁK: Jest fajny wywiad z zeszłego roku z jednym z współtwórców, z Brandonem Berensem. On teraz pracuje w Microsoft, bo przeszedł do Microsoftu parę lat temu. No i w wywiadzie jest bardzo fajna rzecz. To, co on myśli, taka ambicja twórców tego była trochę, teraz na to patrzą tak, że opisy Kubernetesa staną się takim X86 zestawem instrukcji 86 czy armowych dla cloud-native. Czyli że nie patrzą już na Kubernetesa jak na platformę do hostowania apek, ale ta rzecz, która najlepsza się teraz zdarzyła, czyli te manifesty… Że one staną się jakby zestawem instrukcji, który zostanie reużyty i zaimplementowany w innych miejscach.
SW: To dochodzimy do tego, gdzie ja się bardzo z tego powodu cieszę, bo ten zestaw opisu właśnie, jak to wygląda, zawiera też rzecz, która dla mnie była przełomowa, jak zacząłem Kubernetes. Zacząłem się nim bawić, używać, to było OK i fajnie, fajnie, wszystko jest OK. A potem użyłem deploymentów i zobaczyłem jak Kubernetes z pudełka implementuje canary deployment. Jak mając trzy maszynki, on wpierw wdroży na trzy pody, wpierw wdroży na 1 pod, spróbuje, pobierze obraz, dopiero jak to się uda, to wgra, jak nie, to będzie pobierał. Deploymenty - to w Kubernetesie po prostu jest super. Ten, kto pisał deploymenty w PowerShellu, Bashu, w czymkolwiek - widziałem tysiące linii kodu deploymentu, deploymenty są trudne, a w procesie po prostu to działa. Jest to element wyglądu systemu, jest element tego, jak system powinien działać, ponieważ wdrożenie jest elementem życia systemu, więc jako życie jest zapisywane przez odpowiednie atrybuty: ile, jak, kiedy może ubić, kiedy może być więcej maszyn.
ŁK: Deploymenty tak. Drugą rzecz, którą widzę tam: wystarczy naprawdę bardzo mało, żeby robić je dobrze. Nawet zero data deploymenty. Jedynie, co tak naprawdę najważniejsze, to nie używać ORMa i troszeczkę pożyczyć bazy relacyjne.
SW: O czym powiemy, tak, zgadza się. To coś jeszcze, bo powiedziałeś, że - i to będzie motyw przewodni tak naprawdę w Kubernetesie, że tam wiele rzeczy na starcie jest zrobionych po prostu dobrze. Ten deployment, który jest, to jest ładny Canary, nie jest idealny, ale z reguły błędy w deploymencie spowodowane są tym, że czegoś nie użyliśmy, na przykład nie użyliśmy odpowiednich progów, health checków itd., nie ustawiliśmy, ile może maszyn ubić, to działa dobrze! Ty zauważałeś, że zrobienie tam CACD jest po prostu proste.
ŁK: Tak. I to jest duża zaleta też Kubernetesa, że manifesty są niezależne od języka.
SW: Tak!
ŁK: Czyli jeżeli wiesz, jak daną aplikacje skonteneryzować, to już sama filozofia na Kubernetesie, oczywiscie *bo teraz mówimy troszkę kłamstwa dla dzieci, bo są pewne tam niuanse, ale na ogół jest to proste.
SW: Tak, jest to proste.
ŁK: Powtarzalne…
SW: Powtarzalne, przyjemne. To, co trochę mnie boli, to jest to, że jak się szuka w sieci (mam nadzieję, że wasz kurs to naprawi), to bardzo dużo jest definicji, jak to zrobić z konsoli, nie z plików. Wklepanie danych w Kubernetesie z poziomu konsoli jest niewykorzystywaniem potęgi, jaką daje Kubernetes, jaką dają pliki.
ŁK: Tak, jest tam jeszcze inna filozofia, ale o tym później. Z tym się zgodzę się, że powinniśmy korzystać z manifestów albo czegoś, co generuje te manifesty.
SW: Tak!
ŁK: O, może tak to wezmę. Tak, coś, co będzie trzymane w repo.
SW: Dobra, mam jeszcze jedną rzecz jeśli chodzi o Kubernetesa, takiego z poziomu aplikacyjnego, co zahaczyliśmy. Ile Kubernetes usług wyciągnął jako commodity. Tak naprawdę te usługi nie są idealne, o czym też sobie powiemy. Ale przede wszystkim mega proste: Service Discovery.
ŁK: Tak.
SW: Bardzo prosty API Gateway. Inicjalnie możemy sobie robić load balancing. Możemy wybierać, możemy dywersjonować. Selektory i metadane, które są obecne na każdym nodzie, do którego można się odwołać, powodują, że z taką prostą ideą, są w stanie niesamowicie fajne rzeczy robić.
ŁK: Tak, czyli zacznijmy może od tego jeszcze, jak działa Service Discovery, bo jak już poruszyłeś, że robili do commodity, no to mamy te dwie opcje. Jedna to jest taka właśnie ta najprostsza, o której mówisz, czyli walimy po DNSie, tak jak nazywa się nasza usługa plus Namespace, gdzie są dostępne w klastrze i możemy się po prostu odwoływać i koniec.
SW: Przez serwis Node’a.
ŁK: Tak, przez serwis. I to jest super rzecz i będzie good enough chyba dla większości przypadków.
SW: W większości z tego, co widzę to jest chyba more than good enough nawet.
ŁK: Tak. Druga opcja, jak chcemy zrobić coś zaawansowanego, bo chciałbyś popytać się właśnie o labelach po metadanych, się zaczyna to pokrywać. No to już musimy się zintegrować z API Kubernetesowemu.
SW: Pozostaje ten obszar, gdzie nie komunikujemy się bezpośrednio synchronicznie, tylko po prostu chcemy coś się dowiedzieć… To tam, to zaczyna być tricky. Zgodzę się jak najbardziej.
ŁK: Tak, tam to jest takie trochę chyba… Z notatek twój komentarz, czyli jak chcemy zacząć kombinować, to może zewnętrzne Service Discovery. Jak chcemy robić coś bardziej skomplikowanego.
SW: Tak! No bo jeżeli potrzebujemy takich rzeczy jak Key Vaulta, a będziemy potrzebowali czegoś do sekretów… No to pytanie, czy w tym momencie właśnie nie potrzebujemy czegoś zewnętrznego, jak Consul, Ajour, Key Vault, cokolwiek innego. Pytanie, czy warto właśnie walczyć z Kubernetesem, czy jednak zewnętrznego jako normalny serwis i zadziała.
ŁK: Z mojej perspektywy, praca z większą ilością klastrów, jest tak, że jeżeli twoja apka nie wychodzi z potrzebami poza klaster, to ten podstawowy wystarcza w zupełności.
SW: Ja bym też tak powiedział. A pytanie, jak jest ze wsparciem dla sekretów i Key Vaulta?
ŁK: Wiesz co? Nie ładujesz zewnętrznie same secrety od strony, tak jak patrzę właśnie, dostarczania platforma aplikacji. No to, te domyślne już teraz, w zależności, gdzie trzymamy tego Kubernetesa, ale można zaszyfrować te secrety pod spodem.
SW: Faktycznie, była opcja…
ŁK: Czyli mogą być już szyfrowane pod spodem. Czy w cloudowych jest teraz dużo providerów, które podpinają zewnętrzne, czyli na przykład Key Vault ażurowy może być zamontowany jako volumen. Secrety mogą być zamontowane jako volumen. Czy z inną opcją, tak jak mówimy o konsoli HashiCorp, no to są pluginy, które robią auto injecting z Vaulta do poda. Więc jest ileś tych fajnych opcji, które są, jeżeli chodzi o secrety.
SW: Dobra, to ja dorzucę obszar, co mnie trochę martwi, co będziemy rozwijali, to jest to, że overhead Kubernetesa jest duży. Kubernetes to jest 2,5 miliona linii kodu. To jest dużo. Jak ja włączam na moim laptopie, to nagle to jest 45% zużycia procesora, który w tej wersji jeszcze nie ma żadnej aplikacji. To jest tak - rzucam, odwołamy się, trochę chyba nie z twojego punkty widzenia.
ŁK: Dobra. Moją tezą jest to, że nadaje się do budowy platform. I dla mnie to jest super rzecz kiedy jest dostarczany w jakiś sposób jako kompleksowy ofering. Przez to rozumiem na przykład wzięcie klastra as a servise od jakiegoś vendora z GKE czy z Azura. Bierzemy ten klaster i dostajemy do niego całą tę potrzebną otoczkę. Bo właśnie to, co trochę powiedziałaś, Kubernetes ma swój poziom wyobrażenia, że jest skomplikowany, niby ma też overhead, co jest prawdą i nieprawdą, bo sam Kubernetes jest tylko orchiestratorem.
SW: Zgadza się.
ŁK: I to głupim jak budowa cepa, to jest taka moja perspektywa.
SW: Zgadza się.
ŁK: Więc trochę mit… Repo jest duże, teraz są prace, które mówią, że pewne rzeczy są wyodrębniane, bo rozwój Kubernetesa, to też istotne, przez długi czas było to tak naprawdę wszystko pchane do jednego repa, jeżeli chodzi o kod. I tam znajdują się np. integracje third-party, tak jak z Azurem, AWSem, VMwarem i innymi rzeczami. One znajdują się natywnie sobie w corcode’dzie, a teraz są wyrzucane jako zewnętrzny moduł, więc duża część będzie schodziła. Tam jest parę takich nawet w repo fajnych plików, tak jak od volumenów. Proszę tego nie przerabiać, jeden plik jest najbardziej czytelny i nie rozbijajcie tego. Jest taki stary, klasyczny inżynierski “if” - “jeżeli coś” i leci zduplikowany kod, i nikt się tym nie przejmuje, i się nie dotyka.
SW: Ale z czego wynika ten “if”. Ten “if” wynika z jakiegoś bugu, który znaleźli i który jest naprawiony. I każdy system, który jest używany produkcyjnie, zbiera taki “szlam” realiów jego użycia.
ŁK: W szczególności tak szeroko. No i druga rzecz, to z punktu widzenia platformy aplikacji też, bo jest nice to have to mieć. No to mamy ten cały ekosystem Cloud Native Foundation. No i te Cloud Native Foundation to jest fundacja opensource’owa założona przez Linux Foundation, czyli tę fundację, która utrzymuje kernel i tutaj są rozwijane projekty, nazwijmy to krytycznej infrastruktury i biblioteki, rozwiązania całe cloudnative’owe. Więc to nie jest tylko Kubernetes, ale możemy znaleźć masę rzeczy, która jest w ogóle nie związana z Kubernetes, ale się integruje. Możemy wziąć Fluentd do forwardowania logów, które Microsoft wykorzystuje to pod spodem w swoim agencie do wypychania logów, na przykład z Linuxów czy Metrek. Inną rzeczą będzie NATS, czyli bardzo szybka, nowoczesna kolejka do IoT, która potrafi przepychać setki tysięcy jednoczesnych połączeń, więc cały ten świat jest bardziej szeroki.
SW: Pytanie pozostaje takie, na ile, z punktu widzenia znowu mojego, na ile można liczyć, że będzie rozdzielany Kubernetes od całego CNCFa? No bo Kubernetes jest sprzedawany jako taki produkt pudełkowy, który jest zaopiniowanym Stackiem, bo tam to, co powiedziałeś, kryje się zestaw technologii, które są skonfigurowane, które z sobą ładnie działają. Czy to jest problem poznawczy generalnie, jak jest sprzedawany? Czy jak jest widziany? Bo pod nazwą Kubernetes kryje się wszystko.
ŁK: Tak jest, wszystko. A dla mnie to jest tylko orchiestrator. To, co mówisz, cały ekosystem - tak, jest ważny, potrzebujesz tych funkcjonalności. Tylko z drugiej strony możesz wziąć sobie właśnie cloudową rzecz, która dostarcza wokół te usługi funkcjonalności czy, to co na początku wspomnieliśmy, OpenShifta. Czyli możesz wziąć dystrybucje, które to wszystko mają i one nie zawsze mają klocki z CNCFu.
SW: Pytanie, jak w długiej perspektywie, czy nagle nie będą smaki Kubernetesa, Kubernetes z tymi klockami i z tymi… Czy nie będzie działał inaczej, czy nie będą różnice? Tego się trochę boję.
ŁK: Wiesz co? Troszeczkę to się teraz uspokoiło, bo Kubernetes jest, jak sobie popatrzę na rozwój funkcjonalności, które dochodzą, to zwolniło. On się stabilizuje i dojrzewa teraz. Jesteśmy już na takim etapie stabilizacji i dojrzewania, czyli bardziej jest sprzątanie, uspójnianie, repo stylu kodowania czy budowa nowej infrastruktury do testów CACD wewnątrz samego projektu Kubernetesowego.
SW: I budowanie poparcia biznesowego dla niego też, bardzo ważne.
ŁK: Tak. Więc to się tam uspokoiło. Jeżeli sobie popatrzymy, jak mówimy troszeczkę o platformie, jeżeli tylko popatrzymy, to musimy dostarczyć z takich rzeczy, tak jak ja mówię, dla aplikacji, do hostowania aplikacji, offering platformowy. No to dostarczasz tego wysoko dostępnego Kubernetesa, coś do zbierania metryk.
SW: Musi być.
ŁK: Coś do zbierania logów.
SW: Tak, musi być.
ŁK: Jakiś dashboard do wyświetlania. Dashboard w sensie metryk, logów, takiego monitoringu. I coś do zarządzania secretów. Tak. Bo CACD są pomysły dziwne, na przykład, które są, latają sobie. Ja ich nie popieram, są różne dziwne trzymania CACD na samym Kubernetesie. Ja tego nie popieram, wolę rzecz osobiście, wolę narzędzia zewnętrzne i nie zamykać się w ogóle na to.
SW: To przypomina mi trochę trend, jak pojawiły się mikroserwisy, to za chwilę pojawił się trend nanoserwisy, czyli ludzie poszli z ideą jeszcze dalej, bo myśleli, że jak pomysł pociągną za daleko, to będzie dobrze, to teraz trzymamy wszystko w Kubernetesie - nie ma sensu. Tak. I że jak CACD i baza…
ŁK: Tak, do bazy przejdziemy, bo mam to w notatkach.
SW: Wiem, bo jest temat, który mnie też bardzo interesuje i problematyczny.
ŁK: Tak, czyli patrząc się na platformę, to musimy wiedzieć, że Kubernetes to są klasyczne trzy warstwy pod spodem. To jest monolit, piękny monolit, jeżeli byśmy sobie na to popatrzyli. I zaczynając od takich komponentów, no to wspomniałeś o bazach danych. Za wszystkim gdzieś przychodzi przechowywany stan w Kubernetesie, za to jest odpowiedzialna etcd, która ma swoje problemy i niuanse. To jest baza rozproszona, która ma zapewnić w miarę strong consistency i wykorzystuje też rafta, jest to Key-Value, no i ma swoje bottom leg. Im większy klaster, tym ma troszkę niestety, przez to, że jest strong consistency, musi zwolnić swoje odczyty, zapisy i pozwolić rozpropagować. Tam pod spodem działa raft, protokuł raft, jest implementacja rafta.
SW: Swoją drogą jakby ktoś chciał zobaczyć, jak wygląda raft, to ja proponuję sobie postawić klaster Consula i tam bardzo ładnie widać, jak on się degaduje, jak działa.
ŁK: Ile czasu komunikacji w logach zajmuje? Ile czasu wymiana i komunikacja zajmuje?
SW: Tak. I np. ubić któryś note i zobaczyć, jak on się zachowa, kiedy generalnie nie ma konsensusu i tak dalej. Ale jak już ruszełeś z etcd, to jest problem, który jest adresowany przez Microsoft, między innymi, bo to jest profiler, w którym najwięcej siedzę, to właśnie jednak mimo wszystko jest elementem Cosmosa. No bo Cosmos zaczyna mieć taki plug and play, kawałek. No skoro już masz Kubernetesa, to może nie etcd, tylko może weź w tym momencie Cosmosa, bo Cosmosa umiemy ogarnąć na poziomie lokalizacji, na poziomie geo i będzie działało dobrze.
ŁK: Tak. To jest takie pierwsze podejście, drugi projekt, który się pojawił, to użycie SQL Lite’a dla małych instalacji w K3, właśnie od Rangera, więc etcd jest tam odpowiedzialna za wszystko, jest takim centralnym punktem fakapów, to tak jak z back-upami, innymi rzeczami. Czy w teorii też powinniśmy ją czyścić, trochę mightnessu poświęcić.
SW: Jak każda baza danych.
ŁK: Następny zarzut, który widzę trochę z perspektywy platformy, to jest brak perfect pair detection dla nodów.
SW: Dobrze, że dodałeś “perfect”, bo będę tu miał “ale”.
ŁK: Tak, “ale”. Teraz ja patrzę z poziomu platformy, nasze nody, czyli powiedziałem, że Kubernetes jest trójwarstwowy. Czyli mamy sobie bazę danych, mamy ten centralny zestaw na masterze serwisów, gdzie głównym jest taki API server, przez którego przechodzą wszystkie requesty. I działa tak, że nasz węzeł ze swoim agentem Qbletem, on wysyła w jedną stronę tylko strzały, puszcza tylko Heartbeat, że żyje, więc jeżeli wleci nam node, to nie dowiemy się o tym szybko. No i mamy swoje czasy reakcji na to, co się stanie i to troszeczkę może być bolączką, w szczególności jak źle zrobimy aplikację.
SW: Tak, to jest taki trade off między tym. Albo będziemy bardzo często pytali się, dzięki czemu mamy szybką informację, ale będziemy system obciążali, albo generalnie pytamy się rzadziej, ale obciążamy mniej. Ja dodam znowu z punktu widzenia systemu, budowania systemów, to to, co daje Kubernetes, czyli on daje dwa probe’y. Liveness probe i readiness probe. Jedna mówi o tym, że OK, aplikacja żyje, druga o tym, że możemy przyjmować requesty. To rozwiązuje 90% problemów na poziomie budowania aplikacji tak naprawdę, wdrożeń przede wszystkim. I jak patrzę, co potrzebują, to zgodzę się: wyłączenie jest ważne, ale że mamy te dwa proby z pudełka, wystarcza na pierwszy rok-dwa lata developmentu większości systemów.
ŁK: Ja patrzę właśnie z poziomu platformy, nie aplikacji. Dla ciebie rozwiązaniem będzie użycie, żeby twoja inicjalna liczba podów, to były trzy czy cztery właśnie instancje twojego serwisu i już dziś masz szansę, że zostanie to tak rozrzucone, że taka awaria właśnie node’a cię nie złapie.
SW: I co więcej, jak node się przekręca, to żeby nagle nie trafiło do niego sto requestów, tylko żeby trafiło dopiero jak będzie readiness probe na OK, czyli on się rozgrzeje, cash się zbuduje, aplikacja się zdżituje i wszystko będzie w porządku. I tym można sterować z punktu widzenia aplikacji. To jest dla mnie niesamowita wartość.
ŁK: No i druga rzecz, która mi się trochę rzuca, to są, przy tym jak mówię, brak failure detection. Dla małych klastrów Kubernetes może być nie do końca dobry, jak nie jesteśmy świadomi. Ze względu na bezwładność i sposób właśnie działania.
SW: Dobrze. To zdefiniujmy małe, bo małe to jest bardzo względne pojęcie.
ŁK: Wiesz co? Ja powiem, czy zaboli cię jak wyrzucisz 10-20% infrastruktury?
SW: OK!
ŁK: Bo jeżeli sobie popatrzymy przy skali, jeżeli wypadnie ci 10 serwerów ze 100, to nie ma tragedii. Jeżeli wypadnie ci 50 z 500, tym bardziej nie ma tragedii, jeżeli wypadnie ci na przykład 2 z 10, które często zaczynają być dopchane…
SW: To zaczyna być ciekawie.
ŁK: Tak, więc to będzie dla mnie właśnie ta skala, przez to, że właśnie jest ten stan raportowany, to on powoduje trochę bezwładności.
SW: Tak, ale to trochę wraca do tego, co jest trochę moim przeczuciem, to czy na ile Kubernetes ma sens przy małych systemach? I tu mam bardzo mieszane uczucia.
ŁK: Wiesz co? Dobra, to z perspektywy platformy, weź as a service.
SW: I tak! Z tym się w zupełności zgadzam.
ŁK: Tam, gdzie mam okazję, przy jakiejś mniejszych rozwiązaniach stosować Kubernetesa, to on właśnie twoją perspektywę, czyli dla dewelopera, deploymenty, probe’y, to rzeczy, które wprowadza do kultury pracy, naprawdę jest tego warte, ale nie jest warte tego utrzymywania.
SW: I też do tego właśnie dążę, dokładnie. Płacenie overheadu, utrzymania dla małych aplikacji - nie. Opis aplikacji - chciałbym go mieć, bo to ma wartość. I zgodzę się w tym momencie, że as a service zdecydowanie ma ogromny sens.
ŁK: I druga rzecz, która jest podkreślana przy Kubernetesie, jest to też sprzedaż tego produktu, że dostajemy agnostyczność względem infrastruktury i dostawców. Trochę mówiłeś o abstrakcji, wspominaliśmy na początku o abstrakcji z perspektywy aplikacji, ale dostajemy też dzięki temu właśnie w teorii agnostyczność od dostawców. Czyli możemy sobie to odpalić gdziekolwiek, gdzie mamy wirtualizację plus jakiś storage, który jest sterowany.
SW: Tak.
ŁK: No i tutaj to jest fajne, ale trzeba się nagłowić.
SW: Tak, ale znowu wracamy do tego, co mówiliśmy na wcześniejszych odcinkach, że jeżeli zgadzamy się z pewnym vendor lock-ingiem, czyli bierzemy as a service, to wiele problemów jest rozwiązanych. Jak chcemy być agnostyczni, to jest niższy poziom API zgodności i musimy się bardzo nagłowić.
ŁK: Tak, ale to dorzucę od siebie. Problemy, które widzę przy tej agnostyczności, z którymi ktoś się spotyka, budując platformę np., czyli dostarczając oferiting, gwarantując, no to pierwsza rzecz, to będzie jak zawsze słynna - sieć. No i w tym przypadku każdy vendrocloudowy ma swoje pluginy, one troszeczkę inaczej działają, trochę mają inną filozofię działania. Ale taką pierwszą, z którą się stykamy od strony aplikacji, to są load balancery i sposób wystawiania tych aplikacji do świata czy do wewnątrz firmy. I tam na przykład dotyka to już manifestu twojego, ponieważ mamy anotację. Na przykład load balancerem, pewne parametry load-balance, ustawienia na świat typu load balancer, że przed naszą apką stoi ten już zewnętrzny, publiczny czy prywatny load balancer. Tam są anotacje i trzeba już niestety coś ruszyć w aplikacji i wiedzieć w opisie aplikacji, opisie serwisu, trzeba wiedzieć, jak to zrobić, jeżeli wystawiamy bezpośrednio.
SW: Choć można to trzymać w osobnym pliku jbl-owym.
ŁK: No nie jest to w jbl-u, ale no niestety w tym manifeście chodzi o to, że to nie będzie tak, że grzebnę i przeniosę. Weźmy najsławniejszą anotację, czyli internal load balancer na true, opis w AWSie w Google’u i w tym, każdy ma swoją oddzielną anotację w metadanych.
SW: Tak zgadza się. Przenoszalność jest z gwiazdką, mianowicie można przenieść, ale trzeba się trochę nagłowić.
ŁK: Dobra. Następną rzeczą będzie storage. Mówię o storege’u: nie używajcie! To jest od razu moja perspektywa, jak nie musicie, to nie używajcie. No i tam znowu trafiamy w specyfikację easów, na których to jest trzymane. Od dostawców. Czyli weźmy na to z Ajourem będą problemy, są czasami jak node się wywali czy ogólnie długi czas przepinania dysku volumenu z jednego do drugiej maszyny. I to jest specyfika easu i koniec.
SW: Tak, ale ja w ogóle jestem zdania, że korzystanie z dysków, czyli interfejsu dyskowego w chmurze, no to od tego mamy bloba.
ŁK: Czy NFSa, tak. Ale ludzie czasem mają pewne potrzeby, w szczególności, czy jak mówimy jeszcze o problemach, no to w AWSie są EBSy są per zona. Czyli jak masz znowu mały klaster, to może się zdarzyć, że nie ma gdzie się przenieść ten pode, bo w tej zonie już gdzie jest EBS od niego, nie ma już węzła w tym momencie. I trzeba poczekać, kiedy autorepair się odpali. Więc to jest to. Druga rzecz troszeczkę z filozofii jest, to fajnie powiedział Hightower z Google’a, że z Kubernetesem jest tak, to magnetyczność, że być może odcinamy się od ciekawych futere’ów. Tak jak ty powiedziałaś o blobie, przed chwilą wspomniałeś, że czasami się nie zastanawiamy nad wzięciem gotowych API, które są dobre przez to, że się w tym antyvendor lock-ingu zapinamy mentalnie, że będziemy mieli agnostyczne.
SW: Tak, tak samo, jak chcieć wymieniać bazy danych w trakcie działania i być nie zależnym, czy będziemy chodzili na Oracle’u czy na SQL Serverze czy na MySQL.
ŁK: Czekaj, a to nie bajka o REMach?
SW: Cicho, cicho! Bajki są dobre w pewnym momencie życia.
ŁK: Jak rzuciłeś trochę z bazami danych i stanowością. I ogólnie tu się na szczęście zgadzamy. Stanowość, czyli statefule w Kubernetesie, są i to mocno.
SW: A ja skontruję to: nieprawda. Ja daję taką zagadkę często na szkoleniach: co ma 50 lat i każdy ma to w swojej aplikacji? Baza relacyjna. Stateful są w każdym projekcie IT, bo nikt nie ma pomysłu jak to wdrażać. Ta baza ma 50 lat i dalej nie mamy pomysłu jak robić upgrade’owe skrypty na przykład.
ŁK: Dobra, czyli ustalmy. Między innymi trzymanie stanu - dla mnie to będzie tak naprawdę baza danych albo coś, co trzyma in memory i musi się z replikować. Więc pierwszą rzeczą Kubernetes podchodzi do stanowości bardzo ciekawie i uproszczenie. Nie powiem, że luźno. Uprościli bardzo. Stanowość oznacza to, że ten stateful, kiedy nasza instancja wystartuje, jest do śmierci przypisana na jednej instancji. Przykładowo jeżeli wywalił się node, to taka instancja nie zostanie nigdzie odpalona, dopóki jej nie skasujemy bądź nie skasujemy węzła, na którym była. Więc ma swoją właśnie problematyczność, a jeżeli użyjemy deploymentów do postawienia bazy danych na przykład, czyli można pójść (pisałem na blogu artykuł na temat Linkedin Driven Development), tam jest taki przykład człowieka, który mówi, że mu wszystko działa i postawił bazę danych w State Klasie, ale mówi, że mu się dysk przepina. Więc… to tak do końca nie działa, bo możemy trafić na momenty konfliktów czy problemów. Czyli tak naprawdę polega to na tym, że mamy stałe miejsce, w którym będzie ustawiony nasz serwis, i stałą nazwę. I to daje. No i to, co wspomniałeś właśnie przy baza danych, jest to problematyczne. Problematyczne, więc na dzień dobry jeżeli mówimy, czy trzymać bazę danych w Kubernetesie? Na dzień dobry powiem, że nie. I to jest takie dla wszystkich, którzy zaczynają, to jest nie, potem pojawia się konsultanckie “to zależy”.
SW: Tak. Ja z perspektywy oceny ryzyka projektów i łatwości zarządzania tym, też mój default jest “nie”. Czemu? Bo ja - by default - powiem “Zacznij od bazy relacyjnej”, to jest dobry punkt, żeby gdzieś pójść w innym kierunku. A relacyjna w Kubernetesie - może tak niekoniecznie.
ŁK: Dobra. I tutaj jest sobie coś takiego, jest post Google’a, który dobrze to pokazuje, problemy, overheady… Jest na temat, czy odpalać czy nie odpalać te bazy danych w Kubernetesie. I jest tak że jest gros baz, które są gotowe na działanie w takim statefulu, który daje Kubernetes. Rzucając: MongoDB, Cassandra, czyli bazy, które posiadają własną replikację i własny konsensus.
SW: I nie mają rotacji rozproszonych i nie są wysoko spójne.
ŁK: Tak. Czyli takie bazy możemy czy Elastica z dużą ilością replik, możemy możemy właśnie odpalić w Kubernetesie. Jest to jeden z przykładów i wtedy można się zastanowić, jeżeli już umiemy tego statelessa, żeby zrozumieć statefula i problemy, które idą. I to wtedy zadziała. Jest jeszcze takie jedno “ale”, o który mówi GCP, żeby używać też baz danych, które mają (jeżeli już chcemy korzystać) operatorów. Czym jest operator? Wyjaśnimy zaraz. Jest sobie custom resource definition, czyli manifest, o którym powiedziałaś. Ty możesz zbudować własne obiektyw Kubernetesie. Nie tylko możesz rozszerzyć jego funkcjonalność, czyli dodać swoje nowe metadane, nowe opisy dla swoich usług. I jak jest realizowane? No właśnie. Można napisać sobie serwis, instancje, żyjątko, które będzie przypinało się do Kubernetesa i wykonywało jakieś akcje na podstawie tych custom resource definition, naszych obiektów. I przy bazach danych działa to w ten sposób, że wrzucamy opis, że ja chcę teraz bazę danych o takiej nazwie, z takim silnikiem, takie parametry. I on z tego generuje deployment i utrzymuje jego stan na klastrze, zarządza upgradem i innymi rzeczami. I wtedy to ma sens. Przykładem nawet z relacyjnych, które wchodzą i są rozwiązania, na przykład jest Postgres od Crunchy na Kubernetesa, który właśnie jest tak sterowany. Czy nawet Failover jest sterowany przez operator. Czy w Microsofcie teraz SQL Server 2019 z Always On’em - też będzie dostarczony operator, żeby odpalić klastry Always On enterprise’owe na Kubernetesie.
SW: Max to w ogóle sporo zainwestował w Always Ona na SQL Serverze. On się w ciągu otatnich czterech lat dość mocno pozmieniał i działa dużo lepiej.
ŁK: Tak, jest wsparcie na Linuxie i następną rzecz też będą używać, jest to w Preview, zaraz pewnie wyjdzie, w ciągu kilku-kilkunastu tygodni, na przestrzeni tego jeszcze roku wyjdzie do produkcji. Więc można zdeployować sobie, wpisujemy, że chciałbym tego SQL Server w nasz obiekt manifestu, właśnie, że chciałbym taką bazę danych. I taki operator, jak zobaczy taki obiekt, jak się pojawi, to to deployuje. I to jest też ciekawa rzecz, właśnie rozszerzalność tego opisu, czyli można dodawać do Kubernetesa swoje własne rzeczy.
SW: Do spróbowania, jak najbardziej. Dobrze, to chyba czas nas goni, trzeba to zwrapować. Twoje dwie myślisz czy ileś myśli, które chciałbyś, żeby były wyniesione z tego?
ŁK: Dobrze. To pierwsza jest taka: jak robisz pojedynczą aplikację, użyj gotowych rozwiązań. Jeżeli chodzi o Kubernetesa, jeżeli chcesz go użyć, to do 100 węzłów nie zastanawiaj się, weź wszystko, co daje ci operator. Jeżeli zaczynasz i nie wiesz, co chcesz osiągnąć, weź gotowe rzeczy, czyli gotowy monitoring, metryki, zarządzanych klaser przez Vendora.
SW: To trochę wraca do tego, co powiedzieliśmy przy agile generalnie, szybki czas do działania. Tak, zgadzamy się.
ŁK: Tak, bo stoi tam parę rzeczy. No i konieczną rzeczą, jeżeli też zaczynasz, robisz lub na tym Kubernetes się z statelessy. W pełni świadomie rób statelessy. Bazy danych na start trzymaj sobie poza klastrem. Mogą być to zwykłe VMki, jeżeli potrafisz w Immutable IaaS - super. Jeżeli nie potrafisz, to spróbu, zacznij z database as a service. Jeżeli żądasz tej agnostyczności, no to użyj Postgresa czy MySQLa, który jest dostępny tak naprawdę na większości topowych cloudów as a servise.
SW: Czyli podsumowując, to start simple and complicate things as you move on. No, zgadzalibyśmy się. To ja dorzucę swoje dwie rzeczy - z punktu “Czemu warto?”, bo uważam, że zdecydowanie Kubenetesa warto, mimo że ma jakieś swoje problemy. Dla samych deploymentów - warto, opisu środowisk, opisu całych systemów przede wszystkim - warto, zdecydowanie, bo to jest taki pierwszy opis, którzy deweloperzy wykorzystują i może być ładnie przekazany potem do deploymentu i używany cały czas. Wchodzę w projekt, widzę pliki Kubernetesowe, odpalam aplaya i cały system mi działa. To jest fenomenalne. Druga myśl, która nawiązuje bardzo mocno do twoich małych systemów, to jest to, żeby pamiętać o tym o overheadzie. Żeby nagle nie stwierdzić, że “O! Mam moje trzy instancje, trzy serwisy, które ze sobą rozmawiają raz na jakiś czas, to użyję Kubernetesa i będzie wszystko chodziło szybciej i lepiej”. Overhead istnieje, nie jest tani. Będzie się zmieniało. Ale to trzeba mnie zawsze z tyłu głowy, bo za to płacimy sporo. Ale warto, żeby było pozytywnie.
ŁK: Tak, warto, na tą chwilę warto.
SW: Zdecydowanie. Kończymy?
ŁK: Kończymy! Na razie!
SW: Na razie!