Docker-Swarm, Kubernetes, Mesos e Core-OS Flotta

Question

Sono relativamente nuovo a tutti questi, ma ho problemi a ottenere un quadro chiaro tra le tecnologie elencate.

Tuttavia, tutti questi tentativi cercano di risolvere diversi problemi, ma hanno anche cose in comune. Mi piacerebbe capire quali sono le cose che sono comuni e ciò che è diverso. È probabile che la combinazione di pochi sarebbe ottima, se sì, quali sono?

Sto elencando alcuni di essi insieme a domande, ma sarebbe bello se qualcuno li elencasse tutti in dettaglio e rispondesse alle domande.

1. kubernetes vs Mesos:

   Questo link

   What's the difference between Apache's Mesos and Google's Kubernetes

   offre una buona panoramica delle differenze, ma non riesco a capire il motivo per cui dovrebbe kubernetes correre sulla cima di Mesos. Ha più a che fare con l'unione di due soluzioni opensource?

2. kubernetes vs core-OS Flotta:

   Se uso kubernetes, è necessario flotta?

3. In che modo Docker-Swarm si adatta a tutto quanto sopra?

Answer 1

Disclosure: io sono un ingegnere capo sul kubernetes

penso che Mesos e kubernetes sono in gran parte finalizzate a risolvere problemi simili di applicazioni in esecuzione in cluster, hanno storie diverse e differenti approcci per risolvere il problema.

Mesos concentra la propria energia su una pianificazione molto generica e collega più programmatori diversi. Ciò significa che consente a sistemi come Hadoop e Marathon di coesistere nello stesso ambiente di pianificazione. Mesos è meno focalizzato sulla gestione dei container. Mesos esisteva prima di un interesse diffuso nei contenitori ed è stato rielaborato in parti per supportare i contenitori.

Al contrario, Kubernetes è stato progettato da zero per essere un ambiente per la costruzione di applicazioni distribuite da contenitori. Include primitive per la replicazione e l'individuazione di servizi come primitive primarie, dove, come tali, vengono aggiunte tramite framework in Mesos. L'obiettivo principale di Kubernetes è un sistema per la creazione, l'esecuzione e la gestione di sistemi distribuiti.

Flotta è un distributore di attività di livello inferiore. È utile per eseguire il bootstrap di un sistema cluster, ad esempio CoreOS lo utilizza per distribuire gli agenti e i binari di Kubernetes alle macchine in un cluster al fine di creare un cluster Kubernetes. In realtà non è inteso a risolvere gli stessi problemi di sviluppo di applicazioni distribuite, pensandoci più come systemd/init.d/upstart per il tuo cluster. Non è necessario se esegui kubernetes, puoi utilizzare altri strumenti (ad esempio Salt, Puppet, Ansible, Chef, ...) per ottenere la stessa distribuzione binaria.

Swarm è uno sforzo di Docker per estendere l'API Docker esistente per rendere un cluster di macchine simile a una singola API Docker. Fondamentalmente, la nostra esperienza su Google e altrove indica che l'API del nodo non è sufficiente per un'API del cluster. Potete vedere un mucchio di discussione su questo qui: https://github.com/docker/docker/pull/8859 e qui: https://github.com/docker/docker/issues/8781

Sperare che aiuti! Unisciti a noi su IRC @ # google-containers se vuoi parlare di più.

Answer 2

Penso che la risposta più semplice sia che non esiste una risposta semplice. La rapida ascesa al potere dei container e Docker in particolare ha lasciato un vuoto di potere per "scheduling e orchestrazione dei container", qualunque cosa ciò possa significare. In realtà, ciò significa che hai un numero di tecnologie che possono funzionare in armonia su alcuni livelli, ma con alcuni aspetti della competizione. Ad esempio, Kubernetes può essere utilizzato come uno sportello unico per la distribuzione e la gestione di container in un cluster di calcolo (come originariamente progettato da Google), ma può anche essere collocato in cima a Fleet, sfruttando il livello di resilienza fornito da Fleet su CoreOS.

