Redigera

Dela via

Helm-baserade distributioner för Apache NiFi

Azure Kubernetes Service (AKS)

Den här lösningen visar hur du använder Helm-diagram när du distribuerar NiFi på Azure Kubernetes Service (AKS). Helm effektiviserar processen med att installera och hantera Kubernetes-program.

Apache®, Apache NiFi® och NiFi® är antingen registrerade varumärken eller varumärken som tillhör Apache Software Foundation i USA och/eller andra länder. Inget godkännande från Apache Software Foundation underförstås av användningen av dessa märken.

Arkitektur

Diagram som visar hur en användare konfigurerar ett Helm-diagram för att distribuera ett program på Kubernetes. Komponenterna omfattar poddar och volymer som Kubernetes skapar.

Ladda ned en Visio-fil med den här arkitekturen.

Arbetsflöde

  • Ett Helm-diagram innehåller en values.yaml fil. Den filen visar indatavärden som användarna kan redigera.

  • En användare justerar inställningarna i ett diagram, inklusive värden för:

    • Volymstorlekar.
    • Antalet poddar.
    • Mekanismer för användarautentisering och auktorisering.

  • Användaren kör Helm-kommandot install för att distribuera diagrammet.

  • Helm kontrollerar om användarindata innehåller värden för alla obligatoriska variabler.

  • Helm skapar ett manifest som beskriver de objekt som ska distribueras på Kubernetes.

  • Helm skickar manifestet till Kubernetes-klustret. Apache ZooKeeper tillhandahåller klustersamordning.

  • Kubernetes skapar de angivna objekten. En NiFi-distribution kräver följande objekt:

    • Konfigurationsobjekt.
    • Datavolymer. Poddlagring är tillfälligt.
    • En loggvolym.
    • Poddar som använder en avbildning för att köra NiFi i en container. Kubernetes använder en StatefulSet-arbetsbelastningsresurs för att hantera poddarna.
    • En Kubernetes-tjänst som gör NiFi-användargränssnittet tillgängligt för användare.
    • Inkommande vägar om klustret använder ingress för att göra användargränssnittet tillgängligt externt.

Komponenter

Ett Helm-diagram är en samling filer i en mapp med en trädstruktur. Dessa filer beskriver Kubernetes-resurser. Du kan konfigurera följande komponenter i ett Helm-diagram:

ZooKeeper

ZooKeeper använder ett separat diagram. Du kan använda det ZooKeeper-standarddiagram som Kubernetes tillhandahåller i dess inkubatordiagramlagringsplats. Men när dina beroenden inkluderar offentligt registerinnehåll medför du risker i arbetsflödena för avbildningsutveckling och distribution. För att minska den här risken behåller du lokala kopior av offentligt innehåll när du kan. Detaljerad information finns i Hantera offentligt innehåll med Azure Container Registry.

Som ett alternativ kan du distribuera ZooKeeper på egen hand. Om du väljer det här alternativet anger du ZooKeeper-servern och portnumret så att poddarna som kör NiFi kan komma åt ZooKeeper-tjänsten.

Kubernetes StatefulSet

Om du vill köra ett program på Kubernetes kör du en podd. Den här grundläggande enheten kör olika containrar som implementerar programmets olika aktiviteter.

Kubernetes erbjuder två lösningar för att hantera poddar som kör ett program som NiFi:

  • En ReplicaSet, som upprätthåller en stabil uppsättning replikpoddar som körs vid en viss tidpunkt. Du använder ofta en ReplicaSet för att garantera tillgängligheten för ett angivet antal identiska poddar.
  • En StatefulSet, som är det arbetsbelastnings-API-objekt som du använder för att hantera tillståndskänsliga program. En StatefulSet hanterar poddar som baseras på en identisk containerspecifikation. Kubernetes skapar dessa poddar från samma specifikation. Men de här poddarna är inte utbytbara. Varje podd har en beständig identifierare som den underhåller över omplanering.

Eftersom du använder NiFi för att hantera data är en StatefulSet den bästa lösningen för NiFi-distributioner.

