Header Ads Widget

Ticker

6/recent/ticker-posts

Uso de Kubernetes para crear microservicios versátiles


 A menudo se habla de Kubernetes , pero rara vez se entiende por completo en la industria de las API. Esto se debe en gran parte a que la contenedorización , el enfoque principal sobre el que se basa Kubernetes, todavía no es tan ubicuo como el enfoque clásico para el diseño de API y la gestión de recursos. Sin embargo, Kubernetes es posiblemente uno de los sistemas más poderosos que los proveedores de API pueden aprovechar para lograr eficiencia, escalabilidad y modularidad.

Con ese fin, en este artículo, vamos a sumergirnos en lo que realmente es Kubernetes. Definiremos algunos términos clave, contextualizaremos qué son realmente los contenedores y, con suerte, demostraremos el valor inherente que la contenedorización, y especialmente la contenedorización a través de Kubernetes, ofrece a los microservicios de API .

Construyendo un fondo

Para comprender Kubernetes, primero debemos comprender los contenedores en el contexto de las API. Los contenedores son esencialmente un método completamente diferente de manejar aplicaciones y recursos cuando se brinda un servicio al usuario final. El método del contenedor es contrario al enfoque clásico y, como tal, merece cierta discusión.

En el método tradicional , las aplicaciones, las bibliotecas y el núcleo operativo principal existen independientemente entre sí en uno o más servidores. Cuando se llama a una función, la aplicación se comunica a través de la pila del servidor, llamando a los recursos en sus ubicaciones típicamente codificadas. Estas aplicaciones se han implementado en el host mediante algún tipo de administrador de aplicaciones , a menudo integrado en el núcleo del sistema operativo. Esas aplicaciones no siempre se relacionan con una única ubicación de recursos y, en muchos casos, pueden llamar a muchas fuentes dispares e incorporar una enorme maraña de bibliotecas.

Si bien esto funcionó para funciones y aplicaciones más pequeñas, cuando los recursos eran algo limitados y comunes entre las aplicaciones megalíticas masivas, la industria de microservicios ha hecho que este enfoque ya no sea manejable. Tener múltiples versiones de ejecutables y bibliotecas con varias bases de código versionadas da como resultado una complejidad e ineficacia crecientes dentro del enfoque clásico.

La respuesta a esto es el contenedor . En un enfoque de contenedor , cada aplicación se empaqueta en un contenedor a menudo efímero, que tiene solo la biblioteca mínima requerida para su función. Esto evita el exceso de contenido, los ejecutables copiados y las bibliotecas complejas, y hace que la administración de cada contenedor sea mucho más fácil. Cada contenedor es funcionalmente un paquete de aplicación autónomo , que funciona de forma independiente de todos los demás, pero sigue informando al kernel general u otra fuente de orquestación para sus órdenes base.

Por lo tanto, los contenedores utilizan la virtualización a nivel de sistema operativo a través de un hipervisor, que ofrece lo mejor del enfoque clásico, al tiempo que reduce la hinchazón y permite una administración más eficiente, brindando los principales beneficios de los microservicios a nivel local.

Lea también: ¿Debería comenzar con un monolito o microservicios?

¿Qué es Kubernetes?

Logotipo de Kubernetes

Para obtener más información, visite el sitio web Kubernetes.io .

Ahora que entendemos los contenedores, deberíamos ver cómo Kubernetes implementa específicamente el concepto. Si bien la antigua metodología era demasiado compleja, ofrecía un control centralizado . Ahora bien, si los contenedores están destinados a segmentar contenido, ¿cómo podemos establecer el control? En Kubernetes específicamente, necesitamos orquestar funciones en muchos contenedores, automatizar la implementación , manejar automáticamente la replicación, escalar nuestros contenedores y más. Entonces, con estos requisitos, ¿cómo hace exactamente Kubernetes todo esto?

Términos clave

Para resolver esto, definamos algunos términos clave.

Clusters

Los clústeres son grupos de servidores físicos o máquinas virtuales que tienen el sistema Kubernetes como administrador principal. Cada clúster está formado por varias partes clave, que definiremos en breve. En pocas palabras, el clúster es esencialmente una combinación entre los nodos, que contienen el sistema Kubernetes real, y el maestro Kubernetes, que incluye un servidor API para procesar comandos y un controlador de replicación, que se detallará a continuación.

