🍆 🦑 💃🏽 "¡Usemos Kubernetes!" Ahora tienes 8 problemas 🏫 🐆 👨🏻‍🚀

Si usa Docker, el siguiente paso lógico parece ser cambiar a Kubernetes, son los K8, ¿verdad? Bueno, supongamos. Sin embargo, las soluciones diseñadas para 500 ingenieros de software que desarrollan simultáneamente una sola aplicación son bastante diferentes de las soluciones para 50 personas. Y la solución para un equipo de 5 programadores es otra historia completamente diferente.

Si trabajas en un equipo pequeño, lo más probable es que Kubernetes no sea para ti. Te traerá mucho dolor a cambio de beneficios extremadamente modestos.
Veamos por qué puede suceder esto.

A todos les gustan las "partes móviles"

Kubernetes se está moviendo y cambiando mucho: conceptos, subsistemas, procesos, máquinas, código ... Y todo esto significa muchas dificultades.

Varios autos

Kubernetes es un sistema distribuido: tiene una máquina host que controla el resto, los trabajadores. Cada máquina realiza trabajos en contenedores.
Entonces, ya estamos hablando de al menos dos máquinas físicas o virtuales, que son necesarias solo para que funcione. Pero de hecho obtienes ... solo un auto. Si vas a escalar (¡ahí es donde está enterrado el perro!), Necesitarás tres, cuatro o tal vez hasta diecisiete máquinas virtuales.

Muy, mucho código

La base de código de Kubernetes a principios de marzo de 2020 incluye más de 580,000 líneas de código en Go. Y esto es solo código limpio, excluyendo comentarios, líneas en blanco y paquetes de proveedores. La revisión de seguridad de 2019 describe la base del código de la siguiente manera:
“La base del código de Kubernetes tiene un margen significativo de mejora. Es grande y complejo, contiene grandes secciones de código con una documentación mínima y una gran cantidad de dependencias, incluidos los sistemas que no forman parte de Kubernetes. También en la base del código hay muchos casos de reimplementación de lógica que podrían centralizarse en bibliotecas de soporte, lo que reduciría la complejidad, simplificaría las correcciones y reduciría la carga de documentos en varias áreas de la base del código ”
Para ser sincero, se puede decir lo mismo de muchos otros proyectos grandes, pero todo este código debería funcionar correctamente si no desea que su aplicación falle.

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

Kubernetes es un sistema integral con muchos servicios, sistemas y más.
Antes de que pueda lanzar su única aplicación, deberá proporcionar la siguiente arquitectura muy simplificada (la imagen original se toma de la documentación de Kubernetes):

La documentación del concepto K8s incluye muchas cosas puramente "educativas", como el siguiente fragmento:

In Kubernetes, an EndpointSlice contains references to a set of network endpoints. The EndpointSlice controller automatically creates EndpointSlices for a Kubernetes Service when a selector is specified. These EndpointSlices will include references to any Pods that match the Service selector. EndpointSlices group network endpoints together by unique Service and Port combinations.
By default, EndpointSlices managed by the EndpointSlice controller will have no more than 100 endpoints each. Below this scale, EndpointSlices should map 1:1 with Endpoints and Services and have similar performance.

En realidad, entiendo de qué se trata, pero preste atención a cuántos conceptos necesita aprender: EndpointSlice, Service, selector, Pod, Endpoint.

Y sí, la mayoría de las veces no utilizará todas estas funciones. Por lo tanto, la mayoría de las veces no necesitarás Kubernetes en absoluto.

Aquí hay otro fragmento aleatorio:

De manera predeterminada, el tráfico enviado a un ClusterIP o al Servicio NodePort puede enrutarse a cualquier dirección de back-end para el Servicio. Desde Kubernetes 1.7 ha sido posible enrutar el tráfico "externo" a los Pods que se ejecutan en el Nodo que recibió el tráfico, pero esto no es compatible con los Servicios de ClusterIP, y las topologías más complejas, como el enrutamiento zonal, no han sido posibles. La característica de topología de servicio resuelve esto permitiendo que el creador del servicio defina una política para enrutar el tráfico en función de las etiquetas de nodo para los nodos de origen y destino.

Esto es lo que dice la revisión de seguridad sobre esto:

Kubernetes — , . , Kubernetes — , , , .

Cuanto más obtenga en Kubernetes, más difícil se volverá el proceso de desarrollo normal: necesita todos estos conceptos (Pod, Implementación, Servicio, etc.) solo para que su código funcione. Por lo tanto, debe promover un sistema K8 completo, incluso solo para probar a través de una máquina virtual o contenedores Docker anidados.

Y, dado que su aplicación se vuelve más difícil de ejecutar localmente, el desarrollo se ve complicado por muchas opciones para resolver este problema, desde un entorno de banco hasta la representación de un proceso local en un clúster (escribí esta herramienta hace un par de años ) y la representación de un proceso remoto en una máquina local ...

