É bo Kafka en Kubernetes?

Saúdos, Habr!

Nun tempo, fomos os primeiros en introducir o tema no mercado ruso Kafka e continúa pista para o seu desenvolvemento. En particular, atopamos o tema da interacción entre Kafka e Kubernetes. Observable (e bastante coidadoso) artigo este tema publicouse no blog Confluent alá por outubro do ano pasado baixo a autoría de Gwen Shapira. Hoxe queremos chamar a vosa atención sobre un artigo máis recente de abril de Johann Gyger, quen, aínda que non sen signo de interrogación no título, examina o tema dun xeito máis substantivo, acompañando o texto de interesantes ligazóns. Por favor, perdóanos a tradución gratuíta de "mono do caos" se podes!

Introdución

Kubernetes está deseñado para xestionar cargas de traballo sen estado. Normalmente, tales cargas de traballo preséntanse en forma de arquitectura de microservizos, son lixeiras, escalan ben horizontalmente, seguen os principios das aplicacións de 12 factores e poden funcionar con interruptores e monos do caos.

Kafka, pola súa banda, actúa esencialmente como unha base de datos distribuída. Así, cando traballas, tes que tratar co estado, e é moito máis pesado que un microservizo. Kubernetes admite cargas con estado, pero como sinala Kelsey Hightower en dous tweets, deben manexarse ​​con coidado:

Algunhas persoas consideran que se incorporas Kubernetes a unha carga de traballo con estado, convértese nunha base de datos totalmente xestionada que rivaliza con RDS. Isto está mal. Quizais, se traballas o suficiente, engades compoñentes adicionais e atraes a un equipo de enxeñeiros SRE, poderás construír RDS enriba de Kubernetes.

Sempre recomendo que todos teñan moito coidado ao executar cargas de traballo con estado en Kubernetes. A maioría das persoas que preguntan "podo executar cargas de traballo con estado en Kubernetes" non teñen experiencia suficiente con Kubernetes e moitas veces coa carga de traballo que están a preguntar.

Entón, deberías executar Kafka en Kubernetes? Pregunta contraria: Kafka funcionará mellor sen Kubernetes? É por iso que quero destacar neste artigo como Kafka e Kubernetes se complementan e cales son as trampas que poden vir ao combinalos.

Tempo de realización

Falemos do básico: o propio ambiente de execución

proceso

Os corredores de Kafka son compatibles coa CPU. TLS pode introducir algunha sobrecarga. Non obstante, os clientes de Kafka poden consumir máis CPU se usan cifrado, pero isto non afecta aos corredores.

memoria

Os corredores de Kafka comen a memoria. O tamaño do montón de JVM adoita estar limitado a 4-5 GB, pero tamén necesitará moita memoria do sistema xa que Kafka usa moito a caché da páxina. En Kubernetes, establece os límites de recursos do contedor e solicitudes en consecuencia.

Almacén de datos

O almacenamento de datos en contedores é efémero: os datos pérdense ao reiniciar. Para os datos de Kafka pode usar un volume emptyDir, e o efecto será semellante: os datos do corredor perderanse despois de completar. As túas mensaxes aínda se poden almacenar noutros corredores como réplicas. Polo tanto, despois dun reinicio, o corredor fallido debe primeiro replicar todos os datos e este proceso pode levar moito tempo.

É por iso que deberías usar o almacenamento de datos a longo prazo. Que sexa almacenamento non local a longo prazo co sistema de ficheiros XFS ou, máis precisamente, ext4. Non use NFS. Avisei. As versións de NFS v3 ou v4 non funcionarán. En resumo, o corretor de Kafka fallará se non pode eliminar o directorio de datos debido ao problema de "renome estúpido" en NFS. Se aínda non te convencín, con moito coidado le este artigo. O almacén de datos debe ser non local para que Kubernetes poida escoller un novo nodo de forma máis flexible despois dun reinicio ou traslado.

Rede

