Cloud Native News #1: Rise of the Kubernaut

Ziel der Cloud Native News ist es, im regelmäßigen Abstand von wichtigen Ereignissen und Neuigkeiten im Cloud-Native-Ökosystem zu berichten und diese zu interpretieren, damit der Überblick gewahrt bleibt.

Know-how  –  0 Kommentare
Cloud Native News #1: Rise of the Kubernaut
Anzeige

Im Jahr 2015 hat es begonnen: Google veröffentlichte das Abbild seiner eigenen Software-Infrastruktur unter dem Namen Kubernetes als Open-Source-Projekt. Parallel dazu wurde von Google, Docker, Mesosphere, Red Hat und anderen Konsorten die CNCF (Cloud Native Computing Foundation) gegründet. Sie ist organisatorische Heimat von Kubernetes unter dem Dach der Linux Foundation und hat das Ziel, ein Ökosystem für Cloud Native Applications zu schaffen – also Anwendungen und Infrastruktur, die originär für den Betrieb in der Cloud geschaffen sind. Solche Software zeichnet aus, dass sie in Microservices geschnitten, in Container wie Docker verpackt und dynamisch in der Cloud ausgeführt wird.

Kubernetes ist dabei für die letzte dieser Eigenschaften zuständig. Neben der CNCF gibt es auch noch weitere Open-Source-Stiftungen, die Cloud-Native-Projekte unter ihren Fittichen haben, wie die Apache Software Foundation mit Spark und die Eclipse Foundation mit der Cloud-Native-Variante von JavaEE, dem MicroProfile.

Seit 2015 ist das Cloud-Native-Ökosystem rasant gewachsen bezüglich der Anzahl an Open-Source-Projekten, Start-ups und schierer Popularität. Bei der Geschwindigkeit, mit der Neues entsteht und manchmal Altes vergeht, ist es schwierig, den Überblick zu behalten. Dabei wollen die Cloud Native News helfen.

Die Anzahl der Kubernetes-Distributionen wächst und wächst, und das Tool verdrängt weiter Konkurrenten im Bereich der Container-Orchestrierung.

  • Bei DC/OS steht Kubernetes nun als alternatives Orchestrierungswerkzeug neben Marathon zur Verfügung. Das hat den großen Vorteil, dass Mesos dabei weiterhin der übergreifende Scheduler bleibt und sich pro DC/OS-Cluster auf Knopfdruck viele Kubernetes-Cluster instanziieren lassen. Die Integration von DC/OS mit Kubernetes ist noch in der Beta-Phase.
  • Das Unternehmen Docker verfolgt dieselbe Strategie in seiner Docker Enterprise Edition. Dort steht nun neben Docker Swarm auch Kubernetes zur Orchestrierung von Containern zur Verfügung. Es befindet sich ebenfalls noch in der Beta-Phase.
  • Pivotal hat auf dem Cloud Foundry Summit in Basel bekannt gegeben, dass mit der Cloud Foundry Container Runtime nun eine auf Kubernetes basierende Plattform zum Ausführen von Containern zur Verfügung steht. Die Plattform basiert auf dem gemeinsam von Pivotal und Google initiierten Kubo-Projekt und nutzt BOSH zur Provisionierung der Kubernetes Cluster. Bloomberg pilotiert die Plattform bereits. Die Container- und die bisherige Applikations-Runtime scheinen neben BOSH aber wenig zu teilen – nicht einmal die Knoten im Cluster. Bei der Schwemme an Kubernetes-Distributionen legt die Cloud Native Computing Foundation nun die schützende Hand über Kubernetes und führt mit der Kubernetes Software Certification eine Zertifikation für Distributionen ein. Der CNCF sind derzeit bereits 48 Distributionen bekannt – 32 davon sind schon zertifiziert.

Red Hat und Konsorten haben mit CRI-O einen Adapter von Kubernetes-CRI (Container Runtime Interface) auf die OCI-Spezifikation (Open Container Initiative). Der Große Fortschritt liegt darin, dass es den Einsatz jeder OCI-konformen Container-Runtime in Kubernetes ermöglicht. Zur Zeit sind runC (die Container Runtime von Docker) und Intels Clear Containers integriert.

Mesosphere bringt bei DC/OS wieder Bewegung ins Spiel und kündigte innerhalb kurzer Zeit sowohl Kubernetes als auch TensorFlow auf DC/OS an. Damit lassen sich nun Workloads mit dem De-facto-Standard für Container Orchestrierung (Kubernetes), Machine Learning (TensorFlow) und Big Data (Spark) auf dem leistungsfähigen Mesos-Cluster-Scheduler betreiben.

