Kubernetes vs. CloudFoundry [geschlossen]

Die nächste Version von CloudFoundry / Diego bietet native Unterstützung für Docker-Container, die auf mehreren Hosts orchestriert werden [ Link ]. Das klingt Kubernetes sehr ähnlich.

Natürlich ist das Problem, das Kubernetes zu lösen versucht, eher ein allgemeines, bei dem sich CloudFoundry mehr auf die App-Entwicklung konzentriert. Für mich klingt es jedoch so, als würden beide in eine ähnliche Richtung gehen und CloudFoundry fügt zusätzlich zur einfachen Orchestrierung viel mehr Funktionen hinzu.

Ich frage mich also über Anwendungsfälle, in denen Kubernetes mehr Wert als CloudFoundry bieten würde.

Als CloudFoundry (Vergangenheit) und Kubernetes (Gegenwart) Commiter bin ich wahrscheinlich einzigartig qualifiziert, um diese Frage zu beantworten.

PaaS-ähnlich

Ich nenne CloudFoundry gerne "Application PaaS" und Kubernetes "Container PaaS", aber die Unterscheidung ist ziemlich subtil und fließend, da sich beide Projekte im Laufe der Zeit ändern, um auf denselben Märkten zu konkurrieren.

Der Unterschied zwischen beiden besteht darin, dass CF über eine Staging-Ebene verfügt, die eine (12-Faktor-) Benutzer-App (z. B. JAR oder Gem) und ein Buildpack im Heroku-Stil (z. B. Java + Tomcat oder Ruby) verwendet und ein Tröpfchen erzeugt (analog zu a) Docker-Bild). CF stellt die Containerisierungsschnittstelle dem Benutzer nicht zur Verfügung, Kubernetes jedoch.

Publikum

Die Hauptzielgruppe von CloudFoundry sind Entwickler von Unternehmensanwendungen, die zustandslose 12-Faktor-Apps mithilfe von Buildpacks im Heroku-Stil bereitstellen möchten.

Das Publikum von Kubernetes ist etwas breiter, einschließlich zustandsloser Anwendungsentwickler und Entwickler von Stateful Services, die ihre eigenen Container bereitstellen.

Diese Unterscheidung könnte sich in Zukunft ändern:

• CloudFoundry akzeptiert möglicherweise Docker-Images ( Lattice akzeptiert Docker-Images ).
• Kubernetes könnte eine Bilderzeugungsschicht hinzufügen ( OpenShift macht so etwas ).

Funktionsvergleich

Wenn beide Projekte reifen und miteinander konkurrieren, werden sich ihre Ähnlichkeiten und Unterschiede ändern. Nehmen Sie also den folgenden Funktionsvergleich mit einem Salzkorn.

Sowohl CF als auch K8 haben viele ähnliche Funktionen gemeinsam, wie Containerisierung, Namespace, Authentifizierung,

Wettbewerbsvorteile von Kubernetes:

• Gruppieren und skalieren Sie Pods von Containern, die sich einen Netzwerkstapel teilen, anstatt nur unabhängig zu skalieren
• Bringen Sie Ihren eigenen Behälter mit
• Stateful Persistance Layer
• Größere, aktivere OSS-Community
• Erweiterbarere Architektur mit austauschbaren Komponenten und Plugins von Drittanbietern
• Kostenlose Web-GUI

Wettbewerbsvorteile von CloudFoundry:

• Unterstützung für ausgereifte Authentifizierung, Benutzergruppierung und Mandantenfähigkeit [x]
• Bringen Sie Ihre eigene App mit
• Enthaltener Load Balancer
• Von BOSH bereitgestellt, skaliert und am Leben erhalten [x]
• Robuste Protokollierung und Metrikaggregation [x]
• Enterprise Web GUI [x]

[x] Diese Funktionen sind nicht Teil von Diego oder in Lattice enthalten.

Einsatz

Einer der Wettbewerbsvorteile von CloudFoundry besteht darin, dass es über eine ausgereifte Bereitstellungs-Engine, BOSH, verfügt, die Funktionen wie Skalierung, Wiederbelebung und Überwachung der wichtigsten CF-Komponenten ermöglicht. BOSH unterstützt auch viele IaaS-Schichten mit einer steckbaren Cloud-Provider-Abstraktion. Leider sind die Lernkurve von BOSH und das Management der Bereitstellungskonfiguration ein Albtraum. (Als BOSH-Committer kann ich das mit Genauigkeit sagen.)

Die Bereitstellungsabstraktion von Kubernetes steckt noch in den Kinderschuhen. Im Kern-Repo stehen mehrere Zielumgebungen zur Verfügung, die jedoch nicht alle funktionieren, gut getestet oder von den Hauptentwicklern unterstützt werden. Dies ist meistens eine Reifesache. Man könnte erwarten, dass sich dies im Laufe der Zeit verbessert und die Abstraktion zunimmt. Mit Kubernetes unter DCOS können Sie beispielsweise Kubernetes mit einem einzigen Befehl in einem vorhandenen DCOS- Cluster bereitstellen .

