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

Я відносно новий у всьому цьому, але у мене виникають проблеми з чіткою картиною серед перерахованих технологій.

Хоча всі вони намагаються вирішувати різні проблеми, але теж мають спільне. Мені хотілося б зрозуміти, що є спільним і чим відрізняється. Цілком імовірно, що поєднання кількох було б чудово підходить, якщо так, що вони?

Я перелічу декілька з них разом із питаннями, але було б чудово, якби хтось детально перерахував їх усіх і відповів на запитання.

1. Kubernetes vs Mesos:

   Це посилання

   Яка різниця між Mesos Apache та Kubernetes від Google

   дає гарне уявлення про відмінності, але я не в змозі зрозуміти, чому саме Кубернетес повинен працювати на вершині Месоса. Чи більше це стосується поєднання двох рішень з відкритим кодом?

2. Kubernetes vs Core-OS флот:

   Якщо я використовую кубернети, чи потрібен флот?

3. Як Докер-Рой вписується у все вищезазначене?

Розкриття: Я провідний інженер Kubernetes

Я думаю, що Mesos і Kubernetes багато в чому спрямовані на вирішення подібних проблем роботи кластерних додатків, вони мають різну історію та різні підходи до вирішення проблеми.

Mesos фокусує свою енергію на дуже загальному плануванні та підключенні до декількох різних планувальників. Це означає, що вона дозволяє системам на зразок Hadoop та Marathon співіснувати в одному середовищі планування. Mesos менш зосереджений на запущених контейнерах. Mesos існував до широкого інтересу до контейнерів і був реконструйований частинами для підтримки контейнерів.

Навпаки, Kubernetes був розроблений з самого початку, щоб бути середовищем для побудови розподілених програм із контейнерів. Він включає примітиви для реплікації та виявлення сервісу як основні примітиви, де такі речі додаються через рамки в Mesos. Основна мета Kubernetes - це система побудови, роботи та управління розподіленими системами.

Флот є розповсюджувачем завдань нижчого рівня. Це корисно для завантаження кластерної системи, наприклад, CoreOS використовує її для розповсюдження агентів кубернетів та бінарних файлів на машини в кластері, щоб підняти кластер кубернетів. Він насправді не призначений для вирішення одних і тих же проблем з розробленою програмою, подумайте про це більше, як systemd / init.d / upstart для вашого кластера. Це не потрібно, якщо ви запускаєте кубернети, ви можете використовувати інші інструменти (наприклад, Сіль, Лялька, Відповідач, Шеф-кухар, ...) для того ж двійкового розподілу.

Swarm - це зусилля Docker розширити існуючий API Docker, щоб скупчення машин було схожим на єдиний API Docker. По суті, наш досвід роботи в Google та інших країнах свідчить про те, що API вузла недостатній для API кластера. Купу обговорень з цього приводу ви можете побачити тут: https://github.com/docker/docker/pull/8859 та тут: https://github.com/docker/docker/isissue/8781

Сподіваюся, що це допомагає! Приєднуйтесь до нас у IRC @ # google-контейнерах, якщо хочете поговорити більше.

Я думаю, що найпростіша відповідь полягає в тому, що простої відповіді немає. Швидкий підйом потужності контейнерів, і Докер, зокрема, залишив вакуум потужності для "планування контейнерів і оркестрації", що б це не означало. Насправді це означає, що у вас є низка технологій, які можуть працювати на гармонії на деяких рівнях, але з певними аспектами у конкуренції. Наприклад, Kubernetes можна використовувати як єдину зупинку для розгортання та керування контейнерами на обчислювальному кластері (як спочатку розробив Google), але також міг би розташуватися на вершині флоту, використовуючи рівень стійкості, який флот надає на CoreOS.

Оскільки цей Google відзначає, Kubernetes - це не повне рішення щодо масштабування контейнерів, але це хороша заява. Таким же чином, ви на певному етапі очікували, що Apache Mesos зможе працювати з Кубернетом, але не з Марафоном, наскільки Марафон, як видається, виконує ту саму роль, що і Кубернетес. Десь я думаю, що я прочитав, що це може стати частиною тих же зусиль, але я можу помилитися з цього приводу - це дійсно про стратегічний напрямок мезосфери та відповідне прийняття принципів Кубернета.

У доповіді DockerCon Соломон Хайкс припустив, що Swarm буде рівнем, який може забезпечити спільний інтерфейс для багатьох структур оркестрування та планування. Як я бачу, Swarm призначений для забезпечення плавного робочого процесу розгортання Docker, що працює з деякими існуючими рамками робочого процесу контейнерів, такими як Deis, але досить гнучким, щоб піддатися «важкій вазі» розгортання та управління ресурсами, наприклад Mesos.

Сподіваюся, що це допомагає - це може бути величезний пост. Я думаю, що ключовим є те, що це молоді, що розвиваються служби, які, ймовірно, об'єднаються та стануть сумісними, але нам потрібно їхати наступні 12 місяців, щоб побачити, як це відбувається. Є кілька дуже розумних людей щодо проблеми, тому майбутнє виглядає дуже світлим.

Наскільки я це розумію:

Месос, Кубернетес і Флот намагаються вирішити дуже подібну проблему. Ідея полягає в тому, що ви відмовитесь від усього обладнання від розробників, а «інструмент управління кластерами» все це розробить для вас. Тоді все, що вам потрібно зробити, - це надати контейнер кластеру, дати йому деяку інформацію (постійно працювати, масштабувати, якщо X трапляється тощо), і менеджер кластерів зробить це.

З Mesos він робить для вас все управління кластером, але він не включає планувальник. Планувальник - це біт, який говорить, нормально, цей процес потребує 2 прок. І 512 Мб оперативної пам’яті, і у мене є машина з цим вільним, тому я запускаю його на цій машині. Для Месосів доступні деякі планувальники плагінів: Marathon і Chronos, і ви можете написати свій власний. Це дає велику потужність розподілу ресурсів та масштабування кластерів тощо.

Флот і Кубернети, здається, абстрагують ці деталі (тому вам не потрібно писати власного планувальника в основному). Це означає, що ви повинні визначити свої завдання та подати їх у форматі / порядку, визначеному Флотом чи Кубернетами, а потім вони приймуть та планують завдання (контейнери) для вас.

Тому я здогадуюсь: використання Mesos може означати трохи більше роботи над написанням власного планувальника, але, можливо, забезпечує більшу гнучкість, якщо потрібно.

Я думаю, що ідея запуску Kubernetes на вершині Mesos полягає в тому, щоб Kubernetes виступав планувальником Mesos. Особисто я не впевнений, яка користь від цього приносить той чи інший процес самостійно (сподіваюся, хтось заскочить і пояснить!)

Як сказав MikeB .. це ранні дні, і це все для захоплень (слідкуйте також за ECS на Amazon), тому існує багато конкуруючих стандартів і багато перекриття!

-edit- Я не згадав про рій Докера, оскільки я не маю великого досвіду з цим.

Для тих, хто приходить до цього після 2017 року флот застарілий. Не використовуйте його більше.

Документи флоту кажуть, що "флот більше не активно розвивається і не підтримується CoreOS" і посилається на контейнерну оркестрацію: перехід від флоту до Кубернетів . Флот був вилучений з контейнера Linux ( раніше відомий як CoreOS Linux ) і замінений кубелетом Kubernetes (агентом). Це збіглося з корпоративним стрижнем, щоб запропонувати Tectonic (дистрибутив Kubernetes) в якості свого основного продукту.