Kafka no Kubernetes é bom?

Saudações, Habr!

Ao mesmo tempo, fomos os primeiros a apresentar o tema ao mercado russo Kafka E continue seguir para o seu desenvolvimento. Em particular, encontramos o tema da interação entre Kafka e Kubernetes. Observável (e bastante cuidadoso) artigo este tópico foi publicado no blog Confluent em outubro do ano passado sob a autoria de Gwen Shapira. Hoje gostaríamos de chamar a atenção para um artigo mais recente, de abril, de Johann Gyger, que, embora não sem um ponto de interrogação no título, examina o tema de forma mais substantiva, acompanhando o texto com links interessantes. Por favor, perdoe-nos a tradução gratuita de “macaco do caos”, se puder!

Introdução

O Kubernetes foi projetado para lidar com cargas de trabalho sem estado. Normalmente, essas cargas de trabalho são apresentadas na forma de uma arquitetura de microsserviços, são leves, têm boa escalabilidade horizontal, seguem os princípios de aplicativos de 12 fatores e podem funcionar com disjuntores e macacos do caos.

O Kafka, por outro lado, atua essencialmente como um banco de dados distribuído. Assim, ao trabalhar, você tem que lidar com estado, e é muito mais pesado que um microsserviço. Kubernetes oferece suporte a cargas com estado, mas como Kelsey Hightower aponta em dois tweets, elas devem ser tratadas com cuidado:

Algumas pessoas acham que se você transformar o Kubernetes em uma carga de trabalho com estado, ele se tornará um banco de dados totalmente gerenciado que rivaliza com o RDS. Isto está errado. Talvez, se você trabalhar duro o suficiente, adicionar componentes adicionais e atrair uma equipe de engenheiros de SRE, você consiga construir RDS em cima do Kubernetes.

Sempre recomendo que todos tenham extremo cuidado ao executar cargas de trabalho com estado no Kubernetes. A maioria das pessoas que perguntam “posso executar cargas de trabalho com estado no Kubernetes” não tem experiência suficiente com o Kubernetes e, muitas vezes, com a carga de trabalho sobre a qual estão perguntando.

Então, você deveria executar o Kafka no Kubernetes? Contra-pergunta: o Kafka funcionará melhor sem o Kubernetes? É por isso que quero destacar neste artigo como Kafka e Kubernetes se complementam e quais armadilhas podem surgir ao combiná-los.

Tempo de conclusão

Vamos falar sobre o básico - o próprio ambiente de execução

processo

Os corretores Kafka são compatíveis com CPU. O TLS pode introduzir alguma sobrecarga. No entanto, os clientes Kafka podem consumir mais CPU se usarem criptografia, mas isso não afeta os corretores.

Память

Os corretores Kafka consomem memória. O tamanho de heap da JVM geralmente é limitado a 4-5 GB, mas você também precisará de muita memória do sistema, pois o Kafka usa muito o cache de páginas. No Kubernetes, defina recursos de contêiner e solicite limites de acordo.

Data warehouse

O armazenamento de dados em contêineres é efêmero – os dados são perdidos quando reiniciados. Para dados Kafka você pode usar um volume emptyDir, e o efeito será semelhante: os dados do seu corretor serão perdidos após a conclusão. Suas mensagens ainda podem ser armazenadas em outros corretores como réplicas. Portanto, após uma reinicialização, o broker com falha deve primeiro replicar todos os dados e esse processo pode levar muito tempo.

É por isso que você deve usar armazenamento de dados de longo prazo. Que seja um armazenamento não local de longo prazo com o sistema de arquivos XFS ou, mais precisamente, ext4. Não use NFS. Eu te avisei. As versões NFS v3 ou v4 não funcionarão. Resumindo, o corretor Kafka irá travar se não conseguir excluir o diretório de dados devido ao problema de “renomeação estúpida” no NFS. Se ainda não te convenci, com muito cuidado leia este artigo. O armazenamento de dados não deve ser local para que o Kubernetes possa escolher com mais flexibilidade um novo nó após uma reinicialização ou realocação.

