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


23.05.2019

Wzmocniony model

Panasonic Toughbook FZ-N1
23.05.2019

Szybsze sieci

D-Link Smart Mesh Wi-Fi AC1900/AC2600/AC3000
23.05.2019

Curved 4K

Samsung LU32R590
14.05.2019

Bezpłatna konferencja OSEC...

Jako patron medialny serdecznie zapraszamy na bezpłatną konferencję OSEC Forum 2019, któa...
23.04.2019

Optymalizacja zużycia chmury

HPE GreenLake Hybrid Cloud
23.04.2019

Zarządzanie wydajnością

VMware vRealize Operations 7.5
19.04.2019

Technologie open source

SUSECON 2019
19.04.2019

Wyjątkowo małe

OKI seria C800
19.04.2019

Łatwy montaż

Rittal AX i KX

Kubernetes – uniwersalna orkiestracja

Data publikacji: 20-12-2018 Autor: Grzegorz Kuczyński
Każdy pod jest umieszczony we...

Konteneryzacja usług w dużych środowiskach to dziś jeden z najszybciej rozwijających się kierunków w IT. Najpopularniejszym standardem wśród technologii kontenerów jest Docker, który poza samymi kontenerami oferuje narzędzie do orkiestracji nimi – Swarm – ale ma ono już swoją konkurencję od Google.

 

Mimo swojej popularności Docker wcale nie jest prekursorem w dziedzinie kontenerów. Choć wprowadził wiele innowacji, kontenery istniały o wiele wcześniej – w systemie GNU/Linux były to LXC, a jeszcze dawniej Jails we FreeBSD. Jednym z dużych środowisk, które od dawna miały do czynienia z kontenerami, był Google, i to właśnie stamtąd wywodzi się Kubernetes. Choć sam projekt jest dość nowy, to buduje się go na bazie wieloletnich doświadczeń z ogromną infrastrukturą. Wspomniane technologie kontenerów należało jeszcze połączyć w klaster – przed Kubernetes Google rozwijał własny system tego typu, Borg. Przede wszystkim miał on spełniać trzy wymagania: ukrywać skomplikowane detale przed użytkownikiem, oferować wysoką niezawodność i dostępność oraz pracować pod dużym obciążeniem na ogromną skalę. W 2014 roku Google postanowił podzielić się swoją technologią i rozpocząć nowy projekt pod nazwą Kubernetes, który miał być lepszą wersją Borga. Jego powstanie było bezpośrednio powiązane z pojawieniem się kontenerów Docker w 2013 roku.

> KUBERNETES A DOCKER

Relacja pomiędzy tymi narzędziami jest dość istotna. Przede wszystkim Docker oficjalnie wspiera Kubernetes, choć jest on konkurencją projektu Docker Swarm – natywnego rozwiązania służącego do tworzenia klastrów z kontenerów. Z kolei dla Kubernetes Docker jest domyślnym standardem kontenerów, ale nie jedynym. Ponadto może on obsługiwać inne kontenery na zasadzie pluginu mechanizmu Container Runtime Interface (CRI).

Kontener jest procesem systemu, który uruchamia jądro w wydzielonej przestrzeni nazw dla procesów, sieci i innych elementów systemu. Taki kontener możemy uruchomić również w systemie wirtualnym, co zapewnia większą izolację. Powstają więc nowe inicjatywy mające na celu połączenie lekkości kontenera z bezpieczeństwem maszyny wirtualnej, którą wspiera sprzęt. Hypervisor-Based Containers to zazwyczaj minimalny kod jądra systemu wraz z demonem pozwalającym uruchomić docelowy proces. Oczywiście takiego kontenera nie uruchomimy na maszynie wirtualnej. Jednym z takich rozwiązań obsługiwanych przez Kubernetes jest hypercontainer.io, który wewnątrz minimalnej maszyny wirtualnej uruchamia kontenery Docker.

> NAMESPACES