As this Google vid states Kubernetes non è una completa soluzione di scaling del contenitore, ma è una buona affermazione da cui partire. Allo stesso modo, a un certo punto ti aspetteresti che Apache Mesos sia in grado di lavorare con Kubernetes, ma non con Marathon, in quanto Marathon sembra svolgere lo stesso ruolo di Kubernetes. Da qualche parte penso di aver letto queste potrebbero diventare parte dello stesso sforzo, ma potrei sbagliarmi: si tratta in realtà della direzione strategica della Mesosfera e della corrispondente adozione dei principi di Kubernetes.

Nel keynote di DockerCon, Solomon Hykes ha suggerito che Swarm sarebbe un livello che potrebbe fornire un'interfaccia comune sui numerosi framework di orchestrazione e programmazione. Da quello che vedo, Swarm è progettato per fornire un flusso di lavoro di distribuzione Docker uniforme, lavorando con alcuni framework di workflow del contenitore esistenti come Deis, ma abbastanza flessibile da consentire la distribuzione "pesante" e la gestione delle risorse come Mesos.

Spero che questo aiuti - questo potrebbe essere un post enorme. Penso che la chiave sia che si tratta di servizi giovani e in continua evoluzione che probabilmente si uniranno e diventeranno interoperabili, ma dobbiamo andare avanti nei prossimi 12 mesi per vedere come si evolverà. Ci sono persone molto intelligenti sul problema, quindi il futuro sembra molto brillante.

Answer 3

Per quanto ho capito:

Mesos, kubernetes e Fleet sono tutti cercando di risolvere un problema molto simile. L'idea è quella di estrarre tutto il tuo hardware dagli sviluppatori e lo 'strumento di gestione dei cluster' ordina tutto per te. Quindi tutto ciò che devi fare è dare un contenitore al cluster, dargli alcune informazioni (tenerlo sempre attivo, scalare se X accade ecc.) E il gestore cluster lo farà accadere.

Con Mesos, gestisce tutto il cluster management, ma non include lo scheduler. Lo scheduler è il bit che dice, ok questo processo richiede 2 proc e 512 MB di RAM, e ho una macchina laggiù con quella gratuita, quindi la eseguirò su quella macchina. Ci sono alcuni programmatori di plugin disponibili per Mesos: Marathon e Chronos e puoi scrivere il tuo. Questo ti dà molta potenza nella distribuzione delle risorse e nel ridimensionamento dei cluster, ecc.

Fleet e Kubernetes sembrano astrarre questi dettagli (in modo da non dover scrivere fondamentalmente il proprio programma di pianificazione). Ciò significa che devi definire le tue attività e inviarle nel formato/modo definito da Fleet o Kubernetes e poi subentrano e pianificano le attività (contenitori) per te.

Quindi suppongo: l'utilizzo di Mesos potrebbe significare un po 'più di lavoro nello scrivere il proprio programmatore, ma potenzialmente offre una maggiore flessibilità se necessario.

Penso che l'idea di eseguire Kubernetes su Mesos sia che Kubernetes funge da programmatore per Mesos. Personalmente non sono sicuro dei benefici che ne derivano (uno spero che qualcuno salti e spieghi!)

Come diceva MikeB .. sono i primi tempi, ed è tutto in palio (tieni d'occhio anche l'ECS di Amazon) quindi ci sono molti standard in competizione e molti si sovrappongono!

-edit- Non ho menzionato lo sciame Docker perché non ho molta esperienza con esso.

Answer 4

Per chi arriva in questo dopo il 2017 la flotta è deprecata. Non usarlo più.

Fleet docs dire "flotta non è più sviluppata o gestita attivamente da CoreOS" e collegamento a Container orchestration: Moving from fleet to Kubernetes. La flotta è stata rimossa da Container Linux (formerly known as CoreOS Linux) e sostituita con Kubernetes kubelet (agente). Questo ha coinciso con un pivot aziendale per offrire Tectonic (una distro di Kubernetes) come prodotto principale.