Bericht von der KubeCon/CloudNativeCon in Berlin

Microservices, Kubernetes, Docker, CoreOS und mehr

| Autor / Redakteur: Ulrike Ostler / Ulrike Ostler

Im Berlin Convention Center fand vom 28. bis 30. März die KubeCon/CloudNativeCon statt. rund 1500 Kubernauts waren gekommen.
Im Berlin Convention Center fand vom 28. bis 30. März die KubeCon/CloudNativeCon statt. rund 1500 Kubernauts waren gekommen. (Bild: Cloud Native Computing Foundation)

„Das Ding wird riesig, viel größer als OpenStack jemals werden könnte“. Darin waren sich die Mitglieder der erst im vergangenen Jahr gegründeten Non-Profit-Organisation Cloud Native Computing Foundation (CNCF) unter dem Dach der Linux Foundation einig, als sie sich zur „KubeCon/CloudNativCon“ in Berlin mit Fans und Kontributoren trafen.

Kubernetes ist ursprünglich von Google als „K8s“ in Go entwickelt worden und wird von Kelsey Hightower, Mitautor des Buchs „Kubernetes: Up and Running - Dive into the Future of Infrastructure” und einer der Köpfe hinter der Google Cloud sowie hinter Kubernetes als Infrastuktur für Applikationen und als Voraussetzung für Multi-Cloud-Betrieb gesehen.

John Beda, CTO von Hepteo und Co-Autor des Buchs, drückt das so aus: „Ursprünglich ist Kubernetes von System-Ingenieuren, als System-Software für System-Ingenieure entwickelt worden. „Doch jetzt“, ermahnt er seine Zuhörerschaft, „seien ganz andere Menschen in den Unternehmen involviert. Diese bringen neue Sichtweisen, aber weniger Know-how mit. Behandelt sie mit Respekt.“

Zu dem Zeitpunkt als Kubernetes, griechisch für Steuermann, als Version 1.0 im Jahr 2015 released wurde und von nun an bei Github zum Download bereitstand, hatten bereits mehr als 400 Contributors rund 14.000 Commits zu dem Open-Source-Release beigesteuert und Google übergab das Projekt nach 15 Jahren Entwicklungstätigkeit an die neue gegründete Cloud Native Computing Foundation (CNCF). „Ein beispielloses Vorgehen“, sagt Alexis Richardson, Mitgründer und CEO von Weaveworks und im CNCF Governing Board. Damals steuerte Google bereits Milliarden an Containern pro Woche.

Kubernetes wird zum CNCF-Projekt

Während Docker ein Lifecycle-Management für Container aus etwa Code, Laufzeitmodul, System-Tools und Systembibliotheken bereitstellt, erlaubt Kubernetes auf einem höheren Level die Orchestrierung und das Management von Container-Clustern. Kubernetes kann Container auf existenten virtuellen Maschinen (VMs) bereitstellen sowie neue VMs provisionieren und Container dort platzieren. Die Funktionen reichen also weit darüber hinaus, Container zu booten, zu überwachen und zu verwalten.

Kelsey Hightower, Staff Developer Advocate bei Google, erläutert, wie Kubernetes Federation funktioniert.
Kelsey Hightower, Staff Developer Advocate bei Google, erläutert, wie Kubernetes Federation funktioniert. (Bild: Cloud Native Computing Foundation)

Die Administratoren erstellen so genannte Pods, eine logische Kollektion von Containern, die zu einer Anwendung gehören. Diese Pods lassen sich mit Ressourcen verknüpfen, etwa mit VMs oder auch Bare-Metal-Servern. Rechner, die Anwendungen ausführen, werden als „Nodes“, früher „Minion“ bezeichnet. Außerdem gehört zum Funktionsumfang die „Control Plane“, auch als „Master“ bezeichnet. Hier liegt die Steuerung des Clusters. Das Kommandozeilen-Programm „kubectl” erlaubt es, von einem Client-Rechner das Cluster und Deployment zu steuern.