Сеть

Tal como acontece com a maioria dos sistemas distribuídos, o desempenho do Kafka é altamente dependente de manter a latência da rede no mínimo e a largura de banda no máximo. Não tente hospedar todos os corretores no mesmo nó, pois isso reduzirá a disponibilidade. Se um nó do Kubernetes falhar, todo o cluster Kafka falhará. Além disso, não disperse o cluster Kafka por data centers inteiros. O mesmo vale para o cluster Kubernetes. Um bom compromisso neste caso é escolher diferentes zonas de disponibilidade.

Configuração

Manifestos regulares

O site do Kubernetes tem guia muito bom sobre como configurar o ZooKeeper usando manifestos. Como o ZooKeeper faz parte do Kafka, este é um bom lugar para começar a se familiarizar com os conceitos do Kubernetes que se aplicam aqui. Depois de entender isso, você poderá usar os mesmos conceitos com um cluster Kafka.

• Em: um pod é a menor unidade implantável no Kubernetes. Um pod contém sua carga de trabalho e o próprio pod corresponde a um processo em seu cluster. Um pod contém um ou mais contêineres. Cada servidor ZooKeeper no conjunto e cada corretor no cluster Kafka serão executados em um pod separado.
• StatefulSet: um StatefulSet é um objeto do Kubernetes que lida com diversas cargas de trabalho com estado, e essas cargas de trabalho exigem coordenação. StatefulSets fornecem garantias quanto ao pedido dos pods e sua exclusividade.
• Serviços sem cabeça: os serviços permitem separar pods de clientes usando um nome lógico. O Kubernetes, neste caso, é responsável pelo balanceamento de carga. No entanto, ao operar cargas de trabalho com estado, como ZooKeeper e Kafka, os clientes precisam se comunicar com uma instância específica. É aqui que os serviços headless são úteis: nesse caso, o cliente ainda terá um nome lógico, mas você não precisará entrar em contato diretamente com o pod.
• Volume de armazenamento de longo prazo: Esses volumes são necessários para configurar o armazenamento persistente de bloco não local mencionado acima.

На Yolean Fornece um conjunto abrangente de manifestos para ajudar você a começar a usar o Kafka no Kubernetes.

Gráficos do Helm

Helm é um gerenciador de pacotes para Kubernetes que pode ser comparado a gerenciadores de pacotes de sistemas operacionais como yum, apt, Homebrew ou Chocolatey. Facilita a instalação de pacotes de software predefinidos descritos nos gráficos do Helm. Um gráfico Helm bem escolhido facilita a difícil tarefa de configurar corretamente todos os parâmetros para usar o Kafka no Kubernetes. Existem vários diagramas Kafka: o oficial está localizado em estado de incubadora, há um de Junção, mais um - de BitNami.

operadores

Como o Helm tem algumas deficiências, outra ferramenta está ganhando popularidade considerável: os operadores Kubernetes. A operadora não apenas empacota software para Kubernetes, mas também permite implantar esse software e gerenciá-lo.

a lista operadores incríveis Dois operadores para Kafka são mencionados. Um deles - Strimzi. Com Strimzi, é fácil colocar seu cluster Kafka em funcionamento em minutos. Praticamente nenhuma configuração é necessária, além disso, o próprio operador fornece alguns recursos interessantes, por exemplo, criptografia TLS ponto a ponto dentro do cluster. Confluent também fornece operador próprio.

Desempenho

É importante testar o desempenho comparando sua instância do Kafka. Esses testes ajudarão você a encontrar possíveis gargalos antes que os problemas ocorram. Felizmente, o Kafka já oferece duas ferramentas de teste de desempenho: kafka-producer-perf-test.sh и kafka-consumer-perf-test.sh. Faça uso ativo deles. Para referência, você pode consultar os resultados descritos em esta postagem Jay Kreps, ou foco em esta revisão Amazon MSK por Stéphane Maarek.

