Aby pomóc w zrozumieniu zależności pomiędzy ww. pojęciami, warto przyjrzeć się różnym rodzajom wdrożeń aplikacji biznesowych i oprogramowania w środowisku serwerowym firmy. Tradycyjne wdrożenie, które nie jest już spotykane w firmowej infrastrukturze IT, to instalacja i uruchamianie wszystkich aplikacji bezpośrednio na fizycznym komputerze lub serwerze obsługiwanym przez tradycyjny system operacyjny.

Rozwiązanie takie, choć wygodne i łatwe do zarządzania, ma jednak szereg istotnych wad. Dwie najważniejsze to niewykorzystanie wszystkich możliwości i mocy obliczeniowej serwera, na którym w tradycyjnym modelu uruchamiane są aplikacje, i brak możliwości separowania zasobów dla poszczególnych aplikacji, co może przekładać się na problemy z alokacją zasobów.

Zobacz również:

• 5 priorytetów, które obniżają koszty chmury i usprawniają operacje IT

Innymi słowy, mamy tu do czynienia z sytuacją, gdy najbardziej zasobożerne programy zużyją niemal w całości dostępne zasoby serwera, spowalniając tym samym w istotny sposób pozostałe, uruchomione na nim aplikacje.

Można takie programy uruchamiać samodzielnie na pojedynczym serwerze, ale zwiększa to problem z niewykorzystaną mocą obliczeniową, a samo utrzymanie wielu serwerów, pracujących większą część swojego czasu „na pół gwizdka” jest bardzo kosztowne.

Pierwszą próbą rozwiązania problemów było wprowadzenie symulacji i emulacji do środowiska systemu operacyjnego. Symulacja polega na imitacji działania oprogramowania, lub częściej urządzenia na poziomie systemu operacyjnego hosta, którego architektura zgodna jest z symulowanym środowiskiem. W ten sposób można było stworzyć środowisko uruchomieniowe dla zasobożernych aplikacji, które nie wpływałoby na pozostałe działające na serwerze aplikacje. Emulacja polega na symulowania działania oprogramowania lub urządzenia, które nie jest zgodne z architekturą hosta.

Czas wirtualizacji

Dość szybko możliwości symulacji stały się niewystarczające i sięgnięto po mechanizmy wirtualizacji. W uproszczeniu, wirtualizacja polega na zasymulowaniu obecności wirtualnych zasobów, przydzielając poszczególnym procesom logicznym rzeczywiste, fizyczne zasoby serwera, komputera czy notebooka. Wirtualizacja pozwala na uruchamianie wielu maszyn wirtualnych na pojedynczym komputerze czy serwerze, nawet gdy wyposażony jest w jeden, jednordzeniowy procesor.

Co ważne, wirtualizacja umożliwia izolowanie aplikacji i procesów pomiędzy wirtualnymi maszynami, zwiększając bezpieczeństwo systemu jako całości, gdyż dane związane z jedną wirtualną maszyną nie są w prosty sposób dostępne dla pozostałych.

Wirtualizacja pozwala lepiej wykorzystywać zasoby fizyczne serwera i lepiej je skalować, gdyż do wirtualnej maszyny łatwo dodawać zasoby lub je odejmować, gdy uruchomione w dany środowisku wirtualnej maszyny aplikacje nie będą ich zbyt dużo zużywać.

Tak udaje się w racjonalny sposób zwiększyć wykorzystanie możliwości sprzętowych serwera i ograniczyć koszty związane z utrzymaniem sprzętu – przy wirtualizacji, jeden serwer jest w stanie zastąpić nawet kilka fizycznych maszyn. Warto dodać, że każda wirtualna maszyna jest z zewnątrz widziana tak jak pojedynczy, fizyczny komputer, który ma do dyspozycji własną pamięć, procesor, zasoby dyskowe, w tym własny system plików wraz z aplikacjami i bibliotekami, oraz zasoby sprzętowe i własny system operacyjny pracujący w zwirtualizowanej warstwie sprzętowej.

Jak widać, w wypadku tradycyjnej wirtualizacji mamy do czynienia z pełnym systemem operacyjnym, który działa w wydzielonym środowisku obsługiwanym przez system operacyjny komputera hosta. Jedną z najważniejszych zalet wirtualizacji jest możliwość uruchomienia wielu maszyn wirtualnych, na których mogą działać zupełnie inne systemy operacyjne, różne od systemu operacyjnego hosta.

