Confluent Germany GmbH

Das Ziel einer Cloud-nativen Infrastruktur ist es, sich auf das zu konzentrieren, WAS man will, und nicht darauf, WIE man es bekommt, und das möglichst automatisiert, elastisch und flexibel. Glücklicherweise können Maschinen so programmiert werden, dass sie sich mit dem WIE beschäftigen.

Ein deklarativer API-Ansatz ermöglicht es Unternehmen, den gewünschten Zustand der eigenen Infrastruktur und Anwendungen zu definieren, und die zugrunde liegende Software und Systeme setzen ihn dann um. Wenn ein Plattform-Team einen Service für viele Entwickler im Unternehmen verwaltet, kann es sich mit diesem Ansatz auf höherwertige Aktivitäten konzentrieren, die das Geschäft vorantreiben, anstatt die Low-Level-Infrastruktur zu verwalten.

Confluent for Kubernetes bietet deklarative APIs auf hoher Ebene, indem die Kubernetes-API durch CustomResourceDefinitions (CRDs) erweitert wird, um die Verwaltung von Confluent-Services und Data-Plane-Ressourcen, wie z. B. Kafka-Topics, zu unterstützen. Der Benutzer interagiert mit der CRD, indem eine CustomResource definiert wird, die den gewünschten Zustand angibt. Dann kümmert sich Confluent for Kubernetes um den Rest.

Verwaltung von Confluent-Services

Confluent for Kubernetes bietet eine Reihe von CRDs zur Bereitstellung und Verwaltung von Confluent-Services: Kafka, ZooKeeper, Confluent Schema Registry, Kafka Connect, ksqlDB und Confluent Control Center.

Damit Unternehmen sich ausschließlich auf ihre Echtzeit-Geschäftsanwendungen konzentrieren können, ermöglicht es die deklarative API, die Handhabung der Infrastruktur der Software-Automatisierung zu überlassen: so dass Unternehmen sich ausschließlich auf die Echtzeit-Geschäftsanwendungen konzentrieren können:

• Kafka mit einer einzigen Änderung an der deklarativen Spezifikation skalieren. Confluent for Kubernetes fährt dann die erforderlichen Rechen-, Netzwerk- und Speicherkapazitäten hoch, startet die neuen Broker und und verteilt die Partitionen sinnvoll auf dem nun größeren Kafka Cluster.

• Eine vollständig sichere Plattform mit einer einzigen deklarativen Spezifikation bereitstellen. Confluent for Kubernetes automatisiert die Plattformkonfiguration für starke Authentifizierung, Autorisierung und Netzwerkverschlüsselung und erstellt den Satz an Zugriffskontrollen und TLS-Zertifikaten, die für den Betrieb von Confluent-Services erforderlich sind:

kind: Kafka

spec:

  replicas: 3

  image:

    application: confluentinc/cp-server-operator:6.1.0.0

    init: confluentinc/cp-init-container-operator:6.1.0.0

  dataVolumeCapacity: 250Gi

  tls:

    autoGeneratedCerts: true

  authorization:

    type: rbac

  listeners:

    external:

      authentication:

        type: plain

        jaasConfig:

          secretRef: credential

      externalAccess:

        type: loadBalancer

• Ein Upgrade auf eine aktuellere Version von Confluent Platform durchführen, indem die neue Version in der deklarativen Spezifikation angegeben wird. Confluent for Kubernetes orchestriert dann ein Rolling Upgrade, bei dem die neue Version ohne Unterbrechung der laufenden Workloads bereitgestellt wird.

• Eine fehlertolerante Infrastruktur in jeder Umgebung bereitstellen. Confluent for Kubernetes kennt die Infrastrukturtopologie von Knoten, Racks und Zonen und gewährleistet gleichzeitig die Ausfallsicherheit bei Infrastrukturfehlern:

kind: Kafka

spec:

  replicas: 6

  rackAssignment:

    nodeLabels:

    - topology.kubernetes.io/zone

  podTemplate:

    serviceAccountName: kafka

  oneReplicaPerNode: true

  image:

    application: confluentinc/cp-server-operator:6.1.0.0

    init: confluentinc/cp-init-container-operator:6.1.0.0

Data-Plane-Ressourcen verwalten

Confluent for Kubernetes bietet eine Reihe von CRDs zur Verwaltung von Confluent-Data-Plane-Ressourcen, insbesondere von Topics und RBAC-Rollenbindungen (Role-Based Access Control). 

Der Begriff Control Plane (Steuerebene) bezieht sich auf alle Funktionen und Prozesse, die bestimmen, welcher Pfad zum Senden eines Pakets oder Frames verwendet werden soll. Data Plane (Datenebene) bezieht sich hingegen auf alle Funktionen und Prozesse, die Pakete/Frames von einer Schnittstelle zu einer anderen weiterleiten, basierend auf der Logik der Steuerebene.

