Kubernetes: Instalar balanceador MetalLB

Raul Unzue Pulido 2 semanas hace Automatización, Kubernetes Deja un comentario 174 Vistas

Kubernetes: Instalar balanceador MetalLB

MetalLB es una implementación de LoadBalancer para clústeres Kubernetes que se ejecutan en entornos no soportados por los balanceadores de carga de nube nativos, como los entornos bare-metal (hardware físico) o on-premise. Kubernetes, en entornos de nube como AWS, Azure o Google Cloud, se integra automáticamente con los balanceadores de carga de las plataformas, pero en una infraestructura física local, esta funcionalidad no está disponible de manera nativa. Aquí es donde MetalLB juega un papel crucial.

¿Qué es MetalLB?

MetalLB es un controlador de red que permite a los clústeres de Kubernetes basados en hardware bare-metal asignar direcciones IP externas a los servicios que se exponen como LoadBalancer. Básicamente, MetalLB simula el comportamiento de un balanceador de carga en un entorno de nube pública, proporcionando direcciones IP externas para que los servicios sean accesibles desde fuera del clúster.

Componentes principales de MetalLB:

Controller: Este componente gestiona la asignación de direcciones IP a los servicios que tienen el tipo LoadBalancer. Escucha continuamente los cambios en los servicios y asigna una IP cuando sea necesario.
Speaker: Es el componente responsable de anunciar las direcciones IP externas. Puede funcionar en dos modos principales: Layer 2 (L2) y Border Gateway Protocol (BGP).
- L2 (Capa 2): El modo más sencillo de MetalLB, funciona dentro de la red local sin necesidad de hardware adicional, anunciando la dirección IP a través de ARP.
- BGP (Protocolo de Gateway Fronterizo): Un modo avanzado, en el cual MetalLB habla con enrutadores BGP para anunciar la ruta a las IP asignadas.

¿Cuál es la utilidad de MetalLB en un clúster de Kubernetes?

Provisión de IPs Externas: Proporciona una IP externa a los servicios de Kubernetes tipo LoadBalancer en entornos on-premise o bare-metal donde no se cuenta con un balanceador de carga externo.
Distribución de tráfico: En un entorno bare-metal, permite balancear el tráfico de red de entrada entre los nodos del clúster, utilizando técnicas de balanceo que normalmente no están disponibles en estos entornos.
Alta Disponibilidad (HA): En combinación con BGP o un protocolo similar, MetalLB puede proporcionar alta disponibilidad para los servicios expuestos, distribuyendo el tráfico de manera eficiente entre múltiples nodos.

Cómo instalar MetalLB en tu cluster de Kubernetes

A continuación, te explico los pasos necesarios para desplegar MetalLB en un clúster de Kubernetes. Este proceso cubre una instalación básica de MetalLB en el modo Layer 2.

Requisitos previos MetalLB:

Un clúster de Kubernetes en funcionamiento.
Acceso administrativo al clúster (kubectl configurado).
Un rango de direcciones IP disponibles en tu red local para asignar a los servicios.

Paso 1: Instalar MetalLB

Aplicar los manifiestos de instalación:

MetalLB se instala mediante el uso de un archivo YAML que contiene los recursos necesarios. Puedes aplicar estos manifiestos directamente desde el repositorio oficial de MetalLB:

kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/main/manifests/metallb-native.yaml

1	kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/main/manifests/metallb-native.yaml

Crear el espacio de nombres:

MetalLB generalmente se instala en su propio namespace para mantener la separación de componentes, pero si no se crea, podéis usar:

kubectl create namespace metallb-system

1	kubectl create namespace metallb-system

Paso 2: Configurar MetalLB

Ahora necesitamos configurar MetalLB para que use el rango de direcciones IP disponibles. Esto se hace mediante un archivo de configuración que le indica a MetalLB qué direcciones IP puede asignar.

Crear un ConfigMap para MetalLB:Crea un archivo metallb-config.yaml con la siguiente configuración. Define un rango de direcciones IP de tu red local que serán asignadas a los servicios tipo LoadBalancer:

apiVersion: v1
kind: ConfigMap
metadata:
  namespace: metallb-system
  name: config
data:
  config: |
    address-pools:
    - name: default
      protocol: layer2
      addresses:
      - 192.168.1.240-192.168.1.250

apiVersion: v1

kind: ConfigMap

metadata:

namespace: metallb-system

data:

config: |

address-pools:

- name: default

protocol: layer2

addresses:

- 192.168.1.240-192.168.1.250

En este ejemplo, el rango de direcciones IP disponible para MetalLB es de 192.168.1.240 a 192.168.1.250.

Aplicar la configuración:

Aplica el archivo ConfigMap al clúster:

kubectl apply -f metallb-config.yaml

1	kubectl apply -f metallb-config.yaml

Paso 3: Crear un servicio tipo LoadBalancer

Para validar la instalación de MetalLB, podemos crear un servicio de Kubernetes tipo LoadBalancer. A continuación se muestra un ejemplo sencillo de cómo exponer un servicio mediante MetalLB.