ConfigMaps

Kubernetes erbjuder ConfigMaps för lagring av icke-konfidentiella data. Kubernetes använder dessa objekt för att hantera olika konfigurationsfiler som nifi.properties. Containern som kör programmet kommer åt konfigurationsinformationen via monterade volymer och filer. ConfigMaps gör det enkelt att hantera konfigurationsändringar efter distributionen.

ServiceAccount

I skyddade instanser använder NiFi autentisering och auktorisering. NiFi hanterar den här informationen i filsystemfiler. Mer specifikt måste varje klusternod underhålla en authorizations.xml fil och en users.xml fil. Alla medlemmar måste kunna skriva till dessa filer. Och varje nod i klustret måste ha en identisk kopia av den här informationen. Annars blir klustret osynkroniserat och bryts ned.

För att uppfylla dessa villkor kan du kopiera dessa filer från den första medlemmen i klustret till varje medlem som finns. Varje ny medlem behåller sedan sina egna kopior. Poddar har vanligtvis inte behörighet att kopiera innehåll från en annan podd. Men en Kubernetes ServiceAccount är ett sätt att få auktorisering.

Tjänster

Kubernetes-tjänster gör programtjänsten tillgänglig för användare av Kubernetes-klustret. Tjänstobjekt gör det också möjligt för medlemsnoder i NiFi-kluster att kommunicera med varandra. För Helm-diagramdistributioner använder du två tjänsttyper: huvudlösa tjänster och IP-baserade tjänster.

Ingress

En ingress hanterar extern åtkomst till klustertjänster. Mer specifikt exponerar en förkonfigurerad ingresskontrollant HTTP- och HTTPS-vägar utanför klustret för tjänster i klustret. Du kan definiera ingressregler som avgör hur kontrollanten dirigerar trafiken. Helm-diagrammet innehåller ingressvägen i konfigurationen.

Hemligheter

För att konfigurera skyddade NiFi-kluster måste du lagra autentiseringsuppgifter. Kubernetes-hemligheter är ett säkert sätt att lagra och hämta dessa autentiseringsuppgifter.

Information om scenario

Apache NiFi-användare behöver ofta distribuera NiFi på Kubernetes. En Kubernetes-distribution omfattar många objekt, till exempel poddar, volymer och tjänster. Det är svårt att hantera de manifest eller specifikationsfiler som Kubernetes använder för det här antalet objekt. Svårigheten ökar när du distribuerar flera NiFi-kluster som använder olika konfigurationer.

Helm-diagram tillhandahåller en lösning för att hantera manifesten. Helm är pakethanterare för Kubernetes. Genom att använda Helm-verktyget kan du effektivisera processen med att installera och hantera Kubernetes-program.

Ett diagram är det paketeringsformat som Helm använder. Du anger konfigurationskrav i diagramfiler. Helm håller reda på varje diagrams historik och versioner. Helm använder sedan diagram för att generera Kubernetes-manifestfiler.

Från ett enda diagram kan du distribuera program som använder olika konfigurationer. När du kör NiFi i Azure kan du använda Helm-diagram för att distribuera olika NiFi-konfigurationer på Kubernetes.

Apache®, Apache NiFi® och NiFi® är antingen registrerade varumärken eller varumärken som tillhör Apache Software Foundation i USA och/eller andra länder. Inget godkännande från Apache Software Foundation underförstås av användningen av dessa märken.

Att tänka på

Dessa överväganden implementerar grundpelarna i Azure Well-Architected Framework, som är en uppsättning vägledande grundsatser som kan användas för att förbättra kvaliteten på en arbetsbelastning. Mer information finns i Microsoft Azure Well-Architected Framework.

Datadiskar

För diskanvändning bör du överväga att använda en randig uppsättning diskar för lagringsplatser. I testdistributioner som använde VM-skalningsuppsättningar fungerade den här metoden bäst. Följande utdrag visar nifi.properties en diskanvändningskonfiguration:

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

