Bearbeiten

Freigeben über

Helm-basierte Bereitstellungen für Apache NiFi

Azure Kubernetes Service (AKS)

In dieser Lösung wird gezeigt, wie Sie Helm-Charts beim Bereitstellen von NiFi in Azure Kubernetes Service (AKS) verwenden. Helm optimiert den Installations- und Verwaltungsprozess für Kubernetes-Anwendungen.

Apache®, Apache NiFi® und NiFi® sind entweder eingetragene Marken oder Marken der Apache Software Foundation in den USA und/oder anderen Ländern. Die Verwendung dieser Markierungen impliziert kein Endorsement durch die Apache Software Foundation.

Aufbau

Diagramm: Ein Benutzer konfiguriert ein Helm-Chart für die Bereitstellung einer Anwendung in Kubernetes. Die Komponenten umfassen Pods und Volumes, die von Kubernetes erstellt werden.

Laden Sie eine Visio-Datei dieser Architektur herunter.

Workflow

  • Ein Helm-Chart enthält eine Datei namens values.yaml. Diese Datei enthält eine Liste mit Eingabewerten, die Benutzer bearbeiten können.

  • Ein Benutzer kann Einstellungen in einem Chart anpassen und so unter anderem Werte für Folgendes bearbeiten:

    • Volumegrößen
    • Podanzahl
    • Mechanismen für Benutzerauthentifizierung und -autorisierung

  • Der Benutzer führt den Helm-Befehl install aus, um das Chart bereitzustellen.

  • Von Helm wird überprüft, ob die Benutzereingabe Werte für alle erforderlichen Variablen enthält.

  • Von Helm wird ein Manifest erstellt, das die Objekte beschreibt, die in Kubernetes bereitgestellt werden sollen.

  • Das Manifest wird von Helm an den Kubernetes-Cluster gesendet. Die Clusterkoordination wird von Apache ZooKeeper übernommen.

  • Von Kubernetes werden die angegebenen Objekte erstellt. Für eine NiFi-Bereitstellung sind folgende Objekte erforderlich:

    • Konfigurationsobjekte
    • Datenvolumes. Podspeicher ist temporär.
    • Ein Protokollvolume
    • Pods, die ein Image verwenden, um NiFi in einem Container auszuführen. Kubernetes verwendet eine Workloadressource vom Typ StatefulSet für die Podverwaltung.
    • Ein Kubernetes-Dienst, der die NiFi-Benutzeroberfläche für Benutzer verfügbar macht
    • Eingangsrouten, falls der Cluster eingehenden Datenverkehr verwendet, um die Benutzeroberfläche extern verfügbar zu machen

Komponenten

Ein Helm-Chart ist eine Sammlung von Dateien in einem Ordner mit einer Baumstruktur. Diese Dateien beschreiben Kubernetes-Ressourcen. In einem Helm-Chart können folgende Komponenten konfiguriert werden:

ZooKeeper

ZooKeeper verwendet ein separates Chart. Sie können das standardmäßige ZooKeeper-Chart verwenden, das von Kubernetes im zugehörigen Incubator-Chart-Repository bereitgestellt wird. Falls Ihre Abhängigkeiten allerdings öffentliche Registrierungsinhalte umfassen, entsteht dadurch ein Risiko in Ihren Workflows für die Imageentwicklung und -bereitstellung. Um dieses Risiko zu minimieren, sollten Sie nach Möglichkeit lokale Kopien von öffentlichen Inhalten aufbewahren. Ausführliche Informationen finden Sie unter Verwalten öffentlicher Inhalte mit Azure Container Registry.

Alternativ können Sie ZooKeeper selbst bereitstellen. Geben Sie bei Verwendung dieser Option den ZooKeeper-Server und die Portnummer an, damit die Pods, von denen NiFi ausgeführt wird, auf den ZooKeeper-Dienst zugreifen können.

StatefulSet von Kubernetes

Wenn Sie eine Anwendung in Kubernetes ausführen möchten, führen Sie einen Pod aus. In dieser einfachen Einheit werden verschiedene Container ausgeführt, die die verschiedenen Aktivitäten der Anwendung implementieren.