Puede elige cualquier opción, pero ninguna de ellas será perfecta. La forma más fácil de no usar Kubernetes en absoluto.

Microservicios (esta es una mala idea)

Un problema secundario es que, dado que su sistema le permite ejecutar muchos servicios, debe escribir estos servicios. Mala idea.
La aplicación distribuida es difícil de escribir. De hecho , mientras más partes móviles, más estos problemas interfieren con el trabajo.

Las aplicaciones distribuidas son difíciles de depurar. Necesitará un tipo completamente nuevo de herramientas de depuración y registro, que aún le proporcionarán menos que los registros de una aplicación monolítica.

Microservicios es una de las técnicas de escalado en las organizaciones: cuando tienes 500 desarrolladores que sirven a un sitio web productivo, tiene sentido soportar el costo de un sistema distribuido a gran escala si permite que los equipos de desarrollo trabajen de forma independiente. Por lo tanto, cada equipo de 5 personas recibe un solo microservicio y finge que todos los demás microservicios son servicios externos en los que no debe confiar.

Si todo su equipo está formado por 5 personas, tiene 20 microservicios y las circunstancias de fuerza mayor no lo obligan a crear un sistema distribuido, entonces en algún lugar calculó mal. En lugar de 5 personas por 1 microservicio, como en las grandes empresas, obtienes 0,25 personas.

¿No es útil Kubernetes en absoluto?

Escalada

Kubernetes puede ser útil si necesita una escalabilidad seria. Sin embargo, veamos qué alternativas tiene:

Puede comprar máquinas virtuales en la nube, y tendrán hasta 416 CPU virtuales y 8 TB de RAM, es decir, una potencia completamente poco halagadora. Le costará un centavo bastante, pero será extremadamente simple de hacer.
Muchas aplicaciones web simples se pueden escalar de una manera bastante fácil con servicios como Heroku.

Se supone, por supuesto, que un aumento en el número de máquinas virtuales en funcionamiento también jugará en sus manos:

La mayoría de las aplicaciones no requieren escalamiento significativo, tendrán suficiente optimización de alta calidad.
El cuello de botella para escalar la mayoría de las aplicaciones web son las bases de datos, no los trabajadores web

Fiabilidad

Cuantas más partes móviles, mayor es la posibilidad de que ocurra un error.
Las capacidades de Kubernetes, agudizadas por una mayor confiabilidad (comprobaciones de estado, implementaciones continuas), en muchos casos ya se pueden incorporar o implementar de manera mucho más fácil. Por ejemplo, nginx puede hacer comprobaciones de estado en los procesos de los trabajadores, y también puede usar docker-autoheal o algo similar para reiniciar automáticamente estos procesos.

Si está particularmente preocupado por el tiempo de inactividad, el primer pensamiento que lo visitará no debería ser "¿cómo reduzco el tiempo de inactividad al implementar de 1 segundo a 1 milisegundo?), Sino que debería ser" cómo me aseguro de que los cambios en el esquema de la base de datos permitan la reversión si yo en alguna parte en alguna parte?
Y si necesita trabajadores web confiables sin una sola máquina como punto de falla, hay muchas maneras de implementar esto sin Kubernetes.

Mejores prácticas?

De hecho, no existen mejores prácticas en la naturaleza. Solo hay mejores prácticas para cada situación específica. Por lo tanto, si algo está en tendencia y es popular, esto no significa en absoluto que sea la opción correcta para usted específicamente.
En algunos casos, Kubernetes es la mejor opción. El resto es una pérdida de tiempo.

A menos que tenga una gran necesidad de todas estas complejidades, tiene una amplia selección de herramientas que resolverán sus problemas: Docker Compose para una máquina, Hashicorp's Nomad para orquestación, Heroku y sistemas similares para escalar, y algo como Shakemake para calcular tuberías.

Epílogo del Editor

Como proveedor de la nube, nos encontramos regularmente con una amplia variedad de clientes, desde pequeñas startups hasta grandes organizaciones con procesos comerciales complejos y solicitudes de infraestructura relacionadas. Independientemente de cuán buena sea la tecnología, siempre habrá precedentes en los que su aplicación resultará en dificultades innecesarias. Siempre debe proceder de la situación y sopesar cuidadosamente los pros y los contras de las opciones disponibles. El autor del artículo espesó un poco sus colores, pero su mensaje es bastante claro: a veces, para tomar la decisión correcta, vale la pena alejarse de las tendencias y evaluar imparcialmente su proyecto. Esto ahorrará fuerza a los desarrolladores y el uso de los recursos de la compañía lo hará más apropiado.

"¡Usemos Kubernetes!" Ahora tienes 8 problemas