Kubernetes: código abierto frente a proveedor específico

Hola, mi nombre es Dmitry Krasnov. Durante más de cinco años he estado administrando clústeres de Kubernetes y construyendo arquitecturas de microservicios complejas. A principios de este año lanzamos un servicio para gestionar clústeres de Kubernetes basado en Containerum. Aprovechando esta oportunidad, te contaré qué es Kubernetes y en qué se diferencia la integración con un proveedor del código abierto.

Para empezar, que es Kubernetes. Este es un sistema para administrar contenedores en una gran cantidad de hosts. Del griego, por cierto, se traduce como "piloto" o "timonel". Desarrollado originalmente por Google y luego donado como contribución tecnológica a la Cloud Native Computing Foundation, una organización internacional sin fines de lucro que reúne a los principales desarrolladores, usuarios finales y proveedores de tecnología de contenedores del mundo.

Gestionar una gran cantidad de contenedores.

Ahora averigüemos qué tipo de contenedores son estos. Esta es una aplicación con todo su entorno, principalmente las bibliotecas de las que depende el programa. Todo esto está empaquetado en archivos y presentado en forma de imagen que se puede ejecutar independientemente del sistema operativo, probar y más. Pero hay un problema: administrar contenedores en una gran cantidad de hosts es muy difícil. Por eso se creó Kubernetes.

Una imagen de contenedor representa una aplicación más sus dependencias. La aplicación, sus dependencias y la imagen del sistema de archivos del sistema operativo se encuentran en diferentes partes de la imagen, las llamadas capas. Las capas se pueden reutilizar para diferentes contenedores. Por ejemplo, todas las aplicaciones de una empresa pueden utilizar la capa base de Ubuntu. Al ejecutar contenedores, no es necesario almacenar varias copias de una única capa base en el host. Esto le permite optimizar el almacenamiento y la entrega de imágenes.

Cuando queremos ejecutar una aplicación desde un contenedor, las capas necesarias se superponen entre sí y se forma un sistema de archivos superpuesto. Encima se coloca una capa de grabación, que se retira cuando el contenedor se detiene. Esto garantiza que cuando se ejecute el contenedor, la aplicación siempre tendrá el mismo entorno, que no se puede cambiar. Esto garantiza la reproducibilidad del entorno en diferentes sistemas operativos host. Ya sea Ubuntu o CentOS, el entorno siempre será el mismo. Además, el contenedor está aislado del host mediante mecanismos integrados en el kernel de Linux. Las aplicaciones en un contenedor no ven archivos, procesos del host ni de los contenedores vecinos. Este aislamiento de aplicaciones del sistema operativo host proporciona una capa adicional de seguridad.

Hay muchas herramientas disponibles para administrar contenedores en un host. El más popular de ellos es Docker. Le permite proporcionar el ciclo de vida completo de los contenedores. Sin embargo, sólo funciona en un host. Si necesita administrar contenedores en varios hosts, Docker puede hacer la vida un infierno para los ingenieros. Por eso se creó Kubernetes.

La demanda de Kubernetes se debe precisamente a la capacidad de gestionar grupos de contenedores en múltiples hosts como una especie de entidad única. La popularidad del sistema brinda la oportunidad de construir DevOps u Operaciones de Desarrollo, en las que se utiliza Kubernetes para ejecutar los procesos de este mismo DevOps.

Figura 1. Representación esquemática de cómo funciona Kubernetes

Automatización completa

DevOps es básicamente la automatización del proceso de desarrollo. En términos generales, los desarrolladores escriben código que se carga en el repositorio. Luego, este código se puede recopilar automáticamente inmediatamente en un contenedor con todas las bibliotecas, probarlo y "implementarlo" en la siguiente etapa: puesta en escena, y luego inmediatamente en producción.

Junto con Kubernetes, DevOps permite automatizar este proceso para que se produzca prácticamente sin participación de los propios desarrolladores. Debido a esto, la compilación es mucho más rápida, ya que el desarrollador no tiene que hacer esto en su computadora: simplemente escribe un fragmento de código, lo envía al repositorio y luego se inicia la canalización, que puede incluir el proceso. de construcción, prueba e implementación. Y esto sucede con cada confirmación, por lo que las pruebas se realizan continuamente.

Al mismo tiempo, el uso de un contenedor le permite estar seguro de que todo el entorno de este programa se lanzará a producción exactamente en la forma en que se probó. Es decir, no habrá problemas como “había algunas versiones en prueba, otras en producción, pero cuando las instalamos todo se cayó”. Y como hoy en día tenemos una tendencia hacia la arquitectura de microservicios, cuando en lugar de una aplicación enorme hay cientos de aplicaciones pequeñas, para administrarlas manualmente se necesitará una enorme plantilla de empleados. Por eso usamos Kubernetes.

Ventajas, ventajas, ventajas

Si hablamos de las ventajas de Kubernetes como plataforma, entonces tiene importantes ventajas en términos de gestión de arquitectura de microservicios.

