zurück zum Artikel

Cloud Native News #2: Konferenzeindrücke

Know-how
Cloud Native News #2: Konferenzeindrücke

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.

Die Cloud Native News #2 stehen im Zeichen der CloudNativeCon/KubeCon North America 2017, die vom 6. bis 8. Dezember stattfand, und der Impulse, die die Konferenz für 2018 brachte. In wenigen Worten zusammengefasst:

Kubernetes explodiert (und wird erwachsen)

Fast jede Statistik zum Thema Kubernetes zeigt eine exponenzielle Steigerung: die Anzahl der Teilnehmer der KubeCon/CloudNativeCon, die Anzahl der Commits, die Anzahl der Contributors, die Anzahl der Firmen, die Kubernetes einsetzen, und die Größe des Ökosystems um Kubernetes herum.

Dabei wird Kubernetes aber auch erwachsen. Das zeigt sich insbesondere in zwei Aspekten:

  1. Aufmerksamkeit bei den Großen und
  2. Standardisierung.

Aufmerksamkeit der Großen

Jeder große Cloud-Provider ist dabei, ein eigenes Kubernetes-as-a-Service Angebot nach dem Vorbild der Google Kubernetes Engine anzubieten und ihren Nutzern so den Einsatz von Container-Techniken und Kubernetes zu erleichtern.

Nach Oracle (Oracle Container Engine) und Microsoft (Azure Container Service) folgte zuletzt AWS mit der Ankündigung von AWS EKS (Elastic Container Service for Kubernetes), der ab Sommer 2018 offiziell verfügbar sein soll. Es ist davon auszugehen, dass die breite Verfügbarkeit von Container-Engines den Einsatz von Container-Techniken weiter beschleunigen wird. Spannend wird in diesem Zusammenhang insbesondere sein, wie sich kleinere Cloud-Anbieter beim Thema Container-Technologien und Kubernetes aufstellen, um sich gegenüber den großen Providern zu behaupten.

Außerdem ist es interessant zu beobachten, wie sich der Markt für Pay-per-Container entwickelt. Mit AWS Fargate oder Azure Container Instances sind erste Angebote als Preview verfügbar. Fraglich ist vor allem, ob und wie sich die einzelnen Provider auf einen Standard einigen können. Eine erste Initiative gibt es schon mit virtual kubelet [2] und der Integration in Kubernetes.

Standardisierung

Kubernetes per se wird mehr und mehr zum Standard bei der Container-Orchestrierung. Aber auch innerhalb von Kubernetes wird eifrig standardisiert. Im Fokus sind dabei insbesondere die Schnittstellen zwischen Kubernetes und den von Kubernetes orchestrierten Ressourcen. Hier gibt es mit CRI eine Standard-Schnittstelle für Containerizer, die flexibel zwischen Docker, rkt oder CRI-O wählen lassen. Ferner ist mit CNI die Schnittstelle für Netzwerkprovider standardisiert und mit CSI ein entsprechender Standard für Storage-Provider in der Mache.

Kubernetes für Entwickler

Das allgegenwärtige Motto auf der CloudNativeCon für die weitere Entwicklung von Kubernetes war, die Developer Experience zu verbessern. Kubernetes ist als Betriebswerkzeug entstanden, das aber Entwickler von jeher direkt nutzen. Es gibt bereits spannende Ansätze, um den Umgang für Entwickler zu verbessern:

Paketmanager

Linux-Nutzer sind seit Langem komfortable Paketmanager wie APT gewöhnt. Helm [3] wird mehr und mehr zum Standardpaketmanager für Kubernetes. Er hilft dabei, Anwendungen so zu verpacken, dass Entwickler sie einfach und reproduzierbar installieren und damit vorgefertigte Infrastrukturbausteine beziehen können.

Lokale Entwicklung

Cloud Native News

  1. Rise of the Kubernaut [4]
  2. Konferenzeindrücke
  3. Endlich Produktion [5]
  4. Volle Breitseite [6]
  5. Es menschelt im Cloud-Native-Universum [7]