Como coa maioría dos sistemas distribuídos, o rendemento de Kafka depende en gran medida de manter a latencia da rede ao mínimo e o ancho de banda ao máximo. Non tente aloxar a todos os corredores no mesmo nodo, xa que isto reducirá a dispoñibilidade. Se falla un nodo de Kubernetes, fallará todo o clúster de Kafka. Ademais, non dispersa o clúster de Kafka en centros de datos completos. O mesmo ocorre co clúster de Kubernetes. Un bo compromiso neste caso é escoller diferentes zonas de dispoñibilidade.

Configuración

Manifestos habituais

O sitio web de Kubernetes ten moi boa guía sobre como configurar ZooKeeper usando manifestos. Dado que ZooKeeper forma parte de Kafka, este é un bo lugar para comezar a familiarizarse cos conceptos de Kubernetes que se aplican aquí. Unha vez que entendas isto, podes usar os mesmos conceptos cun clúster de Kafka.

• En: un pod é a unidade despregable máis pequena de Kubernetes. Un pod contén a túa carga de traballo e o propio pod corresponde a un proceso do teu clúster. Unha vaina contén un ou máis recipientes. Cada servidor ZooKeeper do conxunto e cada corredor do clúster de Kafka executaranse nun pod separado.
• StatefulSet: Un StatefulSet é un obxecto de Kubernetes que xestiona varias cargas de traballo con estado, e tales cargas de traballo requiren coordinación. StatefulSets ofrece garantías sobre a ordenación dos pods e a súa singularidade.
• Servizos sen cabeza: Os servizos permítenche separar pods dos clientes mediante un nome lóxico. Kubernetes neste caso é responsable do equilibrio de carga. Non obstante, ao operar cargas de traballo con estado, como ZooKeeper e Kafka, os clientes deben comunicarse cunha instancia específica. Aquí é onde os servizos sen cabeza son útiles: neste caso, o cliente aínda terá un nome lóxico, pero non terás que contactar directamente co pod.
• Volume de almacenamento a longo prazo: Estes volumes son necesarios para configurar o almacenamento persistente de bloques non locais mencionado anteriormente.

En Yolean Ofrece un conxunto completo de manifestos para axudarche a comezar a utilizar Kafka en Kubernetes.

Gráficos de timón

Helm é un xestor de paquetes para un Kubernetes que se pode comparar con xestores de paquetes de SO como yum, apt, Homebrew ou Chocolatey. Facilita a instalación de paquetes de software predefinidos descritos nos gráficos Helm. Un gráfico de Helm ben escollido facilita a difícil tarefa de configurar correctamente todos os parámetros para usar Kafka en Kubernetes. Hai varios diagramas de Kafka: localízase o oficial en estado de incubadora, hai un de Confluente, un máis - de BitNami.

Operadores

Debido a que Helm ten certas deficiencias, outra ferramenta está a gañar considerable popularidade: os operadores de Kubernetes. O operador non só empaqueta software para Kubernetes, senón que tamén che permite implementar ese software e xestionalo.

Na lista operadores sorprendentes Menciónanse dous operadores para Kafka. Un deles - Strimzi. Con Strimzi, é fácil poñer en marcha o teu clúster Kafka en minutos. Practicamente non é necesaria ningunha configuración, ademais, o propio operador ofrece algunhas funcións agradables, por exemplo, o cifrado TLS punto a punto dentro do clúster. Confluente tamén ofrece propio operador.

Produtividade

É importante probar o rendemento comparando a túa instancia de Kafka. Tales probas axudarán a atopar posibles pescozos de botella antes de que xurdan problemas. Afortunadamente, Kafka xa ofrece dúas ferramentas de proba de rendemento: kafka-producer-perf-test.sh и kafka-consumer-perf-test.sh. Fai un uso activo delas. Para referencia, pode consultar os resultados descritos en esta publicación Jay Kreps, ou céntrase en esta revisión Amazon MSK de Stéphane Maarek.

