Exponer aplicaciones en Internet

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.

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:

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:

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...

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.

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

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:

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:

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:

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 

3. Despliegue de MailHog

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)

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

$ helm search repo nginx-ingress 

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 
  #...