Technologie pojemników: doker, rkt, orkiestracja, kubernetes, GKE i AWS Container Service

Question

Próbuję uzyskać dobre zrozumienie technologii pojemników, ale jestem nieco zdezorientowany. Wygląda na to, że niektóre technologie nakładają się na różne części stosu, a różne zespoły różnych technologii mogą być używane, jak uważają zespół DevOps (np. Mogą używać kontenerów Docker, ale nie muszą używać silnika Docker, mogą używać silnika od dostawcy chmury zamiast). Moje zamieszanie polega na zrozumieniu, co zapewnia każda warstwa "stosu kontenerów" i kto jest kluczowym dostawcą każdego rozwiązania.

Oto zrozumienie mojego laika; doceniam wszelkie poprawki i opinie na temat dziur w moim rozumieniu

1. Kontenerów: samodzielny pakiet zawierający aplikację, środowisko uruchomieniowe, biblioteki systemowe, itp .; jak mini-OS z aplikacją
   • Wygląda na to, że Docker jest standardem de facto. Wszelkie inne, które są godne uwagi i szeroko stosowane?
2. kontenerów Klastry: grupy pojemników, które dzielą zasoby
3. Pojemnik silnika: Grupy pojemniki na klastry, zarządza zasobami
4. Orchestrator: Jest to inaczej z silnikiem pojemnika? W jaki sposób?
   • Skąd Docker Engine, rkt, Kubernetes, Google Container Engine, AWS Container Service itp. Znajdują się między #s 2-4?

Answer 1

Aby odpowiedzieć na Twoje pytania konkretnie:

1. Docker silnik: narzędzie do zarządzania cyklem życia pojemniku Döcker i obrazów Döcker. Twórz, restartuj, usuwaj kontenery dokowane. Twórz, zmieniaj nazwy i usuwaj okna dokowane.

2. RKT: Analogicznie do dokowanym silnik, ale inna implementacja

3. Kubernetes: Zbiór narzędzi do zarządzania cyklem życia aplikacji rozproszonej, która używa pojemników. Zawiera narzędzia do zarządzania kontenerami, grupami kontenerów, konfiguracją kontenerów, aranżacją kontenerów, harmonogramowaniem ich w rzeczywistych instancjach, narzędziami ułatwiającymi programistom tworzenie i utrzymywanie innych usług/narzędzi do obsługi kontenerów.

4. Google Container Engine: Zamiast zbierać maszyny wirtualne, instalować na nich "silnik dokujący", instalować na nich kernernetes i uruchamiać wszystko, aby działało z takimi prawami, jak uprawnienia do infrastruktury itp. Wyobraź sobie, że wszystko to połączyło się aby można było wybrać typy maszyn i rozmiar klastra, który po prostu działa. Takie rzeczy, jak przeciąganie obrazów z repozytorium konkretnego kontenera (google container container) lub pobieranie trwałych woluminów lub udostępnianie mechanizmów równoważenia obciążenia, działają bez obawy o konta i uprawnienia usług, a także o to, co nie.

5. ECS: analogiczny do GKE (4), ale bez Kubernetes.

Aby odnieść się do punktów w twoim rozumieniu: masz luźne pojęcie o rzeczy (z wyjątkiem silnika kontenerowego, który myślę).Ważne jest, aby zrozumieć, że jedyną ważną rzeczą, którą należy zrozumieć, jest kontener. Reszta to tylko nazwy marketingowe/produktowe. Ważne jest również zrozumienie, że dzisiejsze rozumienie kontenerów jest bardzo wypaczone przez to, czym są kontenery Docker i wiele opinii wymuszonych przez Docker i narzędzi Dockera. Pojemniki są już od dawna.

Kiedy zrozumiesz czym jest kontener (doker), silnik kontenera to tylko narzędzie do zarządzania nimi, klaster kontenerów to tylko grupa kontenerów, a orkiestrator to narzędzie do zarządzania działaniem kontenerów na niektóre parametry. IMHO, naprawdę nie musisz martwić się zbytnio o resztę narzędzi, kiedy zrozumiesz i zbudujesz solidny model mentalny wokół kontenerów. Reszta po prostu się dopasuje automatycznie.

Najlepszy sposób na zrozumienie tego wszystkiego? Buduj & wdrożyć przyzwoicie złożoną aplikację z Dockerem (dane trwałe/użyj bazy danych w aplikacji) i wszystko będzie miało sens.

Answer 2

@iamnat pod warunkiem, naprawdę miłe & zwięzłe wyjaśnienie. Pozwólcie, że spróbuję wyjaśnić nieco więcej szczegółów z pierwszych zasad. Może to być trochę długa i przedstawia pewne uproszczenie, ale powinno wystarczyć, aby ten pomysł był przekonywujący.

maszyny fizyczne

Jakiś czas temu, najlepszym sposobem rozmieszczania prostych aplikacji było po prostu kupić nowy serwer WWW, należy zainstalować swój ulubiony system operacyjny na nim i uruchomić tam swoje aplikacje.

Wady tego modelu są:

• Procesy mogą kolidować ze sobą (bo oni dzielić procesora i systemu plików zasobów), a jeden może wpływać na wydajność tego drugiego.

• Skalowanie tego systemu w górę/w dół również jest trudne, ponieważ wymaga wiele wysiłku i czasu podczas konfigurowania nowego fizycznego urządzenia.

• Mogą występować różnice w specyfikacjach sprzętowych, wersjach systemu operacyjnego/jądra oraz wersjach pakietów oprogramowania maszyn fizycznych, które utrudniają zarządzanie tymi instancjami aplikacji w sposób niezagrażający sprzętowi.

