Open Source im professionellen Einsatz

Cloud Native Con + Kubecon Europe 2017: Wo Kubernetes Sinn ergibt

30.03.2017

Den Namen ihrer Konferenz wollen die Macher der Cloud Native Con + Kubecon Europe 2017 auf Vorschlag des Linux-Magazin nicht ändern, der Besucherzahl aber beim nächsten Mal mit einer größeren Location Herr werden. Schuld sei auch der Erfolg von Kubernetes.

921

Mit so vielen Besuchern hatten die Macher der Cloud Native Con + Kubecon Europe 2017 offenbar nicht gerechnet: das BCC in Berlin platzt dank der 1500 Gäste aus allen Nähten, auch viele Vortragsräume waren überfüllt. Chris Aniszczyk von der Linux Foundation und die PR-Managerin Natasha Woods gelobten Besserung, offenbar habe man das Besucherwachstum unterschätzt. Die Planungen einer Konferenz beginnen meist recht früh, zur Vorgängerkonferenz der CNCF in einem Hotel in Seattle kam noch eine überschaubare Menge an Menschen.

Kubernetes blieb auch am zweiten Tag das treibende Moment in den Vorträgen auf der Konferenz, das Interesse der Unternehmen daran scheint zu wachsen. Auch große Unternehmen setzen Kubernetes ein, häufig allerdings erst einmal intern und in Experimenten. Daneben drehen sich Vorträge aber auch um das dazugehörige Ökosystem, zu dem unter anderem das verteilte Monitoring mit Prometheus, der Daemon Containerd und das RPC-Framework gRPC gehören.

Brandon Philips, CTO von Core OS, erstaunte auf der Veranstaltung am meisten, wie viele unabhängige Applikationen in jüngster Zeit rund um Kubernetes entstanden sind. Vor nicht allzu langer Zeit habe man viele Komponenten noch selbst programmieren müssen, berichtet Philips, inzwischen sprießen Anwendungen aus dem Boden, die sich um alle möglichen Bereiche kümmern. Core OS selbst arbeitet an Kubernetes mit und trug im aktuellen Release wesentlich zur Role Based Access Control bei. Auch die Arbeit an der Docker-Alternative Rkt geht weiter. Hier wollen die Projektmacher vor allem neue Mitarbeiter gewinnen und Rkt 100 Prozent kompatibel mit Kubernetes machen.

Image-Probleme

Ein Problem mit Image Registries wie dem Docker Hub oder Quay (dem Pendant von Core OS) sind die Sicherheitslücken, die sich in den Images schnell sammeln, wenn die Image-Erzeuger keine regelmäßigen Updates liefern, was sie häufig noch nicht tun. So weisen beispielsweise auch viele offizielle Images von Projekten oder Unternehmen im Docker-Hub Sicherheitslücken auf, wie ein Artikel im aktuellen Linux-Magazin zeigt.

Das Problem ist nicht nur bei Docker bekannt, das für Docker-Hub-Nutzer einen Scanner für Sicherheitslücken anbietet. Auch bei Core OS macht man sich Gedanken zum Thema. Laut Philips hat das Problem zwei Seiten: Einerseits geht es darum, die Sicherheitslücken in den Images zu finden, andererseits muss jemand den Admins mitteilen, dass die Image unsicher sind und er sie neu bauen sollte.

Mit Clair bietet Core OS einen eigenen Imagescanner an, der verschiedene CVE-Datenbanken von Distributionen anzapft und die gescannten Images mit deren Sicherheitslückensammlung abgleicht. Eine Integration in Kubernetes sei angedacht, könne aber noch etwas dauern. Zudem arbeite man an einem Channel-Konzept für Quay: Künftig könnten in einem Stable Channel Images erlauben.

Auch Clayton Coleman, Open-Shift-Architekt bei Red Hat, sieht das unsichere Container-Images als ein Problem. Man wisse nicht wirklich, wie gut die einzelnen Images betreut werden, auch, wenn sie offiziell von Upstream stammen. Container zu scannen sei daher eine Art, mit dem Problem umzugehen, auf jeden Fall sollten sich die Nutzer der Problematik bewusst sein. Red Hat deaktiviere daher für einige Kunden den Zugriff auf die offiziellen Image-Repositories und baue eigene Images für Open Shift, die bestimmte Sicherheitschecks durchlaufen.

Bauen statt updaten

