Exposición de aplicaciones con Services

En Kubernetes, los Pods son las unidades desplegables más pequeñas. Están diseñados para ser temporales y Kubernetes puede crearlos, destruirlos o moverlos en cualquier momento.

Esta flexibilidad es excelente para la resiliencia, pero plantea un desafío: ¿cómo pueden otras aplicaciones encontrar y comunicarse de forma fiable con estos Pods que cambian constantemente?

Cada Pod obtiene su propia dirección IP. Cuando un Pod se reinicia o escala, suele obtener una nueva dirección IP. ¡Conectarse directamente a la IP de un Pod es como intentar acertar a un objetivo móvil!

Imagine una aplicación web con varios Pods. Si uno de ellos se reinicia, su IP cambia y se interrumpen las conexiones de otros servicios o usuarios.

¡Aquí entran en juego los Services de Kubernetes! Un Service proporciona un punto de conexión de red estable y fijo para un conjunto de Pods.

Considérelo como una dirección permanente para su aplicación, aunque los Pods que hay detrás cambien constantemente sus direcciones individuales.

Un Service actúa como una capa de abstracción sobre un grupo de Pods. Les proporciona una única dirección IP y un nombre DNS coherentes.

• Otras aplicaciones utilizan la IP o el nombre estable del Service.
• El Service dirige entonces el tráfico a los Pods saludables que administra.
• Esto desacopla a los clientes de las IP individuales de los Pods.

¿Cómo sabe un Service a qué Pods debe dirigir el tráfico? ¡Utiliza etiquetas y selectores!

Al definir un Service, se especifica un selector. Cualquier Pod que coincida con estas etiquetas pasará automáticamente a formar parte del grupo de ese Service.

Esta asociación dinámica permite añadir automáticamente los Pods nuevos y eliminar los que no estén saludables.

Los Services gestionan el flujo del tráfico de red. Definen puertos para asignar las solicitudes entrantes a los puertos correctos de sus Pods.

Conceptos clave sobre los puertos:

• port: El puerto en el que escucha el propio Service.
• targetPort: El puerto del Pod al que el Service reenvía el tráfico.

Al igual que la mayoría de los recursos de Kubernetes, los Services se definen mediante archivos YAML. Veamos su estructura básica:

• apiVersion: v1
• kind: Service
• metadata: Nombre, etiquetas
• spec: Contiene la definición principal, incluidos selector y ports.

El tipo de Service más común para la comunicación interna es ClusterIP. Expone el Service mediante una dirección IP interna dentro del clúster.

Este es un ejemplo de una aplicación web sencilla:

Una vez que tenga el YAML de su Service, puede desplegarlo en el clúster mediante kubectl, igual que haría con Pods o Deployments.

Este comando indica a Kubernetes que cree el Service basándose en su definición:

Después del despliegue, su Service obtiene una IP estable y un nombre DNS dentro del clúster. Ahora otros Pods pueden acceder a su aplicación mediante este nombre.

Por ejemplo, otro Pod podría conectarse a my-web-service:80, y el Service se encargaría de dirigir el tráfico a los Pods my-webapp correspondientes.

Ha aprendido cómo los Services de Kubernetes proporcionan acceso de red estable a Pods dinámicos.

¿Cuál de las siguientes opciones describe mejor la función principal de un Service de Kubernetes?

¡Buen trabajo! En esta lección hemos explorado los Services de Kubernetes.

• Los Pods son efímeros y tienen IP dinámicas.
• Los Services proporcionan puntos de conexión de red estables para los Pods.
• Utilizan selectores para encontrar los Pods de destino.
• Los Services asignan el port externo al targetPort interno.
• ClusterIP es un tipo común para la comunicación interna.

A continuación profundizaremos en los distintos tipos de Service y sus usos.