Kubernetes vs. CloudFoundry [chiuso]

La prossima versione di CloudFoundry / Diego offrirà supporto nativo per i container Docker che verranno orchestrati su host multipli [ link ]. Sembra molto simile a Kubernetes.

Ovviamente, il problema che Kubernetes sta cercando di risolvere è più generico, in cui CloudFoundry è più focalizzato sullo sviluppo di app. Tuttavia, per me sembra che entrambi stiano andando in una direzione simile e CloudFoundry sta aggiungendo molte più funzionalità oltre alla semplice orchestrazione.

Quindi mi chiedo quali siano i casi d'uso in cui Kubernetes aggiungerebbe più valore di CloudFoundry?

In qualità di commiter di CloudFoundry (passato) e Kubernetes (presente), probabilmente sono qualificato in modo univoco per rispondere a questo.

PaaS-like

Mi piace chiamare CloudFoundry un "Application PaaS" e Kubernetes un "Container PaaS", ma la distinzione è abbastanza sottile e fluida, dato che entrambi i progetti cambiano nel tempo per competere negli stessi mercati.

La distinzione tra i due è che CF ha un livello di staging che accetta un'app utente (a 12 fattori) (ad esempio jar o gem) e un buildpack in stile Heroku (ad esempio Java + Tomcat o Ruby) e produce un droplet (analogo a un Immagine Docker). CF non espone l'interfaccia di containerizzazione all'utente, ma Kubernetes sì.

Pubblico

Il pubblico principale di CloudFoundry sono gli sviluppatori di applicazioni aziendali che desiderano distribuire app stateless a 12 fattori utilizzando i buildpack in stile Heroku.

Il pubblico di Kubernetes è un po 'più ampio, inclusi sviluppatori di applicazioni senza stato e di servizi con stato che forniscono i propri contenitori.

Questa distinzione potrebbe cambiare in futuro:

• CloudFoundry potrebbe iniziare ad accettare immagini Docker ( Lattice accetta immagini Docker ).
• Kubernetes potrebbe aggiungere un livello di generazione di immagini ( OpenShift fa qualcosa di simile ).

Confronto delle caratteristiche

Man mano che entrambi i progetti maturano e competono, le loro somiglianze e differenze cambieranno. Quindi prendi il seguente confronto delle caratteristiche con un grano di sale.

Sia CF che K8 condividono molte funzionalità simili, come containerizzazione, spazio dei nomi, autenticazione,

Vantaggi competitivi di Kubernetes:

• Raggruppa e ridimensiona pod di contenitori che condividono uno stack di rete, anziché ridimensionarli in modo indipendente
• Porta il tuo contenitore
• Livello di persistenza con stato
• Comunità OSS più ampia e attiva
• Architettura più estensibile con componenti sostituibili e plug-in di terze parti
• GUI web gratuita

Vantaggi competitivi di CloudFoundry:

• Autenticazione matura, raggruppamento di utenti e supporto multi-tenancy [x]
• Porta la tua app
• Bilanciatore del carico incluso
• Distribuito, ridimensionato e mantenuto in vita da BOSH [x]
• Registrazione robusta e aggregazione di metriche [x]
• GUI Web aziendale [x]

[x] Queste funzionalità non fanno parte di Diego né sono incluse in Lattice.

Distribuzione

Uno dei vantaggi competitivi di CloudFoundry è che ha un motore di distribuzione maturo, BOSH, che abilita funzionalità come il ridimensionamento, la resurrezione e il monitoraggio dei componenti CF principali. BOSH supporta anche molti livelli IaaS con un'astrazione di provider di cloud collegabile. Sfortunatamente, la curva di apprendimento di BOSH e la gestione della configurazione della distribuzione sono da incubo. (In qualità di committer BOSH, penso di poterlo dire con precisione.)

L'astrazione della distribuzione di Kubernetes è ancora agli inizi. Più ambienti di destinazione sono disponibili nel repository principale, ma non tutti funzionano, sono ben testati o supportati dagli sviluppatori principali. Questa è principalmente una questione di maturità. Ci si potrebbe aspettare che questo migliori nel tempo e aumenti l'astrazione. Ad esempio, Kubernetes su DCOS consente di distribuire Kubernetes a un cluster DCOS esistente con un singolo comando.

