Strona korzysta z plików cookies w celu realizacji usług i zgodnie z Polityką Plików Cookies.


10.06.2019

Inteligentne zarządzanie...

W dniach 11, 12 i 13 czerwca – odpowiednio – w Gdańsku, w Warszawie i w Katowicach,...
27.05.2019

Rozwiązania na platformie GCP

Citrix SD-WAN i Citrix ADC
27.05.2019

Chmura hybrydowa

Dell Technologies Cloud
27.05.2019

Uproszczona komunikacja

Cisco Webex
24.05.2019

Konferencja IT Manager of...

W dniach 12–14 czerwca w Sopocie odbędzie się konferencja IT Manager of Tomorrow 2019. To...
24.05.2019

Ochrona sieci

Fortinet FortiOS 6.2
24.05.2019

Mniejsza złożoność

Rittal VX25 Ri4Power
24.05.2019

All-in-one NAS

QNAP TDS-16489U R2
24.05.2019

Układy SoC

AMD Ryzen Embedded R1000

Orkiestracja z Kubernetes

Data publikacji: 27-07-2018 Autor: Maciej Lelusz
DOSTĘP I SCHEMAT PRZEPŁYWU...

Kubernetes, oznaczany też skrótem K8S, jest orkiestratorem umożliwiającym uruchamianie skonteneryzowanych aplikacji. Projekt ten był na początku tworzony przez Google, które powołało go do życia zainspirowane wieloma latami doświadczeń w tworzeniu i uruchamianiu wysoce skalowalnych systemów w kontenerach poprzez zorientowane na aplikację API. Dziś K8S jest projektem open source, i ten właśnie produkt opisujemy w artykule.

Kubernetes to o wiele więcej niż tylko technologia udostępniona przez Google, w tym momencie to cała społeczność pracująca nad coraz bogatszym ekosystemem, jakim stał się ten projekt. Dzięki temu uwolnieniu oprogramowania spod skrzydeł Google Kubernetes stał się platformą spełniającą wymagania nie tylko ogromnych, wysoko skalowalnych infrastruktur internetowych gigantów, ale również umożliwił tworzenie infrastruktury dla aplikacji cloud-native mniejszym graczom, którzy mają zaledwie kilka hostów.

 
Zacznijmy od wyjaśnienia, czym są te opiewane w pieśniach bardów dystrybuowane skalowalne aplikacje i platformy zorientowane na API. Wyobraźmy sobie oto taką hipotetyczną sytuację, że mamy za zadanie uruchomić infrastrukturę pod aplikację stale obciążoną określoną liczbą użytkowników, ale obciążenie to może w każdej chwili wzrosnąć – dziesiątki tysięcy czy też nawet setki tysięcy razy. Pewnie taka sytuacja nie jest dla wielu z nas obca – nie ma to jak dobrze zdefiniowane wymagania aplikacji… ale są sytuacje, gdy nie da się tego w prosty sposób zdefiniować, a już z pewnością nie na samym początku rozwoju programu, bo nigdy nie wiadomo, czy aplikacja „chwyci” i jej popularność będzie rosła, czy też nie. Nikt nie jest w stanie przewidzieć zachowań przyszłych użytkowników, pojawiania się błędów w kodzie, kwestii wymagających optymalizacji itd. Aby przykład stał się bardziej realny, weźmy na tapetę znane i lubiane przez wszystkich strony umożliwiające komunikację za pomocą kamer internetowych. Oczywiście nie mówimy o tych stronach, o których właśnie pomyśleliście… oj, nie, nie! Mówimy tutaj np. o portalach do udzielania korepetycji. Normalnie na takiej stronie mamy ok. 2–3 tysięcy użytkowników, którzy oglądają materiały, komunikują się itd. Jednakże zdarzają się takie pory roku (lub dnia), gdy dopiero co pełnoletnie korepetytorki/korepetytorzy z krajów azjatyckich muszą uczyć swoich klientów po drugiej stronie globu, gdzie akurat jest wieczór (wiadomo, korepetycje zawsze są po pracy, zajęciach itp.). 
 
