kkempin’s dev blog
Published in

kkempin’s dev blog

Kubernetes

W ramach podcastu “Porozmawiajmy o IT” miałem okazję porozmawiać z Maćkiem Kuźniarem i Zbyszkiem Kamińskim o Kubernetes.

Posłuchaj naszej rozmowy w wersji audio 🎧 👇

Cześć! Dziś moimi gośćmi są Maciek Kuźniar, pomysłodawca, główny architekt i CEO polskiej chmury obliczeniowej Oktawave, od 2003 roku związany z K2 Internet S.A., gdzie odpowiadał za rozwój i utrzymanie infrastruktury IT i współtworzył biznesowy sukces działu zajmującego się hostingiem zaawansowanych systemów IT dla kluczowych klientów. Autor koncepcji technologicznie wspierających rozwój biznesu oraz rozwiązań architektonicznych, gwarantujących wysoką dostępność i spełniających rygorystyczne wymogi serwisowe.

Drugim gościem jest dzisiaj Zbyszek Kamiński, Cloud Masters & Premium Support Director Oktawave. Z chmurą Oktawave związany od 9 lat, a w branży IT od 1999 roku — piękny wynik! Zarządza zespołami Premium Support i Cloud Masters, wyspecjalizowanymi w analizie, optymalizacji, migracji i utrzymaniu systemów IT w chmurze. Odpowiada za wsparcie dużych portali internetowych — tui.pl, pracuj.pl czy serwisów grupy Edipresse — w trakcie i po migracji do chmury. Doradza w zakresie optymalnego zarządzania chmurą prywatną, publiczną, hybrydową oraz środowiskami multi-cloud. Pomaga skorzystać z rozwiązań globalnych dostawców, takich jak AWS, Azure, JCP.

Maciek, Zbyszek, bardzo miło mi Was gościć w podcaście!

Maciek Kuźniar: Dziękujemy, nam też jest bardzo miło!

Zbyszek Kamiński: Cześć, Krzyśku! Dzień dobry wszystkim!

Z Maćkiem i Zbyszkiem będę chciał dzisiaj porozmawiać o bardzo gorącym, można powiedzieć temacie, o którym się dużo słyszy w świecie cloud ostatnio, czyli o Kubernetes.

Chciałem natomiast rozpocząć od takiego standardowego punktu każdego mojego podcastu, czyli pytania do gości — czy słuchacie podcastów, jeśli tak, to może macie jakieś swoje ulubione audycje?

M.K.: Wiesz co, słuchamy. Czasem rzadziej, czasem częściej. Ja osobiście czasami słucham takich technologicznych podcastów, Zbyszek pewnie podobnie, choćby Niebezpiecznika, ale słucham też takich podcastów lifestylowych, np. popularnego pewnie dzisiaj Filipkowskiego z Zaprojektuj swoje życie, to naprawdę fajny podcast. I rzeczywiście czasami siedząc w samochodzie, wracając do domu, przesłuchuję sobie te podcasty Filipkowskiego, niektóre są naprawdę bardzo fajne.

Z.K.: Ja podobnie, tak jak Maciek powiedział. Rzeczywiście będąc blisko świata technologicznego, te podcasty technologiczne bardzo pomagają w zapoznaniu się z technologią, nowinkami technologicznymi itd., niekoniecznie specjalnie rezerwując sobie czas na tę naukę, możesz po prostu słuchać w dowolnym momencie.

Natomiast jeśli chodzi o coś poza technologicznymi rzeczami… My jesteśmy taką rodziną parkolubną, tak to nazywamy. To znaczy generalnie jesteśmy zakręceni z żoną i córką na parki rozrywki typu Disneyland, Warner Bros w Madrycie itd. Korzystamy więc również z takich podcastów, dlatego że tam najwięcej można się dowiedzieć o jakichś nowinkach, o nowych atrakcjach, o nowej formie zakupu biletów itd. Jest to więc bardzo przydatne.

M.K.: Z tego się nigdy nie wyrasta chyba!

Z.K.: Podobno nie! Warto zawsze być dzieckiem.

Dokładnie, nigdy nie zaszkodzi trochę takiej fantazji i jednocześnie takiego odpuszczenia tematów i niezastanawiania się co będzie jutro, pewnie! Ale to jest inny temat.

Dzisiaj mamy bardziej techniczną rzecz do przedyskutowania. Chciałbym zapytać o Wasze doświadczenia związane z Kubernetes. Właśnie! Lepiej mówić kubernetes, kiubernetis — jak jest poprawnie według waszej wiedzy?

