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

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

Tuttavia, tutti questi tentano di risolvere diversi problemi, ma hanno anche cose in comune. Vorrei capire quali sono le cose che sono comuni e ciò che è diverso. È probabile che la combinazione di pochi sarebbe perfetta, in caso affermativo quali sono?

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

1. Kubernetes vs Mesos:

   Questo link

   Qual è la differenza tra Mesos di Apache e Kubernetes di Google

   fornisce una buona visione delle differenze, ma non riesco a capire perché Kubernetes dovrebbe funzionare su Mesos. Ha più a che fare con l'unione di due soluzioni opensource?

2. Flotta Kubernetes vs Core-OS:

   Se utilizzo kubernetes, è necessaria la flotta?

3. Come si inserisce Docker-Swarm in tutto quanto sopra?

Divulgazione: sono un ingegnere capo di Kubernetes

Penso che Mesos e Kubernetes siano in gran parte volti a risolvere problemi simili nell'esecuzione di applicazioni in cluster, hanno storie diverse e approcci diversi per risolvere il problema.

Mesos concentra le proprie energie su una pianificazione molto generica e inserisce 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 del diffuso interesse per i contenitori ed è stato ricodificato in parti per supportare i contenitori.

Al contrario, Kubernetes è stato progettato da zero per essere un ambiente per la creazione di applicazioni distribuite dai container. Include primitive per la replica e la scoperta di servizi come primitive di base, dove - come tali cose vengono aggiunte tramite framework in Mesos. L'obiettivo principale di Kubernetes è un sistema per la costruzione, l'esecuzione e la gestione di sistemi distribuiti.

La flotta è un distributore di attività di livello inferiore. È utile per il bootstrap di un sistema cluster, ad esempio CoreOS lo utilizza per distribuire agenti e binari di kubernetes alle macchine in un cluster al fine di attivare un cluster di kubernetes. Non è davvero destinato a risolvere gli stessi problemi di sviluppo di applicazioni distribuite, pensalo più come systemd / init.d / upstart per il tuo cluster. Non è necessario se si eseguono kubernetes, è possibile 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 far sembrare un cluster di macchine come 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. Puoi vedere un sacco di discussioni su questo qui: https://github.com/docker/docker/pull/8859 e qui: https://github.com/docker/docker/issues/8781

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

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 la "pianificazione e orchestrazione dei container", qualunque cosa ciò potesse significare. In realtà, ciò significa che hai una serie di tecnologie che possono funzionare in armonia su alcuni livelli, ma con alcuni aspetti in competizione. Ad esempio, Kubernetes può essere utilizzato come sportello unico per la distribuzione e la gestione di container in un cluster di calcolo (come Google lo aveva originariamente progettato), ma poteva anche sedere in cima alla flotta, facendo uso del livello di resilienza che Fleet fornisce su CoreOS.

Come afferma questo video di Google, Kubernetes non è una soluzione completa per il ridimensionamento dei container, ma è una buona affermazione da cui partire. Allo stesso modo, ad 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 che potrebbero diventare parte dello stesso sforzo, ma potrei sbagliarmi a riguardo - riguarda davvero la direzione strategica della Mesosfera e la corrispondente adozione dei principi di Kubernetes.

Nel keynote di DockerCon, Solomon Hykes ha suggerito che Swarm sarebbe un livello in grado di fornire un'interfaccia comune ai numerosi framework di orchestrazione e pianificazione. Da quello che posso vedere, Swarm è progettato per fornire un flusso di lavoro di distribuzione Docker regolare, lavorando con alcuni framework di flusso di lavoro container esistenti come Deis, ma abbastanza flessibile da cedere a una distribuzione "pesante" e alla 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 evoluzione che probabilmente si fonderanno e diventeranno interoperabili, ma dobbiamo cavalcare i prossimi 12 mesi per vedere come va. Ci sono alcune persone molto intelligenti sul problema, quindi il futuro sembra molto luminoso.

Per quanto ho capito:

Mesos, Kubernetes e Fleet stanno tutti cercando di risolvere un problema molto simile. L'idea è di sottrarre tutto il tuo hardware agli sviluppatori e lo "strumento di gestione dei cluster" risolve tutto per te. Quindi tutto ciò che devi fare è dare un contenitore al cluster, dargli alcune informazioni (tenerlo in esecuzione in modo permanente, scalare se X accade ecc.) E il gestore cluster lo farà accadere.

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

Fleet e Kubernetes sembrano sottrarre questo tipo di dettagli (quindi non è necessario scrivere il proprio programmatore in pratica). Ciò significa che devi definire le tue attività e inviarle nel formato / modo definito da Fleet o Kubernetes e quindi assumono e pianificano le attività (container) per te.

Quindi immagino: l'uso di Mesos può significare un po 'più di lavoro nello scrivere il proprio programmatore, ma potenzialmente offre maggiore flessibilità se necessario.

Penso che l'idea di far funzionare Kubernetes su Mesos sia che Kubernetes funga da schedulatore per Mesos. Personalmente non sono sicuro di quali benefici porti a correre l'uno o l'altro da solo (speriamo che qualcuno salti dentro e spieghi!)

Come ha detto MikeB .. sono i primi giorni, ed è tutto pronto (tieni d'occhio anche l'ECS di Amazon), quindi ci sono molti standard concorrenti e molte sovrapposizioni!

-edit- Non ho menzionato lo sciame di Docker in quanto non ho molta esperienza con esso.

Per chiunque venga a questo dopo il 2017 la flotta è deprecata. Non usarlo più.

I documenti della flotta affermano che "la flotta non è più attivamente sviluppata o gestita da CoreOS" e si collega all'orchestrazione dei container: passare dalla flotta a Kubernetes . La flotta fu rimossa da Container Linux ( precedentemente noto come CoreOS Linux ) e sostituita con Kubernetes kubelet (agente). Ciò coincise con un perno aziendale per offrire Tectonic (una distro di Kubernetes) come prodotto principale.