🥇Kubernetes: de código abierto contra con proveedor

Hola, me llamo Dmitry Krasnov. Llevo más de cinco años administrando clústeres de Kubernetes y construyendo arquitecturas de microservicios complejas. A principios de este año, lanzamos un servicio de gestión de clústeres de Kubernetes basado en Containerum. Aprovechando la oportunidad, voy a contarles qué es Kubernetes y en qué se diferencia la integración con un proveedor, en comparación con el código abierto.

Para empezar, ¿qué es Kubernetes? Es un sistema para gestionar contenedores en un gran número de hosts. En griego, de hecho, se traduce como 'piloto' o 'timón'. Fue desarrollado originalmente por Google y luego se entregó a la Cloud Native Computing Foundation, una organización internacional sin fines de lucro que agrupa a los principales desarrolladores, usuarios finales y proveedores de tecnologías de contenedores.

Gestionar un gran número de contenedores

Ahora veamos qué son esos contenedores. Es una aplicación junto con todo su entorno: principalmente, las bibliotecas de las que depende el funcionamiento del programa. Todo esto está empaquetado en archivos y presentado en forma de una imagen que se puede ejecutar independientemente del sistema operativo, probar y más. Pero hay un problema: gestionar contenedores en un gran número de hosts es muy complicado. Por eso se creó Kubernetes.

La imagen de un contenedor representa una aplicación más sus dependencias. La aplicación, sus dependencias y la imagen del sistema de archivos del SO están ubicadas en diferentes partes de la imagen, llamadas capas. Las capas pueden reutilizarse para diferentes contenedores. Por ejemplo, todas las aplicaciones en la empresa pueden usar una capa base de Ubuntu. Al iniciar contenedores, no es necesario almacenar en el host múltiples copias de una misma capa base. Esto permite optimizar el almacenamiento y la entrega de imágenes.

Cuando queremos iniciar una aplicación desde un contenedor, las capas necesarias se superponen entre sí y se forma un sistema de archivos de superposición. Arriba se superpone una capa de escritura que, al detener el contenedor, se elimina. Esto garantiza que, al iniciar el contenedor, la aplicación siempre tendrá el mismo entorno, que no puede ser modificado. Esto asegura la reproducibilidad del entorno en diferentes sistemas operativos anfitriones. Ya sea Ubuntu o CentOS, el entorno siempre será el mismo. Además, el contenedor está aislado del host mediante mecanismos integrados en el núcleo de Linux. Las aplicaciones en el contenedor no ven los archivos ni los procesos del host o de otros contenedores. Este aislamiento de las aplicaciones del sistema operativo host proporciona una capa adicional de seguridad.

Para gestionar contenedores en el host, hay muchas herramientas disponibles. La más popular de ellas es Docker. Permite gestionar el ciclo de vida completo de los contenedores. Sin embargo, solo funciona en un solo host. Si se requiere gestionar contenedores en múltiples hosts, Docker puede convertir la vida de los ingenieros en un infierno. Por eso se creó Kubernetes.

La demanda de Kubernetes se debe precisamente a su capacidad para gestionar grupos de contenedores en múltiples hosts como si fueran entidades únicas. La popularidad del sistema radica en la posibilidad de construir DevOps o Desarrollo de Operaciones, en los que Kubernetes se utiliza para ejecutar los procesos de este mismo DevOps.

Figura 1. Representación esquemática del principio de funcionamiento de Kubernetes

Automatización completa

DevOps, en esencia, representa la automatización del proceso de desarrollo. En términos simples, los desarrolladores escriben código que se sube a un repositorio. Luego, este código puede ser ensamblado automáticamente en un contenedor con todas las bibliotecas, probado y 'desplegado' a la siguiente fase: Staging, y luego directamente a Production.

Junto con Kubernetes, DevOps permite automatizar este proceso para que se lleve a cabo prácticamente sin la intervención de los propios desarrolladores. Esto acelera considerablemente la construcción, ya que al desarrollador no le corresponde ocuparse de ello en su computadora: simplemente escribe un fragmento de código, sube el código al repositorio y se inicia el pipeline, que puede incluir el proceso de construcción, pruebas y despliegue. Esto sucede con cada commit, por lo que las pruebas se llevan a cabo de manera continua.

Además, el uso de un contenedor garantiza que todo el entorno de este programa se aprovisionará en producción exactamente en la misma forma en que se probó. Es decir, no surgirán problemas del tipo "en pruebas había una versión, en producción hay otra y al implementarlo, todo falla". Y dado que hoy en día tenemos la tendencia hacia la arquitectura de microservicios, donde en lugar de una sola aplicación grande hay cientos de aplicaciones pequeñas, administrar todo esto manualmente requeriría un enorme número de empleados. Por eso utilizamos Kubernetes.

Ventajas, ventajas, ventajas

Si hablamos de las ventajas de Kubernetes como plataforma, tiene grandes beneficios desde el punto de vista de la gestión de arquitecturas de microservicios.