Z.K.: Ja kiedyś robiłem takie dochodzenie, dlatego, że sam używałem chyba wszystkich form, o których powiedziałeś, a jest ich jeszcze więcej, i to, co mi się udało znaleźć i staram się w sobie wyrobić taki nawyk, to mówienie kubernetis.

Kubernetis, świetnie. Brzmi bardzo dobrze.

To zacznijmy może od początku — czym ten Kubernetes jest, jak powstał, kto go stworzył, na jakie problemy właściwie odpowiada i dlaczego się o tym temacie teraz całkiem sporo mówi?

M.K.: Wiesz co, to jest bardzo ciekawa historia. Zbyszek, byłem pierwszy.

Z.K.: Dobrze, proszę bardzo Maćku.

M.K.: Pierwowzorem dla Kubernetesa był system, który powstał w Google, system ten nazywa się Borg — nawiązanie do Star Treka. To jest taki system, którego celem było zarządzanie właściwie całą infrastrukturą i wszystkimi zasobami w Google, i próba odpowiedzenia na problem polegający na tym, że setki czy dziesiątki tysięcy inżynierów mają potrzebę skorzystania z zasobów, te zasoby są umieszczone w różnych fizycznych lokalizacjach, w różnych miejscach. Trzeba było więc zbudować jakąś taką warstwę abstrakcji, taką jedną wielką maszynerię, która się właściwie nigdy nie psuje i która ma nieograniczoną ilość zasobów do dyspozycji w każdym momencie. I to był Borg. Borg do dzisiaj istnieje, zarządza chyba wszystkimi centrami danych w Google, jest cały czas rozwijany. Taka ciekawostka — rozwijany jest przez warszawski oddział Google, inżynierowie w Polsce pracują nad Borgiem.

U podstaw Kubernetesa leży taka sama intencja, taki sam cel, jak leżał u podstaw Borga, mianowicie zbudowanie systemu, który stanowi taką jedną wielką maszynę, tylko że tym razem zbudowaną w ekosystemie kontenerów. Maszynę pozwalającą zarządzać nie tyle infrastrukturą taką fizyczną w centrali danych, ile pozwalającą zarządzać kontenerami, i upraszczać procesy, które są z zarządzaniem tymi kontenerami powiązane.

Dzisiaj jest chyba 7 lat od wydania Kubernetesa, to gdzieś w 2014 roku się wydarzyło. Można powiedzieć, że ta platforma jest naprawdę dojrzała, zyskuje niezwykłe tempo rozwoju, bardzo wiele firm z tego korzysta. Czym właściwie jest Kubernetes? Kubernetes to platforma do zarządzania, do skalowania, do automatyzacji wszystkich aplikacji kontenerowych, tak bym to nazwał. Czyli jeśli chcemy stworzyć aplikację i zapakować ją w kontener, to być może dobrym pomysłem będzie umieścić ją w Kubernetesie.

Zapewne wielu słuchaczy ma do czynienia, chociażby developersko pracując na co dzień z Dockerem.

I chciałbym teraz Was zapytać, czym właściwie się różni Kubernetes od Dockera? Dlaczego potrzebujemy dwa systemy związane z konteneryzacją, czy nie wystarczy nam tylko jedno rozwiązanie?

Z.K.: To może teraz ja spróbuję wyjść pierwszy, Maćku.

Generalnie rzeczywiście bardzo często te zwroty, ta terminologia się przecina. To znaczy bardzo często mówiąc o Kubernetesie, mówimy również o Dockerze. Sam Docker to jest ogólnie technologia i forma pliku kontenera. Docker służy do automatyzowania, wdrażania aplikacji, tworząc takie samowystarczalne kontenery. Dlatego chcąc mówić bardziej precyzyjnie, jeżeli robimy porównanie pomiędzy Kubernetesem a Dockerem, powinniśmy porównywać Kubernetesa i Docker Swarma. Bo tak naprawdę w tym przypadku oba narzędzia są właśnie orkiestratorami, którzy służą do zarządzania np. obrazami utworzonymi w tej danej technologii.

