Kubernetes

Load balancer con Kubernetes

 
La funcionalidad «load balancing» o de balanceo de carga es compatible con la solución Kubernetes, el orquestador de contenedores líder del mercado que permite automatizar el despliegue de aplicaciones en un cluster, independientemente de si los servidores son físicos o no.
 

Gracias a Kubernetes las empresas pueden centrarse en el desarrollo de su software gracias en buena parte a la simplificación de numerosas tareas.

Icons/concept/Lines/Line Communicating Created with Sketch.

L’automatisation du cycle de vie des applications conteneurisées

Ces services ont besoin d’être mis à l’échelle, afin de suivre la demande et d’optimiser leur usage des ressources. Kubernetes permet donc d’automatiser cette étape. Cela assure un déploiement continu (CI/CD) de nouvelles versions et réduit drastiquement la maintenance.

Icons/concept/Container Created with Sketch.

Le déploiement d’applications multi-conteneurs (multi-containers)

Certains logiciels peuvent utiliser plusieurs conteneurs à la fois (bases de données, front end, back end, cache…). Cette situation nécessite parfois de posséder plusieurs instances. Kubernetes apporte alors de la synchronisation lors du déploiement, entre les différents conteneurs et composants liés.

Icons/concept/Component/Component Square Created with Sketch.

Le lancement depuis n’importe quel environnement

Cloud public, cloud privé, serveur physique ou virtuel : Kubernetes s’implémente facilement, même dans une architecture hybride. Il offre une plus grande liberté à vos projets, en fonction de leur environnement.

¿Qué es un load balancer?

Un «load balancer» o balanceador de carga permite repartir la carga de trabajo entre los diferentes servidores o aplicaciones y puede instalarse en una infraestructura tanto física como virtual. Así pues, los programas de load balancing adoptan la forma de un controlador de entrega de aplicaciones o ADC (del inglés «aplicación delivery controller»), permitiendo al usuario escalar la carga automáticamente en función de las previsiones de tráfico.

El ADC identifica en tiempo real qué servidores o aplicaciones son las más adecuadas para responder a una petición, garantizando un nivel de rendimiento estable en el cluster. En caso de avería, es posible redirigir el tráfico hacia otro recurso con capacidad para absorberlo. Así pues, existen diferentes configuraciones posibles.

El load balancer interviene entre el visitante y el servidor analizando las peticiones, determinando qué máquina está disponible para responder y, por último, transmitiendo estas peticiones. También es posible añadir servidores en caso de necesidad.

El balanceo de carga, como acabamos de ver, es solo una de las posibles aplicaciones del load balancer. Y es que esta tecnología también resulta especialmente útil para descongestionar un certificado SSL, actualizar grupos de aplicaciones o incluso enrutar sus dominios.

Existen dos tipos de load balancers:

  • Load balancers L4 o balanceadores de carga de red

Estos balanceadores tratan los datos de la capa («layer») 4 que están presentes a nivel de red y transporte (TCP/UDP). Así pues, los balanceadores de carga no se centran en la información aplicativa, como el tipo de contenido, las cookies, la localización de los headers, etc., sino que redirigen el tráfico basándose en los datos de la capa de red.

  • Load balancers L7 o balanceadores de carga de aplicación

A diferencia de los L4, estos balanceadores redirigen el tráfico basándose en los parámetros de la capa de aplicación, por lo que tratan un volumen de datos superior y utilizan una mayor cantidad de información, incluyendo, por ejemplo, los protocolos HTTP, HTTPS y SSL.

Load Balancer OVHcloud

¿Cómo funciona el load balancer con Kubernetes?

Si utilizamos Kubernetes en nuestras aplicaciones, el tráfico externo es un factor importante. Aunque el sitio web oficial de Kubernetes ofrece información al respecto, incluimos a continuación algunos de los aspectos que debemos tener en cuenta.

Existen diversas formas de dirigir el tráfico externo hacia el cluster:

  • utilizar un proxy con el ClusterIP;
  • definir un servicio como NodePort;
  • declarar un servicio como load balancer y exponerlo al tráfico externo (este método es el más utilizado).