• Gestión de múltiples réplicas. Lo más importante es gestionar contenedores en varios hosts. Más importante aún, administre múltiples réplicas de aplicaciones en contenedores como una sola entidad. Gracias a esto, los ingenieros no tienen que preocuparse por cada contenedor individual. Si uno de los contenedores falla, Kubernetes lo verá y lo reiniciará nuevamente.
• Red de clusters. Kubernetes también dispone de la denominada red de clústeres con su propio espacio de direcciones. Gracias a esto, cada pod tiene su propia dirección. Se entiende por subpod la unidad estructural mínima de un cluster en la que se lanzan directamente los contenedores. Además, Kubernetes tiene una funcionalidad que combina un equilibrador de carga y Service Discovery. Esto le permite deshacerse de la administración manual de direcciones IP y delegar esta tarea a Kubernetes. Y los controles de estado automáticos ayudarán a detectar problemas y redirigir el tráfico a módulos que funcionen.
• Gestión de configuración. Cuando se gestiona una gran cantidad de aplicaciones, resulta difícil gestionar la configuración de las aplicaciones. Para ello, Kubernetes dispone de recursos especiales de ConfigMap. Le permiten almacenar configuraciones de forma centralizada y exponerlas a pods cuando ejecuta aplicaciones. Este mecanismo nos permite garantizar la coherencia de la configuración en al menos diez o cien réplicas de aplicaciones.
• Volúmenes persistentes. Los contenedores son inherentemente inmutables y cuando se detiene el contenedor, todos los datos escritos en el sistema de archivos se destruirán. Pero algunas aplicaciones almacenan datos directamente en el disco. Para resolver este problema, Kubernetes tiene una función de gestión de almacenamiento en disco: volúmenes persistentes. Este mecanismo utiliza almacenamiento externo para datos y puede transferir almacenamiento persistente, bloque o archivo, a contenedores. Esta solución le permite almacenar datos por separado de los trabajadores, lo que los guarda si estos mismos trabajadores fallan.
• Equilibrador de carga. Aunque en Kubernetes gestionamos entidades abstractas como Deployment, StatefulSet, etc., en última instancia, los contenedores se ejecutan en máquinas virtuales o servidores de hardware normales. No son perfectos y pueden caer en cualquier momento. Kubernetes verá esto y redirigirá el tráfico interno a otras réplicas. ¿Pero qué hacer con el tráfico que viene del exterior? Si simplemente dirige el tráfico a uno de los trabajadores, si falla, el servicio dejará de estar disponible. Para solucionar este problema, Kubernetes cuenta con servicios como Load Balancer. Están diseñados para configurar automáticamente un equilibrador de nube externo para todos los trabajadores del clúster. Este equilibrador externo dirige el tráfico externo a los trabajadores y monitorea su estado. Si uno o más trabajadores dejan de estar disponibles, el tráfico se redirige a otros. Esto le permite crear servicios de alta disponibilidad utilizando Kubernetes.

Kubernetes funciona mejor cuando ejecuta arquitecturas de microservicios. Es posible implementar el sistema en la arquitectura clásica, pero no tiene sentido. Si una aplicación no puede ejecutarse en varias réplicas, ¿qué diferencia hay entre si en Kubernetes o no?

Kubernetes de código abierto

Kubernetes de código abierto es una gran cosa: lo instalé y funciona. Puede implementarlo en sus propios servidores de hardware, en su propia infraestructura, instalar maestros y trabajadores en los que se ejecutarán todas las aplicaciones. Y lo más importante, todo esto es gratis. Sin embargo, hay matices.

• La primera es la demanda de conocimiento y experiencia de los administradores e ingenieros que implementarán y respaldarán todo esto. Dado que el cliente tiene total libertad de acción en el clúster, él mismo es responsable del funcionamiento del clúster. Y aquí es muy fácil romper todo.
• El segundo es la falta de integraciones. Si ejecuta Kubernetes sin una plataforma de virtualización popular, no obtendrá todos los beneficios del programa. Como el uso de volúmenes persistentes y servicios de equilibrador de carga.

Figura 2. Arquitectura k8s

Kubernetes del proveedor

La integración con un proveedor de nube ofrece dos opciones:

• En primer lugar, una persona puede simplemente hacer clic en el botón "crear clúster" y obtener un clúster ya configurado y listo para usar.
• En segundo lugar, el propio proveedor instala el clúster y configura la integración con la nube.

Cómo sucede aquí. El ingeniero que inicia el clúster especifica 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 de lo cual obtiene acceso al clúster ya formado. En este caso, los trabajadores sobre los que se lanza la carga pasan íntegramente al cliente, pero todo el plano de gestión queda bajo responsabilidad del proveedor (si el servicio se presta según el modelo de servicio gestionado).

Sin embargo, este esquema tiene sus inconvenientes. Debido a que el plano de gestión permanece en manos del proveedor, este no otorga acceso completo al cliente, y esto reduce la flexibilidad al trabajar con Kubernetes. A veces sucede que un cliente quiere agregar alguna funcionalidad específica a Kubernetes, por ejemplo, autenticación vía LDAP, pero la configuración del plano de gestión no lo permite.

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

Qué elegir: código abierto o proveedor

Entonces, ¿Kubernetes es de código abierto o es específico del proveedor? Si tomamos Kubernetes de código abierto, entonces el usuario hace lo que quiere con él. Pero existe una gran posibilidad de pegarse un tiro en el pie. Con el proveedor es más difícil, porque todo está pensado y configurado para la empresa. La mayor desventaja de Kubernetes de código abierto es la necesidad de especialistas. Con una opción de proveedor, la empresa se libera de este dolor de cabeza, pero tendrá que decidir si paga a sus especialistas o al proveedor.

Bueno, las ventajas son obvias, las desventajas también son conocidas. Una cosa es constante: Kubernetes resuelve muchos problemas al automatizar la gestión de muchos contenedores. Y cuál elegir, código abierto o proveedor: cada uno toma su propia decisión.

El artículo fue preparado por Dmitry Krasnov, arquitecto líder del servicio Containerum del proveedor #CloudMTS

Fuente: habr.com