Bericht von der KubeCon/CloudNativeCon in Berlin Micro-Services, Kubernetes, Docker, CoreOS und mehr

„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.

Anbieter zum Thema

Dell GmbH

Vogel IT-Medien GmbH

Schwarz IT KG

Google Germany GmbH

Huawei Technologies Deutschland GmbH

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.“

Bildergalerie

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.

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.

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.

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.

Bildergalerie

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 Micro-Services 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.

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 Micro-Services 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.

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.“

Ergänzendes zum Thema

Die wichtigsten Neuerungen in Kubernetes 1.6

Im CNCF-Blogwird die Version 1.6 als „Stabilisierungs-Release“ bezeichnet. Also ist weniger Wert auf neue Funktionen gelegt worden, denn auf Speed, Wahlfreiheit und Vertrauen, wie Alexis Richardson aus dem CNCF-Board betont. Letzteres fußt auf Stabilität und ist Voraussetzung dafür, dass Kubernetes die Installationsplattform für verteilte Systeme sein kann.

Mehr Sicherheit

Was die wichtigste Neuerung ist, darüber sind sich nicht alle einig. Für den CNCF-Geschäftsführer Dan Kohn ist es die Betaversion von „RBAC“. Das Akronym steht für „Role Bases Access Control“. Es geht also um eine flexiblere und dynamischere Zuweisung von Rechten. Laut Kohn erhöht das die Microservices-immanente Sicherheit enorm.

Aparna Sinha leitet das Produkt-Management-Team Kubernetes bei Google.

Auf der Veranstaltung übernahm Aparna Sinha, die bei Google leitende Produkt-Managerin für Kubernetes ist, die Demonstration der Funktion. Demnach lassen sich nun Pod-übergreifend verschiedene Administratorgruppen definieren und diesen unterschiedliche Rechte zuweisen, beispielsweise die Erlaubnis zum Ändern, zum Einsichtnehmen aber nicht Ändern oder gruppenübergreifende Befugnisse. Darüber hinaus sind default-Einstellungen für bestimmte Rollen definiert.

Mehr Knoten

Pods sind im Kubernetes-Sprachgebrauch Container, die zu einer Gruppe, dem Pod, zusammengefasst wurden. Diese wiederum lassen sich einzelnen Rechnerknoten zuweisen. Kubernetes unterstützt inzwischen die Nutzung von 5.000 Pods, was etwa 150.000 Containern entspricht. Diese Instanzen lassen sich per Federation zu noch größeren Clustern verbinden.

Unter anderem ist die Funktion „etcdv3” dafür verantwortlich. Dieser Controller ist nun per default in Kubernetes eingestellt. Das bedeute, so die Foundation, dass sich die Zahl der Nodes, die durch Kubernetes beherrschbar sind, dramatisch erhöht habe.

Kelsey Hightower, Staff Developer Advocate bei Google, erläutert, wie Kubernetes Federation funktioniert.

Wie Cluster Federation mit Version 1.6 gehandhabt werden soll, machte Kelsey Hightower, Staff Developer Advocate bei Google, deutlich. Keep ist simple, heißt in diesem Fall: eine flache Hierarchie und kein „Aufeinanderstapeln“ von API-Servern mitsamt Control-Plane. Nunmehr spannen sich Applikationen direkt über mehrere Cluster hinweg.

Automatische Storage-Provisionierung

Ganz wesentlich für die Produktivität aber ist auch die automatisierte Provisionierung von Storage. Zuvor war dieses lediglich für nicht-persistenten Speicher möglich. Wollte man über Kubenetes mit persistenten „Volume Claims“ arbeiten, mussten Cloud Provider manuell Storage-Klassen erstellen. Jetzt, im Release 1.6, kann Kubenetes das automatisiert, sobald Storage erforderlich ist.

Sinha zeigte, wie sich Speicher zunächst manuell und dann dynamisch über Yaml-Dateien zuweisen lässt. Dafür reicht aus, wenn der Admin die benötigte Menge an Speicher angibt.

Dediziert und schneller

Mithilfe der Funktion „Controlled Scheduling“ lässt sich definieren, welche Pods mit welchen Nodes kooperieren sollen, laut Sinha ein bedeutsames Feature für Multi-Cluster. Auf diese Weise lasse sich festlegen, dass bestimmte Pods nur auf SSDs laufen oder dass ausgewählte Nodes ausschließlich die für sie bestimmte Workloads abarbeiten. Den Code dafür lieferten Red Hat, IBM, Huawai und Google.

Wahlfreiheit: Docker oder CoreOS?

Zu den zugleich spektakulärsten und doch erwarteten neuen Funktionen gehört, dass Anwender nun nicht mehr ausschließlich auf Docker als Container-Runtime angewiesen sind. In Frage kommen nun auch „rkt” und “CRI-O”.

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.“

Übergang zu Cloud-nativen Systemen noch 2017

Wie geht „cloud native“?

(ID:44617540)