Modifica

Distribuzioni basate su Helm per Apache NiFi

Servizio Azure Kubernetes

Questa soluzione illustra come usare i grafici Helm quando si distribuisce NiFi in servizio Azure Kubernetes (servizio Azure Kubernetes). Helm consente di semplificare il processo di installazione e gestione delle applicazioni Kubernetes.

Apache®, Apache NiFi®, and NiFi® sono marchi o marchi registrati di Apache Software Foundation negli Stati Uniti e/o in altri paesi. L'uso di questi marchi non implica alcuna approvazione da parte di Apache Software Foundation.

Architettura

Diagramma che illustra come un utente configura un grafico Helm per distribuire un'applicazione in Kubernetes. I componenti includono pod e volumi creati da Kubernetes.

Scaricare un file di Visio di questa architettura.

Flusso di lavoro

  • Un grafico Helm contiene un file values.yaml con l'elenco dei valori di input che gli utenti possono modificare.

  • Un utente può modificare le impostazioni in un grafico, inclusi i valori relativi a:

    • Dimensioni del volume.
    • Numero di pod.
    • Autenticazione e autorizzazione degli utenti.

  • L'utente esegue il comando install di Helm per distribuire il grafico.

  • Helm controlla se l'input utente contiene i valori per tutte le variabili obbligatorie.

  • Helm crea un file manifesto che descrive gli oggetti da distribuire in Kubernetes.

  • Helm invia il manifesto al cluster Kubernetes. Apache ZooKeeper gestisce il coordinamento del cluster.

  • Kubernetes crea gli oggetti specificati. Una distribuzione NiFi richiede gli oggetti elencati di seguito.

    • Oggetti di configurazione.
    • Volumi di dati. L'archiviazione pod è temporanea.
    • Un volume di log.
    • Pod che usano un'immagine per eseguire NiFi in un contenitore. Kubernetes usa una risorsa del carico di lavoro StatefulSet per gestire i pod.
    • Un servizio Kubernetes che rende disponibile l'interfaccia utente NiFi per gli utenti.
    • Route in ingresso se il cluster usa l'ingresso per rendere l'interfaccia utente disponibile esternamente.

Componenti

Un grafico Helm è costituito da una raccolta di file in una cartella con una struttura ad albero. Questi file descrivono le risorse Kubernetes. In un grafico Helm è possibile configurare i componenti seguenti:

ZooKeeper

ZooKeeper usa un grafico distinto. È possibile usare il grafico ZooKeeper standard fornito da Kubernetes e disponibile nel relativo repository di grafici dell'incubatore. Tuttavia, se le dipendenze includono il contenuto del Registro di sistema pubblico, si introduce un rischio nei flussi di lavoro di sviluppo e distribuzione di immagini. Per mitigare tale rischio, è opportuno conservare le copie locali del contenuto pubblico, quando possibile. Per informazioni dettagliate, vedere Gestire il contenuto pubblico con Registro Azure Container.

In alternativa, è possibile distribuire ZooKeeper in autonomia. Se si sceglie questa opzione, specificare il server ZooKeeper e il numero di porta per consentire ai pod che eseguono NiFi di accedere al servizio ZooKeeper.

Oggetto StatefulSet di Kubernetes

Per eseguire un'applicazione in Kubernetes, è necessario eseguire un pod. Questa unità di base esegue diversi contenitori che implementano le diverse attività dell'applicazione.

Per la gestione dei pod che eseguono un'applicazione come NiFi, Kubernetes offre i due oggetti indicati di seguito.

  • ReplicaSet, che gestisce un set stabile dei pod di replica eseguiti in un determinato momento. Spesso si usa un oggetto ReplicaSet per garantire la disponibilità di un numero specificato di pod identici.
  • StatefulSet, ovvero l'oggetto API del carico di lavoro utilizzato per gestire le applicazioni con stato. Un oggetto StatefulSet gestisce i pod basati su una specifica di contenitore identica. Kubernetes crea questi pod a partire dalla stessa specifica. Tuttavia, i pod non sono intercambiabili. Ogni pod ha un identificatore permanente che viene mantenuto durante la riprogrammazione.