I teraz jeżeli mielibyśmy to porównać w taki sposób najbardziej przystępny, tak mi się wydaje, to taką jedną z największych różnic jest to, że Kubernetes pozwala na klastrowanie kontenerów platformy Docker. Docker Swarm działa na trochę innej zasadzie, natomiast w momencie, w którym myślimy o zbudowaniu środowiska, które będzie właśnie i odporne na awarie, i skalowalne, i pomoże nam w ogarnięciu tego naszego świata aplikacyjnego, to właśnie tu z pomocą przychodzi przede wszystkim platforma Kubernetes. Jest ona w moim odczuciu platformą po prostu bardziej złożoną od rozwiązania Docker Swarm. Z mojej perspektywy Docker Swarm bardziej pomaga w ogarnięciu takich jednostkowych projektów związanych z całą konteneryzacją, a Kubernetes jest już do zastosowań o skali zdecydowanie większej.

Myślę, że też to, co warto powiedzieć, już może poza samym porównaniem, to jest to, że Kubernetes nie musi być od razu wyciągany na początku naszej drogi do technologii kontenerowej. Tak naprawdę wiele projektów jesteśmy w stanie opracować, przygotować, uruchomić z wykorzystaniem po prostu obrazów właśnie dockerowych. Natomiast przy większych zastosowaniach, zdecydowanie polecałbym już skręcenie w stronę właśnie Kubernetesa.

M.K.: Wiecie co, to jeszcze jedna uwaga z mojej strony. Tak naprawdę Docker i Kubernetes to są dwie różne rzeczy. Można to sobie wyobrazić w ten sposób, że mamy taki gigantyczny statek transatlantyk, który płynie, i na tym transatlantyku są tysiące kontenerów poupychane. Kontenery na tym transatlantyku to są obrazy dockerowe. A transatlantyk to jest Kubernetes.

Kubernetes jest takim miejscem, w którym można uruchomić te wszystkie kontenery zbudowane za pomocą Dockera, czyli to są kontenery dockerowe. Mogą być też inne, ale zwykle używa się kontenerów dockerowych. W tych kontenerach, w tym obrazie dockerowym jest aplikacja, którą Kubernetes zarządza. Aplikacja może się składać z wielu takich obrazów, zwykle to nie jest jeden obraz, zwykle jest ich kilka/kilkanaście, za chwilę będziemy o tym pewnie więcej mówić. Na Kubernetes trzeba patrzeć jako na platformę, a Docker jest komponentem tej platformy.

Rozumiem. Myślę, że to jest bardzo obrazowe pokazanie faktycznie różnic i cieszę się, że to Maciek sprostowałeś, żebyśmy nie porównywali jabłek z gruszkami, bo to faktycznie są dwie różne rzeczy.

Mówiliście wcześniej, że automatyzacja jest jednym z benefitów, który może wynikać z zastosowania Kubernetesa. Skoro automatyzujemy, to przede wszystkim chciałbym Was zapytać o to, co automatyzujemy w przypadku Kubernetesa i jakie benefity zyskujemy dzięki wprowadzeniu takiej automatyzacji, jak tym zarządzamy?

M.K.: Ja nie wiem, czy to jest dobre pytanie, czy można zapytać co automatyzujemy w przypadku Kubernetesa. Zróbmy krok wstecz — co właściwie automatyzujemy dzisiaj w IT? Dzisiaj w IT automatyzujemy procesy. I teraz jakie to mogą być procesy w IT? Pewnie jest ich szereg, ale taki, który przychodzi nam od razu na myśl, to jest automatyzacja procesu związanego z wytwarzaniem aplikacji. Piszemy aplikację, potem jak ją już napiszemy, to ją testujemy, jak ją przetestujemy, to uruchamiamy w systemie produkcyjnym, a jak ją w tym środowisku produkcyjnym uruchomimy, to za chwilę mamy poprawki do tej aplikacji, nowe wersje — to jest proces.

Kubernetes jest narzędziem do automatyzacji. Automatyzować możemy m.in. procesy i dobrym przykładem procesu, który możemy zautomatyzować, jest właśnie proces wytwarzania aplikacji. I tu mówimy np. o takich zjawiskach jak CI/CD, czyli Continuous Integration/Continuous Development, które to terminy — za chwilę będziemy o nich więcej mówić — są już terminami, które mają już istotne znaczenie w świecie Kubernetesa. Natomiast wracając jeszcze do pytania, to chyba raczej nie da się — Zbyszek, co ty na to? — automatyzować samej aplikacji. Automatyzować możemy proces.

