Nach der Definition von "The new Stack" bringt Cloud Native die folgenden 10 Schlüsselmerkmale mit:

• Verpackt als leichtgewichtige Container
• Entwickelt mit best-of-breed Programmiersprachen und Frameworks
• Entwickelt als lose gekoppelte Microservices
• Im Mittelpunkt stehen APIs für Interaktion und Zusammenarbeit.
• Entwickelt mit einer sauberen Trennung von zustandslosen und zustandsbehafteten Services.
• Isoliert von Abhängigkeiten zu Servern und Betriebssystemen
• Wird auf einer Self-Service-, elastischen und Cloud-Infrastruktur eingesetzt.
• Verwaltet durch agile DevOps-Prozesse
• Automatisierte Funktionen

Einige der Hauptvorteile von cloud-nativen Infrastrukturen sind:

• Skalierbarkeit 
• Flexibilität
• Agilität
• Elastizität
• Automatisierung

Dies unterscheidet sich deutlich von herkömmlichen Bare-Metal- oder VM-Infrastrukturen. Selbst wenn Sie Container wie Docker verwenden, erreichen Sie nicht automatisch die oben erwähnten Vorteile. Die Bereitstellung von Cloud-nativer Infrastruktur und Technologie per se ist eine Schlüsselanforderung für den Aufbau einer DevOps-Infrastruktur und -Kultur, dennoch ist zum Aufbau einer stabilen DevOps-Mentalität  meist ein grundsätzliches Umdenken im Unternehmen erforderlich.

Kubernetes hat den Containerkrieg gewonnen

Am Anfang bauten viele Cloud-Native-Containerplattformen ihre eigene Cloud-Native-Technologie und -Infrastruktur. Viele dieser Lösungen waren Open Source, aber nur eine übernahm die klare Führung. Werfen Sie einfach einen Blick auf die Google Trends der letzten fünf Jahre:

In der Zwischenzeit haben die meisten Cloud-basierten Infrastrukturanbieter (wie Red Hat OpenShift, Mesosphere, Pivotal Cloud Foundry) ihre gesamte Strategie auf die Unterstützung von Kubernetes ausgerichtet. Diese Anbieter verbessern das Benutzererlebnis und fügen zusätzliche Funktionen hinzu, um sich vom Vanilla Kubernetes zu unterscheiden. OpenShift hat diese Entscheidung schon vor einigen Jahren getroffen - früher als die meisten anderen; die oben genannten Trends spiegeln dies gut wider. Darüber hinaus ist Kubernetes mittlerweile auch als Managed Service auf allen großen Cloud-Anbieterplattformen (AWS, Azure, GCP) verfügbar.

Zustandsbehaftete Kubernetes Deployments mit dem Operator-Pattern 

Kubernetes wurde in den frühen Phasen hauptsächlich für zustandslose Implementierungen eingesetzt (z.B. zur Bereitstellung von REST-Microservices).

Heute deployen Unternehmen alles auf Kubernetes ein, weil es einen echten Mehrwert schafft - wie im Abschnitt über cloud-native Infrastruktur oben beschrieben. Dazu gehören auch das Kafka-Backend und die Clients.

Zustandsbehaftete Deployments von Backend-Services nutzen das Kubernetes Operator Pattern, wie beispielsweise für viele Infrastrukturkomponenten, wie Datenbanken, Messaging, Suchmaschinen, etc. Die Implementierung des Operator Pattern beinhaltet Standard-Kubernetes-Objekte wie StatefulSets, ConfigMaps, Secrets und Persistent Volumes. Der Clou an der Sache sind jedoch die benutzerdefinierten Kubernetes Controller and Custom Resource Definitions (CRDs), die die benötigte Anwendungsfunktionalität für die konkrete Infrastrukturkomponente (z.B. Apache Kafka) implementieren.

Herausforderungen beim Betrieb von Kafka auf Kubernetes

Apache Kafka wurde zum De-facto-Standard für Event-Streaming-Plattformen. Apache Kafka und sein Ökosystem bieten eine leistungsstarke Plattform, um skalierbare, geschäftskritische, verteilte und zuverlässige Systeme zu entwickeln. Daher ist es, wie Sie sich vorstellen können, schwieriger zu betreiben als ein herkömmliches Messaging-System oder eine Datenbank, die nicht elastisch skalierbar sind, nicht ohne Ausfallzeiten ein Versionsupgrade erlauben, und nur mittels unflexiblen aktiv/passiv Modus für hohe Verfügbarkeit sorgen können.

Kubernetes Umgebungen sind ähnlich: Sehr leistungsstark, aber nicht einfach zu bedienen. Daher macht es die Kombination aus beidem, Kafka und Kubernetes, nicht einfacher. Hier sind einige Herausforderungen, die das Apache Kafka Ökosystem auf Kubernetes betreffen:

• Übersetzung einer bestehenden Architektur in eine Kubernetes Umgebung
• Failover-Handling
• Rebalancing von Daten
• Kommunikation zwischen ZooKeeper, Kafka Brokern, Clients (Java, REST, Connect, KSQL), Schema Registry, etc.
• Externer Zugriff von / auf externe Kubernetes-Cluster
• Persistente Speicheroptionen vor Ort und in der Cloud
• Sicherheitskonfiguration
• Rolling Upgrades
• Etc.

Dieses Konglomerat muss ein Kubernetes-Operator umsetzen und automatisieren. Folglich klingt ein Kafka-Operator wie eine sehr sinnvolle und hilfreiche Komponente.