Esta solução mostra como usar gráficos Helm ao implantar o NiFi no Serviço Kubernetes do Azure (AKS). O Helm simplifica o processo de instalação e gerenciamento de aplicativos Kubernetes.
Apache®, Apache NiFi® e NiFi® são marcas registadas ou marcas comerciais da Apache Software Foundation nos Estados Unidos e/ou noutros países. Nenhum endosso da Apache Software Foundation está implícito no uso dessas marcas.
Arquitetura
Transfira um ficheiro do Visio desta arquitetura.
Fluxo de Trabalho
Um gráfico Helm contém um
values.yaml
arquivo. Esse arquivo lista os valores de entrada que os usuários podem editar.Um usuário ajusta as configurações em um gráfico, incluindo valores para:
- Tamanhos de volume.
- O número de vagens.
- Mecanismos de autenticação e autorização do utilizador.
O usuário executa o comando Helm
install
para implantar o gráfico.O Helm verifica se a entrada do usuário contém valores para todas as variáveis necessárias.
Helm cria um manifesto que descreve os objetos a serem implantados no Kubernetes.
Helm envia o manifesto para o cluster Kubernetes. O Apache ZooKeeper fornece coordenação de cluster.
O Kubernetes cria os objetos especificados. Uma implantação NiFi requer estes objetos:
- Objetos de configuração.
- Volumes de dados. O armazenamento de cápsulas é temporário.
- Um volume de log.
- Pods que usam uma imagem para executar NiFi em um contêiner. O Kubernetes usa um recurso de carga de trabalho StatefulSet para gerenciar os pods.
- Um serviço Kubernetes que disponibiliza a interface do usuário NiFi para os usuários.
- Rotas de entrada se o cluster usar a entrada para disponibilizar a interface do usuário externamente.
Componentes
Um gráfico Helm é uma coleção de arquivos em uma pasta com uma estrutura de árvore. Esses arquivos descrevem os recursos do Kubernetes. Você pode configurar os seguintes componentes em um gráfico de leme:
ZooKeeper
O ZooKeeper usa um gráfico separado. Você pode usar o gráfico padrão do ZooKeeper que o Kubernetes fornece em seu repositório de gráficos de incubadora. Mas quando suas dependências incluem conteúdo de registro público, você introduz risco em seus fluxos de trabalho de desenvolvimento e implantação de imagens. Para reduzir esse risco, mantenha cópias locais do conteúdo público sempre que possível. Para obter informações detalhadas, consulte Gerenciar conteúdo público com o Registro de Contêiner do Azure.
Como alternativa, você pode implantar o ZooKeeper por conta própria. Se você escolher essa opção, forneça o servidor e o número da porta do ZooKeeper para que os pods que executam o NiFi possam acessar o serviço do ZooKeeper.
Kubernetes StatefulSet
Para executar um aplicativo no Kubernetes, execute um pod. Esta unidade básica executa diferentes contêineres que implementam as diferentes atividades do aplicativo.
O Kubernetes oferece duas soluções para gerenciar pods que executam um aplicativo como o NiFi:
- Um ReplicaSet, que mantém um conjunto estável de pods de réplica que são executados a qualquer momento. Você costuma usar um ReplicaSet para garantir a disponibilidade de um número especificado de pods idênticos.
- Um StatefulSet, que é o objeto de API de carga de trabalho que você usa para gerenciar aplicativos com monitoração de estado. Um StatefulSet gerencia pods baseados em uma especificação de contêiner idêntica. O Kubernetes cria esses pods a partir da mesma especificação. Mas esses pods não são intercambiáveis. Cada pod tem um identificador persistente que mantém durante a reprogramação.
Como você usa NiFi para gerenciar dados, um StatefulSet fornece a melhor solução para implantações NiFi.
ConfigMaps
O Kubernetes oferece ConfigMaps para armazenar dados não confidenciais. O Kubernetes usa esses objetos para gerenciar vários arquivos de configuração, como nifi.properties
o . O contêiner que executa o aplicativo acessa as informações de configuração por meio de volumes e arquivos montados. O ConfigMaps facilita o gerenciamento de alterações de configuração pós-implantação.
ServiceAccount
Em instâncias seguras, o NiFi usa autenticação e autorização. O NiFi gerencia essas informações em arquivos do sistema de arquivos. Especificamente, cada nó de cluster precisa manter um authorizations.xml
arquivo e um users.xml
arquivo. Todos os membros precisam ser capazes de gravar nesses arquivos. E cada nó no cluster precisa ter uma cópia idêntica dessas informações. Caso contrário, o cluster fica fora de sincronia e quebra.
Para atender a essas condições, você pode copiar esses arquivos do primeiro membro do cluster para cada membro que venha a existir. Cada novo membro mantém então as suas próprias cópias. Os pods geralmente não têm autorização para copiar conteúdo de outro pod. Mas uma ServiceAccount do Kubernetes fornece uma maneira de obter autorização.
Serviços
Os serviços do Kubernetes disponibilizam o serviço de aplicativo para os usuários do cluster Kubernetes. Os objetos de serviço também possibilitam que os nós membros de clusters NiFi se comuniquem entre si. Para implantações de gráficos Helm, use dois tipos de serviço: serviços sem cabeça e serviços baseados em IP.
Entrada
Uma entrada gerencia o acesso externo aos serviços de cluster. Especificamente, um controlador de entrada pré-configurado expõe rotas HTTP e HTTPS de fora do cluster para serviços dentro do cluster. Você pode definir regras de entrada que determinam como o controlador roteia o tráfego. O gráfico Helm inclui a rota de entrada na configuração.
Segredos
Para configurar clusters NiFi seguros, você precisa armazenar credenciais. Os segredos do Kubernetes fornecem uma maneira segura de armazenar e recuperar essas credenciais.
Detalhes do cenário
Os usuários do Apache NiFi geralmente precisam implantar o NiFi no Kubernetes. Uma implantação do Kubernetes envolve muitos objetos, como pods, volumes e serviços. É difícil gerenciar os manifestos, ou arquivos de especificação, que o Kubernetes usa para esse número de objetos. A dificuldade aumenta quando você implanta vários clusters NiFi que usam configurações diferentes.
Os gráficos de leme fornecem uma solução para gerenciar os manifestos. Helm é o gerenciador de pacotes do Kubernetes. Usando a ferramenta Helm, você pode simplificar o processo de instalação e gerenciamento de aplicativos Kubernetes.
Um gráfico é o formato de empacotamento que Helm usa. Você insere os requisitos de configuração em arquivos de gráfico. Helm acompanha o histórico e as versões de cada gráfico. Em seguida, Helm usa gráficos para gerar arquivos de manifesto do Kubernetes.
A partir de um único gráfico, você pode implantar aplicativos que usam configurações diferentes. Ao executar o NiFi no Azure, você pode usar gráficos Helm para implantar diferentes configurações de NiFi no Kubernetes.
Apache®, Apache NiFi® e NiFi® são marcas registadas ou marcas comerciais da Apache Software Foundation nos Estados Unidos e/ou noutros países. Nenhum endosso da Apache Software Foundation está implícito no uso dessas marcas.
Considerações
Essas considerações implementam os pilares do Azure Well-Architected Framework, que é um conjunto de princípios orientadores que podem ser usados para melhorar a qualidade de uma carga de trabalho. Para obter mais informações, consulte Microsoft Azure Well-Architected Framework.
Discos de dados
Para uso de disco, considere o uso de um conjunto distribuído de discos para repositórios. Em implantações de teste que usavam Conjuntos de Dimensionamento de Máquina Virtual, essa abordagem funcionou melhor. O trecho a seguir mostra uma configuração de uso de nifi.properties
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
Esta configuração usa três volumes de tamanho igual. Você pode ajustar os valores e o striping para atender aos requisitos do sistema.
Cenários de implementação
Você pode usar um balanceador de carga público ou privado ou um controlador de entrada para expor um cluster NiFi. Quando você usa gráficos Helm para essa implementação, duas configurações estão disponíveis:
- Um cluster NiFi não seguro que é acessível através de um URL HTTP sem autenticação ou autorização do usuário.
- Um cluster NiFi seguro que pode ser acessado por meio de uma URL HTTPS. Esse tipo de cluster é protegido com TLS. Ao configurar clusters seguros, você pode fornecer seus próprios certificados. Como alternativa, os gráficos podem gerar os certificados. Para isso, os gráficos usam um kit de ferramentas NiFi que fornece uma Autoridade de Certificação (CA) autoassinada.
Se você configurar um cluster NiFi para ser executado como um cluster seguro com comunicação TLS, precisará ativar a autenticação do usuário. Use um dos seguintes métodos de autenticação de usuário suportados:
- Autenticação de usuário baseada em certificado. Os usuários são autenticados pelo certificado que apresentam à interface do usuário NiFi. Para usar esse tipo de sistema de autenticação de usuário, adicione o certificado público da CA à implantação do NiFi.
- Autenticação de usuário baseada em LDAP. Um servidor LDAP autentica as credenciais do usuário. Ao implantar o gráfico, forneça informações sobre o servidor LDAP e a árvore de informações.
- Autenticação de usuário baseada em OpenID. Os usuários fornecem informações ao servidor OpenID para configurar a implantação.
Configuração e utilização de recursos
Para otimizar o uso de recursos, use estas opções de Helm para configurar valores de CPU e memória:
- A
request
opção, que especifica a quantidade inicial do recurso que o contêiner solicita - A
limit
opção, que especifica a quantidade máxima do recurso que o contêiner pode usar
Ao configurar o NiFi, considere a configuração de memória do seu sistema. Como o NiFi é uma aplicação Java, você deve ajustar configurações como os valores mínimos e máximos de memória da máquina virtual java (JVM). Utilize as seguintes definições:
jvmMinMemory
jvmMaxMemory
g1ReservePercent
conGcThreads
parallelGcThreads
initiatingHeapOccupancyPercent
Segurança
A segurança oferece garantias contra ataques deliberados e o abuso de seus valiosos dados e sistemas. Para obter mais informações, consulte Visão geral do pilar de segurança.
Use um contexto de segurança do Kubernetes para melhorar a segurança dos contêineres subjacentes que executam o binário NiFi. Um contexto de segurança gerencia o acesso a esses contêineres e seus pods. Por meio de um contexto de segurança, você pode conceder permissões a usuários não raiz para executar os contêineres.
Outros usos de contextos de segurança incluem:
- Restringir o acesso de usuários baseados em SO que executam os contêineres.
- Especificando quais grupos podem acessar os contêineres.
- Limitar o acesso ao sistema de arquivos.
Imagens de contentor
Os contêineres Kubernetes são as unidades básicas que executam binários NiFi. Para configurar um cluster NiFi, concentre-se na imagem que você usa para executar esses contêineres. Você tem duas opções para esta imagem:
- Use a imagem NiFi padrão para executar o gráfico NiFi. A comunidade Apache NiFi fornece essa imagem. Mas você precisa adicionar um
kubectl
binário aos contêineres para configurar clusters seguros. - Use uma imagem personalizada. Se você adotar essa abordagem, considere os requisitos do sistema de arquivos. Certifique-se de que a localização dos seus binários NiFi está correta. Para obter mais informações sobre o sistema de arquivos configurado, consulte Dockerfile no código-fonte Apache NiFi.
Contribuidores
Este artigo é mantido pela Microsoft. Foi originalmente escrito pelos seguintes contribuidores.
Autor principal:
- Muazma Zahid - Brasil | Gestor Principal PM
Para ver perfis não públicos do LinkedIn, inicie sessão no LinkedIn.
Próximos passos
- Helm
- Gráficos Helm
- Kubernetes
- Kubernetes StatefulSets
- Kubernetes Volumes
- Kubernetes ConfigMaps
- Segredos do Kubernetes
- Serviço Kubernetes
- Ingresso no Kubernetes
- Azure Kubernetes Service
- Imagem do Apache NiFi Docker