Kubernetes oferuje wiele mechanizmów w celu zapewnienia niezawodnego dostępu do usług w kontenerach, którymi zarządza. Jednym z przykładów jest mechanizm replikacji, dzięki któremu awaria jednej maszyny nie powoduje niedostępności usługi. Jednak Kubernetes nie operuje w tym przypadku bezpośrednio kontenerami, lecz tzw. podami. Pod to najmniejsza jednostka, jaką zarządza Kubernetes. Z technicznego punktu widzenia jest to wydzielona przestrzeń jądra za pomocą mechanizmów Linux kernel namespaces. Dlatego np. dwa kontenery w jednym podzie są dostępne pod tym samym adresem IP, dzielą ze sobą stos TCP/IP, wolumeny i inne zasoby systemu. Zakładając, że jeden kontener to jedna usługa, można stwierdzić, że niektóre z nich są tak bardzo od siebie zależne, że nie mogłyby samodzielnie działać. Dlatego jeden pod może zawierać więcej niż jeden kontener. Poza tym Kubernetes podejmuje wszystkie decyzje dotyczące rozmieszczenia aplikacji na poszczególnych nodach na poziomie pod, więc mógłby współpracujące ze sobą usługi umieścić na zupełnie innych nodach, co z punktu wydajności nie byłoby pożądane.

Niemal każdy zasób zdefiniowany w Kubernetes lub mechanizm określający stan klastra jest reprezentowany przez odpowiedni typ obiektu. Do obiektu można przypisać etykietę, która ma postać key:value. Na tej podstawie da się oznaczać i grupować określone zasoby. Jest to bardzo prosty, ale efektywny mechanizm identyfikacji obiektów znajdujących się w klastrze.

Kubernetes oferuje również mechanizm namespaces, który pozwala na tworzenie wirtualnych klastrów, jakimi można zarządzać i przydzielać zasoby oddzielnie. Każdy obiekt w danej przestrzeni nazw musi mieć unikalną nazwę.

> NETWORK

W klastrze wyróżniamy sieć zewnętrzną, przez którą nody są połączone ze sobą, oraz sieć wewnętrzną. To właś­nie w tej drugiej sieci znajduje się każdy pod, dzięki czemu widzą się nawzajem w jednej sieci. Jednak w klastrze nieraz zdarza się awaria któregoś z nodów, wtedy pod jest ponownie tworzony na innym nodzie i zostaje mu przydzielony inny adres IP. Dlatego w tej sieci dostępna jest druga adresacja przeznaczona tylko na usługi. Services w Kubernetes stanowi wirtualny adres, który nie ulega zmianie po relokacji poda i jest dynamicznie z nim korelowany w postaci przekierowania. Dzięki temu usługa jest zawsze dostępna pod stałym adresem IP. Usługa Services reprezentuje warstwę czwartą modelu OSI, czyli TCP i UDP.

Adresacja zarówno podów, jak i usług jest wykonywana przy użyciu adresów prywatnych. Z zewnątrz nasze usługi są widoczne przez kolejne przekierowanie do adresu usługi. Jednakże pomiędzy usługą a publicznym adresem IP można umieścić jeszcze jeden obiekt Kubernetes – Ingress. Służy on do wdrożenia dodatkowej polityki dla połączeń przychodzących do usługi głównie w warstwie siódmej, czyli proxy dla HTTPS.

Pods network to sieć typu SDN (Soft­ware-Defined Networking). Istnieje wiele projektów realizujących takie zadania, a Kubernetes również nie ogranicza się do jednego z nich. Jednym z prostszych, lecz wciąż funkcjonalnych jest Flannel. Tworzy on sieć typu overlay, czyli jej ramki ethernetowe są kapsułkowane na obecnej sieci i rozsyłane na wszystkie nody w klastrze. Używany jest do tego standard VXLAN (Virtual Extensible LAN), który transportuje ramki poprzez protokół UDP, domyślnie przez port 8472. Flannel uruchamiany jest w kontenerze na każdym nodzie należącym do klastra. Dla każdego z nich przydziela adresację, natomiast informacje te zapisuje w etcd poprzez Kubernetes API.

> USŁUGI KUBERNETES

Wszystkie usługi decyzyjne uruchamiane są na nodzie oznaczonym jako master, choć mogą one być rozmieszczone na wielu hostach. Głównym centrum wymiany informacji jest kube-apiserver – usługa, która udostępnia interfejs wszystkim pozostałym w celu interakcji z klastrem. To Kubernetes API opisuje, jakich parametrów możemy używać, tworząc określone obiekty w klastrze.

 

[...]

 

Autor zawodowo zajmuje się informatyką. Jest członkiem społeczności open source, prowadzi blog nt. systemu GNU/Linux. 

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"