Docker-Swarm, Kubernetes, Mesos & Core-OS Fleet

Myślę, że najprostszą odpowiedzią jest to, że nie ma prostej odpowiedzi. Szybki wzrost mocy kontenerów, a w szczególności Docker, pozostawił próżnię dla "planowania i orkiestracji kontenerów", cokolwiek to może oznaczać. W rzeczywistości oznacza to, że masz wiele technologii, które mogą działać w harmonii na niektórych poziomach, ale z pewnymi aspektami w konkurencji. Na przykład Kubernetes może być używany jako punkt kompleksowej obsługi do wdrażania kontenerów i zarządzania nimi w klastrze obliczeniowym (jak Google pierwotnie zaprojektowany), ale może również siedzieć na szczycie floty, wykorzystując poziom odporności, jaki flota zapewnia Na CoreOS.

Jak stwierdza ten Google vid Kubernetes nie jest kompletnym rozwiązaniem do skalowania kontenerów, ale jest dobrym rozwiązaniem na początek. W ten sam sposób na pewnym etapie można oczekiwać, że Apache Mesos będzie w stanie współpracować z Kubernetes, ale nie z Marathon, w takim stopniu, w jakim Marathon wydaje się spełniać tę samą rolę co Kubernetes. Gdzieś chyba przeczytałem mogą one stać się częścią tego samego wysiłku, ale mogę się mylić - tak naprawdę chodzi o strategiczny kierunek mezosfery i odpowiednie przyjęcie zasad Kubernetes.

W keynote DockerCon Solomon Hykes zasugerował, że Swarm będzie warstwą, która może zapewnić wspólny interfejs dla wielu struktur orkiestracji i harmonogramowania. Z tego, co widzę, Swarm został zaprojektowany, aby zapewnić płynny przepływ pracy przy wdrażaniu Dockera, współpracując z istniejącym kontenerem ramy przepływu pracy, takie jak Deis, ale wystarczająco elastyczne, aby poddać się" ciężkiemu " wdrożeniu i zarządzaniu zasobami, takimi jak Meso.

Mam nadzieję, że to pomoże - to może być ogromny post. Myślę, że kluczowe jest to, że są to Młode, rozwijające się usługi, które prawdopodobnie połączą się i staną się interoperacyjne, ale musimy przejechać przez następne 12 miesięcy, aby zobaczyć, jak to się rozegra. Jest kilku bardzo mądrych ludzi w tym problemie, więc przyszłość wygląda bardzo jasno.

O ile to Rozumiem:

Mezos, Kubernetes i flota próbują rozwiązać bardzo podobny problem. Chodzi o to, że odciągasz cały sprzęt od programistów, a "narzędzie do zarządzania klastrami" sortuje to wszystko za Ciebie. Następnie wystarczy dać kontener do klastra, podać mu pewne informacje (utrzymać go na stałe, skalować w górę, jeśli X się stanie itp.), a Menedżer klastra to zrobi.

Z Mesos, to robi wszystko Zarządzanie klastrem dla Ciebie, ale nie zawiera harmonogramu. Scheduler jest bit, który mówi, ok ten proces potrzebuje 2 procs i 512MB RAM, a ja mam tam maszynę z tym wolnym, więc uruchomię ją na tej maszynie. Istnieje kilka plugin schedulers dostępne dla Mezos: Marathon i Chronos i można napisać własne. Daje to dużą moc dystrybucji zasobów i skalowania klastrów itp.

Flota i Kubernetes zdają się usuwać tego rodzaju szczegóły (więc nie musisz pisać własnych scheduler). Oznacza to, że musisz zdefiniować swoje zadania i przesłać je w formacie / sposób zdefiniowanym przez flotę lub Kubernetes, a następnie przejąć i zaplanować zadania (kontenery) dla Ciebie.

Tak myślę: używanie Mezos może oznaczać nieco więcej pracy przy pisaniu własnego harmonogramu, ale potencjalnie zapewnia większą elastyczność, jeśli jest to wymagane.

Myślę, że idea uruchamiania Kubernetes na Mezos polega na tym, że Kubernetes działa jako scheduler dla Mezos. Osobiście nie jestem pewien co korzyści to przynosi prowadzenie jednego lub drugiego na własną rękę (mam nadzieję, że ktoś wskoczy i wyjaśni!)

Jak powiedział MikeB.. to wczesne dni ,i to wszystko do zgarnięcia (miej oko na ECS Amazon, jak również), więc istnieje wiele konkurencyjnych standardów i wiele nakładają się!

- edit-nie wspomniałem o Docker swarm, ponieważ nie mam z nim zbyt dużego doświadczenia.

Dla wszystkich przybywających do tego po 2017 flota jest przestarzała. Nie używaj go już.

Dokumentacja floty mówi, że "flota nie jest już aktywnie rozwijana ani utrzymywana przez CoreOS" i łączy się z orkiestracja kontenerów: przejście z floty do Kubernetes . Flota została usunięta z kontenera Linux ( znanego wcześniej jako CoreOS Linux ) i zastąpiona Kubernetes kubelet (agent). To zbiegło się z korporacyjnym pivotem, aby zaoferować tektoniczną (dystrybucję Kubernetes) jako ich produkt podstawowy.