Poiché si usa NiFi per gestire i dati, l'oggetto StatefulSet rappresenta la soluzione migliore per le distribuzioni NiFi.

Oggetti ConfigMap

Kubernetes offre oggetti ConfigMap per l'archiviazione di dati non riservati. Kubernetes usa questi oggetti per gestire vari file di configurazione, ad esempio nifi.properties. Il contenitore che esegue l'applicazione accede alle informazioni di configurazione tramite volumi e file montati. Gli oggetti ConfigMaps semplificano la gestione delle modifiche di configurazione post-distribuzione.

ServiceAccount

Nelle istanze protette, NiFi usa l'autenticazione e l'autorizzazione. NiFi gestisce queste informazioni nei file del file system. In particolare, ogni nodo del cluster deve gestire un file authorizations.xml e un file users.xml. Tutti i membri devono poter scrivere in questi file. Ogni nodo del cluster deve avere una copia identica di queste informazioni. In caso contrario, il cluster non viene sincronizzato e viene interrotto.

Per soddisfare queste condizioni, è possibile copiare questi file dal primo membro del cluster a ogni membro esistente. Ogni nuovo membro gestirà quindi le proprie copie. I pod in genere non dispongono dell'autorizzazione per copiare il contenuto da un altro pod. Tuttavia, un ServiceAccount di Kubernetes consente di ottenere l'autorizzazione.

Servizi

I servizi Kubernetes rendono il servizio dell'applicazione disponibile per gli utenti del cluster Kubernetes. Gli oggetti del servizio rendono anche possibile la comunicazione tra i nodi membri dei cluster NiFi. Per le distribuzioni di grafici Helm, è necessario usare due tipi di servizi: headless e basati su IP.

Dati in ingresso

Un ingresso gestisce l'accesso esterno ai servizi del cluster. In particolare, un controller di ingresso preconfigurato espone le route HTTP e HTTPS dall'esterno del cluster ai servizi all'interno del cluster. È possibile definire regole in ingresso per determinare il modo in cui il controller deve instradare il traffico. Il grafico Helm include la route in ingresso nella configurazione.

Segreti

Per configurare cluster NiFi protetti, è necessario archiviare le credenziali. I segreti di Kubernetes offrono un modo sicuro per archiviare e recuperare queste credenziali.

Dettagli dello scenario

Gli utenti di Apache NiFi spesso devono distribuire NiFi in Kubernetes. Una distribuzione di Kubernetes interessa molti oggetti, ad esempio pod, volumi e servizi. La gestione dei file manifesto o dei file di specifica utilizzati da Kubernetes per questo numero di oggetti è complicata. La difficoltà aumenta se si distribuiscono più cluster NiFi con configurazioni diverse.

I grafici Helm offrono una soluzione per la gestione dei file manifesto. Helm è un gestore di pacchetti per Kubernetes. Lo strumento Helm semplifica il processo di installazione e gestione delle applicazioni Kubernetes.

Il grafico è il formato di pacchetto utilizzato da Helm. L'utente immette i requisiti di configurazione nei file dei grafici. Helm tiene traccia della cronologia e delle versioni di ogni grafico. Helm usa quindi i grafici per generare i file manifesto di Kubernetes.

Tramite un singolo grafico è possibile distribuire applicazioni che usano configurazioni diverse. Se si esegue NiFi in Azure, è possibile usare i grafici Helm per distribuire diverse configurazioni NiFi in Kubernetes.

Apache®, Apache NiFi®, and NiFi® sono marchi o marchi registrati di Apache Software Foundation negli Stati Uniti e/o in altri paesi. L'uso di questi marchi non implica alcuna approvazione da parte di Apache Software Foundation.

Considerazioni

Queste considerazioni implementano i pilastri di Azure Well-Architected Framework, che è un set di principi guida che possono essere usati per migliorare la qualità di un carico di lavoro. Per altre informazioni, vedere Microsoft Azure Well-Architected Framework.

Dischi dati

Per l'utilizzo del disco, considerare l'utilizzo di un set di dischi con striping per i repository. Nelle distribuzioni di test che hanno usato set di scalabilità di macchine virtuali questo approccio ha funzionato al meglio. L'estratto di nifi.properties seguente illustra una configurazione di utilizzo del disco:

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

