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


21.02.2019

Wdrażanie projektów AI

Infrastruktura OVH
21.02.2019

Certyfikacja kluczy

HEUTHES-CAK
21.02.2019

Kopie zapasowe

Veeam Availability for AWS
21.02.2019

Dysk SSD Samsung 970 EVO Plus

Dysk SSD Samsung 970 EVO Plus
21.02.2019

Szyfrowane USB

Kingston IronKey D300 Serialized
21.02.2019

Bezpieczeństwo sieci

Check Point Maestro i seria 6000
21.02.2019

Ochrona danych

Commvault IntelliSnap i ScaleProtect
21.02.2019

Ułatwienie telekonferencji

Plantronics Calisto 3200 i 5200
21.02.2019

Transformacja centrów danych

Fujitsu PRIMEFLEX for VMware vSAN

Kubernetes - uniwersalna orkiestracja

Data publikacji: 21-01-2019 Autor: Grzegorz Kuczyński

W pierwszej części artykułu omówiliśmy podstawowe elementy i zasady działania Kubernetes oraz opisaliśmy, jak go samodzielnie zainstalować. Tym razem przejdziemy do praktycznych przykładów, jak korzystać z klastra Kubernetes w celu hostowania ciągle dostępnych aplikacji.

 

W  poprzednim numerze pokazaliśmy instalację testowego klastra Kubernetes, który składa się z trzech hostów: kube1 (master), kube2 i kube3. Nasze maszyny znajdują się fizycznie w jednej sieci, ale wszystkie pody w klastrze są w zupełnie innej sieci typu overlay, którą realizujemy za pomocą projektu Flannel. Mając zainstalowany klaster, możemy uruchomić kilka podów i zobrazować, jak wygląda środowisko kontenerów w Kubernetes. Zanim do tego przejdziemy, musimy jeszcze omówić jedną z najważniejszych koncepcji w Kubernetes – deployment. Do tej pory omawialiśmy podstawowe elementy, z których zbudowany jest Kubernetes. Z kolei deployment to swego rodzaju nadrzędny element, który integruje wiele elementów bazowych i pozwala wdrożyć kilka funkcji wirtualnych, np. możliwość aktualizacji aplikacji bez przerywania jej dostępności.

> TESTOWE PODY

Choć deployment jest tym, z czego w ostateczności powinniśmy korzystać, najpierw musimy zapoznać się z jego składowymi, jakimi są np. pods, services i volumes. W rzeczywistości wszystkie te elementy definiuje się za pomocą deklaracji spisanych w plikach typu YAML, jednak już teraz możemy uruchomić testowy pod w stylu Dockera. Da się to uczynić za pomocą co prawda wycofywanej już funkcji run narzędzia kubectl, ale dzięki niej możemy szybko przetestować, jak działają niektóre mechanizmy w Kubernetes. Ponadto należy jeszcze wspomnieć o tym, że możemy sterować klastrem spoza maszyn należących do niego. Aby to zrobić, należy zainstalować na swoim klienckim hoście kubectl i do pliku .kube/config w swoim katalogu domowym skopiować zawartość pliku /etc/kubernetes/admin.conf z hosta pełniącego funkcję master, w naszym przypadku kube1.

Poniższe polecenia utworzą dwa kontenery, każdy w osobnym podzie. Ponieważ kontener musi wykonywać jakieś zadanie, aby nie zakończył swojej aktywności, uruchamiamy w nich polecenie sleep. Jednak ono w końcu przestanie działać i wtedy kontener zostanie zrestartowany – jest to efekt domyślnej polityki w Kubernetes.

 

W rzeczywistości polecenia te tworzą dwa nowe deployments, ale będą również widoczne jako pody.

 


Jak widać, pierwszy z nich już raz się zakończył i został zresetowany. Warto zaznaczyć, że widzimy tylko dwa pody, ponieważ domyślnie wyświetlana jest wyłącznie przestrzeń nazw default. Za pomocą komendy describe możemy się dowiedzieć, gdzie został uruchomiony pod i jaki ma IP.

 

 

[...]

 

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"