Z.K.: Oczywiście, automatyzujemy zdecydowanie proces dostarczania czy integracji itd., natomiast ja bym jeszcze troszkę inaczej powiedział. Bo dzisiejsze czasy właściwie wymuszają — a ta technologia w tym po prostu pomaga — żebyśmy automatyzowali wszytko, co jest możliwe. To znaczy generalnie zarówno po tej stronie pracy developerskiej… Chociaż developerskiej może mniej, chciałbym powiedzieć o tej stronie bardziej opsowej generalnie, czyli taka zasada, że jeżeli robisz coś po raz kolejny, po raz drugi, trzeci, czwarty, to znaczy, że można to zautomatyzować.

Środowiska związane z kontenerami, aplikacje uruchamiane w formie mikroserwisów — ta technologia pomaga nam w tym, żebyśmy większość procesów, o których wspomniał Maciek, procesów związanych z dostarczaniem, zarządzaniem, utrzymywaniem naszej aplikacji i środowiska, na którym ta aplikacja działa, po prostu automatyzowali.

Tak właśnie rozmawiam również z klientami, i u nas w zespole tak do tego podchodzimy — w momencie, kiedy możesz, jeżeli powtarzasz swoją pracę, to znaczy, że możesz spróbować ją zautomatyzować. Jeżeli mamy więc pytanie o to, co automatyzować, to właściwie wszystko, co jest możliwe. I zarówno to, w jaki sposób tę aplikację dostarczysz, jak ją zbudujesz, jak ją uruchomisz, jak i jak ją utrzymasz — to jest ciągły proces. Właśnie tym się charakteryzuje cykl życia aplikacji w naszym środowisku — ona jest stale zmieniana, stale remiksowana, stale upgrade’owana, pewnie nazw jeszcze można tutaj milion wymyślić, natomiast chodzi o to, że to jest proces ciągły. Im więcej z tego procesu zautomatyzujesz, tym po prostu będziesz miał z tego większe benefity.

M.K.: Tak, tylko mi chodziło o to, że to jest automatyzacja zadań związanych z rozwojem aplikacji. Nie da się za pomocą Kubernetesa, czy w ogóle systemu automatyzacji takiej opartej o kontenery, automatyzować, nie wiem, np. pracy fabryki.

Z.K.: Oczywiście, tak! Zgadzam się z tobą w 100%, że rzeczywiście taśmy produkcyjnej w ten sposób nie zautomatyzujemy. Ale np. rzeczy, które z tej taśmy wpadają nam do różnego rodzaju aplikacji, systemów, baz danych etc., to już można się pokusić o to, żeby tutaj rzeczywiście wdrożyć narzędzia automatyzacji, żeby te informacje w sposób łatwy, bardziej aktualny, mieć po prostu dostępne.

OK, to myślę, że mamy tutaj jasność.

Mam wrażenie, że padł taki mocny akcent na wydawanie aplikacji, że np. na CI/CD, że to jest fajna rzecz, którą można za pomocą Kubernetesa automatyzować, czy połączyć powiedzmy. Natomiast zastanawiam się też na ile, z waszego doświadczenia wynika, że wszelkiego typu utrzymanie, wszelkiego typu skalowanie na przykład aplikacji, zwłaszcza takiej, powiedziałbym, trochę rozproszonej, np. w architekturze mikroserwisów, czy to też jest dobre zastosowanie Kubernetesa?

Z.K.: Tak, oczywiście, że tak. Generalnie patrząc na to, w jaki sposób dziś tworzymy nowoczesne aplikacje właśnie, wydając je w formie mikroserwisów, czyli starając się budować aplikacje będące jak najdalej aplikacji monolitycznych, raczej wybieramy sobie poszczególne funkcjonalności, obudowujemy je właśnie kodem i dostarczamy do środowiska w postaci mikroserwisu, to to wszystko pomaga nam w tym, żeby tę aplikację potem łatwiej utrzymać, w tym, żeby ona była łatwiej skalowalna.

Z historii z życia wziętych — np. pojawia się jakiś pomysł na nowy ficzer. Masz aplikację, aplikacja ta jest nawet monolitem, załóżmy, dlaczego nie. To jest aplikacja monolityczna, obsługuje Twój biznes, nakręca Ci klientów itd. Masz zespół developerów, product ownera itd. Powstaje z tego jakiś pomysł — „słuchajcie, może byśmy zrobili taki ficzer do aplikacji”. I teraz w momencie, kiedy dołożysz sobie taki ficzer do monolitu, a ten ficzer spotka się z bardzo pozytywnym odbiorem Twoich klientów, to tak naprawdę umieszczając ten ficzer w monolicie, musisz skalować całość, żeby można było zadbać o dostępność tego ficzeru.