Crear un servicio de Nginx:Aplica este manifiesto para desplegar un servicio Nginx y exponerlo mediante una IP externa proporcionada por MetalLB:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:latest
        ports:
        - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  selector:
    app: nginx
  type: LoadBalancer
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80

apiVersion: apps/v1

kind: Deployment

metadata:

spec:

replicas: 2

selector:

matchLabels:

app: nginx

template:

metadata:

labels:

app: nginx

spec:

containers:

- name: nginx

image: nginx:latest

ports:

- containerPort: 80

---

apiVersion: v1

kind: Service

metadata:

spec:

selector:

app: nginx

type: LoadBalancer

ports:

- protocol: TCP

port: 80

targetPort: 80

Aplicar el manifiesto:

kubectl apply -f nginx-service.yaml

1	kubectl apply -f nginx-service.yaml

Después de aplicar el manifiesto, puedes verificar que MetalLB ha asignado una IP externa a tu servicio:

kubectl get services

1	kubectl get services

Deberías ver algo similar a esto:

NAME             TYPE           CLUSTER-IP      EXTERNAL-IP      PORT(S)        AGE
nginx-service    LoadBalancer   10.96.109.10    192.168.1.240    80:32429/TCP   1m

1 2	NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE nginx-service LoadBalancer 10.96.109.10 192.168.1.240 80:32429/TCP 1m

En este caso, MetalLB ha asignado la IP externa 192.168.1.240 a nuestro servicio nginx-service.

Paso 4: Acceder al servicio

Una vez que MetalLB ha asignado la dirección IP externa, puedes acceder al servicio desde fuera del clúster utilizando esa IP:

curl http://192.168.1.240

1	curl http://192.168.1.240

Deberías ver la página predeterminada de Nginx si todo está funcionando correctamente.

Integración con Kubernetes y otros ejemplos avanzados

MetalLB también puede integrarse con otros sistemas de red más complejos a través de protocolos como ARP, NDP y BGP, lo que permite una mayor flexibilidad para entornos empresariales con infraestructura avanzada.

Resumen de los protocolos usados en MetalLB

ARP (Address Resolution Protocol): Protocolo de la capa de enlace que permite a los dispositivos de red encontrar la dirección MAC de un dispositivo en la misma red local a partir de su dirección IP.
NDP (Neighbor Discovery Protocol): Similar a ARP, pero utilizado en redes IPv6 para descubrir las direcciones MAC asociadas a una dirección IPv6.
BGP (Border Gateway Protocol): Un protocolo de enrutamiento de capa 3 que intercambia información de enrutamiento entre sistemas autónomos (routers) en redes grandes y distribuidas.

Integración con ARP (Layer 2)

En redes IPv4, MetalLB utiliza el Address Resolution Protocol (ARP) para anunciar las direcciones IP de los servicios a nivel de la capa de enlace de datos. En este modo de funcionamiento, conocido como Layer 2 o capa 2, MetalLB responde a las solicitudes ARP para resolver la dirección IP de un servicio con la dirección MAC del nodo Kubernetes que está manejando el tráfico para ese servicio.

Cómo funciona ARP en MetalLB

Cuando un cliente externo intenta acceder a una dirección IP asignada por MetalLB, enviará una solicitud ARP en la red local preguntando “¿Quién tiene esta dirección IP?”.
El componente Speaker de MetalLB, instalado en los nodos del clúster, responderá con la dirección MAC del nodo que maneja esa IP, permitiendo que el tráfico sea dirigido correctamente.

Ventajas de la integración con ARP

Simplicidad: No se requiere hardware de red avanzado ni cambios de configuración en los routers o switches.
Compatibilidad: Funciona en redes IPv4 estándar, lo que lo hace adecuado para la mayoría de las implementaciones on-premise.

Limitaciones de ARP

Escalabilidad: Este enfoque es más adecuado para pequeñas redes de una sola subred. En entornos de redes más grandes o distribuidas, puede haber limitaciones de escalabilidad y posibles colisiones de ARP.
Alta disponibilidad limitada: En caso de que un nodo falle, puede haber un pequeño lapso de tiempo antes de que MetalLB reasigne correctamente la dirección IP a otro nodo.

Ejemplo de Configuración ARP (Layer 2)

apiVersion: v1
kind: ConfigMap
metadata:
  namespace: metallb-system
  name: config
data:
  config: |
    address-pools:
    - name: default
      protocol: layer2
      addresses:
      - 192.168.1.240-192.168.1.250

apiVersion: v1

kind: ConfigMap

metadata:

namespace: metallb-system

data:

config: |

address-pools:

- name: default

protocol: layer2

addresses:

- 192.168.1.240-192.168.1.250

Integración con NDP (Neighbor Discovery Protocol)

NDP es el protocolo equivalente a ARP en redes IPv6. En lugar de utilizar ARP para descubrir la dirección MAC asociada con una dirección IP en redes IPv4, en redes IPv6 se utiliza NDP para la misma función.