Dass Java EE neben Spring Boot einen Platz als Microservice-Chassis in der Cloud hat, ist spätestens seit dem MicroProfile und den zugehörigen Implementierungen klar. Nun verleiht IBM dem Ganzen noch weiter Schwung, indem es mit OpenJ9 ein JRE (Java Runtime Environment) und mit OpenLiberty ein Java-EE-Chassis für Cloud-Native-Anwendungen als Open-Source-Projekte veröffentlicht hat. Die großzügige Spende umfasst mehreren Millionen Codezeilen. OpenLiberty basiert auf der Codebasis des WebSphere-Liberty-Servers und bietet über das MicroProfile hinaus auch das Full Profile von Java EE 7. In naher Zukunft soll auch die Java-EE-8-API verfügbar sein. OpenJ9 ist eine neuartige JVM-Implementierung, die auf geringen Overhead und hohen Durchsatz ausgelegt ist.

Gerade bei Cloud-Native-Plattformen ist eine Herausforderung, die Softwarelogistik in den Griff zu bekommen, also die vielen beteiligten Bibliotheken und Container sicher und einfach erzeugen und den Zugang bereitstellen zu können. Hier gibt es nun neue Impulse mit dem beschriebenen CNCF-Projekt Notary sowie dem Projekt Grafeas, das Google und andere Unternehmen gestartet haben. Grafeas bietet eine Standardbeschreibung nebst Zugriffsschnittstelle für Metadaten binärer Artefakte wie Docker-Container oder JAR-Bibliotheken. Mit dem Unterprojekt Kritis lassen sich für einen Kubernetes-Cluster Policies definieren, welche binären Artefakte dort deployt werden dürfen und welche nicht.

Oracle ist nicht gerade dafür bekannt, der Open-Source-Gemeinde Gutes zu tun. Umso überraschender ist das Release von Oracle Fn zur JavaOne Anfang Oktober, einer vollwertigen Function-as-a-Service-(FaaS-)/Serverless-Plattform. Fn läuft überall dort, wo Docker-Container laufen können. Es unterstützt alle Sprachen, die in einem Container existieren und per STDIN, STDOUT, STDERR und Umgebungsvariablen kommunizieren können. Ferner lassen sich mit Fn AWS-Lambda-Funktionen importieren.

Bei den Open Source Summits der Linux Foundation in Los Angeles (Ende August) und Prag (Ende Oktober) erhielten mit Jaeger, Envoy und Notary/TUF insgesamt drei neue Open-Source-Projekte den Rang eines CNCF-Projekts.

  • Jaeger sammelt und visualisiert verteilte Traces, ist also ein Werkzeug zur Diagnostizierbarkeit von Cloud-Native-Anwendungen. Jaeger integriert sich in Kubernetes sowie OpenShift und ist kompatibel zum OpenTracing-Format, das sich ebenfalls unter dem Dach der CNCF befindet. Jaeger wurde ursprünglich von Uber entwickelt und ist eine Alternative zu ZipKin.
  • Envoy ist ein hochperformanter Proxy, den Unternehmen sowohl am Eintrittstor in ein Microservice-System (Edge) als auch für die Kommunikationsstrecken zwischen Microservices (Mesh) einsetzen können. Ursprünglich hatte Lyft Envoy in C++ entwickelt. Es ist im Mesh-Szenario eine Alternative zu linkerd und im Edge-Szenario zu Ingress-Implementierungen wie Traefik und NGIX oder Edge-Services und API-Gateways wie Netflix Zuul und Kong. Mit Ambassador ist ein Aufsatz auf Envoy verfügbar, der den Proxy am Edge zu einem vollwertigen API-Gateway aufwertet.
  • Notary/TUF ist eine Anwendung für die sichere Logistik von Containern. TUF steht für "The Update Framework" und spezifiziert ein Protokoll, mit dem sichere Update-Frameworks möglich sind. Letztere sind Mechanismen, die Software verteilen, installieren und aktualisieren wie Windows Update, YUM, Maven Repos und eben auch Docker Registries. Notary setzt auf TUF auf, um Vertrauen und Sicherheit bei den Images in einer Docker Registry zu schaffen. Die Grundidee dahinter ist eine PKI-Struktur, um die unterschiedlichen Daten diverser Rollen bei den einzelnen Verarbeitungsschritten zu signieren. TUF entstand an der New York University, und das Unternehmen Docker hat Notary darauf basierend implementiert.
Anzeige