W momencie, w którym ten ficzer wydasz w formie mikroserwisu i zbudujesz to na takiej platformie jak właśnie platforma Kubernetes, to wtedy nawet w momencie, kiedy to zainteresowanie ze strony Twoich klientów będzie na tyle duże, że w sytuacji takiego monolitu masz problem, tutaj tego problemu mieć nie powinieneś.

Słuchajcie, to jest naprawdę przykład z życia wzięty. Rozmawiałem kiedyś z jednym klientem, który właśnie coś takiego przeżył. To znaczy wypuścili ficzer i nie spodziewali się nawet tego, że aż z takim odbiorem się ten ficzer spotka. Na początku nawet wpadli w taką małą panikę: „ej, kurczę, nie zadbaliśmy o to, nie zadbaliśmy o tamto, co teraz będzie?”. Okazało się, że wszystko było dobrze. Właśnie dlatego, że środowisko wspomogło ich w tym zwiększonym ruchu, w zwiększonym zainteresowaniu. Odpowiadając więc na twoje pytanie — tak, jak najbardziej tak.

Właśnie, to jest, mam wrażenie, często jeden z takich najczęściej wymienianych saving pointów właśnie Kubernetesa — że dosyć dobrze współpracuje z taką architekturą mikroserwisów, że możemy dosyć łatwo skalować całe takie rozwiązania, o czym Zbyszek przed chwilą powiedziałeś.

Chciałbym to na chwilę zderzyć z innym podejściem — z jakimiś usługami PaaS’owymi, gdzie nie musimy się zajmować całą tą administracją z ich usług, one po prostu dla nas są w jakiś sposób udostępniane. Dlaczego więc nie zrealizować naszej aplikacji właśnie z wykorzystaniem takich usług PaaS’owych w świecie chmury, w takim trochę kontrapunkcie do walki z Kubernetesem, z konfigurowaniem tego wszystkiego na własną rękę. Jakie tutaj plusy i minusy tych rozwiązań widzicie?

M.K.: Myślę, że dużo zależy od takiego zdroworozsądkowego podejścia do tego, co chcemy zbudować. Dzisiaj klient może mieć taką sytuację, że posiada już jakąś aplikację, która jest monolitem, chciałby ją rozwijać, ale z drugiej strony przerabianie całej tej aplikacji na architekturę mikroserwisową, dzielenie jej na komponenty, uruchamianie tego w jakimś frameworku dockeryzacji czy konteneryzacji, takim jak Kubernetes — to jest kawał roboty!

Ale przecież tę aplikację trzeba jakoś rozwijać, i są firmy, które dzisiaj dotarły już do takiego brzegu, gdzie nie są już w stanie postawić kolejnej kropki, bo ten monolit ma już w sobie zbyt duży ciężar gatunkowy, żeby go dalej rozwijać. Droga trudniejsza to jest engineering całej aplikacji, próba dockeryzacji czy konteneryzacji i wejścia w architekturę mikroserwisów, z drugiej strony można sobie pomyśleć: „kurczę, na pewno jest jakieś łatwiejsze rozwiązanie”.

Nierzadko takim łatwiejszym rozwiązaniem jest zastosowanie jakichś usług chmurowych, np. usług z kategorii platform as a Service, czyli te, które dostarczają już gotowe mechanizmy, dostarczają gotowe rozwiązania, np. jakiegoś problemu technicznego albo biznesowego, i można je stosunkowo łatwo „doczepić” do naszej monolitycznej aplikacji, w ogóle nie wchodząc w architekturę mikroserwisów.

W takim scenariuszu my dalej zostajemy z monolityczną aplikacją, ale jej dodatkowe funkcjonalności są realizowane przez takie platformowe usługi. To mogą być nowe rzeczy, nowe funkcjonalności, ale to może być też sposób na wyjście w jakiś sposób z monolitu, bo przecież możemy np. backend bazodanowy naszej monolitycznej aplikacji próbować zastąpić jakimś PaaS’owym backendem bazodanowym. Możemy obsługę serwerów wysyłki pocztowej SMTP wyłączyć z naszej aplikacji monolitycznej i zastąpić ją usługą PaaS’ową z jakiejś dużej chmury. I tak stopniowo możemy coraz więcej komponentów tej naszej monolitycznej aplikacji zastępować usługami PaaS’owymi, i za jakiś czas może się skończyć tak, że ta funkcjonalność monolitycznej aplikacji będzie na tyle nieduża, że przejście do architektury mikroserwisów będzie już proste.

