Modifier

Share via

Déploiements Helm pour Apache NiFi

Azure Kubernetes Service (AKS)

Cette solution vous montre comment utiliser des charts Helm quand vous déployez NiFi sur Azure Kubernetes Service (AKS). Helm simplifie le processus d’installation et de gestion des applications Kubernetes.

Apache®, Apache NiFi® et NiFi® sont soit des marques déposées, soit des marques commerciales d’Apache Software Foundation aux États-Unis et/ou dans d’autres pays. L’utilisation de ces marques n’implique aucune approbation de l’Apache Software Foundation.

Architecture

Diagramme montrant comment un utilisateur configure un graphique Helm afin de déployer une application sur Kubernetes. Les composants incluent des pods et des volumes que Kubernetes crée.

Téléchargez un fichier Visio de cette architecture.

Workflow

  • Un graphique Helm contient un fichier values.yaml. Ce fichier liste les valeurs d’entrée que les utilisateurs peuvent modifier.

  • L’utilisateur peut ajuster les paramètres d’un graphique, y compris les suivants :

    • Tailles des volumes.
    • Nombre de pods.
    • Mécanismes d’authentification et d’autorisation utilisateur.

  • L’utilisateur exécute la commande install Helm pour déployer le graphique.

  • Helm vérifie si l’entrée utilisateur contient des valeurs pour toutes les variables nécessaires.

  • Helm crée un manifeste qui décrit les objets à déployer sur Kubernetes.

  • Helm envoie le manifeste au cluster Kubernetes. Apache ZooKeeper fournit la coordination des clusters.

  • Kubernetes crée les objets spécifiés. Un déploiement NiFi nécessite les objets suivants :

    • Des objets de configuration.
    • Des volumes de données. Le stockage Pod est temporaire.
    • Un volume de journal d’activité.
    • Des pods qui utilisent une image pour exécuter NiFi dans un conteneur. Kubernetes utilise une ressource de charge de travail StatefulSet pour gérer les pods.
    • Un service Kubernetes qui rend l’interface utilisateur NiFi accessible aux utilisateurs.
    • Des routes d’entrée si le cluster utilise les entrées pour rendre l’interface disponible aux utilisateurs externes.

Composants

Un graphique Helm est une collection de fichiers situés dans un dossier comportant une arborescence. Ces fichiers décrivent les ressources Kubernetes. Vous pouvez configurer les composants suivants dans un graphique Helm :

ZooKeeper

ZooKeeper utilise un graphique distinct. Vous pouvez utiliser le graphique ZooKeeper standard que Kubernetes fournit dans son référentiel de graphiques Incubator. Toutefois, si vos dépendances incluent du contenu de registre public, vous introduisez des risques dans vos workflows de développement et de déploiement d’images. Pour atténuer ces risques, conservez des copies locales du contenu public si vous le pouvez. Pour plus d’informations, consultez Gérer le contenu public à l’aide d’Azure Container Registry.

Vous pouvez également déployer ZooKeeper de manière autonome. Si vous choisissez cette option, indiquez le serveur ZooKeeper et le numéro de port afin que les pods qui exécutent NiFi puissent accéder au service ZooKeeper.

StatefulSet Kubernetes

Pour exécuter une application sur Kubernetes, vous exécutez un pod. Cette unité de base exécute différents conteneurs qui implémentent les différentes activités de l’application.

Kubernetes propose deux solutions pour gérer les pods qui exécutent une application telle que NiFi :

  • Un ReplicaSet, qui maintient un ensemble stable de pods de réplicas qui s’exécutent à un moment donné. On utilise souvent un ReplicaSet pour garantir la disponibilité d’un nombre spécifié de pods identiques.
  • Un StatefulSet, qui est l’objet d’API de charge de travail que vous utilisez pour gérer les applications avec état. Un StatefulSet gère les pods qui sont basés sur une spécification de conteneur identique. Kubernetes crée ces pods à partir de la même spécification. Cependant, ces pods ne sont pas interchangeables. Chaque pod a un identificateur persistant qu’il gère lors de la replanification.

Étant donné que vous utilisez NiFi pour gérer des données, un StatefulSet fournit la meilleure solution pour les déploiements NiFi.

ConfigMaps

