Kubernetes: Servicios ClusterIP, Ingress, NodePort y LoadBalancer

Raul Unzue Pulido 23 mayo, 2020 Kubernetes 1 Comentario 12,536 Vistas

Kubernetes: Servicios ClusterIP, Ingress, NodePort y LoadBalancer

Los Servicios son objetos que permiten reenviar tráfico de red a un conjunto de Pods, lo cual nos permite acceder a nuestras aplicaciones. Los Servicios se implementan a través de iptables, cuando se genera un servicio se le asigna una IP virtual interna (ClusterIP) que permite la interconexión entre Pods y es el componente kube-proxy de Kubernetes el que se comunica con la API Server que es el que comprueba si se han generado nuevos servicios.

Para definir qué Pods usan qué Servicios, podéis pensar que se usan direcciones IP estáticas, pero no es así, se usan los selectores o etiquetas que definen a cada conjunto de Pods.

Son asignaciones dinámicas, y permite que las nuevas versiones o añadir nuevos Pods a un Servicio sea realmente fácil. Es decir, si activamos un Pod con las mismas etiquetas que un Servicio, se asigna automáticamente a ese Servicio.

¿Qué diferencia hay entre Deployment y Servicio?

La diferencia fundamental está en su funcionalidad. Como hemos dicho, un Servicio permite el acceso a la red a un conjunto de Pods (actuando como un proxy). Y un Deployment se utiliza para mantener un conjunto de Pods en ejecución mediante la creación de Pods a partir de una plantilla.

Ambos trabajan con etiquetas o selectores con los Pods. Y se pueden generar independientemente el uno de otro, o trabajar en conjunto, que es la forma habitual de trabajar.

Tipos de Servicios Kubernetes

Existen varios tipos de servicios en Kubernetes, los principales y que vamos a explicar son:

ClusterIP
NodePort
LoadBalancer
Ingress, que aunque no es un servicio propiamente, tiene una gran relación

Un poco de networking para Kubernetes

Uno de los puntos que más nos cuesta entender en las infraestructuras con microservicios es la red y como trabajamos con nuestro clúster de contenedores y kubernetes.

Lo que vamos a intentar explicar es la diferencia entre ClusterIP, LoadBalancer, Ingress y NodePort en Kubernetes. Y a su vez en qué casos usaríamos cada uno.

Para empezar, hablaremos de ClusterIP, que es el servicio que se genera de forma predeterminada y que nos permite acceder a los servicios dentro del clúster.

De forma predeterminada, este servicio no es accesible desde Internet. Para acceder necesitaríamos habilitar el acceso a través del proxy de Kubernetes con el siguiente comando:

kubectl proxy --port = 8080

1	kubectl proxy --port = 8080

Lo que hay que entender es que se permite es acceder a nuestra API, utilizando el siguiente esquema:
http://localhost:8080/api/v1/proxy/namespaces/<NAMESPACE>/services/<SERVICE-NAME>:<PORT-NAME>/

EJEMPLO CLUSTERIP KUBERNETES:

http://localhost:8080/api/v1/proxy/namespaces/default/services/negulab-clusterip:http/

apiVersion: v1 
kind: 
metadata: 
   name: negulab-clusterip
spec: 
   selector: 
      app: app 
   type: ClusterIP 
   ports: 
   - name: http 
     port: 80 
     targetPort: 80 
     protocol: TCP

apiVersion: v1

kind:

metadata:

spec:

selector:

app: app

type: ClusterIP

ports:

- name: http

port: 80

targetPort: 80

protocol: TCP

Usar ClusterIP + Proxy es interesante para realizar pruebas internas, administración o para permitir tráfico internos, pero no es lo adecuado para una plataforma productiva, ya que para lanzar kubectl debemos autenticarnos en nuestra infraestructura previamente.

Así que si ClusterIP no nos sirve para Producción, qué podemos usar…

NODEPORT

Una alternativa es NodePort, que es otro tipo de servicio como ClusterIP.

Al utilizar NodePort abrimos un puerto específico en todos los hosts, y se reenvía el tráfico directamente al servicio, y a los Pods.

El puerto se especifica en el fichero YAML que crea el servicio, y si no se especifica, se utilizará automáticamente un puerto libre.

EJEMPLO NODEPORT KUBERNETES

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

apiVersion: v1

kind: Service

metadata:

spec:

selector:

app: app-ebdn

type: NodePort

ports:

- name: http

port: 80

targetPort: 80

nodePort: 30003

protocol: TCP

Aunque parece sencillo, tiene ciertas limitaciones:

Sólo se pueden usar puertos en el rango 30000-32767
Sólo un servicio por puerto
No es para ambientes en Producción, pero si para hacer una demo de una aplicación, por ejemplo
Te puede dar problemas con las IPs de los hosts, ya que estamos exponiendo el puerto en cada nodo. Las solicitudes desde fuera serían NodeIP:NodePort, entonces para solucionar esto necesitaríamos implementar un balanceador de carga tipo HAProxy para compensarlo

LOADBALANCER

Otro tipo de servicio que podemos implementar es LoadBalancer, que es el modo más estándar de exponer un servicio en Internet.

Al implementarlo se activa un balanceador de carga que proporcionará una única dirección IP que reenvía todo el tráfico a su servicio.

Este tipo de servicio tiene ciertas ventajas y algún inconveniente:

Es ideal para exponer un servicio concreto, pero no podremos exponer varios servicios a través de él. Con lo que si queremos exponer varios servicios, tendremos que usar varios LoadBalancer, Ips,…que en un cloud, significa dinero.
En este tipo de servicio no hay filtrado ni enrutamiento…

Se podría implementar un proyecto de página web, sabiendo que nuestro clúster va a utilizar un puerto específico HTTP o HTTPS para exponerla a Internet.

INGRESS

Por último, hablaremos de la forma más completa de exponer un servicio, Ingress.

Ingress no es un tipo de servicio como el resto, se trata más de un enrutador que permite la entrada al clúster y gestionar el acceso a múltiples servicios.

Ingress tiene ciertas ventajas:

Dispone de características o complementos avanzados como SSL, Routing, Subdominios para servicios en Backend,…
Con respecto a LoadBalancer, sólo necesitas una IP para exponer varios servicios. Esto se traduce en menos dinero al contratarlo en servicios cloud, por ejemplo
Dispone de soporte para balanceadores de carga nativos de la nube (de Google, Amazon y Microsoft)
Ingress permite configuraciones basadas en tiempos de espera o limitaciones de velocidad y enrutamientos basados en contenido, autenticación y mucho más.

Entre los pequeños inconvenientes el más importante:

Es más complejo de implementar que el resto de soluciones

EJEMPLO KUBERNETES INGRESS

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: ebdn-ingress
spec:
  backend:
    serviceName: ebdn
    servicePort: 8082
  rules:
  - host: www.maquinasvirtuales.eu
    http:
      paths:
      - backend:
          serviceName: negu
          servicePort: 8082
  - host: cloudconsulting.es
    http:
      paths:
      - path: /*
        backend:
          serviceName: cloud
          servicePort: 8082