Historischer Zusammenhang

Diego ist eine Neufassung von CFs Droplet Execution Agent. Es wurde ursprünglich vor der Ankündigung von Kubernetes entwickelt und hat im Zuge der Entwicklung der Wettbewerbslandschaft mehr Funktionsumfang erhalten. Das ursprüngliche Ziel bestand darin, Tröpfchen (Benutzeranwendung + CF-Buildpack) zu generieren und in Warden-Containern (beim Umschreiben in Go in Garden umbenannt) auszuführen. Seit seiner Gründung wurde es auch als Lattice neu verpackt , was eine Art CloudFoundry-Lite ist (obwohl dieser Name von einem bestehenden Projekt übernommen wurde). Aus diesem Grund ist Lattice insofern etwas spielzeugartig, als es die Zielgruppe und den Umfang der Benutzer absichtlich reduziert hat und explizit Funktionen fehlt, die es "unternehmensfähig" machen würden. Funktionen, die CF bereits bietet. Dies liegt zum Teil daran, dass Lattice zum Testen der Kernkomponenten verwendet wird, ohne dass ein Teil des Overheads durch die komplexere CF entsteht. Sie können Lattice jedoch auch in internen Umgebungen mit hohem Vertrauen verwenden, in denen Sicherheit und Mandantenfähigkeit nicht so wichtig sind .

Erwähnenswert ist auch, dass CloudFoundry und Warden (seine Container-Engine) ebenfalls ein paar Jahre älter sind als Docker.

Kubernetes hingegen ist ein relativ neues Projekt, das von Google auf der Grundlage jahrelanger Containernutzung mit BORG und Omega entwickelt wurde. Kubernetes könnte als Container-Orchestrierung der 3. Generation bei Google betrachtet werden, genauso wie Diego die Container-Orchestrierung der 3. Generation bei Pivotal / VMware (v1 bei VMware geschrieben; v2 bei VMware mit Hilfe von Pivotal Labs; v3 bei Pivotal nach Übernahme des Projekts). .

Cloud Foundry ist ein großartiges Tool, vorausgesetzt, Sie sind bereit, immer innerhalb der Einschränkungen des Angebots zu arbeiten, da es sehr eigensinnig / vorgeschrieben ist. Die Web-Benutzeroberfläche ist am ersten Tag cool anzusehen, wird jedoch selten verwendet, nachdem Sie mit der Arbeit mit dem Client begonnen und Ihre CI / CD-Pipeline konfiguriert haben. Ich habe festgestellt, dass Cloud Foundry großartig ist, bis Anwendungsfälle auftauchen, die in Cloud Foundry nicht einfach vollständig unterstützt werden. Das Bereitstellen dieser Anwendungsfälle kann Projekte verzögern, wenn Sie versuchen, diese Probleme zu lösen. Infolgedessen verlieren Sie die Sichtbarkeit der Infrastruktur und die Supportvorteile der Komponenten, die dann meist außerhalb von Cloud Foundry ausgeführt werden (denken Sie an mehrere Datenbanken, kafka, hadoop, cassandra) usw.) Ich vermute, dass die Dynamik von Docker und die Inflexibilität von Cloud Foundry im Laufe der Zeit die Benutzer zu Kubernetes führen werden. Mesos oder Docker Swarm / Datacenter. Es ist möglich, dass Cloud Foundry diese drei einholt, aber aufgrund der Beliebtheit dieser Open-Source-Projekte erscheint dies unwahrscheinlich.

Es ist schwer zu beantworten, warum ein Unternehmen ein Produkt bauen würde, das einem anderen Produkt im Wesentlichen ähnlich ist. Es gibt viele Gründe. Vielleicht haben sie es bereits benutzt und sind in es investiert. Vielleicht denken sie (CF), dass Kubernetes schlecht gemacht ist oder dass die API / das Modell / die Details falsch sind. Vielleicht denken sie, dass sie sich schneller bewegen können, wenn sie das gesamte Produkt kontrollieren, anstatt einen Beitrag zu leisten.

Zugegeben, ich sage dies als Kubernetes-Entwickler - man könnte die gleichen Fragen an Kubernetes gegen Mesos, Amazon ECS gegen Kubernetes oder Docker Swarm gegen Kubernetes stellen.

Ich hoffe, dass wir im Laufe der Zeit alle in die gleiche Richtung tendieren und mehr zusammenarbeiten und weniger Zeit damit verbringen können, die Arbeit des anderen neu zu erfinden.

Bei Kubernetes liegt der Fokus auf App-Entwicklern: einfache und leistungsstarke Grundelemente, mit denen Sie Apps sehr schnell in großem Maßstab erstellen und bereitstellen können. Wir stützen uns auf unsere Erfahrung (nun ja, die von Google) mit ähnlichen Technologien, um unseren Kurs zu bestimmen. Andere Menschen haben andere Erfahrungen oder Meinungen.