Kubernetes met à disposition ConfigMaps pour le stockage des données non confidentielles. Kubernetes utilise ces objets pour gérer différents fichiers de configuration comme nifi.properties. Le conteneur qui exécute l’application accède aux informations de configuration via des volumes et des fichiers montés. ConfigMaps facilite la gestion des modifications de la configuration après le déploiement.

ServiceAccount

Dans les instances sécurisées, NiFi utilise l’authentification et l’autorisation. NiFi gère ces informations dans les fichiers du système de fichiers. Plus précisément, chaque nœud de cluster doit gérer un fichier authorizations.xml et un fichier users.xml. Tous les membres doivent être en mesure d’écrire dans ces fichiers. En outre, chaque nœud du cluster doit avoir une copie identique de ces informations. Dans le cas contraire, le cluster ne sera plus synchronisé et ne fonctionnera plus.

Pour répondre à ces conditions, vous pouvez copier ces fichiers à partir du premier membre du cluster vers chaque membre existant. Chaque nouveau membre gère ensuite ses propres copies. En règle générale, les pods n’ont pas l’autorisation de copier le contenu d’un autre pod. Toutefois, un ServiceAccount Kubernetes permet d’obtenir une autorisation.

Services

Les services Kubernetes mettent le service d’application à la disposition des utilisateurs du cluster Kubernetes. Les objets de service permettent également aux nœuds membres des clusters NiFi de communiquer entre eux. Pour les déploiements de graphiques Helm, vous pouvez utiliser deux types de services : les services sans affichage et les services basés sur l’IP.

Entrée

Une entrée gère l’accès externe aux services de cluster. Plus précisément, un contrôleur d’entrée préconfiguré expose des routes HTTP et HTTPS, de l’extérieur du cluster vers les services situés à l’intérieur du cluster. Vous pouvez définir des règles d’entrée qui déterminent la façon dont le contrôleur route le trafic. Le graphique Helm inclut la route d’entrée dans la configuration.

Secrets

Pour configurer des clusters NiFi sécurisés, vous devez stocker les informations d’identification. Les secrets Kubernetes offrent un moyen sécurisé de stocker et de récupérer ces informations d’identification.

Détails du scénario

Les utilisateurs d’Apache NiFi doivent souvent déployer NiFi sur Kubernetes. Un déploiement Kubernetes implique de nombreux objets, tels que des pods, des volumes et des services. Il est difficile de gérer les manifestes ou les fichiers de spécifications que Kubernetes utilise pour un tel nombre d’objets. La difficulté augmente si vous déployez plusieurs clusters NiFi qui utilisent des configurations différentes.

Les graphiques Helm offrent une solution pour gérer les manifestes. Helm est le gestionnaire de package pour Kubernetes. En utilisant l’outil Helm, vous pouvez simplifier le processus d’installation et de gestion des applications Kubernetes.

Le graphique est le format d’empaquetage utilisé par Helm. Vous entrez des exigences de configuration dans des fichiers de graphique. Helm effectue le suivi de l’historique et des versions de chaque graphique. Helm utilise ensuite des graphiques pour générer des fichiers manifeste Kubernetes.

Vous pouvez déployer des applications qui utilisent des configurations différentes à partir d’un seul et même graphique. Lorsque vous exécutez NiFi sur Azure, vous pouvez utiliser des graphiques Helm pour déployer différentes configurations NiFi sur Kubernetes.

Apache®, Apache NiFi® et NiFi® sont soit des marques déposées, soit des marques commerciales d’Apache Software Foundation aux États-Unis et/ou dans d’autres pays. L’utilisation de ces marques n’implique aucune approbation de l’Apache Software Foundation.

Considérations

Ces considérations implémentent les piliers d’Azure Well-Architected Framework qui est un ensemble de principes directeurs qui permettent d’améliorer la qualité d’une charge de travail. Pour plus d'informations, consultez Microsoft Azure Well-Architected Framework.

Disques de données

Concernant l’utilisation du disque, vous pouvez utiliser un ensemble de disques agrégés par bandes pour les dépôts. Dans les déploiements de tests qui utilisaient Virtual Machine Scale Sets, cette approche fonctionnait mieux. L’extrait suivant tiré de nifi.properties montre une configuration d’utilisation du disque :

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

Cette configuration utilise trois volumes de taille égale. Vous pouvez ajuster les valeurs et l’agrégat par bandes pour répondre aux exigences de votre système.

