Docker Swarm, Kubernetes i Mesos to najpopularniejsze frameworki do orkiestracji kontenerów. W swoim wystąpieniu Arun Gupta porównuje następujące aspekty działania Dockera, Swarma i Kubernetesa:
- Rozwój lokalny.
- Funkcje wdrażania.
- Aplikacje wielokontenerowe.
- Odkrycie usług.
- Skalowanie usług.
- Zadania uruchamiane jednorazowo.
- Integracja z Mavenem.
- Aktualizacja krocząca.
- Utwórz klaster bazy danych Couchbase.
W rezultacie zyskasz solidną wiedzę na temat tego, co ma do zaoferowania każde narzędzie do orkiestracji, i nauczysz się, jak efektywnie korzystać z tych platform.
Arun Gupta jest dyrektorem ds. technologii produktów open source w Amazon Web Services i od ponad 10 lat buduje społeczności programistów Sun, Oracle, Red Hat i Couchbase. Posiada bogate doświadczenie w kierowaniu zespołami interdyscyplinarnymi opracowującymi i wdrażającymi strategie kampanii i programów marketingowych. Kierował zespołami inżynieryjnymi firmy Sun, jest członkiem-założycielem zespołu Java EE i założycielem amerykańskiego oddziału Devoxx4Kids. Arun Gupta jest autorem ponad 2 postów na blogach IT i przemawiał w ponad 40 krajach.
Linia 55 zawiera COUCHBASE_URI wskazującą na tę usługę bazy danych, która jest również tworzona przy użyciu pliku konfiguracyjnego Kubernetes. Jeśli spojrzysz na linię 2, zobaczysz rodzaj: Service to usługa, którą tworzę pod nazwą couchbase-service i ta sama nazwa jest wymieniona w linii 4. Poniżej znajduje się kilka portów.
Kluczowe linie to 6 i 7. W serwisie mówię „Hej, to są etykiety, których szukam!”, a te etykiety to nic innego jak nazwy zmiennych par, a linia 7 wskazuje na moją aplikację couchbase-rs-pod. Poniżej przedstawiono porty zapewniające dostęp do tych samych etykiet.
W linii 19 tworzę nowy typ ReplicaSet, linia 31 zawiera nazwę obrazu, a linie 24-27 wskazują metadane powiązane z moim podem. To jest dokładnie to, czego szuka usługa i z czym należy nawiązać połączenie. Na końcu pliku znajduje się swego rodzaju połączenie pomiędzy liniami 55-56 i 4, mówiące „użyj tej usługi!”.
Rozpoczynam więc usługę z zestawem replik, a ponieważ każdy zestaw replik ma swój własny port z odpowiednią etykietą, jest on objęty usługą. Z punktu widzenia programisty po prostu uzyskujesz dostęp do usługi, która następnie korzysta z potrzebnego zestawu replik.
Skończyłem z modułem WildFly, który komunikuje się z bazą danych za pośrednictwem usługi Couchbase. Mogę korzystać z interfejsu wielopodowego WildFly, który komunikuje się również z zapleczem couchbase poprzez usługę couchbase.
W dalszej części przyjrzymy się, jak usługa zlokalizowana poza klastrem, poprzez swój adres IP, komunikuje się z elementami, które znajdują się wewnątrz klastra i posiadają wewnętrzny adres IP.
Zatem kontenery bezstanowe są świetne, ale jak dobry jest pomysł wykorzystania kontenerów stanowych? Przyjrzyjmy się ustawieniom systemowym kontenerów stanowych lub trwałych. W Dockerze istnieją 4 różne podejścia do lokalizacji magazynu danych, na które warto zwrócić uwagę. Pierwszy z nich to Implicit Per-Container, co oznacza, że w przypadku korzystania z kontenerów z obsługą couchbase, MySQL lub MyDB wszystkie kontenery zaczynają się od domyślnej piaskownicy. Oznacza to, że wszystko, co jest przechowywane w bazie danych, jest przechowywane w samym kontenerze. Jeśli kontener zaginie, dane przejdą wraz z nim.
Drugi to Explicit Per-Container, gdy tworzysz określony magazyn za pomocą polecenia docker Volume Create i przechowujesz w nim dane. Trzecie podejście na hosta jest związane z mapowaniem pamięci masowej, gdy wszystko, co jest przechowywane w kontenerze, jest jednocześnie duplikowane na hoście. Jeśli kontener ulegnie awarii, dane pozostaną na hoście. Ostatnim z nich jest wykorzystanie kilku hostów Multi-Host, co jest wskazane na etapie produkcji różnych rozwiązań. Załóżmy, że Twoje kontenery z aplikacjami działają na hoście, ale jednocześnie chcesz przechowywać swoje dane gdzieś w Internecie i służy do tego automatyczne mapowanie dla systemów rozproszonych.
Każda z tych metod wykorzystuje określoną lokalizację przechowywania. Niejawne i jawne dane przechowują dane na poziomie kontenera na hoście w lokalizacji /var/lib/docker/volumes. W przypadku metody Per-Host pamięć jest montowana wewnątrz kontenera, a sam kontener jest montowany na hoście. W przypadku rozwiązań wielohostowych, takich jak Ceph, ClusterFS, NFS itp. można zastosować.
W przypadku awarii trwałego kontenera katalog magazynu staje się niedostępny w pierwszych dwóch przypadkach, a w dwóch ostatnich dostęp zostaje zachowany. Jednak w pierwszym przypadku dostęp do repozytorium można uzyskać poprzez host Docker działający na maszynie wirtualnej. W drugim przypadku dane również nie zostaną utracone, ponieważ utworzyłeś magazyn jawny.
W przypadku awarii hosta w pierwszych trzech przypadkach katalog repozytorium jest niedostępny, w drugim przypadku komunikacja z repozytorium nie zostaje przerwana. Wreszcie funkcja współdzielona jest całkowicie wykluczona z przechowywania w pierwszym przypadku i możliwa w pozostałych. W drugim przypadku możesz współdzielić pamięć w zależności od tego, czy Twoja baza danych obsługuje pamięć rozproszoną, czy nie. W przypadku Per-Host dystrybucja danych możliwa jest tylko na danym hoście, a w przypadku multi-hostów zapewnia to rozszerzenie klastra.
Należy to wziąć pod uwagę podczas tworzenia kontenerów stanowych. Kolejnym przydatnym narzędziem Dockera jest wtyczka Volume, która działa na zasadzie „baterie są obecne, ale należy je wymienić”. Podczas uruchamiania kontenera Docker pojawia się komunikat: „Hej, uruchamiając kontener z bazą danych, możesz przechowywać swoje dane w tym kontenerze!” Jest to funkcja domyślna, ale możesz ją zmienić. Ta wtyczka umożliwia użycie dysku sieciowego lub czegoś podobnego zamiast kontenerowej bazy danych. Zawiera domyślny sterownik pamięci masowej opartej na hoście i umożliwia integrację kontenerów z zewnętrznymi systemami pamięci masowej, takimi jak Amazon EBS, Azure Storage i dyski trwałe GCE.
Następny slajd przedstawia architekturę wtyczki Docker Volume.
Kolor niebieski oznacza klienta Dockera powiązanego z niebieskim hostem Dockera, który ma lokalny aparat pamięci masowej udostępniający kontenery magazynu. Kolor zielony wskazuje klienta wtyczki i demona wtyczki, które są również połączone z hostem. Zapewniają możliwość przechowywania danych w magazynach sieciowych takiego typu, jakiego potrzebujesz. Storage Backend.
Wtyczka Docker Volume może być używana z pamięcią masową Portworx. Moduł PX-Dev to tak naprawdę uruchamiany kontener, który łączy się z hostem Docker i ułatwia przechowywanie danych w Amazon EBS.
Klient Portworx umożliwia monitorowanie stanu różnych kontenerów pamięci masowej podłączonych do hosta. Jeśli odwiedzisz mojego bloga, możesz przeczytać, jak najlepiej wykorzystać Portworx z Dockerem.
Koncepcja przechowywania w Kubernetes jest podobna do Dockera i jest reprezentowana przez katalogi, które są dostępne dla Twojego kontenera w pod. Są one niezależne od żywotności dowolnego pojemnika. Najpopularniejsze dostępne typy pamięci to hostPath, nfs, awsElasticBlockStore i gsePersistentDisk. Przyjrzyjmy się, jak te magazyny działają w Kubernetesie. Zwykle proces ich łączenia składa się z 3 kroków.
Po pierwsze, ktoś po stronie sieci, zwykle administrator, zapewnia trwałą pamięć masową. Istnieje do tego odpowiedni plik konfiguracyjny PersistentVolume. Następnie twórca aplikacji zapisuje plik konfiguracyjny o nazwie PersistentVolumeClaim, czyli żądanie udostępnienia magazynu PVC, w którym jest napisane: „Mam zapewnione 50 GB rozproszonej pamięci masowej, ale aby inne osoby również mogły korzystać z jej pojemności, informuję w tym PVC, że teraz potrzeba tylko 10 GB”. Na koniec trzeci krok polega na tym, że zapytanie jest montowane jako sklep, a aplikacja posiadająca zestaw podów, replik lub coś podobnego zaczyna z nich korzystać. Należy pamiętać, że proces ten składa się z 3 wspomnianych etapów i pozwala na skalowanie.
Następny slajd przedstawia kontener Kubernetes Persistence Container w architekturze AWS.
Wewnątrz brązowego prostokąta reprezentującego klaster Kubernetes znajduje się jeden węzeł główny i dwa węzły robocze, pokazane na żółto. Jeden z węzłów roboczych zawiera pomarańczowy zasobnik, repozytorium, kontroler repliki i zielony kontener Docker Couchbase. Wewnątrz klastra, nad węzłami, fioletowy prostokąt wskazuje usługę dostępną zewnętrznie. Ta architektura jest zalecana do przechowywania danych na samym urządzeniu. W razie potrzeby mogę przechowywać swoje dane w EBS poza klastrem, co widać na kolejnym slajdzie. Jest to typowy model skalowania, jednakże przy jego stosowaniu należy wziąć pod uwagę aspekt finansowy – przechowywanie danych gdzieś w sieci może być droższe niż na hoście. Przy wyborze rozwiązań konteneryzacyjnych jest to jeden z ważniejszych argumentów.
Podobnie jak w przypadku Dockera, w Portworx można używać trwałych kontenerów Kubernetes.
To właśnie w aktualnej terminologii Kubernetes 1.6 nazywa się „StatefulSet” — sposobem pracy z aplikacjami stanowymi, które obsługują zdarzenia zatrzymania Pod i Graceful Shutdown. W naszym przypadku takimi aplikacjami są bazy danych. Na moim blogu możesz przeczytać, jak utworzyć StatefulSet w Kubernetesie za pomocą Portworx.
Porozmawiajmy o aspekcie rozwojowym. Jak mówiłem, Docker ma 2 wersje - CE i EE, w pierwszym przypadku mówimy o stabilnej wersji Community Edition, która jest aktualizowana co 3 miesiące, w przeciwieństwie do comiesięcznej wersji EE. Możesz pobrać Dockera na komputery Mac, Linux lub Windows. Po zainstalowaniu Docker zostanie automatycznie zaktualizowany, a rozpoczęcie pracy z nim jest bardzo łatwe.
W Kubernetesie wolę wersję Minikube - to dobry sposób na rozpoczęcie pracy z tą platformą poprzez utworzenie klastra na jednym węźle. Aby utworzyć klastry z kilku węzłów, wybór wersji jest szerszy: są to kops, kube-aws (CoreOS + AWS), kube-up (nieaktualne). Jeśli chcesz korzystać z platformy Kubernetes opartej na platformie AWS, polecam dołączenie do grupy AWS SIG, która spotyka się online w każdy piątek i publikuje wiele interesujących treści na temat pracy z platformą AWS Kubernetes.
Przyjrzyjmy się, jak działa aktualizacja krocząca na tych platformach. Jeśli istnieje klaster kilku węzłów, wówczas używa określonej wersji obrazu, na przykład WildFly:1. Aktualizacja ciągła oznacza, że wersja obrazu jest zastępowana nową sekwencyjnie w każdym węźle, jeden po drugim.
W tym celu wykorzystuje się polecenie docker service update (nazwa usługi), w którym określam nową wersję obrazu WildFly: 2 oraz metodę aktualizacji update-parallelism 2. Liczba 2 oznacza, że system zaktualizuje 2 obrazy aplikacji o godz. czas, po którym następuje 10-sekundowe opóźnienie aktualizacji 10 s, po czym kolejne 2 obrazy zostaną zaktualizowane na 2 kolejnych węzłach itp. Ten prosty mechanizm aktualizacji kroczącej jest udostępniany w ramach platformy Docker.
W Kubernetes odświeżanie kroczące działa w ten sposób. Kontroler replikacji rc tworzy zestaw replik jednej wersji, a każdy moduł w tej aplikacji webapp-rc jest oznaczony etykietą znalezioną w pliku etcd. Kiedy potrzebuję jakiegoś poda, korzystam z usługi aplikacji, aby uzyskać dostęp do repozytorium etcd, które dzięki określonej etykiecie udostępnia mi ten pod.
W tym przypadku w kontrolerze replikacji mamy 3 pody z uruchomioną aplikacją WildFly w wersji 1. Podczas aktualizacji w tle tworzony jest kolejny kontroler replikacji o tej samej nazwie i indeksie na końcu - - xxxxx, gdzie x to liczby losowe, a z tymi samymi etykietami. Usługa aplikacji ma teraz trzy Pody ze starą wersją aplikacji i trzy Pody z nową wersją w nowym kontrolerze replikacji. Następnie stare zasobniki są usuwane, zmieniana jest nazwa kontrolera replikacji z nowymi zasobnikami i uruchamiany.
Przejdźmy do monitoringu. Docker ma wiele wbudowanych poleceń monitorujących. Przykładowo interfejs wiersza poleceń docker Container Stats pozwala co sekundę wyświetlać na konsoli dane o stanie kontenerów – wykorzystanie procesora, dysku, obciążenie sieci. Narzędzie Docker Remote API dostarcza danych o sposobie komunikacji klienta z serwerem. Używa prostych poleceń, ale opiera się na API Docker REST. W tym przypadku słowa REST, Flash, Remote oznaczają to samo. Kiedy komunikujesz się z hostem, jest to interfejs API REST. Docker Remote API pozwala uzyskać więcej informacji na temat uruchamiania kontenerów. Mój blog zawiera szczegółowe informacje na temat korzystania z tego monitorowania w systemie Windows Server.
Monitorowanie zdarzeń systemowych zdarzeń systemu dokowanego podczas uruchamiania klastra z wieloma hostami umożliwia uzyskanie danych o awarii hosta lub awarii kontenera na konkretnym hoście, skalowaniu usług i tym podobnych. Począwszy od Dockera 1.20, zawiera Prometheus, który osadza punkty końcowe w istniejących aplikacjach. Umożliwia to otrzymywanie metryk za pośrednictwem protokołu HTTP i wyświetlanie ich na pulpitach nawigacyjnych.
Kolejną funkcją monitorowania jest cAdvisor (skrót od Container Advisor). Analizuje i dostarcza dane dotyczące wykorzystania zasobów i wydajności z uruchomionych kontenerów, dostarczając gotowe do użycia wskaźniki Prometheus. Osobliwością tego narzędzia jest to, że dostarcza dane tylko z ostatnich 60 sekund. Dlatego należy zapewnić możliwość gromadzenia tych danych i umieszczania ich w bazie danych, aby móc monitorować proces długoterminowy. Można go również używać do graficznego wyświetlania metryk na pulpicie nawigacyjnym za pomocą Grafany lub Kibany. Na moim blogu znajduje się szczegółowy opis wykorzystania cAdvisora do monitorowania kontenerów za pomocą dashboardu Kibana.
Następny slajd pokazuje, jak wygląda wynik punktu końcowego Prometheus i metryki dostępne do wyświetlenia.
W lewym dolnym rogu widać metryki żądań HTTP, odpowiedzi itp., po prawej - ich graficzną prezentację.
Kubernetes zawiera także wbudowane narzędzia monitorujące. Ten slajd przedstawia typowy klaster zawierający jeden węzeł główny i trzy węzły robocze.
Każdy z węzłów roboczych zawiera automatycznie uruchamianego cAdvisora. Ponadto istnieje Heapster, system monitorowania wydajności i metryk, który jest kompatybilny z Kubernetes w wersji 1.0.6 i wyższej. Heapster umożliwia zbieranie nie tylko wydajności obciążeń, modułów i kontenerów, ale także zdarzeń i innych sygnałów generowanych przez cały klaster. Aby zebrać dane, komunikuje się z Kubeletem każdego Poda, automatycznie przechowuje informacje w bazie danych InfluxDB i wyświetla je jako metryki w dashboardzie Grafana. Pamiętaj jednak, że jeśli używasz miniKube, ta funkcja nie jest domyślnie dostępna, dlatego do monitorowania będziesz musiał użyć dodatków. Wszystko zależy więc od tego, gdzie uruchamiasz kontenery i jakich narzędzi monitorujących możesz używać domyślnie, a które musisz zainstalować jako osobne dodatki.
Następny slajd przedstawia dashboardy Grafany, które pokazują stan operacyjny moich kontenerów. Jest tu wiele ciekawych danych. Oczywiście istnieje wiele komercyjnych narzędzi do monitorowania procesów Docker i Kubernetes, takich jak SysDig, DataDog, NewRelic. Niektóre z nich mają 30 bezpłatnych okresów próbnych, więc możesz spróbować znaleźć ten, który najbardziej Ci odpowiada. Osobiście wolę używać SysDig i NewRelic, które dobrze integrują się z Kubernetesem. Istnieją narzędzia, które równie dobrze integrują się zarówno z platformą Docker, jak i Kubernetes.
Kilka reklam 🙂
Dziękujemy za pobyt z nami. Podobają Ci się nasze artykuły? Chcesz zobaczyć więcej ciekawych treści? Wesprzyj nas składając zamówienie lub polecając znajomym, , unikalny odpowiednik serwerów klasy podstawowej, który został przez nas wymyślony dla Ciebie: (dostępne z RAID1 i RAID10, do 24 rdzeni i do 40 GB DDR4).
Dell R730xd 2 razy taniej w centrum danych Equinix Tier IV w Amsterdamie? Tylko tutaj w Holandii! Dell R420 — 2x E5-2430 2.2 GHz 6C 128 GB DDR3 2x960 GB SSD 1 Gb/s 100 TB — od 99 USD! Czytać o
Źródło: www.habr.com