Kubernetes + Helm: primeiros passos e como criar um ambiente do Apache Kafka

Renato Groffe
5 min readMay 4, 2020

--

Desenvolvedores e profissionais de DevOps estão acostumados a alternativas de gerenciamento de pacotes como NuGet e npm, soluções estas presentes sobretudo em projetos baseados em .NET e JavaScript. Mas e se contássemos também com uma opção deste tipo para a instalação de aplicações e serviços em um cluster Kubernetes?

O projeto Helm é uma resposta a esta pergunta! Através de repositórios contendo Charts (pacotes) pré-configurados, podemos nos valer do Helm para simplificar em muito o deployment e a atualização de aplicações projetadas para um cluster Kubernetes. Temos inclusive a possibilidade de criar nossos próprios pacotes, com todas as configurações necessárias para a publicação de nossas soluções.

A instalação de Charts do Helm acontece por meio de um utilitário de linha de comando (também chamado helm), o qual conta com versões para Windows, Linux e macOS. Diversos repositórios gratuitos com Charts estão disponíveis de maneira pública na Internet, facilitando assim até mesmo a instalação de ambientes para testes com diferentes tecnologias.

Neste artigo abordarei os primeiros passos na utilização do Helm, bem como a criação de um ambiente baseado no Apache Kafka a partir de um Chart já existente.

E como o assunto deste post envolve a orquestração de containers com Kubernetes, deixo aqui links de artigos que já publiquei sobre esse tema (inclui exemplos e vídeos gratuitos):

Kubernetes: dicas e truques na orquestração de containers - Parte 1

Kubernetes: dicas e truques na orquestração de containers - Parte 2

Kubernetes: dicas e truques na orquestração de containers - Parte 3

Kubernetes + Azure DevOps: build e deployment automatizado de aplicações

E aproveito este espaço para deixar aqui um convite…

Caso precise conhecer mais sobre Azure DevOps, não deixe de aproveitar o desconto de 15% para inscrições na segunda turma online do treinamento promovido pelo Azure na Prática e que acontecerá dia 23/05/2020 (um sábado). Aproveite para ficar por dentro do build e deployment automatizado de aplicações utilizando diversos serviços oferecidos pelo Microsoft Azure e, o melhor, no conforto de sua casa! Acesse o link a seguir para informações e efetuar sua inscrição: https://bit.ly/anp-devops2-blog-groffe

Helm: o gerenciador de pacotes para Kubernetes

Informações sobre como instalar o Helm em Windows, Linux ou Mac podem ser encontradas no link a seguir:

Installing Helm

Para os testes descritos neste artigo baixei a versão do Helm compatível com Windows 10 (um arquivo .zip), copiando o executável para uso em linha de comando desta solução para a pasta C:\Program Files\Helm\:

O caminho em que se encontra o executável do Helm deverá ser indicado na variável de ambiente Path. Acionar para isto as Propriedades de Sistema do Windows:

Incluindo na sequência o caminho C:\Program Files\Helm\ na variável Path:

Ao digitar no PowerShell os comandos:

helm version

E:

helm

Aparecerão a versão do Helm instalada na máquina e informações gerais sobre este utilitário de linha de comando, indicando assim que os ajustes para utilização desta ferramenta na linha de comando tiveram sucesso:

O próximo passo agora consiste em baixar um repositório com charts pré-configurados. Utilizaremos para testes o repositório bitnami, que será adicionado através da seguinte instrução:

helm repo add bitnami https://charts.bitnami.com/bitnami

Já o comando a seguir mostrará que o repositório bitnami foi adicionado localmente com sucesso:

helm repo list

Instalando um Chart do Helm: um exemplo utilizando Apache Kafka

Na sequência de instruções listadas a partir deste ponto montaremos um ambiente do Apache Kafka para testes de mensageria. Neste primeiro momento será criado no cluster Kubernetes um namespace chamado groffe-testes-kafka, ao qual estarão vinculadas as estruturas do ambiente baseado no Apache Kafka:

kubectl create namespace groffe-testes-kafka

Já o próximo comando (helm install) possibilitará a instalação do Chart com o ambiente do Kafka a partir do repositório da Bitnami adicionado na seção anterior:

  • Logo após helm install está o nome com o qual o Chart será instalado (groffe-broker-kafka);
  • No parâmetro --set foram definidas configurações para instalação do Chart, incluindo o uso de um Load Balancer e o acesso ao Apache Kafka acontecendo na porta 19092. Maiores informações sobre a configuração desse Chart podem ser encontradas neste link;
  • Quanto ao parâmetro -n, estamos indicando que todas as estruturas previstas para o Chart serão criadas no namespace groffe-testes-kafka no cluster Kubernetes;
  • Todos estes procedimentos do exemplo aqui detalhado ocorrerão em um cluster do AKS (Azure Kubernetes Service).
helm install groffe-broker-kafka --set externalAccess.enabled=true,externalAccess.service.type=LoadBalancer,externalAccess.service.port=19092,externalAccess.autoDiscovery.enabled=true,serviceAccount.create=true,rbac.create=true bitnami/kafka -n groffe-testes-kafka

Com as instruções abaixo:

kubectl get pods -n groffe-testes-kafkakubectl get services -n groffe-testes-kafka

Serão listados os Pods e outros objetos (incluindo o Load Balancer) do ambiente baseado no Apache Kafka, com tais estruturas vinculadas ao namespace groffe-testes-kafka:

Os projetos a seguir (criados em .NET Core 3.1) exemplificam o envio e consumo de mensagens a um tópico do Kafka:

.NET Core 3.1 + Console Application + Apache Kafka + Confluent.Kafka + Producer

.NET Core 3.1 + Console Application + Apache Kafka + Confluent.Kafka + Consumer

Considerando o IP do Load Balancer e a porta 19092 na execução de tais projetos veremos que o ambiente do Apache Kafka está funcionando normalmente:

Maiores detalhes sobre o uso do Apache Kafka com .NET Core podem ser encontrados no artigo:

.NET Core 3.1 + Apache Kafka: exemplos utilizando mensageria

--

--

Renato Groffe
Renato Groffe

Written by Renato Groffe

Microsoft Most Valuable Professional (MVP), Multi-Plataform Technical Audience Contributor (MTAC), Software Engineer, Technical Writer and Speaker

Responses (2)