Usługi PaaS’owe to są usługi, które są dzisiaj bardzo mocno zdefiniowane i będą zdefiniowane. Dostawcy usług PaaS’owych określają, co dana usługa czyni i w takim zakresie można tę usługę wykorzystywać. Z kolei nasza aplikacja może mieć różnego rodzaju funkcjonalności właściwe tylko dla naszej aplikacji — i nie kupimy usługi PaaS’owej, która akurat takie funkcjonalności realizuje, więc gdzieś jednak ten kod będzie musiał zostać po naszej stronie. Wtedy być może będzie musiał zostać już jako aplikacja taka mała, mikroserwisowa.

I możemy pozostać z taką architekturą hybrydową, gdzie część funkcjonalności będą realizowały albo monolityczne aplikacje, albo mikroserwisy po naszej stronie, jakieś właściwe funkcjonalności dla naszego rozwiązania, dla naszego pomysłu biznesowego, a część będzie realizowana przez usługi PaaS’owe z jakichś dużych chmur. I powstaje taka hybryda łącząca mikroserwisy po naszej stronie i usługi PaaS’owe od dostawców chmur.

Z.K.: Ja bym chciał tutaj nawiązać do tego, co Maciek teraz mówi. Absolutnie w żaden sposób nie powinniśmy na to patrzeć w ten sposób, że wejście w Kubernetesa wyklucza nam stosowanie usług PaaS’owych — absolutnie nie! Wszystko w zależności od naszego zapotrzebowania.

Co w sytuacji, kiedy np. mamy deployment ułożony w ten sposób, że ktoś u siebie ma zainstalowanego minikube’a, w tym minikube’ie ma wszystko, łącznie z bazą danych w Kubernetesie? Potem może to trafić do jakiegoś środowiska testowego w chmurze, gdzie jest Kubernetes, ta baza danych dalej może być uruchomiona jako płot np. w Kubernetesie. Co nie oznacza, że kiedy przechodzimy w kolejne stage’e naszej aplikacji, gdzieś nie pojawiają się jakieś usługi PaaS’owe.

Dlatego, że oczywiście w zależności od naszego zapotrzebowania, to może być zmienne. Czyli w zastosowaniach np. developerskich spokojnie możemy wszystko wepchnąć sobie w kontenery, uruchamiać i nie ma problemu, jest wszystko fajnie. Możemy też, jeżeli mamy np. takie, a nie inne zapotrzebowanie na przetwarzanie i taką, a nie inną ilość przetwarzanych operacji, w zależności właśnie od tego, jaki to jest typ środowiska, możemy dalej w tych środowiskach testowych, developerskich utrzymywać wszystkie usługi uruchomione w Kubernetesie. Natomiast np. środowiska wyższe typu środowiska stage’owe czy środowiska produkcyjne mogą spokojnie korzystać z usług PaaS’owych, np. właśnie tej wspomnianej bazy danych.

Co w sytuacji jednak, w której nasze zapotrzebowanie na bazę danych jest tak duże, że nawet usługi, które są Managed Services u dostawców chmurowych są za małe, bo np. opieramy się o jakieś limity, bo np. rzeczywiście potrzebujemy 20 tys. zapytań na sekundę w bazie danych i zaczyna się to robić problemem? Nic nie stoi na przeszkodzie, żebyśmy zrobili sobie hybrydę i przygotowali konfigurację systemów operacyjnych, dużych serwerów, które również w dalszym ciągu się skalują, np. wielkich maszyn wirtualnych, na których uruchamiamy sobie wtedy takie środowisko bazodanowe.

I ten Kubernetes, ta nasza aplikacja, niezależnie czy to monolityczna, czy podzielona na mikroserwisy, w zależności od tejże aplikacji i zapotrzebowania, może korzystać i być wspierana innymi usługami, więc PaaS przychodzi z pomocą. To nie jest tak, że musimy wszystko uruchamiać w Kubernetesie, nie! Możemy łączyć to wszystko i budować sobie swoistego rodzaju hybrydy.

👉 Czytaj dalej na: https://porozmawiajmyoit.pl/poit-133-kubernetes/

Dev and life blog. Thoughts about programming, design patterns, Ruby and life.