Utilizar el ClusterIP a través de un proxy

Este método, disponible por defecto en Kubernetes, se utiliza generalmente en desarrollo. La apertura de un proxy entre la fuente externa y el ClusterIP le permitirá enrutar el tráfico. Es posible utilizar el comando «kubectl» para crear el proxy. Una vez que esté operativo, se conectará directamente a la IP de su cluster para este servicio específico.

Exponer un servicio como NodePort

Este método le permitirá exponer las direcciones de sus nodos individualmente en los puertos correspondientes (un puerto fijo del servicio de 30000 a 32767). De este modo podrá acceder al servicio externamente desde su propio puerto, en cada nodo. Para ello, utilice el siguiente comando: <NodeIp>:<NodePort>

Aunque es posible, este método puede resultar relativamente complejo para los servicios en producción. Y es que, al utilizar puertos «no estándar», suele ser necesario configurar un balanceador de carga externo que trate los puertos estándar y redirija el tráfico hacia la petición «<NodeIp>:<NodePort>».

Utilizar un load balancer

Este método consiste en declarar un servicio como load balancer para el cluster exponiéndolo al tráfico externo y requiere utilizar una solución de balanceo de carga de un proveedor de cloud, como nuestro Load Balancer, que aprovisionará el servicio para el cluster asignándole automáticamente su NodePort.

Si dispone de un entorno de producción, el load balancer es la solución más recomendable. No obstante, deberá tener en cuenta dos aspectos importantes:

  • cada servicio definido y desplegado como load balancer dispondrá de su propia dirección IP;
  • el uso del Load Balancer de OVHcloud se reserva en exclusiva a los usuarios del servicio Managed Kubernetes.

El balanceador de carga actúa como un filtro entre el tráfico externo entrante y el cluster Kubernetes. Es posible desplegar hasta 16 load balancers por cluster y gestionarlos directamente desde la interfaz K8s. Si necesita ayuda, puede consultar nuestras guías sobre cómo configurar un balanceador de carga.

Añadir un Ingress con el load balancer

El Ingress es un objeto Kubernetes que gestiona el acceso a los servicios del cluster desde el exterior (como un protocolo HTTP). Pero, entonces, ¿en qué se diferencia del load balancer?

El Ingress, como punto único de entrada al cluster, funciona como un proxy inverso dirigiendo las peticiones que pasan por él hacia los diferentes servicios de acuerdo con una configuración de reglas. Está expuesto al tráfico externo a través de ClusterIP, NodePort o un load balancer. El Ingress más conocido es NGINX Ingress Controller.

Utilizar un Ingress con su load balancer le permitirá reducir los costes, ya que la facturación del balanceador dependerá del número de servicios que orquesta, con una capacidad limitada. Por lo tanto, con un Ingress podrá asociar más servicios a un mismo load balancer y reducir así los costes asociados.

¿Cuál es la mejor opción?

Para poder responder a esta pregunta debemos analizar en primer lugar el uso que haremos de la solución Kubernetes.

El load balancer se adapta a la mayoría de los usos, por lo que podrá definir un balanceador de forma personalizada para cada servicio Kubernetes, sin tener que configurarlo posteriormente. Sin embargo, este método no se adapta a todos los bolsillos, ya que requiere una gestión compleja de un gran número de direcciones IP.

Para una mayor simplicidad, puede utilizar un load balancer y un Ingress. De este modo, todos los servicios se almacenarán bajo la misma dirección IP y usted solo tendrá que pagar por un load balancer. No obstante, si elige esta opción, deberá asegurarse de que los servicios orquestados en este modelo mantienen una relación lógica entre ellos, ya que, de lo contrario, podrían producirse fallos de funcionamiento o averías.

Una configuración óptima podría consistir en un load balancer combinado con un Ingress para cada «familia de servicios» o de microservicios. La organización dependerá, en última instancia, de la complejidad de sus arquitecturas.