Ein wesentlicher Unterschied ist meiner Meinung nach der Ansatz, den sie verfolgen:

CF erstellt die Laufzeit automatisch aus 3 Komponenten: Vom Benutzer bereitgestellte Anwendungsbinärdatei, Buildpack mit Middleware, die zum Ausführen der App benötigt wird, und ein Betriebssystem-Image (eine Stammzelle). Der CF-Benutzer (ein Entwickler) muss nur eine Anwendungsbinärdatei bereitstellen (z. B. eine ausführbare JAR-Datei). Der CF kümmert sich um den Rest, das Packen und Ausführen der App.

Kubernetes erwartet von einem Entwickler Docker-Images, die bereits integrierte und betriebsbereite Middleware und ein Betriebssystem enthalten. Zu diesem Zweck beschreibt das „Bereitstellungsmanifest“ von Kubernetes (z. B. ein Helmdiagramm) nicht nur eine einzelne App oder einen einzelnen Dienst, sondern alle [Mikro-] Dienste, aus denen Ihre Lösung zur Laufzeit besteht. Sie senden eine einzelne deklarative Beschreibung Ihrer Laufzeit und Kubernetes kümmert sich darum, dass der tatsächliche Laufzeitstatus mit Ihrer angegebenen Beschreibung übereinstimmt.

Der CF-Ansatz ermöglicht es ihm daher, Anwendungsfälle wie "Ersetzen eines Betriebssystems durch eine gepatchte Sicherheitslücke in Ihrer gesamten Cloud ohne Ausfallzeiten für Ihre Dienste" zu behandeln. Es konzentriert sich aber auch auf die Bereitstellung von Diensten pro Dienst anstelle der deklarativen Beschreibung einer „idealen“ Ziellaufzeit Ihres Systems.

Cloud Foundry ist ein Open-Source-Cloud-Computing-System für die Plattform als Service. Cloud Foundry ermöglicht die Bereitstellung von Projekten in verschiedenen Bereichen und bindet jeden Cloud-Service an Ihre Anwendung.

Kubernete ist eher ein Verzierungswerkzeug für Container (Pods), das die Bereitstellung, Skalierung und Verwaltung von Containeranwendungen automatisiert. Es verwendet den Begriff Pods, um Container oder Containergruppen zu definieren.

Jede Kubernetes-Bereitstellung benötigt mindestens zwei Ressourcen:

1) deploy.yaml: Diese Ressource definiert, welche Version des Images aus Ihrem Containerregister, Replikatsätzen (Pod-Replikaten), Rollout-Strategie, Skalierung und Tests usw. abgerufen werden muss.

2) service.yaml: Es ist eine Schnittstelle zwischen Ihren internen Pods und der Außenwelt. Der gesamte externe Datenverkehr überwacht den in dieser Ressource definierten Port, von wo aus er die Last auf die internen Pods verteilt.

Eine weitere Ressource ist der Eingang, den Kubernetes bereitstellen, um den externen Zugriff auf die Dienste in einem Cluster zu verwalten, normalerweise http. Über Ingress können Sie Lastausgleich, SSL-Terminierung und namenbasiertes virtuelles Hosting bereitstellen.

Weitere Informationen zu Kubernetes finden Sie unten: https://kubernetes.io/docs/

[pcf vs kubernetes] [1] Unterschied zwischen pcf und kubernetes

                                PCF

(Plattformabstraktion auf Anwendungsebene) • Pivotal Cloud Foundry ist eine allgemeine Abstraktion der Cloud-nativen Anwendungsentwicklung.

• Wir haben die Plattformabstraktion auf Anwendungsebene, die eine vollständig konfigurierte Anwendung erstellt und bereitstellt

• PCF ist ein Beispiel für ein „Anwendungs“ -PaaS (auch als Cloud Foundry Application Runtime bezeichnet).

• Der Entwickler verwaltet die Anwendung in Zukunft

• Ideal für neue Anwendungen, Cloud-native Apps. Für Teams, die mit kurzen Lebenszyklen und häufigen Releases arbeiten, bietet PCF ein hervorragendes Produkt.

                       Kubernetes 

(Plattformabstraktion auf Containerebene) • Kubernetes ist ein Container Scheduler oder Orchestrator.

• Wir haben die Plattformabstraktion auf Containerebene, indem Container als Teil einer vollständigen Anwendung erstellt und bereitgestellt werden.

• Kubernetes ist ein „Container“ -PaaS (manchmal auch als CaaS bezeichnet).

• Mit Container-Orchestrierungs-Tools erstellt der Entwickler den Container und verwaltet ihn in Zukunft.

• Für neue Anwendungen Mehr Arbeit für Ihre Entwicklungsteams und geringere Produktivität

Nach 4 Jahren sehen Trends so aus:

Kubernetes-Cluster werden heutzutage sehr billig und die Toolumgebung für Kubernetes ist besser.

Auch die meisten Wettbewerbsfunktionen, die auf anderen Postern aufgeführt sind, lassen sich heutzutage problemlos in Kubernetes replizieren.