Cómo funciona NDP en MetalLB

Cuando un cliente en una red IPv6 envía una solicitud de descubrimiento (solicitud Neighbor Solicitation) para una dirección IPv6 gestionada por MetalLB, el nodo de Kubernetes que está asignado a esa IP responde con su dirección MAC mediante una respuesta Neighbor Advertisement.

Ventajas de la integración con NDP

Compatibilidad con IPv6: Permite a MetalLB funcionar de manera efectiva en redes IPv6 nativas.
Funciona en redes locales: Al igual que ARP, NDP funciona bien en redes de una sola subred sin la necesidad de configuraciones complejas de red.

Ejemplo de Configuración NDP (Layer 2 – IPv6)

apiVersion: v1
kind: ConfigMap
metadata:
  namespace: metallb-system
  name: config
data:
  config: |
    address-pools:
    - name: default
      protocol: layer2
      addresses:
      - 2001:db8::1-2001:db8::ff

apiVersion: v1

kind: ConfigMap

metadata:

namespace: metallb-system

data:

config: |

address-pools:

- name: default

protocol: layer2

addresses:

- 2001:db8::1-2001:db8::ff

Integración con BGP (Border Gateway Protocol)

El modo BGP es útil en entornos más avanzados donde tienes routers que pueden anunciar rutas dinámicamente. En este modo, MetalLB se comunica con un router BGP para anunciar las IPs que están siendo utilizadas por los servicios de Kubernetes. Este enfoque es escalable y más adecuado para grandes infraestructuras que requieren alta disponibilidad.

Cómo funciona BGP en MetalLB

MetalLB, en modo BGP, actúa como un router BGP, anunciando las direcciones IP asignadas a los servicios de Kubernetes a otros routers en la red.
Los routers externos a la red del clúster aprenden la ruta hacia las IPs expuestas por MetalLB y dirigen el tráfico hacia los nodos de Kubernetes que están anunciando esas IPs.

Ventajas de la integración con BGP

Alta disponibilidad: En caso de fallo de un nodo, otro nodo puede asumir la dirección IP y anunciarla sin problemas a los routers.
Escalabilidad: BGP es altamente escalable y adecuado para redes grandes o distribuidas, ya que facilita el enrutamiento entre diferentes segmentos de red y data centers.
Redundancia: Permite implementar múltiples rutas redundantes, asegurando que el tráfico siempre tiene una ruta válida hacia el clúster.

Limitaciones de BGP

Complejidad: La configuración de BGP requiere conocimiento avanzado de redes y acceso a routers compatibles con BGP.
Requisitos de infraestructura: El uso de BGP suele estar limitado a entornos empresariales donde se dispone de infraestructura de red avanzada.

Ejemplo de configuración BGP

En un entorno con soporte BGP, podrías modificar tu archivo de configuración de MetalLB para que utilice el protocolo BGP en lugar de Layer 2.

apiVersion: v1
kind: ConfigMap
metadata:
  namespace: metallb-system
  name: config
data:
  config: |
    peers:
    - peer-address: 192.168.1.1
      peer-asn: 64512
      my-asn: 64513
    address-pools:
    - name: default
      protocol: bgp
      addresses:
      - 192.168.1.240-192.168.1.250

apiVersion: v1

kind: ConfigMap

metadata:

namespace: metallb-system

data:

config: |

peers:

- peer-address: 192.168.1.1

peer-asn: 64512

my-asn: 64513

address-pools:

- name: default

protocol: bgp

addresses:

- 192.168.1.240-192.168.1.250

Este archivo configura MetalLB para que hable con un enrutador BGP con la dirección IP 192.168.1.1 para anunciar el rango de IPs externas 192.168.1.240-192.168.1.250.

En este ejemplo:

peer-address: La dirección IP del router BGP con el que MetalLB intercambia rutas.
peer-asn: El número de sistema autónomo (ASN) del router BGP.
my-asn: El ASN asignado al clúster Kubernetes.

Escenarios de uso de BGP

Multi-data center: En un entorno distribuido con varios centros de datos, BGP puede anunciar rutas a los routers de cada centro, permitiendo un acceso eficiente y balanceado a los servicios de Kubernetes.
Alta disponibilidad geográfica: Si los servicios de Kubernetes necesitan estar disponibles en múltiples ubicaciones geográficas, BGP puede facilitar el enrutamiento óptimo entre regiones.

Comparativa de ARP, NDP y BGP en MetalLB

La elección entre ARP, NDP y BGP dependerá de las necesidades y la infraestructura de tu clúster de Kubernetes:

ARP o NDP (Layer 2): Si tu clúster se encuentra en una red local pequeña o mediana y no necesitas enrutamiento avanzado, la configuración Layer 2 es la más simple y fácil de implementar.
BGP (Layer 3): Si tu infraestructura es más grande, distribuida geográficamente o necesitas alta disponibilidad con enrutamiento avanzado, el modo BGP es la mejor opción. Este modo te proporciona la capacidad de escalar a nivel empresarial

Os dejo una tabla comparativa: