Biblioteca Online : ¡La Suscripción ENI por 9,90 € el primer mes!, con el código PRIMER9. Pulse aquí
¡Acceso ilimitado 24/7 a todos nuestros libros y vídeos! Descubra la Biblioteca Online ENI. Pulse aquí
  1. Libros
  2. Kubernetes
  3. Exponer aplicaciones en Internet
Extrait - Kubernetes Administre la plataforma de despliegue de sus aplicaciones en contenedores
Extractos del libro
Kubernetes Administre la plataforma de despliegue de sus aplicaciones en contenedores
3 opiniones
Volver a la página de compra del libro

Exponer aplicaciones en Internet

Objetivos del capítulo y requisitos previos

En un clúster de Kubernetes, el despliegue de aplicaciones es muy rápido; basta con unas pocas declaraciones, ejecutar un comando y el clúster se encarga del resto.

Por otro lado, las aplicaciones se despliegan en una burbuja y no son directamente accesibles desde el exterior.

Para exponer estos servicios, el lector conoce ligeramente una primera técnica basada en el uso de reglas Ingress. Estas reglas hacen posible asociar un host virtual con un servicio interno. Un controlador Ingress las lee y se encarga de configurar un proxy inverso, que sirve como punto de entrada.

Desafortunadamente, la historia no termina ahí, ya que, además de publicar en un sitio web, el administrador tendrá que realizar otras operaciones, entre ellas:

  • crear entradas DNS,

  • configurar un balanceador de carga.

Estos aspectos se abordarán en este capítulo. Se presentarán diferentes controladores de Ingress para que pueda elegir uno o saber cómo hacerlos cohabitar usando anotaciones.

Tenga en cuenta que se recomienda realizar los siguientes ejercicios en un clúster alojado en la nube. En el caso de clústeres alojados internamente, las instrucciones siguen siendo válidas, pero será preciso que adaptarlas.

Gestionar las entradas DNS

1. Principio de funcionamiento

Exponer un servicio en Internet necesita adoptar ciertas precauciones. Una de estas precauciones consiste en reducir al máximo la cobertura de ataque.

Así, los servicios no están expuestos directamente al exterior, sino que pasan por un balanceador de carga. De esta forma, los nodos de Kubernetes pueden permanecer protegidos detrás de firewalls.

images/14EP01.png

Diagrama de bloques de la exposición de un servicio de Kubernetes en Internet

En el resto del capítulo, el lector abordará diferentes etapas:

  • Mecanismo de creación de entradas DNS.

  • Instalación de balanceadores de carga.

  • Actualización de acceso por el proxy inverso.

La siguiente sección mostrará cómo exponer las entradas DNS utilizando servicios de DNS administrados en la nube.

Los otros dos mecanismos también se presentarán más adelante en el capítulo.

2. Requisitos previos

Para poder realizar estos ejercicios, será necesario ser administrador de una zona DNS o tener la posibilidad de que le creen determinados registros.

En lo sucesivo, el nombre de dominio DNS utilizado será yannig.ovh y la zona DNS delegada será eni.yannig.ovh.

Los ejercicios se realizarán con el servicio de nombres de Google, pero las acciones son las mismas en AWS, Azure o un clúster interno de Kubernetes.

Para conocer los servicios soportados por external-dns, consulte la siguiente dirección: https://github.com/kubernetes-incubator/external-dns

3. Comentarios sobre el funcionamiento del dominio DNS nip.io

Al usar Ingress, las entradas DNS utilizaban la dirección IP de la máquina Minikube, combinada con el mecanismo DNS de nip.io. Este dominio DNS tiene la particularidad de responder a todas las resoluciones DNS por la dirección IP contenida detrás del prefijo .nip.io.

A continuación, se muestran algunos ejemplos de resolución de nombres con el dominio DNS nip.io:

  • 127.0.0.1.nip.io -> 127.0.0.1

  • 192.168.0.1.nip.io -> 192.168.0.1

  • entrada-dns;10.10.12.1.nip.io -> 10.10.12.1

En el contexto de una prueba, este mecanismo es suficiente. Por otro lado, para un hosting profesional, se hace necesario el uso de entradas DNS.