Updates erhalten die Container-Images dabei nicht mehr auf traditionelle Weise über den Paketmanager, was Nachteile, aber auch Vorteile hat. Sicherlich sei der Aufwand, bei Sicherheitslücken und Fixes immer neue Images herunterzuladen, höher, als bei einfachen Paketaktualisierungen. Allerdings betonte Coleman auch die Vorteile. So seien einfachere Rollbacks möglich, während Downgrades in VMs seiner Erfahrung nach nicht immer zuverlässig funktionieren. Konfigurationen, an denen die meisten Änderungen stattfinden, lassen sich zudem zentralisieren und die gesamte Infrastruktur so besser in Schuss halten, etwa mit automatisierten Builds.

In eine ähnliche Kerbe haute auch Lutz Lange, Solutions Architekt bei Red Hat. Die Independet Software Vendor (ISV) müssten lernen, ihre Images aktuell zu halten. Laufen viele verschiedene Workloads in Containern, seien Upgrades sicherlich aufwändiger, weil viele Layer aktualisiert werden müssten. Häufig handele es sich aber um eher homogene Anwendungen. Der Mehraufwand an Rechenzeit lohne sich zudem vor allem bei breit skalierten Anwendungen und wenn Unternehmen recht umfangreiche Aufgaben in Container verlagern.

Nicht alle Legacy-Anwendungen würden aber in der Cloud problemlos laufen. Relationale Datenbanken eignen sich beispielsweise wesentlich schlechter für eine Containerisierung als No-SQL-Datenbanken. Bei manchen komplexeren Applikationen würde er Firmen daher eher empfehlen, die Finger von einer Containerisierung zu lassen, da auch ein Scheitern möglich sei. Insgesamt sei man aber bei dem Vorhaben, auch nicht-flüchtige Daten in Container zu verpacken, bereits ein paar Schritte weiter gekommen.

Überkomplex

Zwei der morgendlichen Keynote-Redner erinnerten zudem daran, dass Lösungen wie Kubernetes nicht in allen Unternehmenskontexten Sinn ergeben und ein Erfolg der Plattform nicht selbstverständlich ist. Wer nur zwei Instanzen betreibe, brauche im Prinzip kein Kubernetes, erklärte Kelsey Hightower, der an Googles Cloud Platform arbeitet. Er zeigte in einer Demo, in welchen Kontexten eine Federation von Anwendungen Sinn ergibt.

Joe Beda von Heptio warnte hingegen davor, Kubernetes mit immer neuen Features zu überladen. Kubernetes sei vor allem "system software for system engineers", man müsse jedoch auch der Perspektive der Cluster-User Rechnung tragen. Jedes neue Konzept, das in Kubernetes Einzug finde, erhöhe auch dessen Komplexität und schrecke neue User ab. Die Plattform müsse sich im Idealfall auch für Admins eignen, die vor allem ihre Anwendungen im Auge haben und keine Systemnerds sind. Es dürfe nicht in jedem Fall nötig sein, alle darunterliegenden Technologien bis ins Detail verstehen zu müssen, um Kubernetes zu benutzen.

Ähnliche Artikel

  • Cloud-Native-Konferenz

    Neben einer Rekordzahl von Keynotes und Besuchern stand bei der Cloud Native Con und Kubecon Europe 2017 unter anderem die Containerverwaltung Kubernetes im Mittelpunkt. Deren Macher kündigten auf der gut besuchten Veranstaltung in der Nähe des Berliner Alexanderplatzes die neue Version 1.6 an.

  • Cloud Native Con + Kubecon Europe 2017: Alles im Pod

    Gleich acht Keynotes servierte die heute am Berliner Alexanderplatz gestartete Cloud Native Con + Kubecon Europe ihren 1500 Besuchern. Im Mittelpunkt stand aber die Containerverwaltung Kubernetes, deren Macher die neue Version 1.6 ankündigten.

  • Azure unterstützt nun Kubernetes und verwaltet Docker-Images

    Für seine Cloudstrategie setzt Microsoft notgedrungen auf Open-Source-Technologie. Nun können Azure-Nutzer Kubernetes verwenden, um Docker-Container zu verwalten, der Konzern hat gar ein visuelles Tool unter Apache-2.0-Lizenz entwickelt.

  • Kubernetes-Monitoring

    In Cloud-Native-Umgebungen stoßen klassische Monitoring-Tools an ihre Grenzen, wenn sie kurzlebige Objekte wie Container überwachen. Diese Lücke schließt Prometheus, das Kubernetes dank der konzeptionellen Ähnlichkeit, des einfachen Aufbaus und einer weitreichenden Automatisierung passgenau ergänzt.

  • Kubernetes

    Google betreibt die meisten Server und beschäftigt sich mit dem Thema Containervirtualisierung. Es stellt in Form von Kubernetes eine Spezialdistribution vor, um Sysadmins das Leben mit Docker zu erleichtern.

comments powered by Disqus

Stellenmarkt

Artikelserien und interessante Workshops aus dem Magazin können Sie hier als Bundle erwerben.