{"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\/es\/blog\/administrirovanie\/kafka-na-kubernetes-eto-horosho","title":{"rendered":"\u00bfKafka en Kubernetes es algo bueno?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\u00a1Bienvenido, Habr!<\/p>\n

En su momento, fuimos los primeros en introducir el tema Kafka<\/a><\/noindex> y continuamos siguiendo<\/a><\/noindex> su desarrollo. En particular, nos ha parecido interesante el tema de la interacci\u00f3n entre Kafka y Kubernetes<\/a><\/noindex>. Se public\u00f3 un art\u00edculo (bastante cauteloso) sobre este tema en el blog de Confluent en octubre del a\u00f1o pasado, escrito por Gwen Shapiro. Hoy, queremos llamar su atenci\u00f3n sobre un art\u00edculo m\u00e1s reciente de abril escrito por Johann Gyger, quien, aunque no se abstuvo de un signo de interrogaci\u00f3n en el t\u00edtulo, aborda el tema de manera m\u00e1s concreta, acompa\u00f1ando el texto con enlaces interesantes. \u00a1Perd\u00f3n por nuestra libre traducci\u00f3n de \u00abchaos monkey\u00bb, si pueden! Windows<\/a><\/noindex> Kubernetes est\u00e1 dise\u00f1ado para trabajar con cargas que no mantienen estado. En general, estas cargas de trabajo se presentan en forma de arquitecturas de microservicios, son ligeras, se escalan horizontalmente bien, siguen los principios de las aplicaciones de 12 factores, permiten trabajar con interruptores autom\u00e1ticos (circuit breaker) y monos del caos (chaos monkeys).<\/p>\n

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

Introducci\u00f3n<\/h4>\n

\nKafka, por otro lado, act\u00faa esencialmente como una base de datos distribuida. Por lo tanto, al trabajar, debes tratar con el estado, que es mucho m\u00e1s pesado que un microservicio. Kubernetes admite cargas con estado, pero, como se\u00f1ala Kelsey Hightower en dos de sus tweets, se debe tener cuidado al hacerlo:<\/p>\n

Algunos piensan que si aplican Kubernetes a una carga con estado, se convierte en una base de datos completamente gestionada capaz de competir con RDS. No es as\u00ed. Puede que, si se trabaja lo suficiente, se integren componentes adicionales y se reclute a un equipo de ingenieros SRE, se pueda configurar RDS sobre Kubernetes.<\/p>\n

Siempre recomiendo tener una extrema precauci\u00f3n al ejecutar cargas con estado en Kubernetes. La mayor\u00eda de aquellos que se preguntan, \u00ab\u00bfpuedo ejecutar cargas con estado en Kubernetes?\u00bb no tienen suficiente experiencia trabajando con Kubernetes y, a menudo, ni con la carga de la que est\u00e1n preguntando.<\/p><\/blockquote>\n

Siempre recomiendo tener una cautela excepcional al ejecutar cargas con estado en Kubernetes. La mayor\u00eda de aquellos que se preguntan: \"\u00bfpuedo ejecutar cargas con estado en Kubernetes?\" no tienen la experiencia suficiente para trabajar con Kubernetes, y a menudo, ni con la carga en cuesti\u00f3n.<\/p><\/blockquote>\n

\u00bfDeber\u00eda ejecutar Kafka en Kubernetes? Pregunta inversa: \u00bffuncionar\u00e1 mejor Kafka sin Kubernetes? Por eso quiero enfatizar en este art\u00edculo c\u00f3mo Kafka y Kubernetes se complementan entre s\u00ed, y cu\u00e1les son los posibles escollos al combinarlos.<\/p>\n

Tiempo de ejecuci\u00f3n<\/h4>\n

\nHablemos de lo b\u00e1sico: el entorno de tiempo de ejecuci\u00f3n en s\u00ed.<\/p>\n

El proceso<\/b><\/i><\/p>\n

Los brokers de Kafka son convenientes en el uso de CPU. TLS puede a\u00f1adir algunos costos. Sin embargo, los clientes de Kafka pueden cargar m\u00e1s la CPU si utilizan cifrado, pero esto no afecta a los brokers.<\/p>\n

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

Los brokers de Kafka consumen memoria. El tama\u00f1o del heap de la JVM generalmente se puede limitar a 4-5 GB, pero tambi\u00e9n necesitar\u00e1s mucha memoria del sistema, ya que Kafka utiliza de manera muy activa la memoria cach\u00e9 de p\u00e1ginas. En Kubernetes, establece adecuadamente los l\u00edmites de recursos y las solicitudes del contenedor.<\/p>\n

Almacenamiento de datos<\/b><\/i><\/p>\n

El almacenamiento de datos en contenedores es ef\u00edmero: los datos se pierden al reiniciar. Para los datos de Kafka, puedes utilizar un volumen emptyDir<\/code>, y el efecto ser\u00e1 similar: los datos de tu broker se perder\u00e1n despu\u00e9s de terminar. Sin embargo, tus mensajes a\u00fan pueden permanecer en otros brokers como r\u00e9plicas. Por lo tanto, despu\u00e9s de reiniciar, el broker fallido debe primero replicar todos los datos, lo que puede llevar tiempo. <\/p>\n

Por eso se debe utilizar almacenamiento de datos a largo plazo. Debe ser un almacenamiento a largo plazo no local con un sistema de archivos XFS o, m\u00e1s precisamente, ext4. No utilices NFS. Te lo advierto. NFS versiones v3 o v4 no funcionar\u00e1n. En resumen, un broker de Kafka fallar\u00e1 si no puede eliminar un directorio de datos debido a problemas con 'renombrados tontos', que son relevantes en NFS. Si a\u00fan no te he convencido, lee muy detenidamente este art\u00edculo<\/a><\/noindex>. El almacenamiento de datos debe ser no local, para que Kubernetes pueda elegir m\u00e1s flexiblemente un nuevo nodo despu\u00e9s de un reinicio o reubicaci\u00f3n.<\/p>\n

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

Al igual que en la mayor\u00eda de los sistemas distribuidos, el rendimiento de Kafka depende en gran medida de minimizar la latencia de la red y maximizar el ancho de banda. No intentes alojar todos los brokers en una sola m\u00e1quina, ya que esto reducir\u00e1 la disponibilidad. Si un nodo de Kubernetes falla, todo el cl\u00faster de Kafka tambi\u00e9n fallar\u00e1. Adem\u00e1s, no distribuyas el cl\u00faster de Kafka entre diferentes centros de datos. Lo mismo se aplica al cl\u00faster de Kubernetes. Un buen compromiso en este caso es elegir diferentes zonas de disponibilidad.<\/p>\n

Configuraci\u00f3n<\/h4>\n

\nManifiestos comunes<\/b><\/i><\/p>\n

En el sitio de Kubernetes hay una gu\u00eda muy buena<\/a><\/noindex> sobre c\u00f3mo configurar ZooKeeper usando manifiestos. Dado que ZooKeeper forma parte de Kafka, es conveniente comenzar a familiarizarse con los conceptos de Kubernetes que son aplicables aqu\u00ed. Una vez que comprendas esto, podr\u00e1s utilizar los mismos conceptos con el cl\u00faster de Kafka.<\/p>\n