Um die Turnaround-Zyklen gering zu halten, ist es oft praktisch, lokal auf dem Rechner Container in einem Kubernetes-Cluster vorab testen zu können. Ein Vortrag von Red Hat [8] stellt diverse Werkzeuge und Kniffe rund um minikube vor, die das auf einfache Art ermöglichen. Mit Squash [9] steht ein aktuell noch rudimentäres Werkzeug zur Verfügung, das ein Debugging einer verteilten Anwendung aus der lokalen IDE heraus ermöglicht.

SQL-Datenbanken auf Kubernetes

Endlich hält der Zustand Einzug bei Kubernetes. So wurden produktionsreife Ansätze vorgestellt, wie Entwickler sowohl PostgreSQL [10] als auch MySQL [11] in einem HA-Setting auf Kubernetes zum Laufen bringen. Im Kern dieser Umsetzungen stehen sogenannte Operatoren: kleine Programme, die bei bestimmten Kubernetes-Ereignissen aktiv werden und Datenbankinstanzen miteinander bekannt machen oder ein Failover auslösen können.

Serverless

Mit zunehmender Reife und einem größerem Funktionsumfang von Cluster-Orchestratoren wie Kubernetes wächst die Komplexität von Anwendungen, die gegen den Cluster-Orchestrator als PaaS-Schnittstelle gebaut sind. Damit gewinnt die Abstraktion der Abstraktion an Bedeutung: Hinter Serverless oder auch Function-as-a-Service (FaaS) steckt die Idee, kleine, zustandslose Funktionen direkt auszuführen, ohne sich um Infrastruktur, Container oder Orchestrierung kümmern zu müssen. Diese Funktionen spielen in einer Cloud-Native-Architektur gerade als Integrationsschicht zwischen Clients und den Microservices eine wichtige Rolle.

Wer nicht die etablierten Serverless-Produkte großer Cloud-Provider nutzen und sich damit an einen Hersteller binden will, findet im Kubernetes-Universum drei interessante Projekte: OpenFaaS [12], Fission [13] und Kubeless [14], die sich in ihrem Reifegrad, den unterstützten Programmiersprachen und in der Art der Kubernetes-Integration unterscheiden.

Cloud-Native-Security

Es tut sich gerade viel im Bereich Cloud-Native-Security, also Sicherheitstechniken, die speziell für den Einsatz auf Cloud-Native-Plattformen wie Kubernetes ausgelegt sind. Das verwundert nicht, denn der Bedarf ist groß, da viele IT-getriebene Unternehmen bei der Sicherheit noch die größten Zweifel auf ihrem Weg in die Cloud haben.

Identität ist die Grundvoraussetzung für die wichtigen IT-Security-Säulen Authentifizierung und Autorisierung. Das Identifizieren von Benutzer übernehmen Systeme wie OpenID Connect zuverlässig. Offen bleibt jedoch die Frage, wie Software mit der Identität bei einer Maschine-zu-Maschine-Kommunikation in einem Microservices-System umgeht. Notwendig ist ein Konzept für die Identität der kommunizierenden Workloads. Das Secure Production Identity Framework for Everyone (SPIFFE [15]) bietet einen Standard, der Workload-Identität interoperabel umsetzt. SPIFFE besteht aus einem Standard für Identitäten (SPIFFE ID), einem Standard, um diese Identitäten als kryptographische Dokumente auszudrücken (SPIFFE Verifiable Identity Document, SVID) und einer API, um SVIDs auszustellen und zu verteilen. Dazu gibt es mit SPIRE [16] eine Referenzimplementierung.

In größeren Umgebungen stellt sich die Frage, wie sich Zugriffsbeschränkungen auf Cluster-Ressourcen umsetzen lassen. Kubernetes bietet dafür seit Version 1.8 Role-Based Access Control [17], womit Administratoren auf der Ebene Orchestrator effektiv Berechtigungskonzepte umsetzen können.