Kubernetes bietet zwei Lösungen für die Verwaltung von Pods, in denen eine Anwendung wie NiFi ausgeführt wird:

  • Ein ReplicaSet, das einen stabile Gruppe der jeweils ausgeführten Replikatpods verwaltet. Ein ReplicaSet wird häufig verwendet, um die Verfügbarkeit einer angegebenen Anzahl identischer Pods zu gewährleisten.
  • Ein StatefulSet. Hierbei handelt es sich um das Workload-API-Objekt, das zum Verwalten zustandsbehafteter Anwendungen verwendet wird. Ein StatefulSet dient zur Verwaltung von Pods, die auf einer identischen Containerspezifikation basieren. Kubernetes erstellt diese Pods auf der Grundlage der gleichen Spezifikation. Diese Pods sind jedoch nicht austauschbar. Jeder Pod verfügt über einen persistenten Bezeichner, der über die Neuplanung hinaus erhalten bleibt.

Da Sie NiFi zum Verwalten von Daten verwenden, ist ein StatefulSet die beste Lösung für NiFi-Bereitstellungen.

ConfigMaps

Kubernetes bietet ConfigMaps zum Speichern nicht vertraulicher Daten. Diese Objekte werden von Kubernetes verwendet, um verschiedene Konfigurationsdateien zu verwalten (beispielsweise nifi.properties). Der Container, in dem die Anwendung ausgeführt wird, greift über eingebundene Volumes und Dateien auf die Konfigurationsinformationen zu. Mithilfe von ConfigMaps lassen sich Konfigurationsänderungen nach der Bereitstellung mühelos verwalten.

ServiceAccount

In geschützten Instanzen werden von NiFi Authentifizierung und Autorisierung verwendet. Die entsprechenden Informationen werden von NiFi in Dateisystemdateien verwaltet. Dabei müssen von jedem Clusterknoten eine Datei vom Typ authorizations.xml und eine Datei vom Typ users.xml verwaltet werden. Alle Mitglieder müssen in diese Dateien schreiben können. Außerdem muss jeder Knoten im Cluster über eine identische Kopie dieser Informationen verfügen. Andernfalls ist der Cluster nicht mehr synchron und fällt aus.

Um diese Bedingungen zu erfüllen, können Sie die Dateien aus dem ersten Mitglied des Clusters in jedes neu erstellte Mitglied kopieren. Die neuen Mitglieder verwalten dann jeweils ihre eigenen Kopien. Pods sind in der Regel nicht zum Kopieren von Inhalten aus einem anderen Pod autorisiert. Die Autorisierung kann jedoch per ServiceAccount von Kubernetes erreicht werden.

Dienste

Kubernetes-Dienste machen den Anwendungsdienst für Benutzer des Kubernetes-Clusters verfügbar. Dienstobjekte ermöglichen zudem die Kommunikation zwischen Mitgliedsknoten von NiFi-Clustern. Für Helm-Chartbereitstellungen stehen zwei Diensttypen zur Verfügung: monitorlose Dienste und IP-basierte Dienste.

Eingehende Daten

Durch Eingangsdaten wird externer Zugriff auf Clusterdienste verwaltet. Ein vorkonfigurierter Eingangsdatencontroller macht HTTP- und HTTPS-Routen von außerhalb des Clusters für Dienste innerhalb des Clusters verfügbar. Sie können Eingangsregeln definieren, die bestimmen, wie der Datenverkehr vom Controller weitergeleitet werden soll. Das Helm-Chart enthält die Eingangsroute in der Konfiguration.

Geheimnisse

Zum Konfigurieren geschützter NiFi-Cluster müssen Anmeldeinformationen gespeichert werden. Kubernetes-Geheimnisse bieten eine sichere Möglichkeit zum Speichern und Abrufen dieser Anmeldeinformationen.

Szenariodetails