Operacións

Seguimento

A transparencia no sistema é moi importante; se non, non entenderá o que está a suceder nel. Hoxe hai un conxunto de ferramentas sólido que ofrece un seguimento baseado en métricas no estilo nativo da nube. Dúas ferramentas populares para este fin son Prometheus e Grafana. Prometheus pode recoller métricas de todos os procesos Java (Kafka, Zookeeper, Kafka Connect) usando un exportador JMX, da forma máis sinxela. Se engades métricas de cAdvisor, poderás comprender máis a fondo como se usan os recursos en Kubernetes.

Strimzi ten un exemplo moi conveniente dun panel de Grafana para Kafka. Visualiza as métricas clave, por exemplo, sobre sectores pouco replicados ou aqueles que están fóra de liña. Alí está todo moi claro. Estas métricas compleméntanse con información sobre a utilización dos recursos e o rendemento, así como con indicadores de estabilidade. Entón, obtén un seguimento básico do clúster de Kafka de balde.

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

Sería bo complementar todo isto co seguimento de clientes (métricas sobre consumidores e produtores), así como monitorización da latencia (para iso hai Burrow) e seguimento de extremo a extremo - para este uso Monitor Kafka.

Rexistro

O rexistro é outra tarefa crítica. Asegúrate de que todos os contedores da túa instalación de Kafka estean rexistrados stdout и stderr, e tamén asegúrese de que o seu clúster de Kubernetes agregue todos os rexistros nunha infraestrutura de rexistro central, por exemplo. Elasticsearch.

Probas Funcionais

Kubernetes usa probas de vitalidade e preparación para comprobar se os teus pods funcionan normalmente. Se a comprobación de vitalidade falla, Kubernetes deterá ese contedor e, a continuación, reiniciará automaticamente se a política de reinicio está configurada en consecuencia. Se a comprobación de preparación falla, Kubernetes illa o pod das solicitudes de servizo. Así, nestes casos, xa non é necesaria a intervención manual, o que supón unha gran vantaxe.

Lanzamento de actualizacións

StatefulSets admite actualizacións automáticas: se selecciona a estratexia RollingUpdate, cada un de Kafka actualizarase á súa vez. Deste xeito, o tempo de inactividade pódese reducir a cero.

Escalado

A escala dun clúster de Kafka non é unha tarefa fácil. Non obstante, Kubernetes fai que sexa moi sinxelo escalar pods a un determinado número de réplicas, o que significa que podes definir de forma declarativa tantos corredores de Kafka como queiras. O máis difícil neste caso é reasignar sectores despois de aumentar a escala ou antes de reducir a escala. De novo, Kubernetes axudarache con esta tarefa.

Administración

As tarefas relacionadas coa administración do seu clúster de Kafka, como a creación de temas e a reasignación de sectores, pódense realizar mediante scripts de shell existentes abrindo a interface de liña de comandos nos seus pods. Non obstante, esta solución non é moi bonita. Strimzi admite a xestión de temas usando un operador diferente. Aquí hai algo de mellora.

Copia de seguranza e restauración

Agora a dispoñibilidade de Kafka tamén dependerá da dispoñibilidade de Kubernetes. Se o teu clúster de Kubernetes falla, no peor dos casos, o teu clúster de Kafka tamén fallará. Segundo a lei de Murphy, isto ocorrerá definitivamente e perderás datos. Para reducir este tipo de risco, teña un bo concepto de copia de seguridade. Podes usar MirrorMaker, outra opción é usar S3 para iso, como se describe neste publicar de Zalando.

Conclusión

Cando se traballa con clústeres Kafka de tamaño pequeno ou mediano, paga a pena usar Kubernetes xa que proporciona flexibilidade adicional e simplifica a experiencia do operador. Se tes requisitos de latencia e/ou rendemento non funcionais moi importantes, quizais sexa mellor considerar algunha outra opción de implantación.

Fonte: www.habr.com