Maszyny te ze względu na wysoki stopień izolacji są bardzo bezpieczne. Oznacza to, że np. zainfekowanie wirusem jednej z wirtualnych maszyn nie powoduje zarażenia ani zagrożenia zarażeniem pozostałych maszyn, co sprawia, że wirtualizacja chętnie wykorzystywana jest w centrach danych do obsługi usług sieciowych, w tym usług udostępnianych w chmurze.

Wirtualizacja ma też jednak wady. Maszyny wirtualne zużywają dużo zasobów komputera hosta, znacznie więcej niż w wypadku uruchomienia podobnego środowiska na pojedynczym, fizycznym serwerze, np. aby uruchomić daną aplikację na maszynie wirtualnej, hipernadzorca (ang. hypervisor), znany też pod nazwą Virtual Machine Manager (VMM), musi najpierw przydzielić dostęp do zasobów komputera, dzięki czemu aplikacja będzie mogła być załadować do pamięci.

Trwa to znacznie dłużej niż w wypadku fizycznego komputera, co zmniejsza wydajność maszyny i ogranicza liczbę efektywnie działających wirtualnych maszyn na jednym hoście, w zależności od jego mocy obliczeniowej do najwyżej kilku lub kilkunastu. Z punktu widzenia administratora niewygodna jest też instalacja systemów operacyjnych i ich konfiguracja na każdej z wirtualnych maszyn.

Sprzętowe wsparcie wirtualizacji

Aby usprawnić obsługę i działanie wirtualnych maszyn, producenci procesorów wprowadzili do swoich układów sprzętowe mechanizmy przyspieszające pracę hipernadzorcy przydzielającego dynamicznie dostęp dla poszczególnych wirtualnych maszyn do zasobów hosta. Istnienie Hypervisora wynika z faktu, że systemy operacyjne są zaprojektowane tak, aby mieć bezpośredni dostęp do fizycznych zasobów komputera, na którym działają. Hypervisor oddziela zaś system operacyjny wirtualnej maszyny od sprzętu, przejmując odpowiedzialność za sprawne udostępnianie zasobów.

I w tym miejscu pojawia się sprzętowa akceleracja. Rozdzielanie sprzętu i oprogramowania za pomocą hypervisora jest ważne również z punktu widzenia przenośności wirtualnych maszyn pomiędzy fizycznymi hostami.

Ponieważ hipernadzorca działa jako pośrednik pomiędzy oprogramowaniem a sprzętem, znacznie łatwiej jest przenieść z komputera na komputer całą wirtualna maszynę bez potrzeby instalowania na wirtualnej maszynie nowych sterowników czy aktualizowania systemu-gościa.

Producenci procesorów, widząc coraz większą popularność wirtualizacji, wprowadzili do jednostek centralnych mechanizmy sprzętowej akceleracji działania hipernadzorcy. Chodzi o rozwiązania Intel Virtualization Technology (Intel VT, obecnie oznaczane jako VT-x) oraz AMD Virtualization (AMD-V). W wypadku obu platform wirtualna maszyna używa zazwyczaj realnego procesora i zaalokowanych dla niej obszarów pamięci, a emulowane są pozostałe elementy platformy sprzętowej.

To dlatego wirtualna maszyna „widzi” dokładnie taki sam procesor, jaki jest zamontowany w komputerze hoście, a zadania wirtualnych maszyn dzielą pamięć operacyjną z zadaniami systemu gospodarza.

Działanie obu technologii polega na dodaniu w specjalnych rejestrach procesora informacji, do której wirtualnej maszyny należy dane zadanie. Dzięki temu przyspieszyć można przełączanie zadań i system operacyjny oraz realizowane na nim aplikacje wykonywane na wirtualnej maszynie działają niemal tak szybko jak na fizycznym komputerze. Daje to możliwość zwiększenia liczby wirtualnych maszyn uruchomionych na komputerze-hoście.

Ponadto procesory z wirtualizacją sprzętową mają wbudowane specjalne mechanizmy chronienia obszarów pamięci wykorzystywanych przez poszczególne wirtualne maszyny, dostępu do urządzeń PCI, komunikacji z portami I/O w obrębie platformy sprzętowej itp. Jeśli procesor nie wspomaga wirtualizacji, ww. funkcje muszą być realizowane programowo, co spowalnia działanie komputera i rodzi niebezpieczeństwo, że awaria jednej maszyny wirtualnej może wpłynąć na działanie pozostałych.

Konteneryzacja

Konteneryzację traktuje się często jako lżejszą formę wirtualizacji. Nie uruchamiamy tutaj wirtualnych maszyn, a jedynie wirtualny „pojemnik”, zwany kontenerem, w którym działają wykorzystywane przez nas aplikacje. Tak więc, z punktu widzenia aplikacji, kontenery są odrębnymi i niezależnymi instancjami środowiska uruchomieniowego – mają własny wydzielony obszar pamięci RAM oraz dysku, jak również własny adres IP do komunikacji sieciowej, a także własną listę procesów.