En lo sucesivo, la atención se centrará en los servicios públicos gestionados. Sin embargo, las operaciones se pueden transponer...

Exposición de servicios y balanceo de carga

1. Presentación del mecanismo

Exponer una aplicación al exterior requiere pasar por el puerto de servicio del controlador de entrada. A menos que solo tenga un nodo en el clúster de Kubernetes, se recomienda enrutar estos accesos a través de un balanceador de carga.

En el caso de un servicio gestionado, la creación del balanceador de carga se realiza automáticamente.

Además de aumentar la resiliencia del sistema, este mecanismo también permite aislar las máquinas del clúster en un área inaccesible de Internet.

Tenga en cuenta que un proxy inverso HTTP permite agrupar el acceso a varios sitios y, por lo tanto, maximizar el uso del balanceador de carga. Por otro lado, este no suele ser el caso para otros protocolos (SMTP, base de datos). Exponer un servicio que no sea HTTP necesariamente implicará configurar un balanceador de carga diferente cada vez.

Estos balanceadores de carga tienen un coste que no se debe pasar por alto. Tenga cuidado con exponer solo los servicios que realmente lo necesitan.

2. Comentarios sobre la noción de servicio

a. Rol de un servicio

Al desplegar las aplicaciones MailHog y MariaDB, se les ha asociado un servicio.

Estos servicios permiten abstraerse de los pods subyacentes (siendo estos últimos de naturaleza efímera). El concepto de servicio sirve para proporcionar una interfaz estable...

El controlador Ingress

1. Principio de funcionamiento

La gestión de entradas DNS y balanceadores de carga se vio en el apartado anterior. Solo falta enlazar con el controlador Ingress.

Su principio de funcionamiento es el siguiente:

  • Recepción de solicitudes desde el exterior (desde el balanceador de carga).

  • Llamada a los servicios internos.

  • Envío de los resultados al cliente externo.

Para establecer esta comunicación, el usuario utiliza declaraciones Ingress.

2. El rol del controlador Ingress

El controlador Ingress controlará el proxy inverso. Para ello, recupera las solicitudes de publicación de servicios y configura automáticamente el proxy inverso. 

Este proxy recopila solicitudes externas para reenviarlas a los servicios internos que hay que exponer.

3. Estructura de una regla Ingress

Las reglas Ingress ya se han trataro anteriormente en el libro. Estas tienen la siguiente estructura:

  • Cabeceras que indican el tipo de objeto.

  • Metadatos que incluyen el nombre de la regla.

  • Un campo espec que contiene la definición de las reglas Ingress.

Este campo espec debe contener, al menos, un campo defaultBackend o rules. El campo defaultBackend designará un destino predeterminado en caso de que ninguna regla sea adecuada.

Este campo acepta un objeto service que contiene los siguientes valores:

  • name: nombre de un servicio (p. ej.: mailhog).

  • port --> number: puerto de escucha del servicio (ej.: 8080).

Es posible...

El controlador Ingress Google

1. Requisitos previos

El resto del ejercicio se realizará en un clúster creado con el servicio gestionado Kubernetes de Google.

Para obtener más detalles sobre esta creación, puede consultar la sección dedicada a la configuración de un clúster, utilizando el servicio administrado de Google.

2. Presentación del controlador GLBC

En el servicio gestionado de Google, se ha tomado la decisión de integrar un controlador Ingress interno. Este controlador se basa en el servicio de balanceo de carga (GLB) de Google.

El pod asociado a este servicio tiene la etiqueta k8s-app=glbc. La consulta de los pods asociados a esta etiqueta se realizará mediante el siguiente comando:

$ kubectl -n kube-system get pods -l k8s-app=glbc 

El comando debería mostrar el siguiente contenido:

NAME                             READY   STATUS    RESTARTS   AGE 
l7-default-backend-7ff48c-ffd7   1/1     Running   0          1d 

A diferencia de lo que sucede con un controlador Ingress Nginx, este controlador no necesita pods para la parte del proxy inverso. Este aspecto se tiene en cuenta directamente por la API de Google.

3. Despliegue de MailHog

a. Preparación de la regla Ingress

Los archivos de despliegue están...

El controlador Ingress Nginx

1. ¿Por qué cambiar de controlador Ingress?