Apache NiFi-Benutzer müssen NiFi häufig in Kubernetes bereitstellen. Eine Kubernetes-Bereitstellung umfasst zahlreiche Objekte wie Pods, Volumes und Dienste. Die Verwaltung der von Kubernetes verwendeten Manifeste (oder Spezifikationsdateien) ist für diese Anzahl von Objekten nicht einfach. Und wenn Sie mehrere NiFi-Cluster mit unterschiedlichen Konfigurationen bereitstellen, wird es noch schwieriger.

Helm-Charts bieten eine Lösung für die Verwaltung der Manifeste. Helm ist der Paket-Manager für Kubernetes. Mithilfe des Helm-Tools können Sie den Installations- und Verwaltungsprozess für Kubernetes-Anwendungen optimieren.

Ein Chart ist das von Helm verwendete Paketformat. Konfigurationsanforderungen werden von Ihnen in Chart-Dateien eingegeben. Helm verfolgt den Verlauf und die Versionen jedes einzelnen Charts nach. Anschließend werden von Helm mithilfe von Charts Kubernetes-Manifestdateien generiert.

Über ein einzelnes Chart können Anwendungen mit unterschiedlichen Konfigurationen bereitgestellt werden. Wenn Sie NiFi in Azure ausführen, können Sie Helm-Charts verwenden, um verschiedene NiFi-Konfigurationen in Kubernetes bereitzustellen.

Apache®, Apache NiFi® und NiFi® sind entweder eingetragene Marken oder Marken der Apache Software Foundation in den USA und/oder anderen Ländern. Die Verwendung dieser Markierungen impliziert kein Endorsement durch die Apache Software Foundation.

Überlegungen

Diese Überlegungen beruhen auf den Säulen des Azure Well-Architected Frameworks, d. h. einer Reihe von Grundsätzen, mit denen die Qualität von Workloads verbessert werden kann. Weitere Informationen finden Sie unter Microsoft Azure Well-Architected Framework.

Datenträger

Erwägen Sie für die Datenträgerverwendung die Verwendung eines Stripesets von Datenträgern für Repositorys. Dieser Ansatz hat sich in Testbereitstellungen mit Virtual Machine Scale Sets bewährt. Der folgende Auszug aus nifi.properties zeigt eine Datenträgerverwendungskonfiguration:

nifi.flowfile.repository.directory=/data/partition1/flowfiles
nifi.provenance.repository.directory.stripe1=/data/partition1/provenancenifi.provenance.repository.directory.stripe2=/data/partition2/provenancenifi.provenance.repository.directory.stripe3=/data/partition3/provenancenifi.content.repository.directory.stripe2=/data/partition2/content
nifi.content.repository.directory.stripe3=/data/partition3/content

Diese Konfiguration umfasst drei gleich große Volumes. Sie können die Werte und das Striping an Ihre Systemanforderungen anpassen.

Bereitstellungsszenarien

Sie können einen öffentlichen oder privaten Lastenausgleich oder einen Eingangsdatencontroller verwenden, um einen NiFi-Cluster verfügbar zu machen. Wenn Sie Helm-Charts für diese Implementierung verwenden, stehen zwei Konfigurationen zur Verfügung:

  • Ein ungeschützter NiFi-Cluster, auf den über eine HTTP-URL ohne Benutzerauthentifizierung oder Autorisierung zugegriffen werden kann
  • Ein geschützter NiFi-Cluster, auf den über eine HTTPS-URL zugegriffen werden kann. Diese Art von Cluster wird mit TLS geschützt. Wenn Sie geschützte Cluster konfigurieren, können Sie Ihre eigenen Zertifikate bereitstellen. Alternativ können die Zertifikate durch die Charts generiert werden. Zu diesem Zweck verwenden die Charts ein NiFi-Toolkit, das eine Zertifizierungsstelle (Certificate Authority, CA) für selbstsignierte Zertifikate bietet.