operações

Monitoramento

A transparência no sistema é muito importante - caso contrário você não entenderá o que está acontecendo nele. Hoje existe um kit de ferramentas sólido que fornece monitoramento baseado em métricas no estilo nativo da nuvem. Duas ferramentas populares para essa finalidade são Prometheus e Grafana. O Prometheus pode coletar métricas de todos os processos Java (Kafka, Zookeeper, Kafka Connect) usando um exportador JMX - da maneira mais simples. Se você adicionar métricas do cAdvisor, poderá entender melhor como os recursos são usados ​​no Kubernetes.

Strimzi tem um exemplo muito conveniente de painel Grafana para Kafka. Ele visualiza as principais métricas, por exemplo, sobre setores sub-replicados ou que estão off-line. Tudo está muito claro aí. Estas métricas são complementadas por informações sobre utilização de recursos e desempenho, bem como indicadores de estabilidade. Assim, você obtém monitoramento básico de cluster Kafka de graça!

Fonte: streamzi.io/docs/master/#kafka_dashboard

Seria bom complementar tudo isso com monitoramento de clientes (métricas de consumidores e produtores), bem como monitoramento de latência (para isso existe Toca) e monitoramento ponta a ponta - para esse uso Monitor Kafka.

Exploração madeireira

O registro é outra tarefa crítica. Certifique-se de que todos os contêineres em sua instalação do Kafka estejam registrados stdout и stderre também garantir que seu cluster Kubernetes agregue todos os logs em uma infraestrutura de log central, por exemplo. ElasticSearch.

Testes Funcionais

O Kubernetes usa testes de atividade e prontidão para verificar se seus pods estão funcionando normalmente. Se a verificação de atividade falhar, o Kubernetes interromperá esse contêiner e o reiniciará automaticamente se a política de reinicialização estiver definida de acordo. Se a verificação de prontidão falhar, o Kubernetes isolará o pod das solicitações de serviço. Assim, nesses casos, a intervenção manual deixa de ser necessária, o que é uma grande vantagem.

Lançando atualizações

StatefulSets suporta atualizações automáticas: se você selecionar a estratégia RollingUpdate, cada um no Kafka será atualizado por vez. Desta forma, o tempo de inatividade pode ser reduzido a zero.

Escala

Dimensionar um cluster Kafka não é uma tarefa fácil. No entanto, o Kubernetes torna muito fácil escalar pods para um determinado número de réplicas, o que significa que você pode definir declarativamente quantos corretores Kafka desejar. O mais difícil neste caso é reatribuir setores após o aumento ou antes da redução. Novamente, o Kubernetes irá ajudá-lo nessa tarefa.

administração

As tarefas relacionadas à administração do cluster Kafka, como a criação de tópicos e a reatribuição de setores, podem ser realizadas usando scripts de shell existentes abrindo a interface de linha de comando em seus pods. Porém, esta solução não é muito bonita. Strimzi oferece suporte ao gerenciamento de tópicos usando um operador diferente. Há algum espaço para melhorias aqui.

Restaurar e recuperar

Agora a disponibilidade do Kafka também dependerá da disponibilidade do Kubernetes. Se o seu cluster Kubernetes falhar, na pior das hipóteses, o seu cluster Kafka também falhará. De acordo com a lei de Murphy, isso definitivamente acontecerá e você perderá dados. Para reduzir esse tipo de risco, tenha um bom conceito de backup. Você pode usar o MirrorMaker, outra opção é usar o S3 para isso, conforme descrito neste publicar de Zalando.

Conclusão

Ao trabalhar com clusters Kafka de pequeno e médio porte, definitivamente vale a pena usar o Kubernetes, pois ele fornece flexibilidade adicional e simplifica a experiência do operador. Se você tiver requisitos de latência e/ou taxa de transferência não funcionais muito significativos, talvez seja melhor considerar alguma outra opção de implantação.

Fonte: habr.com