Eine Anwendung, ihre abhängigen Topics und die erforderlichen RBAC-Rollenbindungen können nun angegeben werden – alles in einer einzigen deklarativen Spezifikation. Für Entwicklung, Testen in QA und zum Betrieb in der Produktion können unterschiedliche deklarative Spezifikationen verwendet werden. Dadurch werden Sicherheitseinstellungen unabhängig und entkoppelt von der Anwendungsentwicklung konfiguriert.

Verwalten von Confluent-Data-Plane-Ressourcen mit einer deklarativen "Custom Resource"-Spezifikation:

apiVersion: platform.confluent.io/v1beta1

kind: KafkaTopic

metadata:

  name: 

  namespace: confluent

spec:

  replicas: 1

  partitionCount: 1

  configs:

    cleanup.policy: "delete"

Best Practices liefern ein konsistentes Erlebnis 

Confluent for Kubernetes bietet eine deklarative Spezifikation, die den Wunschzustand der Confluent-Infrastruktur festhält. Dies bildet die Single Source of Truth für den Infrastruktur- und Anwendungsstatus und fördert die Konsistenz im gesamten Unternehmen: 

• Eine konsistente, standardmäßig sichere Produktionsumgebung bereitstellen. Eine deklarative Spezifikation mit vollständigen Sicherheitskontrollen verwenden. Dazu gehört die vollständige Automatisierung der granularen rollenbasierten Zugriffskontrolle von Confluent für die Autorisierung – so wird ein Setup-Prozess mit Dutzenden von Schritten auf einen einzigen Schritt reduziert.
• Bereitstellung einer einfach zu implementierenden Entwicklungsumgebung. Verwendung einer deklarativen Spezifikation, die alle Confluent Platform Services mit optimaler Ressourcennutzung bereitstellt.
• Standardisierung der Art und Weise, wie Kafka für externe Client-Anwendungen zugänglich gemacht wird, um das Risiko von Fehlkonfigurationen und Sicherheitsvorfällen zu vermeiden. Eine deklarative Spezifikation verwenden, die entweder Load Balancer oder einen Ingress Controller einsetzt.

Diese deklarativen Spezifikationen ermöglichen es Unternehmen, den Zustand der eigenen Infrastruktur und den Zustand ihrer Anwendung als Code auszudrücken – als eine Sammlung von YAML-Dateien. Diese YAML-Dateien können in ein Git-Repository eingecheckt werden, sodass Teams bei der Verwaltung dieser Umgebungen zusammenarbeiten können. Mit CI/CD-Systemen können die YAML-Dateien aus Git gezogen werden, um Updates in den Confluent-Umgebungen in der Entwicklung, QA und dann in der Produktion zu verteilen. Dieses gesamte Paradigma wird als GitOps bezeichnet und ermöglicht das automatische Ausrollen von neuen Features und Bugfixes..

Confluent for Kubernetes bündelt die Konstrukte für die deklarative Verwaltung der gesamten Plattform. Ein zentrales Plattformteam oder ein Shared Services-Team kann darauf aufbauen, um Anwendungsteams eine Self-Service-Private-Cloud-Erfahrung für Confluent Platform zu bieten.

Ein Cloud-natives Ökosystem für einen effizienten Betrieb nutzen

Es ist nicht nur Confluent, das Unternehmen in der gemeinsam genutzten Compute-Umgebung betreiben werden! Mit Confluent for Kubernetes können Kubernetes-native Schnittstellen, Integrationen und Scheduling-Steuerungen genutzt werden, um konsistent und kostengünstig neben anderen Anwendungen und Datensystemen zu arbeiten.

Confluent hat diese Reise vor ein paar Jahren mit Confluent Operator begonnen. Es startete mit der Verwendung von Helm, um eine einfache Konfigurationsabstraktion über Kubernetes bereitzustellen, und erlaubte Unternehmen, eine deklarative Spezifikation als Helm values.yaml-Datei zu definieren.

Als die Überlegung entstand, wie Confluent Automatisierung und verpackte Best Practices bereitstellen könnte, wurde schnell klar, dass Helm-Vorlagen nicht die richtige Wahl für die Architektur waren. Daher Ist Confluent zu einem Industriestandard übergegangen und hat sich auf die Bereitstellung einer Kubernetes-nativen Schnittstelle mit CRDs und Controllern ausgerichtet. Eine Kubernetes-native Erfahrung ermöglicht es Unternehmen, sich auf einen API-gesteuerten Ansatz durch benutzerdefinierte Ressourcen zu verlassen und die Vorteile von Ökosystem-Tools und Funktionen zu nutzen, die Kubernetes zugrunde liegen. Das bedeutet, dass vom Kunden kein spezielles Wissen darüber aufgebaut werden muss, wie die Anwendungen bereitgestellt werden, z. B. wie Storage und Netzwerk für zustandsabhängige Services konfiguriert werden.

Jede Spezifikation der Ressourcenkonfiguration in Confluent for Kuberentes wird als Kubernetes-native CRD definiert, und jede Confluent-Ressource bietet eine Schnittstelle zur Konfigurationserweiterung:

• Komponenten-Servereigenschaften konfigurieren, JVM-Konfigurationen und Log4j-Eigenschaften für jeden Confluent Platform-Service.
• Den Lebenszyklus sensibler Anmeldedaten und Konfigurationen separat verwalten und nur in der Spezifikation der Confluent-Ressourcenkonfiguration auf sie verweisen. Industriestandards wie Kubernetes Secrets oder Hashicorp Vault nutzen, um den Lebenszyklus von Anmeldeinformationen zu verwalten.
• Regeln für das Workload Scheduling durch Kubernetes-Toleranzen sowie Node- und Pod-Affinität spezifizieren.
• Die Integration mit Prometheus und Grafana ist sofort verfügbar. Jeder Confluent Platform Service stellt JMX-Metriken über einen Prometheus-Exporter zur Verfügung, und Prometheus on Kubernetes erkennt automatisch die Schnittstelle des Exporters und beginnt mit dem Scraping von Metriken.

Recordings vom Kafka Summit Europe 2021 geben Einblicke in die Praxis 

• Mehr Informationen zu Confluent for Kubernetes und anderen Confluent News gibt es im Recording der Keynote von Confluent-Mitbegründer und CEO Jay Kreps beim Kafka Summit Europe vom 12. Mai 2021. 
• Für einen noch tieferen Einblick in Confluent for Kubernetes empfehlen wir den Kafka Summit Europe 2021 Lightning Talk. 
• Zum Thema deklarative Spezifikationen und GitOps den Kafka Summit Talk “GitOps for Kafka” anschauen.

Jetzt die Recordings ansehen: https://kafkasummit.io/

Ein Blick in die Zukunft

Globale Kontrollebene

Heute bietet Confluent for Kubernetes die Möglichkeit, eine deklarative Spezifikation für Entwicklungs- und Produktionskonfigurationen zu definieren. Dadurch können Unternehmen dann in jeder beliebigen Umgebung ihrer Wahl die Confluent Infrastruktur automatisiert bereitstellen und verwalten.

In Zukunft werden Kunden eine konsistente Erfahrung über diese Umgebungen und Bereitstellungen hinweg erhalten:

• Eine einzige grafische Oberfläche, um den Betriebsstatus über mehrere Umgebungen hinweg zu überwachen, mit der Möglichkeit, die einzelnen Umgebungen zu analysieren
• Eine GUI- und CLI-Schnittstelle zur Bereitstellung und Verwaltung von Confluent in verschiedenen Umgebungen. Dies können entweder Infrastrukturen für Entwicklung, Test und Produktion oder auch verschiedene Data Center sein.

Cloud-natives Networking

Istio ist eine Plattform zum Verbinden, Verwalten und Sichern von Microservices. Kafka ist ein beliebtes Tool für Microservices, da es viele der Probleme der Microservice-Kommunikation und -Orchestrierung löst und gleichzeitig Attribute ermöglicht, die Microservices anstreben, wie Skalierbarkeit, Effizienz und Geschwindigkeit.

Obwohl Istio ursprünglich zur Erleichterung der RESTful-HTTP-Kommunikation entwickelt wurde, gibt es einige Szenarien, in denen Istio zur Unterstützung von Kafka-Operationen weiterentwickelt wurde. Istio ist daher auch sinnvoll mit Confluent kombinierbar und könnte beispielsweise:

• eine Ansicht der Netzwerkkommunikation über die Confluent-Dienste hinweg bereitstellen.
• als Routing-Schicht für die Kommunikation zwischen Clients und Kafka-Brokern dienen
• bei der Verwaltung von TLS-Verschlüsselungszertifikaten und -konfigurationen helfen

Confluent hat den aktuellen Status in diesem Whitepaper dokumentiert. Es wird aktiv untersucht und dokumentiert werden, wie der Stand sich weiterentwickelt.

Fazit

Confluent geht davon aus, dass Cloud-native Datensysteme die Zukunft sind und dass Kafka und Event-Streams zu den zentralen Architekturprimitiven für digitale Unternehmen gehören, um ihre Daten in Bewegung zu setzen. Es ist jetzt an der Zeit, auf ein Cloud-natives Confluent in allen Unternehmensumgebungen hinzuarbeiten.

Ganz gleich, ob ein Unternehmen mit seinem ersten Anwendungsfall in Produktion geht und mit Agilität arbeiten möchte oder Streaming-as-a-Service für Entwickler im Unternehmen aufgebaut werden soll, Confluent für Kubernetes kann die richtige Lösung bieten und kann sofort eingerichtet und getestet werden.

Confluent ist nominiert in der Kategorie "Big Data as a Service" beim IT-AWARD 2021. Jetzt abstimmen!

Zusätzliche Ressourcen

• Weitere Details zur Funktionsweise von Confluent for Kubernetes sind in unserem Blog zu finden: https://www.confluent.io/blog/confluent-for-kubernetes-offers-cloud-native-kafka-automation/ 
• Case Studies: Wie Confluent seinen Kunden hilft, ihr Business zu transformieren: https://www.confluent.io/customers/ 
• Mehr Informationen über Confluent: https://www.confluent.io/ 
• Interessante offene Stelle? Jetzt Teil des Confluent-Teams werden : https://www.confluent.io/careers/