Jestem stosunkowo nowy w tym wszystkim, ale mam problemy z uzyskaniem wyraźnego obrazu wśród wymienionych technologii.
Chociaż wszystkie te rozwiązania próbują rozwiązać różne problemy, ale mają też coś wspólnego. Chciałbym zrozumieć, jakie rzeczy są wspólne, a co się różni. Jest prawdopodobne, że połączenie kilku byłoby świetnie dopasowane, jeśli tak, to jakie?
Wymieniam kilka z nich wraz z pytaniami, ale byłoby świetnie, gdyby ktoś szczegółowo je wszystkie wymienił i odpowiedział na pytania.
Kubernetes kontra Mesos:
Ten link
Jaka jest różnica między Mesosem Apache a Kubernetesem Google
zapewnia dobry wgląd w różnice, ale nie jestem w stanie zrozumieć, dlaczego Kubernetes powinien działać na Mesosie. Czy ma to więcej wspólnego z połączeniem dwóch rozwiązań open source?
Kubernetes a flota Core-OS:
Jeśli korzystam z kubernetes, czy flota jest wymagana?
Jak Docker-Swarm pasuje do wszystkich powyższych?
źródło
Odpowiedzi:
Ujawnienie: jestem głównym inżynierem w Kubernetes
Myślę, że Mesos i Kubernetes są w dużej mierze nastawione na rozwiązywanie podobnych problemów związanych z uruchamianiem aplikacji klastrowych, mają inną historię i różne podejścia do rozwiązania problemu.
Mesos koncentruje swoją energię na bardzo ogólnym planowaniu i podłączaniu wielu różnych harmonogramów. Oznacza to, że umożliwia współistnienie systemów takich jak Hadoop i Marathon w tym samym środowisku planowania. Mesos mniej koncentruje się na prowadzeniu kontenerów. Mesos istniał przed powszechnym zainteresowaniem kontenerami i został przekształcony w części do obsługi kontenerów.
W przeciwieństwie do tego Kubernetes został zaprojektowany od podstaw jako środowisko do tworzenia rozproszonych aplikacji z kontenerów. Obejmuje prymitywy do replikacji i wykrywania usług jako podstawowe prymitywy, podczas gdy takie rzeczy są dodawane za pośrednictwem struktur w Mesos. Podstawowym celem Kubernetes jest system do budowy, uruchamiania i zarządzania systemami rozproszonymi.
Flota jest dystrybutorem zadań niższego poziomu. Jest to przydatne do ładowania systemu klastrowego, na przykład CoreOS używa go do dystrybucji agentów kubernetes i plików binarnych do maszyn w klastrze w celu uruchomienia klastra kubernetes. Nie jest tak naprawdę przeznaczone do rozwiązywania tych samych problemów związanych z tworzeniem aplikacji rozproszonych, pomyśl o tym bardziej jak systemd / init.d / upstart dla twojego klastra. Nie jest to wymagane, jeśli używasz kubernetes, możesz użyć innych narzędzi (np. Salt, Puppet, Ansible, Chef, ...), aby uzyskać tę samą dystrybucję binarną.
Swarm to próba Dockera mająca na celu rozszerzenie istniejącego API Dockera, aby klaster maszyn wyglądał jak pojedynczy interfejs API Dockera. Zasadniczo nasze doświadczenie w Google i innych miejscach wskazuje, że interfejs API węzła jest niewystarczający dla interfejsu API klastra. Możesz zobaczyć sporo dyskusji na ten temat tutaj: https://github.com/docker/docker/pull/8859 i tutaj: https://github.com/docker/docker/issues/8781
Mam nadzieję, że to pomoże! Dołącz do nas na IRC @ # google-container, jeśli chcesz porozmawiać więcej.
źródło
Myślę, że najprostsza odpowiedź jest taka, że nie ma prostej odpowiedzi. Szybki wzrost mocy kontenerów, aw szczególności Docker, pozostawił próżnię mocy dla „planowania i orkiestracji kontenerów”, cokolwiek to może znaczyć. W rzeczywistości oznacza to, że masz wiele technologii, które mogą działać harmonijnie na niektórych poziomach, ale z pewnymi aspektami 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 (tak jak pierwotnie zaprojektował go Google), ale może również znajdować się na szczycie Floty, korzystając z warstwy odporności, którą Fleet zapewnia na CoreOS.
Jak stwierdza ten film Google, Kubernetes nie jest kompletnym rozwiązaniem do skalowania kontenerów, ale jest dobrym stwierdzeniem, od którego można zacząć. W ten sam sposób na pewnym etapie można by oczekiwać, że Apache Mesos będzie w stanie współpracować z Kubernetesem, ale nie z Marathonem, ponieważ Marathon wydaje się spełniać tę samą rolę co Kubernetes. Gdzieś myślę, że przeczytałem, że mogą one stać się częścią tego samego wysiłku, ale mogę się co do tego mylić - tak naprawdę chodzi o strategiczny kierunek mezosfery i odpowiednie przyjęcie zasad Kubernetes.
W przemówieniu na DockerCon Solomon Hykes zasugerował, że Swarm byłby warstwą, która mogłaby zapewnić wspólny interfejs dla wielu struktur orkiestracji i planowania. Z tego, co widzę, Swarm został zaprojektowany w celu zapewnienia płynnego przepływu pracy wdrażania Dockera, współpracując z niektórymi istniejącymi platformami przepływu pracy kontenerów, takimi jak Deis, ale wystarczająco elastycznym, aby umożliwić „ciężkie” wdrażanie i zarządzanie zasobami, takie jak Mesos.
Mam nadzieję, że to pomoże - to może być ogromny wpis. Myślę, że kluczowe jest to, że są to młode, ewoluujące usługi, które prawdopodobnie połączą się i staną się interoperacyjne, ale musimy przetrwać następne 12 miesięcy, aby zobaczyć, jak to się potoczy. Problem dotyczy kilku bardzo sprytnych ludzi, więc przyszłość wygląda bardzo jasno.
źródło
O ile rozumiem:
Mesos, Kubernetes i Fleet próbują rozwiązać bardzo podobny problem. Chodzi o to, aby oddzielić cały sprzęt od programistów, a „narzędzie do zarządzania klastrami” rozwiązuje to za Ciebie. Następnie wszystko, co musisz zrobić, to przekazać kontener do klastra, podać mu kilka informacji (utrzymuj go na stałe, skaluj w górę, jeśli wystąpi X itp.), A menedżer klastra to zrobi.
W Mesosie wykonuje za Ciebie całe zarządzanie klastrem, ale nie obejmuje harmonogramu. Program planujący to bit, który mówi, ok, ten proces wymaga 2 procesów i 512 MB pamięci RAM, a mam tam maszynę z tym wolnym, więc uruchomię ją na tej maszynie. Dostępnych jest kilka programów do planowania wtyczek dla Mesos: Marathon i Chronos i możesz napisać własne. Daje to duże możliwości w zakresie dystrybucji zasobów i skalowania klastrów itp.
Fleet i Kubernetes wydają się oddzielać tego rodzaju szczegóły (więc nie musisz w zasadzie pisać własnego harmonogramu). Oznacza to, że musisz zdefiniować swoje zadania i przesłać je w formacie / sposób zdefiniowanym przez Fleet lub Kubernetes, a następnie przejmą i zaplanują zadania (kontenery) za Ciebie.
Więc myślę: Używanie Mesos może oznaczać trochę więcej pracy przy pisaniu własnego harmonogramu, ale potencjalnie zapewnia większą elastyczność, jeśli jest to wymagane.
Myślę, że pomysł uruchomienia Kubernetes na Mesosie polega na tym, że Kubernetes działa jako planista dla Mesos. Osobiście nie jestem pewien, jakie korzyści przynosi to samodzielne prowadzenie jednego lub drugiego (mam nadzieję, że ktoś wskoczy i wyjaśni!)
Jak powiedział MikeB… to wczesne dni i wszystko jest do zdobycia (miej również oko na ECS Amazona), więc istnieje wiele konkurencyjnych standardów i wiele się pokrywa!
-edit- Nie wspomniałem o roju Dockerów, ponieważ nie mam z tym dużego doświadczenia.
źródło
Dla każdego, kto przyjdzie do tego po 2017 roku, 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 orkiestracją kontenerów: przejście z floty na Kubernetes . Flota została usunięta z Container Linux ( wcześniej znanego jako CoreOS Linux ) i zastąpiona Kubernetes kubelet (agent). Zbiegło się to z korporacyjnym przestawieniem się na oferowanie Tectonic (dystrybucja Kubernetes) jako podstawowego produktu.
źródło