Zu den CNCF-Gründungsmitgliedern zählten damals außer Google AT&T, Box, Cisco, die Cloud Foundry Foundation, CoreOS, Docker, eBay, Goldman Sachs, Huawei, IBM, Intel, Mesosphere, Red Hat, Twitter, Univa, VMware and Weaveworks. Mittlerweile zählt die Folie mit den Unterstützern der CNCF 535 Logos. Gut, viele davon dürften einem breiteren Publikum kaum bekannt sein, doch seit fünf Tagen ist etwa Suse Gold-Mitglied und bietet nun „Kubernetes-as-a-Service” in der hauseigenen OpenStack-Cloud “Cloud 7” an, quasi als Kubernetes-integriertes Container-Betriebssystem, ausgeliefert per Container-as-a-Service (CaaS) Plattform, die zudem eine Konvergenz von CaaS und PaaS bietet und bald innerhalb Cloud Foundry mit Kubernetes als Schlüsselelement ausgeliefert werden soll. Ebenfalls vor fünf Tagen schlossen sich Hangzhou Harmony Cloud Technology LTD, QAware, Solinea und Tenxcloud an.

Ergänzendes zum Thema
 
Die wichtigsten Neuerungen in Kubernetes 1.6

Neue Plattformen, neue Projekte

Doch nicht nur die wachsende Anzahl von Unterstützern – und Kunden – ist ein Indiz für die wachsende Bedeutung, sondern auch die Integration weiterer Plattformen und neuer Projekte. Bereits im Juli 2014 ging Google mit Microsoft eine Partnerschaft ein, so dass Kubernetes in „Azure“ funktioniert. Seit Juli 2015 besteht eine Partnerschaft zu Mesosphere; Kubernetes funktioniert also auch mit dem „Datacenter Operating System“ (DCOS) des Herstellers, ebenso wie im Zusammenspiel mit dem Apache „Mesos Cluster Manager“ der Apache-Foundation, so dass Docker-Container unter DCOS laufen.

2016 wurde erneut der Versuch angestoßen, OpenStack als Container auf Kubernetes laufen zu lassen. Dafür wird das OpenStack-Management-Produkt „Fuel“ überarbeitet. Erste Integrationsansätze aber gab es bereits mit dem OpenStack-Projekt „Magnum“ und „Heat“.

Den größten Widerstand gegen den Einsatz von Kubernetes bot Amazon Web Services mit dem eigenen Tool „EC2 Container Service“. Doch lässt sich Kubernetes mittlerweile auch dort anwenden, unter anderem wegen guter Dokumentationen. Insgesamt gelten die Dokumentationen und Best Practices der CNCF als vorbildlich sowie die Veröffentlichung von Release-Ständen.

In der Nacht vor der offiziellen Eröffnung der CloudNativeCon kam das jüngste Release von Kubernetes heraus (siehe: Kasten), Version 1.6. Und CNCF-Geschäftsführer Dan Kohn freute sich sichtlich, erzählen zu können, dass erstmals nicht Google federführend gewesen sei. Caleb Miles von CoreOS habe das Release-Projekt geleitet. Zwar trage Google mehr denn je zu Kubernetes bei, doch insgesamt weniger als 50 Prozent, so Kohn.

Aparna Sinha leitet das Produkt-Management-Team Kubernetes bei Google.
Aparna Sinha leitet das Produkt-Management-Team Kubernetes bei Google. (Bild: Cloud Native Computing Foundation)

Wahlfreiheit: rkt wird CNCF-Projekt

Außerdem gehörte es auf der Berliner Veranstaltung zu Kohns ersten Ausführungen, dass das für die Aufnahme neuer Projekte zuständige Technical Oversight Committee der Integration zweier weiterer Projekte zugestimmt habe: „rkt“ von CoreOS und „containerd“ vom Konkurrenten Docker sind zukünftig ebenfalls Teil der CNCF. Die Anwender können zwischen verschiedenen Laufzeit-Engines wählen. Zudem erhöht sich die Zahl der CNCF-Projekte mitsamt „fluentd“, „linkerd“ und „Prometheus“ auf neun.

Tigera und Nuage Networks

Interessant ist zudem, dass sich mehr und mehr Start-ups, aber auch etablierte Companies um die Netzwerk-Features, SDN, und Security kümmern, die für die Multi-Cloud-Microservices-Container-Welt essentiell sind.

Das Start-up Tigera beispielsweise kombiniert die Open-Source-Projekte „Flannel“ von CoreOS und „Calico“ von Metawitch, um im Nirwana von Containernetzen Infrastrukturen aufzuspüren und sichtbar zu machen (siehe auch: „SDxCentral report: Inside the Linux Container Ecosystem“). Während das Projekt Calico einen kompletten Layer 3 Stack bietet, bietet Flannel eine „Fabric“ mit Network Policy Management, die wiederum auf der Kubernetes-Basistechnik „etcd“ basiert, einem Information Storage Daemon für verteilte Systeme.