Kontenery mogą komunikować się między sobą w ramach ściśle zdefiniowanych kanałów wymiany informacji, co nie jest możliwe w wypadku wirtualnych maszyn, które są od siebie odseparowane. Najważniejszą różnicą jest więc to, że system operacyjny jest zawsze współdzielony z hostem! Nie ma możliwości uruchomienia aplikacji w innym środowisku niż to środowisko (system operacyjny), które zainstalowane zostało na fizycznym komputerze hoście.

Taka konstrukcja kontenera sprawia, że różnica w wydajności pomiędzy aplikacją „kontenerową”, a aplikacją działającą na fizycznym sprzęcie staje się naprawdę niewielka. Istotne jest to, że zachowane są zalety wirtualizacji, takie jak: skalowalność, przenośność i separacja poszczególnych instancji.

Należy pamiętać, że konteneryzacja nie jest następcą wirtualizacji. Oba rozwiązania mają wady i zalety. W wypadku wirtualizacji mamy do czynienia z w pełni izolowaną i bezpieczną maszyną wirtualną, która jest jednak dość zasobożerna. W konteneryzacji jest szereg środowisk uruchomieniowych, które pozbawione są m.in. pełnej izolacji procesów, ale oferują wydajne i szybkie środowisko, jakie można łatwo i szybko wdrożyć w firmie.

Zastosowanie jednego z tych rozwiązań zależy od potrzeb organizacji. Do istotnych wad konteneryzacji zalicza się uzależnienie od systemu operacyjnego hosta. Aby ominąć ten problem, w praktyce często uruchamia się wirtualną maszynę z potrzebnym nam systemem operacyjnym i dopiero wówczas tworzy środowisko kontenerowe. Takie hybrydowe środowisko daje administratorom IT wystarczająca elastyczność i skalowalność, a szybkość działania jest nieznacznie niższa niż czystego środowiska kontenerowego.

Narzędzia do konteneryzacji

Najbardziej znanym i najczęściej wykorzystywanym narzędziem do konteneryzacji jest Docker, udostępniany na zasadach open source. Docker to platforma działająca w modelu klient-serwer, która wykorzystuje otwartą bibliotekę runc, powstałą w ramach inicjatywy Open Container Initiative. Jej celem jest standardyzacja rozwiązań konteneryzacji.

W kontenerach Dockera znajduje się nie tylko kod uruchamianego przez nas programu, ale również wszelkiego rodzaju narzędzia oraz biblioteki systemowe i skonfigurowane środowisko uruchomieniowe. Takie rozwiązanie gwarantuje, że oprogramowanie zawsze będzie działało w identyczny sposób, bez względu na to, w jakim środowisku zostanie wdrożone.Kontenery wraz z ww. zawartością działają niezależnie od siebie i nie wiedzą o swoim istnieniu, dopóki ich o tym nie poinformujemy. Jeśli chcemy uruchomić bazę danych współpracującą z naszą aplikacją, to możemy uruchomić kolejny kontener z bazą i stworzyć połączenie sieciowe pomiędzy nimi.

Doker wykorzystywany jest bardzo często do tworzenia pełnych, przenośnych środowisk deweloperskich na potrzeby kolejnych projektów, bez potrzeby wykorzystywania „cięższych” mechanizmów wirtualizacji. Co ważne, Docker pozwala wykorzystywać gotowe obrazy zainstalowanych systemów, aplikacji i baz danych, które zostały wcześniej przygotowane. Wiele z tych projektów umieszczonych jest w publicznym rejestrze i dostępnych za darmo. W ten sposób można zbudować własne środowisko, korzystając z gotowych obrazów zawierających zainstalowane kontenery i usługi.

Docker działa tylko na jądrze Linuksa i pozwala uruchamiać tylko aplikacje linuksowe. W wypadku systemów Windows i Mac OS możliwe jest skorzystanie z narzędzia Docker Toolbox, które pozwala zainstalować Dockera w minimalnej maszynie wirtualnej pod kontrolą VirtualBoksa, a więc stworzenie środowiska hybrydowego.

W środowisku produkcyjnym należy mieć możliwość zarządzania kontenerami, w których uruchomiliśmy aplikacje. Należy też pilnować, aby nie było przerw w dostępności usług uruchomionych w kontenerach. O ile zarządzanie jednym, kilkoma lub kilkunastoma kontenerami Dockera nie stanowi problemu, o tyle sytuacja zmienia się diametralnie, gdy liczba kontenerów znacząco wzrasta, są one rozproszone, dynamicznie tworzone i niszczone. Z pomocą przychodzi Kubernetes, stworzone przez Google na własne potrzeby narzędzie, z czasem wydane jako oprogramowanie typu open source.

