Configuración de Recursos de Ingress en Kubernetes. Bloque 3. Tema 3.4 del CKA.

 

El uso de Ingress en Kubernetes es una práctica esencial para gestionar el acceso a los servicios de una forma centralizada y eficiente. Los recursos Ingress permiten definir reglas para enrutar el tráfico HTTP y HTTPS hacia los servicios internos, proporcionando una manera de exponer múltiples servicios a través de un único punto de entrada.

1. Creación de Recursos de Ingress

Los recursos de Ingress se pueden crear utilizando el comando kubectl create ingress, especificando reglas que indican cómo redirigir el tráfico hacia los servicios correspondientes. Esto es particularmente útil cuando se quiere exponer varios servicios en rutas específicas.

Ejemplos de creación de Ingress:

$ kubectl create ingress ingress-a --rule=/base/path-a=service-a:6330 --namespace workload-a --class nginx --annotation nginx.ingress.kubernetes.io/rewrite-target=/
$ kubectl create ingress ingress-b --rule=/base/path-b=service-b:6331 --namespace workload-b --class nginx --annotation nginx.ingress.kubernetes.io/rewrite-target=/
  • Descripción:
    • Estas reglas especifican que las rutas /base/path-a y /base/path-b redirigen el tráfico a service-a y service-b, respectivamente.
    • La anotación nginx.ingress.kubernetes.io/rewrite-target=/ asegura que la ruta se redirija correctamente al backend, eliminando el prefijo antes de enviarlo al servicio.
    • El ingressClassName nginx indica que estas reglas deben ser gestionadas por el NGINX Ingress Controller.

Explicación de los conceptos:

  • Ingress: Proporciona un punto de entrada único para acceder a múltiples servicios de forma centralizada.
  • NGINX Ingress Controller: Es uno de los controladores más populares para gestionar reglas de Ingress en Kubernetes. Interpreta las reglas de los recursos Ingress y las aplica para redirigir el tráfico entrante a los servicios internos.

2. Verificación de la Configuración de Ingress

Una vez configurado el Ingress, es fundamental verificar que las reglas y configuraciones sean correctas para asegurar que el tráfico se dirige a los servicios deseados.

$ kubectl describe ingress ingress-a -n workload-a
$ kubectl describe ingress ingress-b -n workload-b
  • Descripción:
    • Estos comandos muestran los detalles de cada recurso Ingress, incluyendo las anotaciones, reglas de enrutamiento y los eventos recientes.
    • Es importante revisar que los eventos no indiquen errores y que los destinos de backend apunten a los servicios correctos.

Buenas prácticas para la verificación:

  • Revisar eventos y errores: Los eventos pueden mostrar si hubo problemas al procesar el Ingress.
  • Confirmar los backends: Asegurarse de que los servicios listados en el Ingress están vinculados correctamente a los servicios esperados.

3. Pruebas del Ingress con curl

Probar la configuración de Ingress es esencial para verificar que las aplicaciones son accesibles desde las rutas esperadas. Para estas pruebas, usamos la herramienta curl para simular solicitudes HTTP hacia las rutas configuradas.

$ curl http://127.0.0.1:8080/base/path-a
# Resultado esperado: "It works!" si la configuración del Ingress está funcionando correctamente para `service-a`.

$ curl http://127.0.0.1:8080/base/path-b
# Resultado esperado: "Welcome to nginx!" si la configuración del Ingress está funcionando correctamente para `service-b`.
  • Descripción:
    • Estos comandos prueban que las rutas configuradas están redirigiendo correctamente el tráfico a los servicios service-a y service-b.
    • Una respuesta exitosa indica que el tráfico llega al servicio correcto y que el Ingress está funcionando como se espera.

Sugerencias para las pruebas:

  • Usar un pod de prueba: Ejecutar estas pruebas desde un pod de prueba dentro del clúster ayuda a simular cómo se comporta el tráfico interno.
  • Pruebas de diferentes rutas: Verificar diferentes rutas configuradas en el Ingress para asegurarse de que todas redirigen correctamente.

Configuración y Funcionamiento de CoreDNS en Kubernetes

CoreDNS es el componente predeterminado para la resolución de nombres en Kubernetes, encargado de traducir nombres de servicios y pods en direcciones IP. Esto permite que las aplicaciones dentro del clúster se comuniquen de manera dinámica y escalable.

1. Visión General de CoreDNS

  • Resolución de nombres DNS: CoreDNS asigna nombres DNS a los servicios y pods, utilizando una convención estándar <service-name>.<namespace>.svc.cluster.local.
  • Conectividad simplificada: Gracias a CoreDNS, los servicios pueden comunicarse entre sí utilizando nombres fáciles de recordar, lo que facilita la reconfiguración de la infraestructura sin cambiar las configuraciones de las aplicaciones.

Ejemplo:

  • Si hay un servicio llamado encrypt en el namespace research, desde otros namespaces se accede usando:
    • encrypt.research.svc.cluster.local
    • Dentro del mismo namespace, simplemente se puede usar encrypt.

Customización de CoreDNS:

  • CoreDNS se puede personalizar para incluir zonas adicionales o ajustar la política de caché, lo que permite optimizar su rendimiento según las necesidades del clúster.
  • Configurar una zona personalizada puede ser útil para integrar la resolución de nombres de servidores externos dentro del clúster.

Uso de Plugins CNI (Container Network Interface) en Kubernetes

El correcto funcionamiento de la red en un clúster de Kubernetes depende de la implementación de plugins CNI, que gestionan la conectividad de red entre los pods y la asignación de direcciones IP.

1. Requerimientos de CNI en Clústeres de Kubernetes

  • CNI (Container Network Interface): Es una especificación para gestionar redes de contenedores. Cada clúster de Kubernetes requiere un plugin CNI para gestionar la red.
  • Implementación: Los plugins CNI se despliegan como DaemonSets, garantizando que cada nodo del clúster tenga un agente de red activo que gestione las conexiones entre pods.

2. Comparación de Plugins CNI:


3. Elección del Plugin CNI Adecuado

La selección del plugin depende de factores como el tamaño del clúster, la necesidad de políticas de seguridad avanzadas y el rendimiento de la red:

  • Flannel es adecuado para entornos simples y pruebas.
  • Calico y Cilium son preferidos en entornos de producción debido a su capacidad de manejar políticas de seguridad detalladas.
  • Weave Net es una buena opción si necesitas un equilibrio entre simplicidad y escalabilidad.

Conclusión

Configurar recursos de Ingress, CoreDNS y CNI es esencial para gestionar la conectividad y el tráfico de un clúster de Kubernetes. Estos componentes permiten controlar cómo se comunican las aplicaciones entre sí y con el mundo exterior, asegurando que los servicios sean accesibles de manera eficiente y segura.

El dominio de estas configuraciones es clave para cualquier aspirante a la certificación CKA, ya que reflejan habilidades críticas para la administración de un clúster de Kubernetes. Practicar con ejemplos reales y probar configuraciones es la mejor manera de asegurarse de que se comprende el funcionamiento de estos recursos.

¡En el siguiente capítulo, profundizaremos aún más en las mejores prácticas de escalabilidad y balanceo de carga en Kubernetes!

Comentarios

Publicar un comentario