Zatem nagle strona, która spokojnie działała na 5–10 instancjach aplikacji, nagle potrzebuje ich znacznie więcej, i to w ciągu sekundy! Standardowa monolityczna architektura byłaby tu bardzo niewygodna – trzeba by dorzucać procesory do VM-ek, dosypywać RAM-u itd. Słabo się to skaluje. Wyobraźmy sobie, że oto jedna VM w konfiguracji 4 vCPU i 64 GB RAM obsługiwała około 1000 użytkowników. Aplikacja przetrzymywała dane i jak już potencjalny nasz klient wpadł na dany serwer, to na nim siedział (przyczepiony był na przykład za pomocą sesji). Kiedy liczba użytkowników szła w górę, trzeba było szybko za pomocą ręcznego mechanizmu zbadać, czy już wysyciliśmy serwer czy może jeszcze ktoś się zmieści, i, korzystając z load balancera, rozrzucić ruch. Jak brakło zasobów – szybko instalować nowy serwer. Brzmi to trywialnie na papierze, lecz w rzeczywistości jest trudne i długotrwałe. A to tylko skalowanie w górę. A w dół? A zmiana wersji? A awarie? Masakra. 
 
> Nowy pomysł na wirtualizację
 
Pomyślano więc o nieco innym podejściu. Zamiast wielkich VM – małe kontenerki (lub małe VM) realizujące bardzo konkretną funkcję – np. jedna odpowiada za logowanie, druga kolejkuje wiadomości (np. zapytania przekazywane za pomocą GUI, wiadomości pomiędzy użytkownikami, akcje, które należy zalogować, itp.), trzecia odpowiada za komunikację z bazą danych lub tą bazą danych po prostu jest. Wszystkie one porozumiewają się pomiędzy sobą za pomocą API – wewnętrznego języka aplikacji przesyłanego w stylu REST, za pomocą JSON, YAML itp. (języki formalne, uniwersalne, niezależne od języka, w którym napisana jest aplikacja). Poza ewentualnymi bazami danych żaden z elementów infrastruktury aplikacji nie przechowuje danych, a odpowiada za przechwycenie wpadających poprzez API danych, przetworzenia zgodnie ze swoją funkcją, przesłania zwrotnego lub przesłania dalej do kolejnych instancji odpowiedzialnych za następne funkcje. Czyli zamiast jednej ogromnej binarki i armii bibliotek mieszczącej się na monstrualnej maszynie wirtualnej, mamy wiele binarek i wiele zestawów bibliotek umieszczonych na wielu VM lub w przypadku Kubernetesa – w kontenerach w postaci naszych mikroserwisów.
 
Na początku może się to zdawać niepotrzebnie skomplikowane, ale pomyślmy, że gdy potraktujemy każdą z tych funkcji jako zdefiniowany element infrastrukturalny (np. w kodzie), to powoływanie ich automatycznie okaże się o niebo bardziej naturalne. Mniejsza aplikacja tworzy relatywnie mniej zależności, a co za tym idzie, jej konfiguracja podczas instalacji czy aktualizacji może być prostsza, kończy się mniejszą liczbą błędów, a ponieważ nie przetrzymuje danych użytkownika, nie jest z nim związana. Zatem każdy użytkownik może za każdym razem trafiać na inny węzeł serwerów aplikacji, a to sprawia, że nie musimy się martwić, że jakiś fragment infrastruktury nam padnie… lub będziemy go aktualizować. Taka aplikacja może być napisana w różnych językach (zależnie od modułu), które będą się ze sobą komunikować za pomocą API. Wszystko wygląda zbyt idealnie… W takim razie gdzie jest haczyk?
 
Przysłowiowy haczyk tkwi w tym, że takie new-wave-jezzy-funky aplikacje potrzebują platformy infrastrukturalnej, która będzie je wspierać. Dlaczego? Ponieważ czysta „blacha” z Linuksem lub „gołe” VM są zbyt surowe, aby zrealizować tak skalowalną, samoleczącą się infrastrukturę aplikacji – byłoby to skomplikowane i pracochłonne. Wymagałoby albo ogromnej liczby godzin pracy polegającej na tworzeniu automatów, albo ogromnego stosu technologicznego, prawdopodobnie za całkiem konkretne pieniądze… A na końcu, po miesiącach trudnej i żmudnej pracy napisalibyście Kubernetesa. Czy zatem nie lepiej po prostu z niego skorzystać? 
 
[...]
 
Bloger i niezależny konsultant z wieloletnim doświadczeniem w branży IT, specjalizujący się w wirtualizacji i cloud computingu. Posiada tytuły MCP, MCTS, VCP oraz VMware vExpert.  

Artykuł pochodzi z miesięcznika: IT Professional

Pełna treść artykułu jest dostępna w papierowym wydaniu pisma.

.

Transmisje online zapewnia: StreamOnline

All rights reserved © 2019 Presscom / Miesięcznik "IT Professional"