La configurazione usa tre volumi di dimensioni uguali. Per soddisfare i requisiti di sistema, è possibile modificare i valori e lo striping.

Scenari di distribuzione

Per esporre un cluster NiFi, è possibile usare un servizio di bilanciamento del carico pubblico o privato o un controller in ingresso. Se si usano grafici Helm per questa implementazione, sono disponibili due configurazioni:

  • Un cluster NiFi non protetto accessibile tramite un URL HTTP, senza autenticazione o autorizzazione dell'utente.
  • Un cluster NiFi protetto accessibile tramite un URL HTTPS. Questo tipo di cluster è protetto tramite TLS. Quando si configurano cluster protetti, è possibile fornire certificati personalizzati. In alternativa, si possono generare i certificati tramite i grafici. A questo scopo, i grafici usano un toolkit di NiFi che fornisce un'autorità di certificazione (CA) autofirmata.

Se si configura un cluster NiFi per l'esecuzione come cluster protetto con comunicazione TLS, è necessario attivare l'autenticazione utente. Usare uno dei metodi di autenticazione supportati seguenti:

  • Autenticazione dell'utente basata su certificati. Gli utenti vengono autenticati tramite il certificato che presentano nell'interfaccia utente NiFi. Per usare questo tipo di sistema di autenticazione, aggiungere il certificato pubblico della CA alla distribuzione di NiFi.
  • Autenticazione dell'utente basata su LDAP. Un server LDAP autentica le credenziali dell'utente. Quando si distribuisce il grafico, fornire le informazioni sul server LDAP e sull'albero delle informazioni.
  • Autenticazione dell'utente basata su OpenID. Gli utenti forniscono le informazioni al server OpenID per configurare la distribuzione.

Configurazione e utilizzo delle risorse

Per ottimizzare l'utilizzo delle risorse, usare le opzioni di Helm indicate di seguito per configurare i valori di CPU e memoria.

  • Opzione request, che specifica la quantità iniziale della risorsa richiesta dal contenitore
  • Opzione limit, che specifica la quantità massima di risorse che il contenitore può usare

Quando si configura NiFi, considerare la configurazione della memoria di sistema. Poiché NiFi è un'applicazione Java, è necessario modificare le impostazioni come i valori di memoria JVM (Java Virtual Machine) minimo e massimo. Usare le seguenti impostazioni:

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

Sicurezza

La sicurezza offre garanzie contro attacchi intenzionali e l'abuso dei dati e dei sistemi preziosi. Per altre informazioni, vedere Panoramica del pilastro della sicurezza.

Usare un contesto di protezione Kubernetes per migliorare la sicurezza dei contenitori sottostanti che eseguono il file binario NiFi. Un contesto di protezione gestisce l'accesso a tali contenitori e ai relativi pod. Utilizzando un contesto di protezione, è possibile concedere agli utenti autorizzazioni non radice per eseguire i contenitori.

Altri usi dei contesti di protezione includono quanto segue.

  • Limitazione dell'accesso degli utenti basati sul sistema operativo che eseguono i contenitori.
  • Specifica dei gruppi che possono accedere ai contenitori.
  • Limitazione dell'accesso al file system.

Immagini contenitore

I contenitori Kubernetes sono le unità di base che eseguono i file binari NiFi. Per configurare un cluster NiFi, concentrarsi sull'immagine utilizzata per eseguire tali contenitori. Le opzioni disponibili per l'immagine sono due:

  • Usare l'immagine NiFi standard per eseguire il grafico NiFi. Tale immagine è fornita dalla community di Apache NiFi. Tuttavia, è necessario aggiungere un file kubectl binario ai contenitori per configurare i cluster protetti.
  • Usare un'immagine personalizzata. Se si sceglie questo approccio, tenere in considerazione i requisiti del file system. Assicurarsi che il percorso dei file binari NiFi sia corretto. Per altre informazioni sulla configurazione del file system, vedere Dockerfile nel codice sorgente di Apache NiFi.

Autori di contributi

Questo articolo viene gestito da Microsoft. Originariamente è stato scritto dai collaboratori seguenti.

Autore principale:

Per visualizzare i profili LinkedIn non pubblici, accedere a LinkedIn.

Passaggi successivi