Scénarios de déploiement

Vous pouvez utiliser un équilibreur de charge public ou privé, ou un contrôleur d’entrée pour exposer un cluster NiFi. Lorsque vous utilisez des graphiques Helm pour cette implémentation, deux configurations sont disponibles :

  • Cluster NiFi non sécurisé accessible via une URL HTTP, sans authentification ou autorisation de l’utilisateur.
  • Un cluster NiFi sécurisé, accessible par le biais d’une URL HTTPS. Ce type de cluster est sécurisé avec TLS. Quand vous configurez des clusters sécurisés, vous pouvez fournir vos propres certificats. Les graphiques peuvent également générer les certificats. À cet effet, les graphiques utilisent une boîte à outils NiFi qui fournit une autorité de certification auto-signée.

Si vous configurez un cluster NiFi pour qu’il s’exécute en tant que cluster sécurisé avec une communication TLS, vous devez activer l’authentification utilisateur. Utilisez l’une des méthodes d’authentification utilisateur suivantes :

  • Authentification utilisateur basée sur les certificats. Les utilisateurs sont authentifiés par le certificat qu’ils présentent à l’interface utilisateur NiFi. Pour utiliser ce type de système d’authentification utilisateur, ajoutez le certificat public de l’autorité de certification au déploiement NiFi.
  • Authentification utilisateur basée sur LDAP. Un serveur LDAP authentifie les informations d’identification de l’utilisateur. Lorsque vous déployez le graphique, fournissez des informations sur le serveur LDAP et l’arborescence d’informations.
  • Authentification utilisateur basée sur OpenID. Les utilisateurs fournissent des informations au serveur OpenID pour configurer le déploiement.

Configuration et utilisation des ressources

Pour optimiser l’utilisation des ressources, utilisez ces options Helm afin de configurer les valeurs du processeur et de la mémoire :

  • L’option request, qui spécifie la quantité initiale de la ressource qui est demandée par le conteneur
  • L’option limit, qui spécifie la quantité maximale de la ressource que le conteneur peut utiliser

Quand vous configurez NiFi, tenez compte de la configuration de la mémoire de votre système. Étant donné que NiFi est une application Java, vous devez ajuster les paramètres comme les valeurs minimale et maximale de la mémoire JVM. Utilisez les paramètres suivants :

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

Sécurité

La sécurité fournit des garanties contre les attaques délibérées, et contre l’utilisation abusive de vos données et systèmes importants. Pour plus d’informations, consultez Vue d’ensemble du pilier Sécurité.

Utilisez un contexte de sécurité Kubernetes pour améliorer la sécurité des conteneurs sous-jacents qui exécutent le binaire NiFi. Un contexte de sécurité gère l’accès à ces conteneurs et à leurs pods. À l’aide d’un contexte de sécurité, vous pouvez accorder aux utilisateurs non racines l’autorisation d’exécuter les conteneurs.

Les autres utilisations d’un contexte de sécurité sont les suivantes :

  • Restreindre l’accès des utilisateurs du système d’exploitation qui exécutent les conteneurs.
  • Spécifier les groupes qui peuvent accéder aux conteneurs.
  • Limiter l’accès au système de fichiers.

Images de conteneur

Les conteneurs Kubernetes sont les unités de base qui exécutent les binaires NiFi. Pour configurer un cluster NiFi, concentrez-vous sur l’image que vous utilisez pour exécuter ces conteneurs. Vous disposez de deux options pour cette image :

  • Utilisez l’image NiFi standard pour exécuter le graphique NiFi. Cette image est fournie par la communauté Apache NiFi. Toutefois, vous devrez ajouter un binaire kubectl aux conteneurs pour configurer des clusters sécurisés.
  • Utilisez une image personnalisée. Si vous choisissez cette approche, tenez compte de la configuration requise pour votre système de fichiers. Vérifiez que l’emplacement de vos binaires NiFi est correct. Pour plus d’informations sur le système de fichiers configuré, consultez Dockerfile in the Apache NiFi source code.

Contributeurs

Cet article est géré par Microsoft. Il a été écrit à l’origine par les contributeurs suivants.

Auteur principal :

Pour afficher les profils LinkedIn non publics, connectez-vous à LinkedIn.

Étapes suivantes