Implementación de un clúster de Kafka en Azure Kubernetes Service (AKS) mediante Strimzi

En esta guía, revisamos los requisitos previos, las consideraciones de arquitectura y los componentes clave para implementar y operar un clúster de Apache Kafka de alta disponibilidad en Azure Kubernetes Service (AKS) mediante el operador Strimzi.

¿Qué es Apache Kafka y Strimzi?

Apache Kafka es una plataforma de streaming de eventos distribuidos de código abierto diseñada para controlar datos de streaming en tiempo real y de gran volumen. Como resultado, miles de empresas usan para canalizaciones de datos de alto rendimiento, análisis de streaming, integración de datos y aplicaciones críticas. Sin embargo, la administración y el escalado de clústeres de Kafka pueden ser difíciles y a menudo lentos.

Strimzi es un proyecto de código abierto que simplifica la implementación, la administración y el funcionamiento de Apache Kafka en Kubernetes. Proporciona un conjunto de operadores de Kubernetes e imágenes de contenedor que automatizan tareas operativas complejas de Kafka a través de la configuración declarativa.

Los operadores strimzi siguen el patrón de operador de Kubernetes para automatizar las operaciones de Kafka. Reconcilia continuamente el estado declarado de los componentes de Kafka con su estado real, controlando tareas operativas complejas automáticamente.

Para más información sobre Strimzi, revise la documentación de Strimzi.

Componentes

Operador de clúster strimzi

El operador de clúster de Strimzi es el componente central que administra todo el ecosistema de Kafka. Cuando se implementa, también puede aprovisionar el operador de entidad, que consta de:

• Operador de temas: automatiza la creación, modificación y eliminación de temas de Kafka basados en KafkaTopic recursos personalizados.
• Operador de usuario: administra los usuarios de Kafka y sus listas de control de acceso (ACL) a través KafkaUser de recursos personalizados.

Juntos, estos operadores crean un sistema de administración totalmente declarativo en el que la infraestructura de Kafka se define como recursos de Kubernetes que puede controlar versiones, auditar e implementar de forma coherente en todos los entornos.

Clúster de Kafka

El operador de clústeres strimzi administra clústeres de Kafka a través de recursos personalizados especializados:

• KafkaNodePools: defina grupos de nodos de Kafka con roles específicos (agente, controlador o ambos).
• Kafka: el recurso personalizado principal que vincula todo lo mismo, definiendo configuraciones de todo el clúster.

Una implementación típica de KafkaNodePools e Kafka incluye:

• Nodos de agente dedicados que controlan el tráfico de cliente y el almacenamiento de datos.
• Nodos de controlador dedicados que administran los metadatos y la coordinación del clúster.
• Varias réplicas de cada componente distribuidas entre zonas de disponibilidad.

Control de crucero

Cruise Control es un componente avanzado que proporciona equilibrio y supervisión automatizados de cargas de trabajo para clústeres de Kafka. Cuando se implementa como parte de un clúster de Kafka administrado por Strimzi, Cruise Control ofrece:

• Reequilibrio automatizado de particiones: redistribuye las particiones entre agentes para optimizar el uso de recursos.
• Detección de anomalías: identifica y alerta sobre el comportamiento anómalo del clúster.
• Funcionalidades de recuperación automática: soluciona automáticamente problemas comunes de desequilibrio de clústeres.
• Análisis de cargas de trabajo: proporciona información sobre el rendimiento del clúster y el uso de recursos.

Cruise Control ayuda a mantener un rendimiento óptimo a medida que cambia la carga de trabajo con el tiempo, lo que reduce la necesidad de intervención manual durante los eventos de escalado o tras fallas de intermediarios.

Limpiador de desagües

Strimzi Drain Cleaner es una utilidad diseñada para ayudar a administrar pods de broker de Kafka implementados por Strimzi durante el drenaje de nodos de Kubernetes. Strimzi Drain Cleaner intercepta las operaciones de purga de nodos de Kubernetes a través de su webhook de admisión para coordinar el mantenimiento correcto de los clústeres de Kafka. Cuando se realiza una solicitud de expulsión para pods de agente de Kafka, se detecta la solicitud y el limpiador de purga anota los pods para indicar al operador de clúster strimzi para controlar el reinicio, asegurándose de que el clúster de Kafka permanece en un estado correcto. Este proceso mantiene el estado del clúster y la confiabilidad de los datos durante las operaciones de mantenimiento rutinarias o errores inesperados de nodo.

Cuándo usar Kafka en AKS

Considere la posibilidad de ejecutar Kafka en AKS cuando:

• Necesita un control completo sobre las operaciones y la configuración de Kafka.
• El caso de uso requiere características específicas de Kafka que no están disponibles en las ofertas administradas.
• Quiere integrar Kafka con otras aplicaciones en contenedor que se ejecutan en AKS.
• Debe implementar en regiones en las que los servicios de Kafka administrados no están disponibles.
• Su organización tiene experiencia existente en Kubernetes y la orquestación de contenedores.