Den här konfigurationen använder tre volymer med samma storlek. Du kan justera värdena och remsan för att uppfylla systemkraven.

Distributionsscenarier

Du kan använda en offentlig eller privat lastbalanserare eller en ingresskontrollant för att exponera ett NiFi-kluster. När du använder Helm-diagram för den här implementeringen är två konfigurationer tillgängliga:

  • Ett oskyddat NiFi-kluster som är tillgängligt via en HTTP-URL utan användarautentisering eller auktorisering.
  • Ett skyddat NiFi-kluster som är tillgängligt via en HTTPS-URL. Den här typen av kluster skyddas med TLS. När du konfigurerar skyddade kluster kan du ange egna certifikat. Alternativt kan diagrammen generera certifikaten. För detta ändamål använder diagrammen en NiFi-verktygslåda som tillhandahåller en självsignerad certifikatutfärdare (CA).

Om du konfigurerar ett NiFi-kluster så att det körs som ett skyddat kluster med TLS-kommunikation måste du aktivera användarautentisering. Använd någon av följande metoder för användarautentisering som stöds:

  • Certifikatbaserad användarautentisering. Användarna autentiseras av certifikatet som de presenterar för NiFi-användargränssnittet. Om du vill använda den här typen av användarautentiseringssystem lägger du till certifikatutfärdarcertifikatets offentliga certifikat i NiFi-distributionen.
  • LDAP-baserad användarautentisering. En LDAP-server autentiserar användarautentiseringsuppgifter. När du distribuerar diagrammet anger du information om LDAP-servern och informationsträdet.
  • OpenID-baserad användarautentisering. Användarna tillhandahåller information till OpenID-servern för att konfigurera distributionen.

Resurskonfiguration och -användning

Om du vill optimera resursanvändningen använder du dessa Helm-alternativ för att konfigurera cpu- och minnesvärden:

  • Alternativet request , som anger den initiala mängden av resursen som containerbegäranden
  • Alternativet limit , som anger den maximala mängden av den resurs som containern kan använda

När du konfigurerar NiFi bör du överväga systemets minneskonfiguration. Eftersom NiFi är ett Java-program bör du justera inställningar som minsta och högsta java-minne (JVM). Använd följande inställningar:

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

Säkerhet

Säkerhet ger garantier mot avsiktliga attacker och missbruk av dina värdefulla data och system. Mer information finns i Översikt över säkerhetspelare.

Använd en Kubernetes-säkerhetskontext för att förbättra säkerheten för de underliggande containrar som kör NiFi-binärfilen. En säkerhetskontext hanterar åtkomsten till dessa containrar och deras poddar. Via en säkerhetskontext kan du bevilja icke-rotanvändare behörighet att köra containrarna.

Andra användningar av säkerhetskontexter är:

  • Begränsa åtkomsten för OS-baserade användare som kör containrarna.
  • Ange vilka grupper som kan komma åt containrarna.
  • Begränsa åtkomsten till filsystemet.

Containeravbildningar

Kubernetes-containrar är de grundläggande enheter som kör NiFi-binärfiler. Om du vill konfigurera ett NiFi-kluster fokuserar du på den avbildning som du använder för att köra dessa containrar. Du har två alternativ för den här bilden:

  • Använd nifi-standardbilden för att köra NiFi-diagrammet. Apache NiFi-communityn tillhandahåller den avbildningen. Men du måste lägga till en kubectl binär fil i containrarna för att konfigurera skyddade kluster.
  • Använd en anpassad avbildning. Om du använder den här metoden bör du överväga dina filsystemkrav. Kontrollera att nifi-binärfilernas plats är korrekt. Mer information om det konfigurerade filsystemet finns i Dockerfile i Apache NiFi-källkoden.

Deltagare

Den här artikeln underhålls av Microsoft. Det har ursprungligen skrivits av följande medarbetare.

Huvudförfattare:

Om du vill se icke-offentliga LinkedIn-profiler loggar du in på LinkedIn.

Nästa steg