El controlador de Google usa un balanceador de carga por objeto Ingress. Además del hecho de que este mecanismo tarda en ejecutarse, el consumo de recursos de la nube puede ser una fuente importante de gastos. En este contexto, el controlador Ingress Nginx es una buena opción predeterminada.

Además de Nginx, existen controladores basados en el software Haproxy y Traefik. También pueden existir otras variantes, como Nginx+, que ofrece soporte de pago.

Otro aspecto es que algunas veces es deseable separar los controladores Ingress. De hecho, en grandes clústeres de producción, más allá de ciertos límites, las actualizaciones pueden ser largas y una fuente de riesgos.

Para abordar estos diferentes aspectos, se implementará un controlador Ingress Nginx además del predeterminado, disponible para los clústeres de Google y Azure. En el caso de Amazon, no hay presente ningún controlador Ingress de forma predeterminada.

2. Presentación del software Nginx

El software Nginx es un servidor web de código abierto, que actúa como una alternativa a Apache. Debido a su reputación, ligereza y facilidad de uso, rápidamente se utilizó como proxy inverso en el mundo de Kubernetes.

Este software está disponible en una versión de pago, con la que se ofrecen soporte y funcionalidades adicionales (extensión Nginx+).

Para obtener más información, consulte la siguiente URL: https://www.nginx.com/

En lo sucesivo, solo se presentará la versión de código abierto.

3. Instalación de Ingress Nginx en GKE (Google)

a. Determinar el chart Helm que hay que instalar

 Hay un chart Helm para instalar el controlador Ingress Nginx en el repositorio ingress-nginx. Añádalo con el siguiente comando:

$ helm repo add ingress-nginx \ 
     https://kubernetes.github.io/ingress-nginx 

 Lance la búsqueda del chart con el siguiente comando:

$ helm search repo nginx-ingress 

El comando devuelve los paquetes correspondientes a esta búsqueda. El paquete ingress-nginx/ingress-nginx se utilizará para la instalación.

b. Espacio de nombres y configuración del chart

Para mantener los componentes separados, el controlador...

El controlador Ingress Traefik

1. Presentación de Traefik

Traefik es una herramienta moderna de balanceo de carga, así como un proxy inverso. Es especialmente adecuado para publicar aplicaciones de tipo microservicios. 

2. Instalar el chart Helm

La forma más fácil de instalar Traefik es utilizar el chart Helm.

Por defecto, el chart Helm de Traefik no funciona correctamente con external-dns: de hecho, el campo status de los registros no se actualiza de forma automática, lo que impide que el sistema sepa cuál es la correspondencia entre la entrada DNS y la dirección del balanceador de carga. Para hacer esto, debe usar el booleano provider --> kubernetesIngress --> publishService --> enabled: este último debe tener el valor true.

Otro aspecto importante es que agregar la clase Ingress requiere el uso del campo ingressClass --> enable con el valor true. Para indicar que Traefik es el controlador predeterminado, utilice el campo ingressClass --> isDefaultClass.

En el caso de una instalación múltiple del controlador Ingress (como se explicó anteriormente para el controlador Ingress Nginx), no dude en utilizar el campo providers --> kubernetesCRD --> ingressClass para cambiar el nombre de la clase Ingress del controlador. No realice este cambio si planea tener un solo controlador Traefik.

Finalmente, para tener información de las peticiones que llegan al controlador Ingress, active las trazas en el registro de actividad del contenedor. Esta operación se realiza con los booleanos logs --> access --> enabled. En el mismo contexto, el campo logs --> general --> level permite especificar el nivel del registro de actividad de Traefik: DEBUG, PANIC, FATAL, ERROR, WARN o INFO.

Para simplificar el paso de parámetros al chart Helm, estas opciones se almacenarán en un archivo.

A continuación, se muestra el contenido completo de este archivo:

# https://github.com/traefik/traefik-helm-chart/blob/master/ 
traefik/values.yaml 
ingressClass: 
  enabled: true 
  # Set this value to use Traefik as a default Ingress controller 
  # isDefaultClass: true 
 
# Update Ingress status 
providers: 
  kubernetesIngress: 
    publishedService: 
      enabled: true 
  #...