8 problemas al usar Kubernetes

Es común pensar que si ya estás usando Docker el siguiente paso es usar Kubernetes, pero no, no lo que funciona para grandes empresas puede funcionar para medianas y pequeñas, aquí te dejo 8 problemas si tienes un equipo pequeños en lo que Kubernetes no es para ti. Mucho dolor y pocos beneficios.

Todos aman las partes móviles

Kubernetes tiene muchas partes móviles: conceptos, subsistemas, procesos, máquinas, código, y eso significa muchos problemas.

Máquinas múltiples

Kubernetes es un sistema distribuido: hay una máquina principal que controla las máquinas de los trabajadores. El trabajo se programa en diferentes máquinas de trabajo. Cada máquina ejecuta el trabajo en contenedores.

Entonces, ya estás hablando de dos máquinas o máquinas virtuales solo para hacer cualquier cosa. Y eso solo te da ... una máquina. Si va a escalar (el objetivo completo del ejercicio) necesita tres, cuatro o diecisiete máquinas virtuales.

Montones y montones de código

La base del código Kubernetes a principios de marzo de 2020 tiene más de 580,000 líneas de código Go. Ese es el código real, no cuenta comentarios o líneas en blanco, ni los paquetes enviados.

Complejidad arquitectónica, complejidad operativa, complejidad de configuración y complejidad conceptual.

Kubernetes es un sistema complejo con muchos servicios, sistemas y piezas diferentes.

Antes de poder ejecutar una sola aplicación, necesita la siguiente arquitectura altamente simplificada (fuente original en la documentación de Kubernetes ):

Complejidad de desarrollo

Cuanto más compre en Kubernetes, más difícil será hacer un desarrollo normal: necesitará todos los conceptos diferentes (Pod, Implementación, Servicio, etc.) para ejecutar su código. Por lo tanto, debe activar un sistema completo solo para probar cualquier cosa, a través de una VM o contenedores Docker anidados.

Y dado que su aplicación es mucho más difícil de ejecutar localmente, el desarrollo es más difícil, lo que lleva a una variedad de soluciones, desde entornos intermedios, hasta la representación de un proceso local en el clúster.

Hay muchas soluciones imperfectas para elegir; La solución más simple y mejor es no usar Kubernetes.

Microservicios (son una mala idea)

Un problema secundario es que, dado que tiene este sistema que le permite ejecutar muchos servicios, a menudo es tentador escribir muchos servicios. Esta es una mala idea.

Las aplicaciones distribuidas son realmente difíciles de escribir correctamente. De verdad . Cuantas más partes móviles, más problemas entran en juego.

Las aplicaciones distribuidas son difíciles de depurar. Necesita categorías completamente nuevas de instrumentación y registro para comprender que no es tan bueno como lo que obtendría de los registros de una aplicación monolítica.

Los microservicios son una técnica de escala organizativa: cuando tienes 500 desarrolladores trabajando en un sitio web en vivo, tiene sentido pagar el costo de un sistema distribuido a gran escala si significa que los equipos de desarrolladores pueden trabajar de forma independiente. Entonces le das a cada equipo de 5 desarrolladores un microservicio único , y ese equipo finge que el resto de los microservicios son servicios externos en los que no pueden confiar.

Si usted es un equipo de 5 y tiene 20 microservicios, y no tener una muy necesidad imperiosa de un sistema distribuido, lo estás haciendo mal. En lugar de 5 personas por servicio, como tiene la gran empresa, tiene 0.25 personas por servicio.

¿Pero no es útil?

Escalada

Kubernetes puede ser útil si necesita escalar mucho. Pero consideremos algunas alternativas:

• Puede obtener máquinas virtuales en la nube con hasta 416vCPU y 8TiB RAM, una escala que solo puedo expresar con blasfemias. Será costoso, sí, pero también será simple .
• Puede escalar muchas aplicaciones web simples de manera bastante trivial con servicios como Heroku

Esto supone, por supuesto, que agregar más trabajadores realmente te hará bien:

• La mayoría de las aplicaciones no necesitan escalar mucho; bastará una optimización razonable.
• El escalado de muchas aplicaciones web suele estar bloqueado por la base de datos, no por los trabajadores web.

Fiabilidad

Más partes móviles significa más oportunidades de error.

Las características que Kubernetes proporciona para la confiabilidad (comprobaciones de estado, implementaciones continuas), se pueden implementar de manera mucho más simple o ya integradas en muchos casos. Por ejemplo, nginx puede realizar comprobaciones de estado en los procesos de los trabajadores, y puede usar docker-autoheal o algo similar para reiniciar automáticamente esos procesos.

Y si lo que le importa es el tiempo de inactividad, lo primero que debe pensar no debería ser "cómo reduzco el tiempo de inactividad de la implementación de 1 segundo a 1 ms", sino "cómo puedo asegurar que los cambios en el esquema de la base de datos no eviten la reversión si atornillo algo arriba."

Y si desea trabajadores web confiables sin una sola máquina como punto de falla, hay muchas maneras de hacerlo que no involucren a Kubernetes.

¿Mejores prácticas?

No existen las mejores prácticas en general; solo hay mejores prácticas para una situación particular . El hecho de que algo esté de moda y sea popular no significa que sea la opción correcta para usted.

En algunas situaciones, Kubernetes es una gran idea. En otros, es un disipador de tiempo sin beneficio.

A menos que realmente necesite toda esa complejidad masiva, hay una gran variedad de herramientas que funcionarán igual de bien: desde Docker Compose en una sola máquina, hasta Heroku y sistemas similares, hasta algo como Snakemake para pipelines  computacionales.