Vainas

Los pods son la unidad funcional implementable más pequeña en el lenguaje de Kubernetes y son esencialmente la "unidad" de Kubernetes. El pod contiene un grupo de contenedores: cada contenedor en el mismo pod comparte el mismo espacio de nombres de red y se comunican entre sí mediante el sistema de host local.

Los pods son efímeros , lo que significa que normalmente no persisten en términos de almacenamiento de datos. En cambio, los Pods son replicados o destruidos a pedido por el Controlador de Replicación antes mencionado, adoptando dinámicamente en escala al recuento de recursos requerido.

Las vainas se pueden etiquetar con etiquetas . Una etiqueta es un par clave / valor que define los atributos del propio pod. Estas etiquetas permiten a los usuarios etiquetar pods utilizando etiquetas personalizadas, describiendo exactamente qué son y determinando cómo son tratados por las políticas establecidas en los Controladores de replicación.

Lea también: Por qué un backend sin servidor es mejor para la escalabilidad

Controladores de replicación

Los controladores de replicación permiten el monitoreo de pods dentro del clúster y son el principal orquestador del sistema Kubernetes en general. Cuando se configura el controlador de replicación, se le asigna un conjunto de políticas mediante las cuales se dictan sus funciones y, a través de estas restricciones, los pods se administran en conjunto entre sí.

Si el controlador de replicación tiene una cantidad específica de pods configurados para la creación, y un pod se destruye por cualquier motivo, el controlador de replicación destruirá automáticamente el servidor sobrante y equilibrará el tráfico de manera adecuada utilizando los servicios de equilibrio de carga internamente. Si el controlador de replicación observa que se demandan más pods pero hay un número menor en servicio actualmente, también puede activar pods adicionales para satisfacer la demanda.

Esencialmente, el controlador de replicación se asegura de que, en cualquier momento, se cumplan las políticas que se le han dado. Lo hace a través de dos elementos simples: la plantilla de pod , que se utiliza para activar nuevos pods o destruirlos, y funciona en un estado y especificación determinados, y las etiquetas , que se utilizan para determinar qué pods supervisará realmente el controlador de replicación y encargarse de.

Servicios

Los servicios son utilizados por Kubernetes para crear una capa de abstracción entre las vainas y el recurso solicitando. Debido a que los pods son efímeros, no siempre se puede esperar un esquema de direcciones IP estático y estable. Incluso cuando usa Volúmenes , que son almacenamiento estático, es probable que tenga Pods que se vinculen con esos Volúmenes y, como tal, necesita alguna metodología para acceder a los Pods.

Los Servicios de Kuberentes definen un conjunto lógico de pods y la política mediante la cual se accede a esos pods . La forma más fácil de pensar en este Servicio es considerarlo como lo haría con un servidor DNS, donde un Pod se etiqueta y organización lógicamente, y el acceso se resuelve entre el solicitante de ese recurso y el recurso en sí. La utilización de un método continuo de identificación sin exigir un esquema de dirección IP estática permite pods efímeros sin exigir un sistema de direccionamiento constante y estable real.

Nodos

Un nodo , como se indicó anteriormente, es una máquina física o virtual. En términos de Kubernetes, a menudo se lo denomina " trabajador de Kubernetes ". Un trabajador está formado por tres componentes principales.

El primero de estos componentes es el método mediante el cual se forma realmente el recipiente, separando el contenido. La mayoría de las veces, esto es algo así como Docker o Rocket, y en realidad es una conversación separada de Kubernetes; para obtener más información sobre Docker, puede encontrar un artículo anterior aquí .

El segundo de esos tres componentes principales es el proxy kube . El kube-proxy es un método de Servicios mediante el cual se establecen conexiones de proxy. El proxy de red de Kubernetes maneja el reenvío y manejo de TCP / UDP para contenedores vinculados, y también se puede vincular a un complemento opcional para la administración de DNS del clúster .

Finalmente, Kubelet es el agente de nodo principal y funcionalmente es el método principal mediante el cual se gestionan los contenedores. Cuando hablamos de la administración de contenedores, realmente estamos hablando del proceso que iniciaron Kubelet y Kubernetes Master.

Lea también: El presente y el futuro de la gestión de la configuración

Maestro de Kubernetes