Para casos de uso más sencillos o cuando la sobrecarga operativa es un problema, considere la posibilidad de usar servicios totalmente administrados como Azure Event Hubs.

Consideraciones clave para Kafka en AKS

Azure Disk Storage

En el caso de las implementaciones de Kafka en AKS, se usa el controlador CSI de disco de Azure que proporciona volúmenes persistentes respaldados por discos administrados de Azure. Strimzi aprovecha la configuración de (Just a Bunch of Disks (JBOD) para administrar la persistencia de datos.

Para garantizar alta disponibilidad ante fallos de infraestructura, las clases de almacenamiento deben configurarse con discos SSD Premium v2 distribuidos entre zonas de disponibilidad, mediante el WaitForFirstConsumer modo de enlace de volumen. Esto garantiza que los pods se programen en zonas donde se puedan crear sus volúmenes persistentes. SSD prémium v2 puede ofrecer la latencia, las IOPS elevadas y el rendimiento coherente que requieren las cargas de trabajo de Kafka intensivas en E/S a una estructura de costos optimizada.

En la tabla siguiente se proporcionan puntos de partida para las configuraciones premium de SSD v2 en diferentes tamaños de clúster de Kafka:

El tamaño real necesario de IOPS, ancho de banda y disco varía en función de las características específicas de la carga de trabajo de Kafka. Estas propiedades pueden evolucionar con el tiempo a medida que cambian los requisitos de retención y rendimiento de la aplicación.

Grupos de nodos

Seleccionar los grupos de nodos adecuados para la implementación de Kafka en AKS es una decisión arquitectónica crítica que afecta directamente al rendimiento, la disponibilidad y la eficiencia de los costos. Las cargas de trabajo de Kafka tienen patrones de uso de recursos únicos, caracterizados por altas demandas de rendimiento, intensidad de E/S de almacenamiento y la necesidad de un rendimiento coherente en cargas variables. Kafka suele ser más intensivo en memoria que el uso intensivo de CPU. Sin embargo, los requisitos de CPU pueden aumentar significativamente con la compresión o descompresión de mensajes, cifrado SSL/TLS o escenarios de alto rendimiento con muchos mensajes pequeños.

Teniendo en cuenta la arquitectura nativa de Kubernetes de Strimzi donde cada broker de Kafka se ejecuta como un pod independiente, la estrategia de selección de nodos de AKS debe optimizarse para el escalado horizontal en lugar de escalar verticalmente en un solo nodo. La configuración adecuada del grupo de nodos en AKS garantiza un uso eficaz de los recursos al tiempo que mantiene el aislamiento de rendimiento que los componentes de Kafka requieren para funcionar de forma confiable.

Kafka se ejecuta mediante una instancia de Java Virtual Machines (JVM). La optimización de JVM es fundamental para un rendimiento óptimo de Kafka, especialmente en entornos de producción. LinkedIn, los creadores de Kafka, han compartido los argumentos típicos para ejecutar Kafka en Java para uno de los clústeres más ocupados de LinkedIn: Configuración de Java de Kafka.

En esta guía, se usará un montón de memoria de 6 GB como línea base para agentes, con un adicional de 2 GB asignados para dar cabida al uso de memoria fuera del montón. En el caso de los controladores, se usará un montón de memoria de 3 GB como línea base, con un adicional de 1 GB como sobrecarga.

Al cambiar el tamaño de las máquinas virtuales para la implementación de Kafka, tenga en cuenta estos factores específicos de la carga de trabajo:

Clústeres de Kafka pequeños a medianos

Clústeres de Kafka grandes

Antes de finalizar el entorno de producción, se recomienda realizar los pasos siguientes:

• Realice pruebas de carga con patrones y volúmenes de datos representativos.
• Supervise el uso de CPU, memoria, disco y red durante las cargas máximas.
• Ajuste las SKU del grupo de nodos de AKS en función de los cuellos de botella observados.
• Revisión del costo de las SKU del grupo de nodos.

Alta disponibilidad y resistencia

Para garantizar la alta disponibilidad de la implementación de Kafka, debe:

• Implemente en varias Availability Zones.
• Configure las restricciones de distribución de réplica adecuadas.
• Implemente los presupuestos de interrupciones de pod adecuados.
• Configure el control de crucero para el reequilibrio de particiones de temas.
• Use Strimzi Drain Cleaner para controlar las operaciones de purga y mantenimiento de nodos.

Supervisión y operaciones

La supervisión eficaz de los clústeres de Kafka incluye:

• Configuración de la recopilación de métricas JMX.
• Supervisión del retraso del consumidor con el exportador de Kafka.
• Integración con Azure Managed Prometheus y Azure Managed Grafana.
• Alertas sobre los indicadores clave de rendimiento y las métricas de estado.

Paso siguiente

Colaboradores

Microsoft mantiene este artículo. Originalmente lo escribieron los siguientes colaboradores:

• Sergio Navar | Ingeniero superior de clientes
• Erin Schaffer | Desarrollador de contenido 2