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



08.07.2019

Narzędzie EDR

ESET Enterprise Inspector
08.07.2019

Usuwanie skutków awarii

Veeam Availability Orchestrator v2
08.07.2019

Indywidualna konfiguracja

baramundi Management Suite 2019
05.07.2019

Technologia Ceph

SUSE Enterprise Storage 6
05.07.2019

Szybkie i bezpieczne...

Konica Minolta bizhub i-Series
05.07.2019

Edge computing

Atos BullSequana Edge
04.07.2019

Terabitowa ochrona

Check Point 16000 i 26000
04.07.2019

Obsługa wideokonferencji

Poly G7500
04.07.2019

Laptop biznesowy

Fujitsu LIFEBOOK U939X

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. 

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"