Saludos Habr!
Hubo un tiempo en que fuimos los primeros en introducir el tema en el mercado ruso. y continuar para su desarrollo. En particular, encontramos el tema de la interacción entre Kafka y . Observable (y bastante cuidadoso) Este tema se publicó en el blog de Confluent en octubre del año pasado bajo la autoría de Gwen Shapira. Hoy nos gustaría llamar su atención sobre un artículo más reciente de abril de Johann Gyger, quien, aunque no sin un signo de interrogación en el título, examina el tema de manera más sustantiva, acompañando el texto con enlaces interesantes. ¡Perdónanos la traducción gratuita de “mono del caos” si puedes!
introducción
Kubernetes está diseñado para manejar cargas de trabajo sin estado. Por lo general, estas cargas de trabajo se presentan en forma de arquitectura de microservicio, son livianas, se escalan bien horizontalmente, siguen los principios de aplicaciones de 12 factores y pueden funcionar con disyuntores y monos del caos.
Kafka, por otro lado, actúa esencialmente como una base de datos distribuida. Por lo tanto, cuando se trabaja, hay que lidiar con el estado, y es mucho más pesado que un microservicio. Kubernetes admite cargas con estado, pero como señala Kelsey Hightower en dos tweets, deben manejarse con cuidado:
Algunas personas sienten que si Kubernetes se integra en una carga de trabajo con estado, se convierte en una base de datos totalmente administrada que rivaliza con RDS. Esto está mal. Tal vez, si trabaja lo suficiente, agrega componentes adicionales y atrae a un equipo de ingenieros de SRE, podrá construir RDS sobre Kubernetes.
Siempre recomiendo que todos tengan extrema precaución al ejecutar cargas de trabajo con estado en Kubernetes. La mayoría de las personas que preguntan "¿puedo ejecutar cargas de trabajo con estado en Kubernetes?" no tienen suficiente experiencia con Kubernetes y, a menudo, con la carga de trabajo sobre la que preguntan.
Entonces, ¿deberías ejecutar Kafka en Kubernetes? Pregunta contraria: ¿Kafka funcionará mejor sin Kubernetes? Es por eso que quiero resaltar en este artículo cómo Kafka y Kubernetes se complementan entre sí y qué peligros puede surgir al combinarlos.
Tiempo de finalización
Hablemos de lo básico: el entorno de ejecución en sí.
proceso
Los corredores de Kafka son compatibles con la CPU. TLS puede introducir algunos gastos generales. Sin embargo, los clientes de Kafka pueden consumir más CPU si utilizan cifrado, pero esto no afecta a los intermediarios.
Память
Los agentes de Kafka devoran la memoria. El tamaño del montón de JVM suele estar limitado a 4-5 GB, pero también necesitará mucha memoria del sistema ya que Kafka utiliza mucho el caché de páginas. En Kubernetes, establezca los límites de solicitudes y recursos del contenedor en consecuencia.
Almacén de datos
El almacenamiento de datos en contenedores es efímero: los datos se pierden cuando se reinicia. Para datos de Kafka puedes usar un volumen. emptyDir, y el efecto será similar: los datos de su corredor se perderán una vez finalizado. Sus mensajes aún pueden almacenarse en otros corredores como réplicas. Por lo tanto, después de reiniciar, el intermediario fallido primero debe replicar todos los datos y este proceso puede llevar mucho tiempo.
Es por eso que debería utilizar el almacenamiento de datos a largo plazo. Sea un almacenamiento no local a largo plazo con el sistema de archivos XFS o, más precisamente, ext4. No utilice NFS. Te lo adverti. Las versiones NFS v3 o v4 no funcionarán. En resumen, el broker Kafka fallará si no puede eliminar el directorio de datos debido al problema del "cambio de nombre estúpido" en NFS. Si aún no te he convencido, mucho cuidado. . El almacén de datos debe ser no local para que Kubernetes pueda elegir con mayor flexibilidad un nuevo nodo después de un reinicio o una reubicación.
Red
Como ocurre con la mayoría de los sistemas distribuidos, el rendimiento de Kafka depende en gran medida de mantener la latencia de la red al mínimo y el ancho de banda al máximo. No intente alojar a todos los intermediarios en el mismo nodo, ya que esto reducirá la disponibilidad. Si falla un nodo de Kubernetes, fallará todo el clúster de Kafka. Además, no disperse el clúster de Kafka en centros de datos completos. Lo mismo ocurre con el clúster de Kubernetes. Un buen compromiso en este caso es elegir diferentes zonas de disponibilidad.
Configuración
Manifiestos regulares
El sitio web de Kubernetes tiene sobre cómo configurar ZooKeeper usando manifiestos. Dado que ZooKeeper es parte de Kafka, este es un buen lugar para comenzar a familiarizarse con los conceptos de Kubernetes que se aplican aquí. Una vez que comprenda esto, podrá utilizar los mismos conceptos con un clúster Kafka.
- debajo: Un pod es la unidad desplegable más pequeña en Kubernetes. Un pod contiene su carga de trabajo y el pod en sí corresponde a un proceso en su clúster. Un pod contiene uno o más contenedores. Cada servidor ZooKeeper del conjunto y cada corredor del clúster Kafka se ejecutará en un pod independiente.
- Conjunto con estado: Un StatefulSet es un objeto de Kubernetes que maneja múltiples cargas de trabajo con estado y dichas cargas de trabajo requieren coordinación. StatefulSets brinda garantías con respecto al pedido de pods y su singularidad.
- Servicios sin cabeza: Los servicios le permiten desconectar pods de los clientes mediante un nombre lógico. Kubernetes en este caso es responsable del equilibrio de carga. Sin embargo, cuando se operan cargas de trabajo con estado, como ZooKeeper y Kafka, los clientes necesitan comunicarse con una instancia específica. Aquí es donde los servicios headless resultan útiles: en este caso, el cliente seguirá teniendo un nombre lógico, pero no tendrás que contactar con el pod directamente.
- Volumen de almacenamiento a largo plazo: Estos volúmenes son necesarios para configurar el almacenamiento persistente en bloque no local mencionado anteriormente.
En Proporciona un conjunto completo de manifiestos para ayudarle a empezar a utilizar Kafka en Kubernetes.
Cartas de timón
Helm es un administrador de paquetes para Kubernetes que se puede comparar con administradores de paquetes de sistemas operativos como yum, apt, Homebrew o Chocolatey. Facilita la instalación de paquetes de software predefinidos que se describen en los gráficos de Helm. Un gráfico de Helm bien elegido facilita la difícil tarea de configurar correctamente todos los parámetros para usar Kafka en Kubernetes. Hay varios diagramas de Kafka: el oficial se encuentra , hay uno de , uno más - de .
operadores
Debido a que Helm tiene ciertas deficiencias, otra herramienta está ganando considerable popularidad: los operadores de Kubernetes. El operador no solo empaqueta software para Kubernetes, sino que también le permite implementar dicho software y administrarlo.
В списке Se mencionan dos operadores de Kafka. Uno de ellos - . Con Strimzi, es fácil poner en funcionamiento su clúster Kafka en minutos. Prácticamente no se requiere configuración, además, el propio operador proporciona algunas características interesantes, por ejemplo, cifrado TLS punto a punto dentro del clúster. Confluent también proporciona .
Rendimiento
Es importante probar el rendimiento comparando su instancia de Kafka. Estas pruebas le ayudarán a encontrar posibles obstáculos antes de que surjan problemas. Afortunadamente, Kafka ya proporciona dos herramientas de prueba de rendimiento: kafka-producer-perf-test.sh и kafka-consumer-perf-test.sh. Haz uso activo de ellos. Como referencia, puede consultar los resultados descritos en Jay Kreps, o centrarse en Amazon MSK por Stéphane Maarek.
operaciones
Monitoreo
La transparencia en el sistema es muy importante; de lo contrario, no entenderás lo que sucede en él. Hoy en día existe un sólido conjunto de herramientas que proporciona monitoreo basado en métricas en el estilo nativo de la nube. Dos herramientas populares para este propósito son Prometheus y Grafana. Prometheus puede recopilar métricas de todos los procesos Java (Kafka, Zookeeper, Kafka Connect) utilizando un exportador JMX, de la forma más sencilla. Si agrega métricas de cAdvisor, podrá comprender mejor cómo se utilizan los recursos en Kubernetes.
Strimzi tiene un ejemplo muy conveniente de un panel de Grafana para Kafka. Visualiza métricas clave, por ejemplo, sobre sectores poco replicados o aquellos que están fuera de línea. Ahí está todo muy claro. Estas métricas se complementan con información sobre la utilización de recursos y el rendimiento, así como con indicadores de estabilidad. ¡Así que obtienes monitoreo básico de clústeres de Kafka gratis!
Fuente:
Sería bueno complementar todo esto con monitoreo de clientes (métricas sobre consumidores y productores), así como monitoreo de latencia (para esto existe ) y monitoreo de extremo a extremo - para este uso .
Inicio sesión
El registro es otra tarea crítica. Asegúrese de que todos los contenedores de su instalación de Kafka estén registrados en stdout и stderry también asegúrese de que su clúster de Kubernetes agregue todos los registros en una infraestructura de registro central, p. .
Verificación funcional
Kubernetes utiliza sondas de actividad y preparación para comprobar si sus pods se están ejecutando normalmente. Si la verificación de actividad falla, Kubernetes detendrá ese contenedor y luego lo reiniciará automáticamente si la política de reinicio se establece en consecuencia. Si la verificación de preparación falla, Kubernetes aísla el pod de las solicitudes de servicio. Por lo tanto, en tales casos ya no es necesaria ninguna intervención manual, lo cual es una gran ventaja.
Implementación de actualizaciones
StatefulSets admite actualizaciones automáticas: si selecciona la estrategia RollingUpdate, cada uno de Kafka se actualizará por turno. De esta manera, el tiempo de inactividad se puede reducir a cero.
Escalado
Escalar un clúster de Kafka no es una tarea fácil. Sin embargo, Kubernetes hace que sea muy fácil escalar pods a una cierta cantidad de réplicas, lo que significa que puede definir de forma declarativa tantos corredores de Kafka como desee. Lo más difícil en este caso es reasignar sectores después de la ampliación o antes de la reducción. Nuevamente, Kubernetes te ayudará con esta tarea.
administración
Las tareas relacionadas con la administración de su clúster Kafka, como la creación de temas y la reasignación de sectores, se pueden realizar utilizando scripts de shell existentes abriendo la interfaz de línea de comandos en sus pods. Sin embargo, esta solución no es muy bonita. Strimzi admite la gestión de temas utilizando un operador diferente. Aquí hay margen de mejora.
Copia de seguridad y recuperación
Ahora la disponibilidad de Kafka también dependerá de la disponibilidad de Kubernetes. Si su clúster de Kubernetes falla, en el peor de los casos, su clúster de Kafka también fallará. Según la ley de Murphy, esto definitivamente sucederá y perderá datos. Para reducir este tipo de riesgo, tenga un buen concepto de respaldo. Puedes usar MirrorMaker, otra opción es usar S3 para esto, como se describe en este de Zalando.
Conclusión
Cuando se trabaja con clústeres Kafka pequeños y medianos, definitivamente vale la pena usar Kubernetes, ya que proporciona flexibilidad adicional y simplifica la experiencia del operador. Si tiene requisitos de rendimiento o latencia no funcionales muy importantes, entonces puede ser mejor considerar alguna otra opción de implementación.
Fuente: habr.com