Für allgemeinere Problemstellungen gibt es OPA, den Open Policy Agent (OPA [18]) als Baustein für Rule-Based Access Control. OPA ermöglicht es, beliebig einfache oder komplexe Policies umzusetzen und bietet eine einfache domänenspezifische Sprache (Domain-Specific Language, DSL) für Policies sowie einen Dienst, um Policies automatisch auszuwerten.

Produkte für Container-Sicherheit sind die Virenscanner für die Cloud. Sie helfen, das Schutzniveau zu erhöhen und bieten in verschiedenen Kombinationen und Ausbaustufen die Überprüfung von Containern auf Sicherheitslücken, Laufzeitschutz, die Überprüfung und Durchsetzung von Compliance-Regeln sowie Zugriffskontrolle und Transparenz über die Netzwerkkommunikation. Nennenswerte Produkte sind Twistlock [19], Aquasec [20] und der Newcomer Alcide [21]. Eine Übersicht, wie man auch mit Kubernetes-Bordmitteln einen gewissen Grundschutz erzielt, zeigen die Folien einer weiteren KubeCon-Präsentation [22].

Ebenfalls zu beobachten ist, dass Vault immer mehr zum Standard für die Verwaltung und die Bereitstellung von Secrets wird. Es gibt zwar diverse Alternativen wie Keywhiz, die aber weitestgehend unbekannt und weit weniger gut in das Cloud-Native-Ökosystem integriert sind.

Service Meshes

Ein Service Mesh ist eine Infrastrukturschicht, die die Service-zu-Service-Kommunikation übernimmt. Service Meshes greifen im Gegensatz zu klassischen Software-Defined Networks wie der Kombination aus Flannel [23] und Calico [24] nicht in die Transportschicht ein. Das Mesh läuft zwischen Transportschicht und Applikation.

Ein Service Mesh besteht aus Proxies, die als Botschafter für die Applikationen dienen und einer Kontrollschicht, die die Proxies steuert. Die Kommunikation zwischen Anwendung und Proxy bleibt lokal, und die Kommunikation zwischen den Proxies ist automatisch abgesichert. Damit lassen sich Querschnittsaspekte wie Identität, Authentifizierung und Autorisierung von Workloads, Resilienz, Traffic-Management und Observability elegant und transparent umsetzen.

Istio [25] ist der aufstrebende Star unter den Service Meshes. Es nutzt Envoy [26] als Proxy und sichert Verbindungen SPIFFE-konform mit mTLS. Istio steht am Anfang. In der aktuellen Version 0.3.0 ist noch kein Feature stabil, und die meisten sind als Alpha gekennzeichnet [27]. Da Lyft, Google und IBM das Projekt treiben, besteht jedoch kein Zweifel, dass Istio schnell reifen wird. Wer schon jetzt mit Istio spielen will, dem sei das zugehörige Google Codelab [28] empfohlen.

Aktuell unterstützt Istio lediglich Kubernetes; der Support für Cloud Foundry und Mesos ist geplant. Für die nahe Zukunft steht außerdem die Integration von Services außerhalb des Mesh an.

Neben Istio lohnt es sich, Conduit [29] im Blick zu behalten. Dabei handelt es sich um ein neues, experimentelles Service Mesh von den Machern von Linkerd mit einem besonders schlanken, in Rust geschriebenen Proxy.

Die CNCF-Projekte werden erwachsen

Neben vier neuen 1.0-Versionen gibt es auch bei Prometheus und Kubernetes wesentliche Neuerungen:

Fazit

Die CloudNativeCon/KubeCon hat gezeigt, dass Kubernetes sich inzwischen als Standard für Orchestrierung durchgesetzt hat. Mit Security und Service Meshes stehen jetzt Themen auf der Agenda, die für große und komplexe Installationen wichtig sind. Die Versionsnummern 1.0 und größer der CNCF-Projekte sind ein deutliches Statement, dass die Technik jetzt auch für Anwender reif ist, die sich nicht an der Bleeding Edge schneiden möchten. (rme [38])

