Get best of the week

Kubernetes: código abierto vs vendedor

Hola, me llamo Dmitry Krasnov. Durante más de cinco años, he estado administrando clústeres de Kubernetes y construyendo arquitecturas complejas de microservicios. A principios de este año, lanzamos el servicio de administración de clúster Kubernetes basado en Containerum. Aprovechando esta oportunidad, te diré qué es este Kubernetes y cómo la integración con el proveedor difiere del código abierto.

Para empezar, ¿qué 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". Originalmente desarrollado por Google, después de lo cual se transfirió la Cloud Native Computing Foundation, una organización internacional sin fines de lucro que reúne a los principales desarrolladores mundiales, usuarios finales y proveedores de tecnología de contenedores, como una contribución tecnológica.



Dirige una gran cantidad de contenedores


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

Una imagen de contenedor es 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, para todas las aplicaciones de la empresa, se puede usar la capa base de Ubuntu. Al iniciar contenedores, no es necesario almacenar varias copias de una capa base en el host. Esto le permite optimizar el almacenamiento y la entrega de imágenes.

Cuando queremos iniciar la aplicación desde el contenedor, las capas necesarias se superponen entre sí y se forma un sistema de archivos superpuestos. Una capa para grabar se superpone en la parte superior, que, cuando se detiene el contenedor, se elimina. Esto garantiza que cuando inicie 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 utilizando los mecanismos integrados en el kernel de Linux. Las aplicaciones en el contenedor no ven archivos, procesos del host y contenedores vecinos. Este aislamiento de aplicaciones del sistema operativo host proporciona una capa adicional de seguridad.

Existen muchas herramientas para administrar contenedores en el host. El más popular de estos es Docker. Le permite garantizar el ciclo de vida completo de los contenedores. Sin embargo, solo funciona en un host. Si necesita administrar contenedores en varios 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 la capacidad de dirigir grupos de contenedores en varios hosts como algunas entidades individuales. La popularidad del sistema proporciona la capacidad de construir DevOps u Operaciones de desarrollo, en las que Kubernetes se utiliza para iniciar los procesos de este DevOps.



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

Automatización completa


DevOps, en principio, es una automatización del proceso de desarrollo. En términos generales, los desarrolladores escriben código que se vierte en el repositorio. Luego, este código puede recopilarse automáticamente de inmediato en un contenedor con todas las bibliotecas, probarse y desplegarse a la siguiente etapa: Puesta en escena y luego inmediatamente a Producción.

Junto con Kubernetes, DevOps le permite automatizar este proceso para que continúe con poca o ninguna participación de los propios desarrolladores. Debido a esto, el ensamblaje se acelera significativamente, ya que el desarrollador no tiene que hacer esto en su computadora: solo escribe un fragmento de código, inserta el código en el repositorio y luego comienza la canalización, que puede incluir el proceso de ensamblaje, prueba y despliegue. Y esto sucede con cada confirmación, por lo que las pruebas están en curso.

Al mismo tiempo, el uso del contenedor le permite estar seguro de que todo el entorno de este programa entrará en producción exactamente en la forma en que se probó. Es decir, no habrá problemas de la categoría "en la prueba hubo algunas versiones, en producción, otras, pero cuando se configuró, todo cayó". Y dado que hoy tenemos una tendencia hacia la arquitectura de microservicios, cuando en lugar de una gran aplicación hay cientos de pequeñas, para administrarlas manualmente, necesitará un gran personal. Por eso usamos Kubernetes.

Pros, Pros, Pros


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

  • . — . , — . . , Kubernetes .
  • . Kubernetes . . , . Kubernetes , Service Discovery. IP- Kubernetes. health check` .
  • . . Kubernetes ConfigMap`. . , .
  • Persistent Volumes. , , . . Kubernetes — Persistent Volumes. , , . , .
  • Load Balancer. , Kubernetes Deployment, StatefulSet .., . . Kubernetes . , ? , . Kubernetes Load Balancer. . . , . Kubernetes.

Kubernetes es el mejor en el lanzamiento de arquitecturas de microservicios. Implementar un sistema en la arquitectura clásica es posible, pero no tiene sentido. Si la aplicación no puede funcionar en varias réplicas, ¿cuál es la diferencia, en Kubernetes o no?

Kubernetes de código abierto


El código abierto Kubernetes es una gran cosa: se instaló y funciona. Puede implementar en sus servidores de hierro, en su infraestructura, poner asistentes y trabajadores en los que se ejecutarán todas las aplicaciones. Y lo más importante: todo esto es gratis. Sin embargo, hay matices.

  • El primero es la precisión del conocimiento y la experiencia de los administradores e ingenieros que implementarán y acompañarán todo esto. Dado que el cliente recibe total libertad de acción en el clúster, tiene la responsabilidad de la operatividad del clúster. Y romper todo aquí es muy simple.
  • El segundo es la falta de integración. Si ejecuta Kubernetes sin alguna plataforma de virtualización popular, no obtendrá todos los beneficios del programa. Tales como el uso de servicios de Volumen persistente y equilibrador de carga.



Figura 2. La arquitectura k8s

Kubernetes del vendedor


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

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

¿Cómo está pasando esto con nosotros? El ingeniero que inicia 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, por ejemplo, 100 GB de disco). Luego obtiene acceso al clúster ya formado. Al mismo tiempo, los trabajadores en los que se lanza la carga se entregan completamente al cliente, pero todo el plano de gestión permanece en el área de responsabilidad del proveedor (si el servicio se proporciona de acuerdo con el modelo de servicio gestionado).

Sin embargo, tal esquema tiene sus inconvenientes. Debido al hecho de que el plano de gestión permanece con el proveedor, el proveedor no le da acceso completo al cliente, y esto reduce la flexibilidad para trabajar con Kubernetes. A veces sucede que el cliente desea adjuntar alguna funcionalidad específica a Kubernetes, por ejemplo, autenticación a través de LDAP, y la configuración del plano de administración no lo permite.



Figura 3. Un ejemplo de clúster de Kubernetes de un proveedor de la nube

Qué elegir: código abierto o proveedor


Entonces, ¿Kubernetes o proveedor de código abierto? Si tomamos Kubernetes de código abierto, entonces el usuario quiere hacer lo que hace. Pero una gran oportunidad de pegarse un tiro en la pierna. Con los vendedores, esto es más complicado, porque todo está pensado y configurado para la empresa. El mayor inconveniente de Kubernetes de código abierto es el requisito de especialistas. Con un proveedor, la empresa se libra de este dolor de cabeza, pero tendrá que decidir si pagar a sus especialistas o al proveedor.





Bueno, los pros son obvios, los contras también son conocidos. Invariablemente, una cosa: Kubernetes resuelve muchos problemas al automatizar la gestión de múltiples contenedores. Y cuál elegir, código abierto o proveedor: todos deciden por sí mismos.

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

More articles:


All Articles