Cuándo usar ClusterIP Vs LoadBalancer Vs NodePort Vs ingress en Kubernetes

Alguna vez he visto que a la hora de definir un servicio el tipo de acceso que establecemos para conectarnos no es el correcto, o incluso a veces no se esta seguro de cuál asignar. En esta entrada sobre cuándo usar ClusterIP vs LoadBalancer vs NodePort vs Ingress en Kubernetes, analizaremos qué es cada tipo y cuál usar en función de nuestras necesidades cuando creamos un servicio.

ClusterIP en Kubernetes

ClusterIP es el servicio que establece por defecto Kubernetes. Este tipo de servicio únicamente va a ser accesible dentro de tu clúster por otros servicios o aplicaciones, es decir, no va a tener acceso externo.

Por ejemplo una definición de servicio con ClusterIP puede ser:

apiVersion: v1
kind: Service
metadata:
  name: myservice
  namespace: mynamespace
spec:
  selector:
    app: myservice
  ports:
    - protocol: TCP
      port: 10007
      targetPort:10007
  type: ClusterIP

Y qué pasa si queremos tener acceso desde internet, pues podemos hacer uso del Kubernetes proxy. El cual se ejecuta en cada nodo y se puede específicar para conectarnos desde fuera del clúster indicando el puerto. Obviamente podemos hacer esto para entornos NO productivos o de pruebas.

Para poder utilizar el proxy de kubernetes para lanzar un proxy server ejecutamos el siguiente comando:

$ kubectl proxy --port=8080

De manera que cuando el proxy esta funcionando podemos mediante un curl inspeccionar el API de Kubernetes y acceder al servicio:

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

Por ejemplo vamos a instalar el dahsboard de kubernetes ejecutando:

kubectl create -f https://raw.githubusercontent.com/kubernetes/dashboard/v1.10.1/src/deploy/alternative/kubernetes-dashboard.yaml

Ejecutamos kubernetes proxy;

kubectl proxy --address 0.0.0.0 --accept-hosts '.*'

y desde nuestro navegador o con un curl ejecutamos:

http://localhost:8001/api/v1/namespaces/kube-system/services/kubernetes-dashboard/proxy/#!/overview

Tal y como hemos comentado anteriormente Kubernetes proxy no lo usaremos en entornos productivos a no ser:

• Necesitemos, como hemos visto en el ejemplo anterior, ver algún dashboard conectándonos desde fuera.
• Permitir el tráfico interno
• Tener que analizar algún problema y tener que hacer debug sobre un servicio.

NodePort en kubernetes

NodePort es una de las primeras formas que se tienen de dirigir tráfico externo de internet a tu servicio. Lo que hace NodePort, es abrir un puerto en los nodos, y todo el tráfico que llegue a ese port se dirige hacia el servicio definido.

Vamos a ver la definición de un servicio con NodePort, veremos que la diferencia lo marca el tipo de servicio:

apiVersion: v1
kind: Service
metadata:  
  name: myservice
spec:
  selector:    
    app: myapp
  type: NodePort
  ports:  
  - name: http
    port: 80
    targetPort: 80
    nodePort: 30000
    protocol: TCP

Como vemos en la definición del servicio de arriba, hemos específicado el puerto para abrir en los nodos, en el caso en el que no se específique se seleccionará un puerto aleatorio.

El uso de este método para acceder a tu servicio, permitirá el acceso directo a través de la red, por lo que no esta recomendado para entornos productivos.

Puntos a tener en cuenta al usar NodePort en Kubernetes

• Los puertos que podemos usar (en el ejemplo hemos hecho uso del 30036) son del 30000 al 32767.
• Si la IP del nodo cambia habrá que re-configurar.
• Un servicio es asignado a un Pod.

¿Cuándo usar un NodePort en Kubernetes?

Tal y como hemos comentado antes, el uso de NodePort va a dar acceso a través de la red a tu servicio, por lo que para entornos de producción no sería muy recomendado. Pero en cambio para hacer uso del servicio que has definido en momentos puntuales, por ejemplo, una demo a un cliente es un buen uso del NodePort.

LoadBalancer en Kubernetes

Un LoadBalancer en Kubernetes expone externamente el servicio usando por lo general un Load Balancer del provedor del cloud en el que te encuentres. La creación de un load balancer sucede de manera asíncrona y la información sobre el balanceador se plublica en el campo status.loadBalancer.

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app: MyApp
  ports:
    - protocol: TCP
      port: 80
      targetPort: 9376
  clusterIP: 10.0.121.221
  type: LoadBalancer
status:
  loadBalancer:
    ingress:
    - ip: 192.0.1.127

El tráfico externo es dirigido a los Pods, el proveedor de cloud decide como balancear en cada caso. En algunos casos los proveedores permiten especificar el loadBalancerIP, sino se añade con una IP efímera.

¿Cuándo usar LoadBalancer en Kubernetes?

El uso de LoadBalancer nos va a permitir exponer un servicio directamente. El tráfico se dirigirá al puerto específicado en el servicio. La principal desventaja de hacer uso de LoadBalancer es que al obtener cada servicio su propia IP, puede que el proveedor de cloud cobre por servicio expuesto, lo que podría llegar a ser caro.

Ingress Controler en Kubernetes

A diferencia de los tipos de servicio comentados anteriormente, un Ingress no es realmente un tipo de servicio, sino que es una «pieza» que se encuentra en frente de muchos servicios y actúa como un punto de entrada a nuestro clúster.

Hay muchos y diferentes tipos de Ingress, incluso dependiendo del proveedor de cloud puedes utilizar el suyo propio. Uno de los más comunes para utilizar es el de Nginx.

A parte con un Ingres podemos añadir diversas funcionalidades y plugins como el cert-manager para dar establecer una conexión SSL a nuestros servicios.

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  annotations:
    kubernetes.io/ingress.class: nginx
    meta.helm.sh/release-name: api-ingress
    meta.helm.sh/release-namespace: my-namespace
    cert-manager.io/cluster-issuer: letsencrypt-prod
    nginx.ingress.kubernetes.io/force-ssl-redirect: "true"
    nginx.ingress.kubernetes.io/rewrite-target: /$1
  labels:
    app: api-ingress
  name: api-ingress
  namespace: my-namespace
spec:
  tls:
  - hosts:
    - api.services
    secretName: api-ingress-tls
  rules:
  - host: api.services
    http:
      paths:
      - backend:
          serviceName: myserviceA
          servicePort: 10030
        path: /my-service-a/(.*)
      - backend:
          serviceName: myserviceB
          servicePort: 10031
        path: /my-service-b/(.*)      

¿Cuándo usar Ingress Controller?

Ingress es la herramienta más utilizada cuando se quiere exponer múltiples servicios a través de la misma IP, además los servicios harán uso del protocolo L7, el cual opera en el más alto nivel de la capa de aplicación, la cual trata con los mensajes.

También el uso de un Ingress, obviamente reduce el coste en un proveedor de cloud, ya que pagarás por un Load Balancer únicamente, además podrás añadir diferentes funcionalidades como SSL, Auth, etc…

Conclusión

El tipo de servicios que suemos con Kubernetes nos va a permitir acceder a una red externa de una u otra manera, en este artículo sobre cuándo usar ClusterIP Vs LoadBalancer Vs NodePort Vs ingress en Kubernetes, hemos podido entender su uso y cuando es mejor usarlo.