Contesto storico

Diego è una riscrittura di Droplet Execution Agent di CF. È stato originariamente sviluppato prima dell'annuncio di Kubernetes e ha assunto un ambito di funzionalità più ampio con l'evoluzione del panorama competitivo. Il suo obiettivo originale era quello di generare droplet (applicazione utente + buildpack CF) ed eseguirli in contenitori Warden (rinominati Garden quando riscritti in Go). Fin dal suo inizio è stato anche riconfezionato come Lattice , che è un po 'un CloudFoundry-lite (sebbene quel nome sia stato preso da un progetto esistente). Per questo motivo, Lattice è in qualche modo simile a un giocattolo, in quanto ha deliberatamente ridotto il pubblico e l'ambito dell'utente, mancando esplicitamente di funzionalità che lo renderebbero "pronto per le imprese". Funzionalità già fornite da CF. Ciò è in parte dovuto al fatto che Lattice viene utilizzato per testare i componenti principali, senza alcun sovraccarico derivante dalla CF più complessa, ma è anche possibile utilizzare Lattice in ambienti interni ad alta affidabilità in cui la sicurezza e il multi-tenancy non sono un problema così importante .

Vale anche la pena ricordare che CloudFoundry e Warden (il suo motore di container) sono anteriori a Docker di un paio di anni.

Kubernetes, d'altra parte, è un progetto relativamente nuovo sviluppato da Google sulla base di anni di utilizzo di container con BORG e Omega. Kubernetes potrebbe essere considerato come l'orchestrazione di container di terza generazione in Google, allo stesso modo in cui Diego è l'orchestrazione di container di terza generazione in Pivotal / VMware (v1 scritta su VMware; v2 su VMware con l'aiuto di Pivotal Labs; v3 su Pivotal dopo che ha rilevato il progetto) .

Cloud Foundry è un ottimo strumento supponendo che tu sia disposto a lavorare sempre entro i limiti dell'offerta in quanto è molto supponente / prescritto. L'interfaccia utente Web è interessante da guardare il primo giorno, ma viene utilizzata raramente dopo aver iniziato a lavorare con il client e aver configurato la pipeline CI / CD. Ho scoperto che Cloud Foundry è ottimo fino a quando non vengono visualizzati casi d'uso che non sono facilmente supportati completamente in Cloud Foundry. La fornitura di questi casi d'uso può ritardare i progetti mentre si tenta di risolvere tali problemi, di conseguenza si perde la visibilità dell'infrastruttura e si supportano i vantaggi di quei componenti che sono quindi per lo più in esecuzione al di fuori di Cloud Foundry (si pensi a più database, kafka, hadoop, cassandra , ecc.) Sospetto che nel tempo, lo slancio che circonda Docker e l'inflessibilità di Cloud Foundry porterà gli utenti a Kubernetes, Mesos o Docker Swarm / Datacenter. È possibile che Cloud Foundry possa raggiungere questi tre, ma sembrerebbe improbabile a causa della popolarità di questi progetti open source.

È difficile rispondere al motivo per cui un'azienda dovrebbe costruire un prodotto sostanzialmente simile a un altro prodotto. Ci sono molte ragioni. Forse hanno già iniziato a usarlo e ci hanno investito. Forse (CF) pensano che Kubernetes sia fatto male o stia sbagliando API / modello / dettagli. Forse pensano di potersi muovere più rapidamente se controllano l'intero prodotto invece di contribuire.

Certo, lo dico come sviluppatore Kubernetes: si potrebbero porre le stesse domande a Kubernetes vs Mesos, Amazon ECS vs Kubernetes o Docker Swarm vs Kubernetes.

Spero che nel tempo andiamo tutti nella stessa direzione e possiamo collaborare di più e dedicare meno tempo a reinventare il lavoro l'uno dell'altro.

Per quanto riguarda Kubernetes, l'attenzione è rivolta agli sviluppatori di app: primitive semplici e potenti che ti consentono di creare e distribuire app su larga scala molto rapidamente. Ci basiamo sulla nostra esperienza (beh, su Google) con tecnologie simili per tracciare la nostra rotta. Altre persone avranno esperienze o opinioni diverse.

Una differenza significativa, secondo me, è l'approccio che stanno adottando:

CF crea automaticamente il runtime da 3 componenti: binario dell'applicazione fornito dall'utente, buildpack contenente il middleware necessario per eseguire l'app e un'immagine del sistema operativo (una cella staminale). L'utente CF (uno sviluppatore) deve fornire solo il binario dell'applicazione (ad esempio un file jar eseguibile). Il CF si occupa del resto, cioè del confezionamento e dell'esecuzione dell'app.

Kubernetes si aspetta da uno sviluppatore immagini Docker che contengono middleware e sistema operativo già integrati e pronti per essere eseguiti. Per questo, il "manifesto di distribuzione" di Kubernetes (ad esempio un grafico Helm) descrive non solo una singola app o servizio, ma tutti i [micro] servizi che compongono la tua soluzione in fase di runtime. Invii una singola descrizione dichiarativa del tuo runtime e Kubernetes si preoccupa che lo stato di runtime effettivo corrisponda alla descrizione fornita.

Quindi l'approccio CF gli consente di affrontare casi d'uso come "sostituire un sistema operativo con una falla di sicurezza corretta nell'intero cloud senza tempi di inattività per i servizi". Ma si concentra anche sull'implementazione del servizio per servizio anziché sulla descrizione dichiarativa di un runtime "ideale" di destinazione del sistema.

Cloud Foundry è un sistema di cloud computing open source platform-as-a-service. Cloud Foundry consente di distribuire i progetti in diversi spazi e inoltre lega qualsiasi servizio cloud alla tua applicazione.

Kubernete è più simile a uno strumento di ornamento per contenitori (pod) che automatizza la distribuzione, il ridimensionamento e la gestione delle applicazioni containerizzate. Utilizza il termine pod per definire un contenitore o un gruppo di contenitori.

Qualsiasi distribuzione di Kubernetes richiede almeno due risorse:

1) deployment.yaml: questa risorsa definisce quale versione dell'immagine deve essere prelevata dal registro del contenitore, dai replicaset (repliche pod), dalla strategia di rollout, dal ridimensionamento e dai probe ecc.

2) service.yaml: è un'interfaccia tra i tuoi pod interni e il mondo esterno, tutto il traffico esterno ascolterà la porta definita in questa risorsa da dove distribuirà il carico ai pod interni.

Una risorsa in più è l'ingresso fornito da kubernetes che gestisce l'accesso esterno ai servizi in un cluster, in genere http. Tramite Ingress puoi fornire bilanciamento del carico, terminazione SSL e hosting virtuale basato sul nome.

Di seguito puoi trovare ulteriori informazioni su kubernetes: https://kubernetes.io/docs/

[pcf vs kubernetes] [1] Differenza tra pcf e kubernetes

                                PCF

(astrazione della piattaforma a livello di applicazione) • Pivotal Cloud Foundry è un'astrazione di alto livello dello sviluppo di applicazioni native del cloud.

• Abbiamo l'astrazione della piattaforma a livello di applicazione, costruendo e distribuendo un'applicazione completamente configurata

• PCF è un esempio di "applicazione" PaaS (chiamato anche Cloud Foundry Application Runtime)

• Lo sviluppatore mantiene l'applicazione in futuro

• Ideale per nuove applicazioni, app native del cloud. Per i team che lavorano con cicli di vita brevi e rilasci frequenti, PCF offre un prodotto eccellente.

                       Kubernetes 

(astrazione della piattaforma a livello di container) • Kubernetes è uno scheduler o orchestrator di container.

• Abbiamo l'astrazione della piattaforma a livello di container, costruendo e distribuendo container come parte di un'applicazione completa.

• Kubernetes è un PaaS "contenitore" (a volte chiamato CaaS).

• Con gli strumenti di orchestrazione del contenitore, lo sviluppatore crea e quindi mantiene il contenitore in futuro.

• Per nuove applicazioni, più lavoro per i team di ingegneri e minore produttività

Dopo 4 anni le tendenze sono così:

I cluster Kubernetes stanno diventando davvero economici in questi giorni e l'ambiente di strumenti per Kubernetes è migliore.

Inoltre, oggigiorno la maggior parte delle funzionalità della concorrenza elencate da altri poster sono facilmente replicabili all'interno di kubernetes.