Kubernetes to środowisko do uruchamiania systemów rozproszonych o wysokiej niezawodności. Obsługuje skalowanie aplikacji oraz przełączanie pomiędzy nimi w sytuacjach awaryjnych, a także, co istotne w wypadku wdrożeń systemów IT, przydatne przy ich aktualizacji. Innymi słowy, Kubernetes grupuje kontenery, które tworzą aplikację, w logiczne jednostki w celu łatwego zarządzania nimi.

Tego typu rozwiązania noszą nazwę „narzędzi orkiestracji”.

W uproszczeniu, orkiestracja to sposób na zautomatyzowaną, masową konfigurację, koordynację oraz zarządzanie „orkiestrą” kontenerów pod komendą jednego dyrygenta. Tak więc orkiestracja jest formą rozszerzonej do całych systemów automatyzacji oraz kompleksowego zarządzania związannego z automatyzacją zadaniami.

Kubernetes pozwala na kontrolowanie dużej liczby instancji skonteneryzowanych aplikacji, a także dodaje własne mechanizmy load-balancingu. Dzieki temu możliwa jest automatyzacja oraz tworzenie zadań deklaratywnych.

Tak więc często stawiane pytanie, czy do konteneryzacji należy wybrać Dockera czy Kubernetesa, nie ma sensu. Kubernetes może działać bez Dockera, a Docker może działać bez Kubernetesa. Ale Kubernetes może przynieść duże korzyści, współpracując z Dockerem. Po prostu Kubernetes i Docker to dwie różne technologie, które mogą ze sobą współpracować w celu tworzenia, dostarczania i skalowania konteneryzowanych aplikacji. Sam w sobie Kubernetes może współpracować z dowolną technologią konteneryzacji, a jego „Dockerowym” odpowiednikiem jest mniej zaawansowany, ale też znacznie prostszy w instalacji i zarządzaniu Docker Swarm.

Kubernetes udostępnia interfejs API do kontrolowania, gdzie i w jaki sposób uruchamiane są kontenery. Platforma umożliwia uruchamianie kontenerów i obciążeń platformy Docker i ułatwia rozwiązywanie problemów, które mogą się pojawić podczas skalowania wielu kontenerów działających jednocześnie na wielu serwerach.

Korzyści biznesowe

Kontenery zapewniają możliwość jednorazowego utworzenia kodu, a następnie uruchamiania go w dowolnym miejscu na dowolnym serwerze. Platforma Kubernetes pozwala zaś na orkiestrację i zarządzanie wszystkimi zasobami tych kontenerów, oferując jeden interfejs i płaszczyznę kontroli. Środowisko to ułatwia wykonywanie operacji sieciowych, równoważenie obciążenia, zabezpieczanie i skalowanie we wszystkich węzłów platformy Kubernetes, w ramach których są uruchamiane kontenery.

W ten sposób firma zyskuje możliwość zwiększenia niezawodności infrastruktury, dostępności aplikacji i oferowanych przez siebie usług. Aplikacje, w tym krytyczne serwisy widoczne z zewnątrz dla klientów, będą działać w trybie online, nawet gdy część węzłów będzie niedostępna lub przejdzie w tryb offline. Istotna jest też lepsza skalowalność aplikacji. Jeśli dany program czy baza danych są coraz bardziej obciążone, wystarczy uruchomić więcej Dockerowych kontenerów lub dodać więcej węzłów w klastrze Kubernetes.

Konteneryzacja i wirtualizacja – zalety i wady
	Konteneryzacja	Wirtualizacja
Zalety	Kontenery zawierają tylko niezbędne zasoby (pliki, biblioteki, narzędzia). Są uruchomiane bardzo szybko w porównaniu do wirtualnej maszyny. Mogą się komunikować między sobą po odpowiednio ustawionym wydzielonym połączeniu.	Wirtualizacja w pełni symuluje działanie fizycznego sprzętu. Jest niezależna od systemu operacyjnego hosta Odizolowuje od systemu operacyjnego hosta. Obraz jest przenośny między środowiskami.
Wady	Kontenery są zależne od systemu operacyjnego. Nie są tak dobrze odizolowane jak w przypadku wirtualizacji, ponieważ zależą od systemu operacyjnego hosta.	Wirtualizacja zużywa dużą część zasobów sprzętowych. Trudna do realizacji komunikacja między maszynami wirtualnymi.

(źródło: bykowski.pl)