El maestro de Kubernetes es donde reside realmente el servidor API de Kubernetes, y también es donde reside técnicamente el controlador de replicación. En muchos sentidos, el maestro de Kubernetes es la “pieza principal” del rompecabezas de Kubernetes, con el nodo funcionando como contenedor y el maestro de Kubernetes como el nodo principal de administración y procesamiento.

Advertencias de Kubernetes

Ahora que entendemos aproximadamente cómo funciona Kubernetes, debemos identificar cualquier problema potencial en su adopción. Kubernetes es extremadamente popular y bastante maduro, pero eso no significa que sea perfecto. Kuberentes es bastante difícil de instalar y configurar , especialmente en comparación con las implementaciones relativamente más limitadas como Docker.

Si bien Docker está limitado por su API, facilita la configuración y, por esa razón, muchos lo preferirían. Dicho esto, Kubernetes cuenta con métodos internos de registro y monitoreo , algo que Docker en realidad no tiene, y algo que Docker necesita para aprovechar las herramientas de terceros para lograrlo. Por supuesto, esto significa que si bien la configuración de Docker puede parecer más fácil, a menudo hay obstáculos adicionales que deben superarse si se va a usar Docker solo, negando gran parte de la facilidad que parece tan evidente.

Kubernetes tiene algunos inconvenientes que deben tenerse en cuenta. Quizás el mayor de ellos es el hecho de que Kubernetes suele tener un procesador pesado en implementaciones más grandes, lo que significa que cuanto más escala, más procesamiento se requiere en comparación con las soluciones tradicionales (y en algunos casos, incluso con métodos alternativos de contenedorización). Sigue siendo muy eficiente y eficaz en términos de escala, pero podría perder algunas de estas eficiencias en ciertas escalas.

También debe tenerse en cuenta que Docker y Kubernetes pueden, por supuesto, usarse en concierto . Dicho esto, en cierto punto, se enfrentará a rendimientos decrecientes: Docker no necesariamente organiza mejor que la orquestación de Kubernetes que pretende reemplazar y, como tal, muchos proveedores pueden enfrentarse a la pregunta de por qué ' Incluso estás intentando utilizar la metodología de Docker en primer lugar.

Utilizando Kubernetes con API

Kubernetes, y los contenedores en general, son perfectos para el enfoque de microservicio de API . Dado que los contenedores permiten el empaquetado de la funcionalidad y solo las dependencias que se necesitan para esa funcionalidad, los microservicios pueden hacerse más portátiles y modulares utilizando Kubernetes que dependiendo de otras metodologías.

Esto también significa que los microservicios se pueden simplificar , solo activando instancias y recursos adicionales cuando sea necesario, en lugar de implementarlos a mano y equilibrar la carga entre las propiedades existentes cuando se requiere su uso. Esto da como resultado una reducción de la redundancia y, en última instancia, una mayor calidad de peso ligero del sistema en términos colectivos.

También hay un gran beneficio para la seguridad que debería discutirse. La mayoría de los servicios no lo llaman "sandboxing", pero eso es exactamente lo que es la contenedorización: segmentar recursos y aplicaciones de otras fuentes y aplicaciones. Esto significa que cada uno se ejecuta en su propio sistema separado , pero se suman entre sí para llegar a ser más grandes que la suma de sus partes.

Finalmente, y quizás lo más importante, Kubernetes ofrece un desarrollo rápido y una iteración más sencilla. Dado que cada contenedor es modular y portátil, y cada contenedor puede aumentarse y replicarse fácilmente de forma individual de cada uno de los otros contenedores, las nuevas API se pueden probar de forma modular, en pilas variables y con los recursos activados solo cuando se requieran.

En última instancia, utilizar la contenedorización es una buena idea para los microservicios de API y, de las opciones disponibles, Kubernetes es sin duda una buena opción.

Conclusión

Kubernetes puede ser difícil de configurar, pero en última instancia, vale la pena el esfuerzo. La contenedorización es un elemento importante del formato de API de microservicio moderno y, debido a su presencia más moderna y ubicua en la industria, es difícil argumentar contra Kubernetes. Ofrece escalabilidad y modularidad que es extremadamente valiosa para los proveedores de API y, a pesar de sus requisitos de procesador relativamente intensivos, en última instancia cuenta con mayores beneficios que inconvenientes.

Publicar un comentario

0 Comentarios