Gestión de múltiples réplicas. Lo más importante es la gestión de contenedores en múltiples hosts. Y lo que es más importante, la gestión de múltiples réplicas de aplicaciones en contenedores como una única entidad. Gracias a esto, los ingenieros no tienen que preocuparse por cada contenedor individual. Si uno de los contenedores falla, Kubernetes lo detectará y lo reiniciará.
Red de clústeres. Kubernetes también cuenta con lo que se llama una red de clústeres con su propio espacio de direcciones. Gracias a esto, cada pod tiene su propia dirección. Un pod se entiende como la unidad estructural mínima de un clúster, en la que se inician directamente los contenedores. Además, Kubernetes tiene funcionalidad que combina un equilibrador de carga y Discovery de Servicios. Esto permite eliminar la gestión manual de direcciones IP y delegar esta tarea a Kubernetes. Los chequeos de salud automáticos ayudarán a detectar problemas y redirigir el tráfico a los pods activos.
Gestión de configuraciones. Al gestionar una gran cantidad de aplicaciones, se vuelve complicado administrar la configuración de las mismas. Para esto, en Kubernetes existen recursos especiales llamados ConfigMap. Estos permiten almacenar configuraciones de manera centralizada y aplicarlas a los pods al iniciar las aplicaciones. Este mecanismo garantiza la consistencia de la configuración, ya sea en diez o en cien réplicas de aplicaciones.
Volúmenes Persistentes. Los contenedores son, por naturaleza, inmutables y al detener un contenedor, todos los datos almacenados en el sistema de archivos serán destruidos. Sin embargo, algunas aplicaciones almacenan datos directamente en el disco. Para resolver este problema, Kubernetes cuenta con la funcionalidad de gestión del almacenamiento en disco: Volúmenes Persistentes. Este mecanismo utiliza almacenamiento externo para los datos y puede proporcionar almacenamiento persistente, ya sea en bloques o en archivos, a los contenedores. Esta solución permite almacenar los datos separadamente de los trabajadores, salvándolos en caso de que estos fallan.
Balanceador de Carga. A pesar de que en Kubernetes gestionamos entidades abstractas como Deployment, StatefulSet, etc., al final, los contenedores se ejecutan en servidores físicos o virtuales. No son perfectos y pueden fallar en cualquier momento. Kubernetes detectará esto y redirigirá el tráfico interno a otras réplicas. Pero, ¿qué hacer con el tráfico que proviene del exterior? Si simplemente dirigimos el tráfico a uno de los trabajadores, en caso de que falle, el servicio se volverá inaccesible. Para abordar este problema, Kubernetes cuenta con servicios de tipo Balanceador de Carga. Están destinados a configurar automáticamente un balanceador de carga en la nube externa para todos los trabajadores en el clúster. Este balanceador externo dirige el tráfico externo a los trabajadores y supervisa su estado. Si uno o varios trabajadores se vuelven inaccesibles, el tráfico se redirige a otros. Esto permite crear servicios altamente disponibles utilizando Kubernetes. máquinas virtuales Kubernetes se desempeña mejor al lanzar arquitecturas de microservicios. Implementar el sistema en una arquitectura clásica es posible, pero sin sentido. Si una aplicación no puede funcionar en varias réplicas, ¿cuál es la diferencia de estar en Kubernetes o no?

Kubernetes de código abierto.

Kubernetes

Kubernetes de código abierto es una excelente herramienta: se instala y funciona. Se puede desplegar en servidores propios, en la infraestructura propia, instalar un maestro y trabajadores donde se ejecutarán todas las aplicaciones. Y lo mejor de todo, es que es completamente gratis. Sin embargo, hay matices.

El primero es la exigencia de conocimientos y experiencia de los administradores e ingenieros que desplieguen y mantengan todo esto. Dado que el cliente tiene total libertad de acción en el clúster, asume la responsabilidad por su funcionamiento. Y es muy fácil romper todo aquí.
El segundo es la falta de integraciones. Si se ejecuta Kubernetes sin alguna plataforma de virtualización popular, no se obtendrán todas las ventajas del programa. Tales como el uso de volúmenes persistentes y servicios de balanceo de carga.

Figura 2. Arquitectura de k8s

Kubernetes del proveedor

La integración con el proveedor de nube ofrece dos posibilidades:

En primer lugar, la persona puede simplemente presionar el botón 'crear clúster' y obtener un clúster ya configurado y listo para usar.
En segundo lugar, el proveedor mismo instala el clúster y configura la integración con la nube.

Así es como sucede en nuestro caso. El ingeniero que lanza el clúster indica cuántos trabajadores necesita y con qué parámetros (por ejemplo, 5 trabajadores, cada uno con 10 CPU, 16 GB de RAM y, digamos, 100 GB de disco). Después, obtiene acceso a un clúster ya formado. En este proceso, los trabajadores en los que se ejecuta la carga son completamente entregados al cliente, pero todo el plano de gestión permanece bajo la responsabilidad del proveedor (en caso de que el servicio se ofrezca bajo el modelo de servicio administrado).

Sin embargo, este esquema tiene sus desventajas. Debido a que el plano de gestión queda con el proveedor, este no concede acceso completo al cliente, lo que reduce la flexibilidad al trabajar con Kubernetes. A veces, el cliente desea implementar alguna funcionalidad específica en Kubernetes, como autenticación a través de LDAP, pero la configuración del plano de gestión no lo permite.

Figura 3. Ejemplo de clúster de Kubernetes de un proveedor de nube

¿Qué elegir: código abierto o de proveedor?

Entonces, ¿Kubernetes de código abierto o con proveedor? Si se opta por Kubernetes de código abierto, el usuario puede hacer lo que quiera. Pero existe un alto riesgo de que se dispare en el pie. Con el de proveedor, esto es más complicado, ya que todo está bien pensado y configurado por la empresa. El mayor inconveniente de Kubernetes de código abierto es la necesidad de especialistas. Con el proveedor, la empresa se libera de este dolor de cabeza, pero tendrá que decidir: si pagar a sus propios especialistas o al proveedor.

Bueno, los pros son evidentes y los contras también son conocidos. Una cosa permanece constante: Kubernetes resuelve un montón de problemas automatizando la gestión de muchos contenedores. ¿Cuál elegir, el de código abierto o el del proveedor? — cada uno toma su propia decisión.