Nuage Networks heingegen hat ganz andere Wurzeln. Hier findet sich die ursprünglich von Nokia entwickelte Netzwerktechnik als Software Defined Network wieder. Insbesondere mit dem im vergangenen Herbst angekündigten Produkt „eXperience“ beziehungsweise „NuageX“ will Nuage Networks einer den kontunierlichen Änderungen in der Microsorvices-Welt genügen. Innerhalb von Sekunden können DevOps-Teams Instanzen in der eigenen Cloud -Umgebung Nuage Networks Virtualized Services Platform (VSP), erzeugen und bereitstellen.

Cisco Contiv und Huawei

Die Startups konkurrieren insbesondere gegen „Cisco Contiv“, ein Open-Source-Container Netzwerk- und (Security-)Policy-Framework für Docker-Container. Adressiert werden sowohl Bare-Metal-Server als auch virtuelle Maschinen, private und public Clouds. Contiv bietet unterschiedliche Modi: Layer2, Layer3, Overlay und ACI und integriert sich in weitere Cisco-Infrastrukturen. „Contiv Volume“ ist ein Docker-Plug-in, das die Open-Source-Software „Ceph“ nutzt, um persistenten, verteilten Speicher bereitzustellen.

Mithilfe von Contiv lassen sich Richtlinien für die Zusammensetzung der Microservices festlegen und angleichen, um für Konsistenz und Sicherheit in ein- und ausgehenden Datenverkehr zu regeln. Dabei übernimmt die Cisco-Technik sowohl die Integration von Layer-4-7-Dienstleistungen wie Load Balancing, Firewalls und Verschlüsselung als auch die Regelung der physischen Infrastruktur wie Bandbreiten und Performance-Anforderungen und SLAs. Darüber hinaus werden auch Storage-Aufgaben erledigt, etwa Speicherallokation und Snapshots. Damit ist klar, dass sich mit Contiv nicht nur containerisierte Anwendungen administrieren lassen.

Dr. Ying Xiong, Chef Architekt der Cloud-Platfform von Huawei Technologies, auf der CloudNativeCon, Berlin.
Dr. Ying Xiong, Chef Architekt der Cloud-Platfform von Huawei Technologies, auf der CloudNativeCon, Berlin. (Bild: Ulrike Ostler)

Einen ähnlichen Anspruch erhebt Huawei. Auf der Berliner Veranstaltung führte Dr. Ying Xiong, Chef Architekt der Cloud-Platfform von Huawei Technologies „Fusion Stage“ vor. Huawei ist von Anfang an bei der CNCF und Platinum-Mitglied. Mit Fusion Stage, auf Open-Source-technik wie Docker und Kubernetes basierend, adressiert das Unternehmen sowohl containerisierte Umgebungen und als auch Umgebungen herkömmlicher Art. Bestandteil ist etwa „iCAN“ eine Management-Plattform für Container-Netze.

Durch das Bereitstellen von standardisierten Komponenten (SNC) für Container, lassen sich vereinfacht nutzerdefinierte Datenströme definieren. iCAN lässt sich mit anderen Container-Orchestrierungswerkzeugen kombinieren, etwa „k8s“ und unterstützt die Standards „CNI“ und „CNM“.

Best Practices

Auf der CNCF-Veranstaltung in Berlin hielt Xiong einen Vortrag zu den Best Practices, die sowohl an die Technologie- als auch an die Anwenderfirmen gerichtet waren. Der interessante Hintergrund: Huawei bietet nicht nur Container-Services an, sondern modifiziert seit 2015 auch selbst seine gesamte interne IT: etwa 800 Anwendungen in acht Rechenzentren und 1 Million VMs sowie 170.000 Anwendern.

Zugleich machte Xiong deutlich, dass Container und Open Source kein Selbstzweck darstellen: So will Huawei mit seiner IT soweit es geht in public clouds, es soll sich durch die Einführung von Containern die Anzahl der VM deutlich reduzieren, bei Huawei etwa 100 zu 20; denn im Schnitt lasse sich eine virtuelle Maschine drei Mal verwenden. Zudem sei das Deployment enorm beschleunigt, was zuvor Wochen gedauert habe, nehme jetzt Minuten in Anspruch.

