Kubernetes: NodePort vs LoadBalancer vs Ingress, ¿cuándo usar cuál?

Entendiendo cada opción para exponer nuestras aplicaciones al mundo exterior y al clúster de Kubernetes

Una de las preguntas claves cuando empiezas a entender Kubernetes, es ¿cómo hago para exponer mi aplicación? Dado que al desplegar tu deployment te darás cuenta que estas no puedes accederlas desde tu navegador o curl.

3 opciones que nos provee K8s son NodePorts, LoadBalancers e Ingress. Todas son formas diferentes de obtener tráfico externo en su clúster, y todas lo hacen de diferentes maneras. Echemos un vistazo a cómo funcionan cada uno de ellos y cuándo usaría cada uno.

Nota: Todo aquí se aplica a Google Kubernetes Engine. Si está ejecutando en otra nube, en prem, con minikube, o algo más, estos serán ligeramente diferentes. Tampoco voy a entrar en detalles técnicos profundos. Si está interesado en aprender más, ¡la documentación oficial es un gran recurso!

ClusterIP

Un servicio ClusterIP es el servicio predeterminado de Kubernetes. Le brinda un servicio dentro de su clúster al que pueden acceder otras aplicaciones dentro de su clúster. No hay acceso externo.

El YAML para un servicio ClusterIP se ve así:

apiVersion: v1
kind: Service
metadata:  
  name: my-internal-service
spec:
  selector:    
    app: my-app
  type: ClusterIP
  ports:  
  - name: http
    port: 80
    targetPort: 80
    protocol: TCP

Si no puedes acceder a un servicio ClusterIP desde Internet, ¿por qué estoy hablando de eso? Resulta que puedes acceder usando el proxy Kubernetes.

Diagrama propiedad de Ahmet Alp Balkan

Puedes iniciar el proxy de esta manera:

$ kubectl proxy --port=8080

Ahora, puedes navegar a través de la API de Kubernetes para acceder a este servicio utilizando este esquema:

http: // localhost: 8080 / api / v1 / proxy / namespaces / <NAMESPACE> / services / <SERVICE-NAME>: <PORT-NAME> /

Para acceder al servicio que definimos anteriormente, puedes usar la siguiente dirección:

http: // localhost: 8080 / api / v1 / proxy / namespaces / default / services / my-internal-service: http /

¿Cuándo usarías esto?
Hay algunos escenarios en los que usaría el proxy Kubernetes para acceder a sus servicios.

• Depuración de sus servicios, o conectarse a ellos directamente desde su computadora portátil por alguna razón
• Permitir tráfico interno, mostrar panels internos, etc.

Debido a que este método requiere que ejecute kubectl como usuario autenticado, NO debe usar esto para exponer su aplicación.

NodePort

Un servicio NodePort es la forma más primitiva de obtener tráfico externo directamente a su servicio. NodePort, como su nombre lo indica, abre un puerto específico en todos los nodos (las máquinas virtuales), y todo el tráfico que se envía a este puerto se reenvía al servicio.

Diagrama propiedad de Ahmet Alp Balkan

Una definición YML para el NodePort se vería algo como así:

apiVersion: v1
kind: Service
metadata:  
  name: my-nodeport-service
spec:
  selector:    
    app: my-app
  type: NodePort
  ports:  
  - name: http
    port: 80
    targetPort: 80
    nodePort: 30036
    protocol: TCP

Básicamente, un servicio NodePort tiene dos diferencias con un servicio normal “ClusterIP”. Primero, el tipo es “NodePort” en el YML. También hay un puerto adicional llamado nodePort que especifica qué puerto abrir en los nodos. Si no especifica este puerto, k8s elegirá un puerto aleatorio. La mayoría de las veces debes dejar que Kubernetes elija el puerto, hay muchas advertencias sobre qué puertos están disponibles para su uso.

¿En qué casos usaríamos esto?
Hay muchos inconvenientes para este método:

• Solo puedes tener un servicio por puerto
• Solo puedes usar los puertos 30000–32767
• Si su dirección IP de Nodo / VM cambia, hay que lidiar con eso

Por estas razones, no recomiendo usar este método en producción para exponer directamente su servicio. Si está ejecutando un servicio que no tiene que estar siempre disponible, o es muy sensible a los costos, este método podría funcionar perfectamente. Un buen ejemplo de dicha aplicación es un demo o algo temporal.

LoadBalancer

Un servicio LoadBalancer es la forma estándar de exponer un servicio a Internet. En GKE (Google Kubernetes Engine), esto activará un Network Load Balancer que le dará una única dirección IP que reenviará todo el tráfico a su servicio.

Diagrama propiedad de Ahmet Alp Balkan

¿Cuándo usarías un LoadBalancer?
Si desea exponer directamente un servicio, este es el método predeterminado. Todo el tráfico en el puerto que especifique se reenviará al servicio. No hay filtrado, ni enrutamiento, etc. Esto significa que puedes enviarle casi cualquier tipo de tráfico, como HTTP, TCP, UDP, Websockets, gRPC o lo que sea.

La gran desventaja es que cada servicio que exponga con un LoadBalancer tendrá su propia dirección IP, y tendrá que pagar un LoadBalancer por servicio expuesto, ¡lo cual puede ser costoso!

Ingress

A diferencia de todos los ejemplos anteriores, Ingress en realidad NO es un tipo de servicio. En cambio, se ubica frente a múltiples servicios y actúa como un “enrutador inteligente” o punto de entrada a su clúster.

Puedes hacer muchas cosas diferentes con un Ingress, y hay muchos tipos de controladores de Ingress que tienen capacidades diferentes.
El controlador de ingreso GKE predeterminado hará un HTTP (S) Load Balancer por usted. Esto le permitirá realizar enrutamientos basados en rutas y subdominios para servicios de back-end. Por ejemplo, puedes enviar todo en foo.yourdomain.com al servicio foo, y todo lo que esté debajo de yourdomain.com/bar/ ruta al servicio de bar.

El YAML para un Ingress en GKE con un equilibrador de carga HTTP L7 podría verse así:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: my-ingress
spec:
  backend:
    serviceName: other
    servicePort: 8080
  rules:
  - host: foo.mydomain.com
    http:
      paths:
      - backend:
          serviceName: foo
          servicePort: 8080
  - host: mydomain.com
    http:
      paths:
      - path: /bar/*
        backend:
          serviceName: bar
          servicePort: 8080

¿Cuándo usar un Ingres?
Ingress es probablemente la forma más poderosa de exponer sus servicios, pero también puede ser la más complicada. Hay muchos tipos de controladores Ingress, desde Google Cloud Load Balancer, Nginx, Contour, Istio y más. También hay complementos para los controladores Ingress, como el cert-manager, que pueden proporcionar automáticamente certificados SSL para sus servicios.

Ingress es el más útil si deseas exponer múltiples servicios bajo la misma dirección IP, y todos estos servicios usan el mismo protocolo L7 (típicamente HTTP). Solo tienes que pagar un equilibrador de carga si estás utilizando la integración nativa de GCP, y debido a que un Ingress es “inteligente”, puedes obtener muchas características de fábrica (como SSL, Auth, Routing, etc.)

En próximos artículos extenderemos el tema de Istio, así que sigue atento a nuestras redes sociales!