{"id":36822,"date":"2019-10-31T22:14:01","date_gmt":"2019-10-31T19:14:01","guid":{"rendered":"https:\/\/prohoster.info\/blog\/kafka-na-kubernetes-eto-horosho\/"},"modified":"2019-10-31T22:14:01","modified_gmt":"2019-10-31T19:14:01","slug":"kafka-na-kubernetes-eto-horosho","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/kafka-na-kubernetes-eto-horosho","title":{"rendered":"Kafka no Kubernetes \u2014 isso \u00e9 bom?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Bem-vindo, Habr!<\/p>\n

Em seu tempo, fomos os primeiros a lan\u00e7ar o tema Kafka<\/a><\/noindex> e continuamos monitorar<\/a><\/noindex> a desenvolv\u00ea-lo. Em particular, achamos interessante o tema da intera\u00e7\u00e3o entre Kafka e Kubernetes<\/a><\/noindex>. Um artigo introdut\u00f3rio (e bastante cauteloso) artigo<\/a><\/noindex> sobre o assunto foi publicado no blog da Confluent em outubro do ano passado, sob a autoria de Gwen Shapiro. Hoje, queremos chamar sua aten\u00e7\u00e3o para um artigo mais recente, de abril, de Johann Gyger, que, embora tenha usado um ponto de interroga\u00e7\u00e3o no t\u00edtulo, aborda o tema de forma mais concreta, acompanhando o texto com links interessantes. Pedimos desculpas pela tradu\u00e7\u00e3o livre de \"chaos monkey\", se puderem!<\/p>\n

\"Kafka<\/a><\/noindex>
\n<\/a><\/noindex> <\/p>\n

Introdu\u00e7\u00e3o<\/h4>\n

\nO Kubernetes \u00e9 projetado para trabalhar com cargas de trabalho sem estado. Geralmente, essas cargas s\u00e3o apresentadas na forma de uma arquitetura de microsservi\u00e7os, sendo leves, bem escal\u00e1veis horizontalmente, obedecendo aos princ\u00edpios de aplicativos de 12 fatores, permitindo o uso de disjuntores autom\u00e1ticos (circuit breaker) e macacos do caos (chaos monkeys).<\/p>\n

O Kafka, por outro lado, atua essencialmente como um banco de dados distribu\u00eddo. Assim, ao trabalhar, voc\u00ea precisa lidar com o estado, que \u00e9 muito mais pesado do que um microsservi\u00e7o. O Kubernetes suporta cargas de trabalho com estado, mas, como aponta Kelsey Hightower em dois de seus tweets, deve-se ter cautela com elas:<\/p>\n

Alguns acreditam que, ao aplicar o Kubernetes em uma carga de trabalho com estado, ele se transforma em um banco de dados totalmente gerenciado capaz de competir com o RDS. Isso n\u00e3o \u00e9 verdade. Pode ser que, se esfor\u00e7ar bastante, adicionar componentes adicionais e envolver uma equipe de engenheiros SRE, seja poss\u00edvel configurar o RDS sobre o Kubernetes.<\/p><\/blockquote>\n

Sempre recomendo extrema cautela ao executar cargas de trabalho com estado no Kubernetes. A maioria daqueles que se perguntam: \"posso executar cargas de trabalho com estado no Kubernetes?\" n\u00e3o possui experi\u00eancia suficiente com Kubernetes, muitas vezes nem mesmo com a carga sobre a qual est\u00e3o perguntando.<\/p><\/blockquote>\n

Ent\u00e3o, devemos executar o Kafka no Kubernetes? Uma pergunta de retorno: ser\u00e1 que o Kafka funcionaria melhor sem o Kubernetes? \u00c9 por isso que quero enfatizar neste artigo como Kafka e Kubernetes se complementam e quais armadilhas podem surgir ao combin\u00e1-los.<\/p>\n

Tempo de Execu\u00e7\u00e3o<\/h4>\n

\nVamos falar sobre algo b\u00e1sico \u2014 o ambiente de tempo de execu\u00e7\u00e3o como um todo.<\/p>\n

Processo<\/b><\/i><\/p>\n

Os brokers do Kafka s\u00e3o convenientes ao trabalhar com CPU. O TLS pode trazer alguns custos. No entanto, os clientes do Kafka podem sobrecarregar mais a CPU se utilizarem criptografia, mas isso n\u00e3o afeta os brokers.<\/p>\n

Mem\u00f3ria<\/b><\/i><\/p>\n

Os brokers do Kafka consomem muita mem\u00f3ria. O tamanho m\u00e1ximo da heap do JVM geralmente deve ser limitado a 4-5 GB, mas voc\u00ea tamb\u00e9m precisar\u00e1 de bastante mem\u00f3ria do sistema, j\u00e1 que o Kafka utiliza muito o cache de disco. No Kubernetes, defina adequadamente os limites de recursos e as solicita\u00e7\u00f5es do cont\u00eainer.<\/p>\n

Armazenamento de dados<\/b><\/i><\/p>\n

O armazenamento de dados em cont\u00eaineres \u00e9 ef\u00eamero \u2014 os dados se perdem na reinicializa\u00e7\u00e3o. Para os dados do Kafka, voc\u00ea pode usar um volume emptyDir<\/code>, e o efeito ser\u00e1 semelhante: os dados do seu broker ser\u00e3o perdidos ap\u00f3s a finaliza\u00e7\u00e3o. Suas mensagens ainda podem ser preservadas em outros brokers como r\u00e9plicas. Portanto, ap\u00f3s a reinicializa\u00e7\u00e3o, o broker que falhou deve primeiro replicar todos os dados, e esse processo pode levar um tempo consider\u00e1vel. <\/p>\n

\u00c9 por isso que voc\u00ea deve usar um armazenamento de dados dur\u00e1vel. Deve ser um armazenamento dur\u00e1vel n\u00e3o local com sistema de arquivos XFS ou, mais precisamente, ext4. N\u00e3o use NFS. Eu avisei. NFS nas vers\u00f5es v3 ou v4 n\u00e3o funcionar\u00e1. Em resumo, o broker Kafka ir\u00e1 falhar se n\u00e3o conseguir excluir um diret\u00f3rio de dados devido a um problema de 'renomea\u00e7\u00f5es problem\u00e1ticas' que ocorre no NFS. Se ainda n\u00e3o o convenci, preste muita aten\u00e7\u00e3o leia este artigo<\/a><\/noindex>. O armazenamento de dados deve ser n\u00e3o local, para que o Kubernetes possa escolher um novo n\u00f3 com mais flexibilidade ap\u00f3s a reinicializa\u00e7\u00e3o ou realoca\u00e7\u00e3o.<\/p>\n

Rede<\/b><\/i><\/p>\n

Assim como em muitos sistemas distribu\u00eddos, o desempenho do Kafka depende muito de minimizar as lat\u00eancias da rede e maximizar a largura de banda. N\u00e3o tente colocar todos os brokers em um \u00fanico n\u00f3, pois isso reduzir\u00e1 a disponibilidade. Se um n\u00f3 do Kubernetes falhar, todo o cluster Kafka tamb\u00e9m falhar\u00e1. Da mesma forma, n\u00e3o espalhe o cluster Kafka por datacenters inteiros. O mesmo se aplica ao cluster Kubernetes. Um bom compromisso, neste caso, \u00e9 escolher diferentes zonas de disponibilidade.<\/p>\n

Configura\u00e7\u00e3o<\/h4>\n

\nManifests comuns<\/b><\/i><\/p>\n

No site do Kubernetes, h\u00e1 um \u00f3timo guia<\/a><\/noindex> sobre como configurar o ZooKeeper usando manifests. Como o ZooKeeper faz parte do Kafka, \u00e9 conveniente come\u00e7ar por aqui para entender quais conceitos do Kubernetes s\u00e3o aplic\u00e1veis. Depois de entender isso, voc\u00ea poder\u00e1 aplicar os mesmos conceitos ao cluster Kafka.<\/p>\n