Best Practices

  • Beginnen Sie das Containerisieren mit der „richtigen“ Anwendung; da sich Container insbesondere für Anwendungen eignen, die in einem hohen Maße „verteilt“ sind, kämen am ehesten Cloud-Anwendungen in Frage, häufig solche, die „neuartig“ sind und keine hohe Integration in bestehende Anwendung verlangten.
    Hände weg von „Standardanwendungen“ beziehungsweise Softwarepaketen, etwa ERP oder PLM-Anwendungen. „Diese umzumodeln“, so Xiong, „ist Aufgabe der Software-Anbieter.“
  • Es braucht eine Strategie, um die Container zur Laufzeit zu managen. Offenbar vergessen das viele.
  • Auch das globale Deployment und das Routing benötigt eine Strategie, am besten für das Management mehrerer Clouds.
  • Das Netzwerk wird offenbar gerne einmal vergessen. Auch dafür müssen Regeln und Strategien her, etwa um die Netzwerkarchitektur festzulegen und die Performance zu definieren.
  • Unternehmen benötigen eine einzige Plattform, um Container-Workloads und nicht durch Microservices geprägte Umgebungen zu verwalten – an der Stelle dürfte Xiong auf Widerspruch stoßen.

Verwirrungen oder Vielfalt

Überhaupt bedeutet das CNCF-Dach keinesfalls, dass alle Rivalitäten beseitigt sind. Offiziell adressieren Mesosphere, Huawei, Weaveworks und Cloud Foundry beispielsweise eine höhere Ebene, verstecken Entwicklungs- und Administrationsarbeiten hinter einen Komplett-Stack. Abby Kearns, VP Industry Strategy der Cloud Foundry Foundation, sagt: „Wir sind das Betriebssystem für das Rechenzentrum,“ und Anwender bestätigen: „Mit Cloud Foundry bekomme ich meine Instanzen in Sekunden und erspare mir jegliche Frickelei.“

Auch die etwa zur CloudNativeCon gestartete Zertifizierungsinitiative für Entwickler kommt bei den Anwenderunternehmen gut an, bekämpft diese doch den derzeitigen eklatanten Mangel an Fachkräften. Auch der geprüfte Stack ist für Anwender ein Pluspunkt: „Wir können nicht einfach einmal etwas verwenden, nur weil es bei Github zum Download bereitsteht“, lautet der Tenor.

CNCF-Geschäftsführer Dan Kohn eröffnet die CloudNativeCon 2017 in Berlin.
CNCF-Geschäftsführer Dan Kohn eröffnet die CloudNativeCon 2017 in Berlin. (Bild: Cloud Native Computing Foundation)

Doch während Kearns, Kohn und Richardson immer wieder betonen, dass man sich gegenseitig nicht weh tue und ohnehin in der Open Container Initiative (OCI) zusammenarbeitet, unterscheiden viele Anwender diese Feinheiten nicht. „Es gibt keine Container-übergreifenden Plattformen, keine Interoperabiität von einer Cloud zur anderen.“

Kein Standard

Tatsächlich lässt Version 1.0 eines OCI-Standards auf sich warten. Richardson betont gar: „CNCF bedeutet: „Projects first”. Allerdings räumt er ein: „Interoperabilität hilft Anwendern und eine Wahl zu haben, ist immer gut (rkt, containerd).“

Während Kritiker aus den Anwenderreihen OCI als Makulatur und „nur gut für das Image der Firmen sehen, die sich hier zusammengefunden haben“, relativiert Richardson: „Manches hilft, anderes eben nicht“. Während Kritiker eine Inflation von „Foundations“ sehen – Wem soll man folgen? – beruhigt Kohn: „Immerhin sind die wichtigsten der Foundations unter dem Dach von The Linux Foundation, der Foundation schlechthin.“

Kommentare werden geladen....

Kommentar zu diesem Artikel

Anonym mitdiskutieren oder einloggen Anmelden

Avatar
  1. Avatar
    Avatar
    Bearbeitet von am
    Bearbeitet von am
    1. Avatar
      Avatar
      Bearbeitet von am
      Bearbeitet von am

Kommentare werden geladen....

Kommentar melden

Melden Sie diesen Kommentar, wenn dieser nicht den Richtlinien entspricht.

Kommentar Freigeben

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

Freigabe entfernen

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 44616391 / Microservices)