Aplikacje, są bezpośrednio dotknięte przez fizyczne specyfikacji urządzenia, mogą wymagać konkretnego szczypanie, rekompilacji, etc, co oznacza, że ​​administrator klastra musi myśleć o nich jak o wypadkach na poziomie poszczególnych maszyn. Dlatego takie podejście nie jest skalowane. Te właściwości powodują, że niepożądane jest wdrażanie nowoczesnych aplikacji produkcyjnych.

maszyn wirtualnych

Maszyny wirtualne rozwiązać niektóre problemy z powyższym:

• Zapewniają izolację nawet podczas pracy na tej samej maszynie.
• Zapewniają one standardowe środowisko wykonawcze (system operacyjny gościa) niezależnie od podstawowego sprzętu.
• Mogą one zostać przeniesione na inną maszynę (zreplikowane) dość szybko podczas skalowania (kolejność minut).
• Aplikacje zwykle nie wymagają rearchitekcji w celu przejścia z fizycznego sprzętu na maszyny wirtualne.

Ale wprowadzić jakieś własne problemy:

• zużywają duże ilości zasobów w prowadzeniu całej instancji systemu operacyjnego.
• Mogą one nie zacząć/zejść tak szybko, jak tego chcemy (kolejność sekund).

• Nawet przy wirtualizacji wspomaganej sprzętem instancje aplikacji mogą powodować znaczne obniżenie wydajności w przypadku aplikacji uruchamianej bezpośrednio na hoście. (To może być problem tylko w przypadku niektórych aplikacji).

• Pakowanie i rozpowszechnianie obrazów maszyn wirtualnych nie jest tak proste, jak mogłoby być. (To nie jest tak samo wadą tego podejścia, jak to jest z istniejących narzędzi do wirtualizacji.)

Kontenery

Potem, gdzieś wzdłuż linii, cgroups (control groups) zostały dodane do jądra Linuksa . Ta funkcja pozwala nam izolować procesy w grupach, decydować, jakie inne procesy i system plików widzą, i wykonywać rozliczanie zasobów na poziomie grupy.

Pojawiły się różne środowiska uruchomieniowe i silniki kontenerowe, dzięki którym proces tworzenia "kontenera", środowiska w systemie operacyjnym, podobnie jak przestrzeń nazw, która ma ograniczoną widoczność, zasoby itp., Jest bardzo łatwa. Typowe przykłady obejmują dokowanym, RKT, runC, LXC itp

dokowanym, zawiera na przykład procesem, który przewiduje interakcji takich jak tworzenie "obraz", wielokrotnego użytku jednostkę które można natychmiast uruchomić w pojemniku. Pozwala także intuicyjnie zarządzać poszczególnymi kontenerami.

Zalety pojemników:

• Są lekkie i uruchomić z bardzo małym obciążeniu, ponieważ nie posiadają własną instancję jądra/OS i są wyświetlane w górnej części jednego hosta OS .
• Oferują one pewien stopień izolacji między różnymi pojemnikami oraz możliwość narzucania limitów na różne zasoby zużywane przez nie (za pomocą mechanizmu cgroup).
• Oprzyrządowanie dookoła nich ewoluowało bardzo szybko, aby umożliwić łatwe tworzenie jednostek wielokrotnego użytku (obrazów), repozytoriów do przechowywania rewizji obrazów (rejestrów kontenerów) i tak dalej, w dużej mierze ze względu na dokowanie.
• Zachęca się, aby pojedynczy kontener uruchamiał pojedynczy proces aplikacji, aby go utrzymywać i dystrybuować niezależnie. Lekka natura pojemnika czyni to preferowanym i prowadzi do szybszego rozwoju dzięki rozłączeniu.

Istnieją pewne minusy, a także:

• Poziom izolacji warunkiem jest mniejsza niż w przypadku maszyn wirtualnych.
• Są one najłatwiejsze w użyciu z bezpaństwowymi 12-factor tworzonymi na nowo aplikacjami i niewielkimi problemami, jeśli ktoś próbuje wdrożyć starsze aplikacje, klastrowe rozproszone bazy danych i tak dalej.
• Potrzebują one potrzebują prymitywów orkiestracji i wyższego poziomu do skutecznego wykorzystania w skali.

Pojemnik Orkiestracja

Po uruchomieniu aplikacji w produkcji, jak złożoność rośnie, to wydaje się mieć wiele różnych składników, z których niektóre skalowanie w górę/w dół, jak to konieczne, czy może trzeba być skalowane. Same pojemniki nie rozwiązują wszystkich naszych problemów. Potrzebujemy systemu, który rozwiązuje problemy związane z rzeczywistych zastosowaniach na dużą skalę, takich jak:

• Networking między pojemnikami
• Równoważenie obciążenia
• Zarządzanie magazynowych przyłączonych do tych pojemników
• pojemniki Aktualizacja, ich skalowanie, rozkładanie ich przez węzły w klastrze z wieloma węzłami itd.

Gdy chcemy zarządzać grupą kontenerów, używamy silnika orkiestracji kontenera. Przykładami są: Kubernetes, Mesos, Docker Swarm itd. Zapewniają one wiele funkcji oprócz tych wymienionych powyżej, a celem jest zmniejszenie nakładu pracy w dev-ops.

---

GKE (Google Pojemnik Engine) jest gospodarzem Kubernetes na Google Cloud Platform. Pozwala to użytkownikowi po prostu określić, że potrzebuje on klastra kubernetes n-węzłów i naraża sam klaster jako zarządzaną instancję. Kubernetes is open source i jeśli ktoś chciał, można go również skonfigurować w Google Compute Engine, innym dostawcy usług w chmurze lub na własnych komputerach w ich własnym centrum danych.

ECS to zastrzeżony system zarządzania/organizowania kontenerów zbudowany i obsługiwany przez Amazon i dostępny jako część pakietu AWS.