Wenn Sie einen NiFi-Cluster so konfigurieren, dass er als geschützter Cluster mit TLS-Kommunikation ausgeführt wird, müssen Sie die Benutzerauthentifizierung aktivieren. Verwenden Sie eine der folgenden unterstützten Methoden für die Benutzerauthentifizierung:

  • Zertifikatbasierte Benutzerauthentifizierung: Benutzer werden durch das Zertifikat authentifiziert, das sie auf der NiFi-Benutzeroberfläche vorlegen. Fügen Sie der NiFi-Bereitstellung das öffentliche Zertifikat der Zertifizierungsstelle hinzu, um diese Art von Benutzerauthentifizierungssystem zu verwenden.
  • LDAP-basierte Benutzerauthentifizierung: Benutzeranmeldeinformationen werden von einem LDAP-Server authentifiziert. Geben Sie beim Bereitstellen des Charts Informationen zum LDAP-Server und zur Informationsstruktur an.
  • OpenID-basierte Benutzerauthentifizierung: Benutzer geben Informationen für den OpenID-Server an, um die Bereitstellung zu konfigurieren.

Ressourcenkonfiguration und -nutzung

Verwenden Sie die folgenden Helm-Optionen zum Konfigurieren von CPU- und Arbeitsspeicherwerten, um die Ressourcennutzung zu optimieren:

  • Die Option request gibt die anfängliche Menge der Ressource an, die durch den Container angefordert wird.
  • Die Option limit gibt die maximale Menge der Ressource an, die vom Container verwendet werden kann.

Berücksichtigen Sie beim Konfigurieren von NiFi die Arbeitsspeicherkonfiguration Ihres Systems. Da es sich bei NiFi um eine Java-Anwendung handelt, sollten Einstellungen wie die Mindest- und Maximalwerte für JVM-Arbeitsspeicher (Java Virtual Machine) angepasst werden. Verwenden Sie folgende Einstellungen:

  • jvmMinMemory
  • jvmMaxMemory
  • g1ReservePercent
  • conGcThreads
  • parallelGcThreads
  • initiatingHeapOccupancyPercent

Sicherheit

Sicherheit bietet Schutz vor vorsätzlichen Angriffen und dem Missbrauch Ihrer wertvollen Daten und Systeme. Weitere Informationen finden Sie unter Übersicht über die Säule „Sicherheit“.

Verwenden Sie einen Kubernetes-Sicherheitskontext, um die Sicherheit der zugrunde liegenden Container zu verbessern, von denen die NiFi-Binärdatei ausgeführt wird. Ein Sicherheitskontext verwaltet den Zugriff auf diese Container und ihre Pods. Über einen Sicherheitskontext können Sie Nicht-Root-Benutzern Berechtigungen zum Ausführen der Container erteilen.

Weitere Verwendungsmöglichkeiten von Sicherheitskontexten:

  • Einschränken des Zugriffs betriebssystembasierter Benutzer, die die Container ausführen
  • Angeben, welche Gruppen auf die Container zugreifen können
  • Beschränken des Zugriffs auf das Dateisystem

Containerimages

Kubernetes-Container sind die Basiseinheiten, in denen NiFi-Binärdateien ausgeführt werden. Um einen NiFi-Cluster zu konfigurieren, konzentrieren Sie sich auf das Image, das Sie zum Ausführen dieser Container verwenden. Für dieses Image stehen Ihnen zwei Optionen zur Verfügung:

  • Sie können das NiFi-Standardimage zum Ausführen des NiFi-Charts verwenden. Dieses Image wird von der Apache NiFi-Community bereitgestellt. Sie müssen den Containern jedoch eine Binärdatei vom Typ kubectl hinzufügen, um geschützte Cluster zu konfigurieren.
  • Sie können ein benutzerdefiniertes Image verwenden. Berücksichtigen Sie bei diesem Ansatz Ihre Dateisystemanforderungen. Achten Sie darauf, dass der Speicherort Ihrer NiFi-Binärdateien korrekt ist. Weitere Informationen zum konfigurierten Dateisystem finden Sie unter Dockerfile im Apache NiFi-Quellcode.

Beitragende

Dieser Artikel wird von Microsoft gepflegt. Er wurde ursprünglich von folgenden Mitwirkenden geschrieben:

Hauptautor:

Melden Sie sich bei LinkedIn an, um nicht öffentliche LinkedIn-Profile anzuzeigen.

Nächste Schritte