Prawda o Tanzu – technicznie rzecz biorąc

Jakiś czas temu nasz kolega Michał przedstawił demo jak uruchomić VMware Tanzu. Natomiast ja napisałem kilka słów wstepu na temat tego rozwiązania (link poniżej), ale odnoszę wrażenie, że potrzeba uzupełnić kilka rzeczy. Musimy jednak zrobić krok w tył. Bez większego przynudzania, zaczynajmy!  

W ostatnim artykule wspomniałem trochę o wersjach, że możemy korzystać z NSX-T lub zewnętrznego load balancera. Ale nie wyjaśniłem, jak wpływa to na działanie, czy możliwości samego Tanzu. Zaczynając od vSpere 7 U1, vSphere with Tanzu, może być uruchomione na dwa sposoby (jeżeli mówimy o części sieciowej).

W grę tutaj wchodzi wspomniany NSX-T lub vSphere Distributed Switches (vDS). Wykorzystanie jednego lub drugiego rozwiązania wpływa na funkcjonalność. W przypadku NSX-T możemy korzystać w pełni z zarządzania siecią i bezpieczeństwem, możemy również uruchomić Tanzu Kubernetes Grid Service, czy vSphere Pod Service.

Oczywiście idąc dalej, możemy wykorzystywać wbudowane: Network, Storage i Registry Services. Brzmi bardzo fajnie. Inaczej wygląda sprawa, jeżeli wykorzystamy vDS’y.

W takiej sytuacji sieć jest oparta o przełączniki wirtualne, możemy uruchomić Tanzu Kubernetes Grid Services, wspierane są zewnętrzne load balancery i w pełni możemy korzystać s Storage Service. Niestety nie możemy korzystać z vSphere Pod i wbudowanego rejestru obrazów Harbor. Oczywiście możemy wykorzystać wersje standalone lub inne rozwiązanie tego typu.  

Zerknijmy szybko jeszcze na Contol Plane.

W przypadku uruchomienia VMware Tanzu powoływane są trzy maszyny wirtualne, które nie różnią się znacząco od Kubernetes control plane nodów. Powołane maszyny współtworzą tzw. Supervisior Cluster. Oczywiście dodatkowo tworzone są polityki odnośnie umiejscowienia maszyn na hostach. Maszyny te zapewniają interfejs zarządzania i programisty, udostępniają usługi i moduły dla klastra i zarządzają cyklem życia maszyn wirtualnych w ramach klastra.  

Od strony sieciowej maszyny wirtualne korzystają z 3 sieci.  

Jak widzimy na załączonym obrazku etcd wykorzystuje sieć Management. Nasi kochani Developerzy dostają się do infrastruktury przez VIP. Wszystkie pody, a właściwie Control Plane komunikuje się z Pod’ami za pomocą dedykowanej sieci.  

Magia Spherelet

W poprzednim artykule (link niżej) wspominałem, że hosty ESXi są wykorzystywane jako Workery. Wszystko to za pomocą instancji Spherelet, który jest specjalną implementacją kubelet i jest uruchamiana bezpośrednio na ESXi i nie jest to maszyna wirtualna. Dzięki temu host staje się częścią klastra Kubernetes. Dodatkowo Spherelet monitoruje vSphere Pod’y, uruchamia je, zarządza konfiguracja i komunikuje się z Control Plane VM. Oto cała magia. Wygląda to mniej więcej (bardziej “więcej niż mniej”) tak jak niżej

W tradycyjnym środowisku Kubernetes pody są uruchamiane w ramach workerów, które chyba zawsze są oparte o system Linux (mogę się mylić). W vSphere with Tanzu pody uruchamiane są na ESXi bardzo podobnie jak maszyny wirtualne.  

https://evoila.com/pl/blog/prawda-o-tanzu-od-poczatku/

Namespace – czyli granica zasobów

Została jeszcze jedna istotna rzecz, którą chciałbym poruszyć w tym artykule – Namespace. Często zdarza się, że przez tak wiele warstw abstrakcji już gubimy się. Niczym w filmie Incepcja.  

Przestrzeń nazw (Namespace) wyznacza granice zasobów, na których mogą działać vSphere Pods i klastry Kubernetes. Musimy jednak pamiętać, że jest to Namespace po stronie środowiska vSphere. Oczywiście jeżeli powołamy klaster Kubernetes, tam też mamy do czynienia z Namespace. Dodatkowo musimy pamiętać, że Namespace po stronie vSphere domyślnie tworzony jest bez ograniczeń. Aby zapewnić DevOps dostęp wystarczy przypisać im uprawnienia (użytkownikom lub grupie użytkowników). Niby banalna sprawa, ale często można ją przeoczyć przede wszystkim, jeżeli chodzi o limit zasobów. Oczywiście jeżeli tworzymy nowy klaster Kubernetes to tworzony jest Control Plane i Workery. A logika wygląda tak:  

https://evoila.com/pl/blog/vsphere-interated-containers-admiral-i-harbor/

Jeszcze kilka słów o zasobach dyskowych

Wykorzystywany jest do tego CNS (Cloud Native Storage) który zintegrowany jest z vCenter Server. Zarządza on powoływaniem wolumenów, wsparciem po stronie kontenerów i datastore vSphere. Zintegrowany jest również z SPBM (Sotrage Policy Based Management). Politykę oraz limity przypisujemy dla konkretnego Namespace w vSphere. W środowisku vSphere with Tanzu obiekty woluminów trwałych są obsługiwane prze FCD. Tanzu obługuje dynamiczne udostępnianie woluminów w trybie ReadWriteOnce, co oznacza ze mogą być montowane do pojedynczego noda. W wersji vSphere 7 U3 w klastrach Tanzu Kubernetes można montować woluminy oparte o vSAN w trybie RWX. Oczywiście stałe woluminy widać z poziomy interfejsu GUI vCenter dlatego łatwo je monitorować i w razie problemów diagnozować.  

https://evoila.com/pl/blog/akcja-integracja-avi-z-nsx-t-czesc-1/

W tym artykule poruszyłem tylko kilka technicznych rzeczy związanych z Tanzu. Rozwiązanie jest, z jednej strony proste w uruchomieniu, ale cała otoczka sieciowa, dyskowa i usług skoncentrowanych na kontenerach może przytłoczyć. To jak wielka góra pływających kontenerów, której szczyt nazywa się VMware Tanzu. Trzeba uważać, żeby nie skończyć jak Titanic na dnie, gdy odkryjemy co jest poniżej powierzchni wody. Buul buul buul…    

Zapraszam do obejrzenia Demoleo przygotowanego przez Michała Iwańczuka oraz do przeczytania pierwszego artykułu o Taznu. Oczywiście z czasem pojawią się kolejne, opisujące inne elementy ekosystemu Tanzu. Dlatego już zapraszam do przeczytania.  

Artykuł został opublikowany w ramach partnerstwa VMware.

Więcej na temat Tanzu