Andreas Zitzelsberger
ist Principal Software Architect bei QAware. Sein aktueller Schwerpunkt ist das Thema Cloud in all seinen Aspekten. Daneben baut er Big-Data-Architekturen oder verbessert die Welt mit Analysen und Stabilisierung komplexer Systeme.

Josef Adersberger
ist CTO und Mitgründer der QAware, einem Softwarehaus aus München mit rund 100 Mitarbeitern, das Cloud-Native-Applikationen entwickelt und bestehende Anwendungen auf Cloud-Native-Plattformen migriert. Er hält seit 2011 Vorlesungen zum Thema Cloud (Native) Computing und ist CNCF-Mitglied.

Sebastian Scheele
ist Mitgründer und CEO von Loodse. Das Unternehmen aus Hamburg begleitet Kunden beim Einsatz von Container- und Cloud Native-Technologien und dem Aufbau von verteilten Architekturen. Zudem ist Loodse einer der ersten dreißig Kubernetes Certified Service Provider weltweit.


URL dieses Artikels:
http://www.heise.de/-3951004

Links in diesem Artikel:
[1] https://github.com/cncf/landscape/tree/1.0
[2] https://github.com/virtual-kubelet/virtual-kubelet
[3] https://github.com/kubernetes/helm
[4] https://www.heise.de/developer/artikel/Cloud-Native-News-1-Rise-of-the-Kubernaut-3904918.html
[5] https://www.heise.de/developer/artikel/Cloud-Native-News-3-Endlich-Produktion-4052428.html
[6] https://www.heise.de/developer/artikel/Cloud-Native-News-4-Volle-Breitseite-4204575.html
[7] https://www.heise.de/developer/artikel/Cloud-Native-News-5-Es-menschelt-im-Cloud-Native-Kosmos-4328403.html
[8] https://schd.ws/hosted_files/kccncna17/3f/Developing-Locally-with-Kubernetes-Kubecon-NA-2017.pdf
[9] https://schd.ws/hosted_files/kccncna17/ef/KUBECON2017E_Idit%20Levine.pdf
[10] https://www.youtube.com/watch?v=Zn1vd7sQ_bc&feature=youtu.be
[11] https://schd.ws/hosted_files/kccncna17/4d/MySQL%20on%20Kubernetes.pdf
[12] https://www.openfaas.com/
[13] http://fission.io/
[14] http://kubeless.io
[15] https://spiffe.io/
[16] https://github.com/spiffe/spire
[17] https://kubernetes.io/docs/admin/authorization/rbac/
[18] http://www.openpolicyagent.org/
[19] https://www.twistlock.com/
[20] https://www.aquasec.com/
[21] https://www.alcide.io/
[22] https://schd.ws/hosted_files/kccncna17/aa/Kubecon17_Castle_Cullen_Shipping_in_pirate-infested_waters.pdf
[23] https://github.com/coreos/flannel
[24] https://www.projectcalico.org
[25] https://istio.io/
[26] https://www.envoyproxy.io/
[27] https://istio.io/docs/welcome/feature-stages.html
[28] https://codelabs.developers.google.com/codelabs/cloud-hello-istio/index.html?index=..%2F..%2Findex#3
[29] https://github.com/runconduit/conduit
[30] https://coredns.io/2017/12/01/coredns-1.0.0-release/
[31] https://blog.docker.com/2017/12/cncf-containerd-1-0-ga-announcement/
[32] https://www.cncf.io/blog/2017/12/06/fluentd-v1-0/
[33] https://www.linuxfoundation.org/press-release/announcing-jaeger-1-0-release/
[34] https://prometheus.io/blog/2017/11/08/announcing-prometheus-2-0/
[35] http://chronix.io/
[36] http://blog.kubernetes.io/2017/12/kubernetes-19-workloads-expanded-ecosystem.html
[37] https://github.com/container-storage-interface/spec
[38] mailto:rme@ct.de