documentation.suse.com / Documentación de SUSE Edge / Guías prácticas / MetalLB en K3s (con el modo de capa 3)

26 MetalLB en K3s (con el modo de capa 3)

 

MetalLB es una implementación de equilibrador de carga para clústeres de Kubernetes en bare metal que utiliza protocolos de enrutamiento estándar.

En esta guía se explica cómo desplegar MetalLB en el modo de capa 3 (L3) de BGP.

26.1 Por qué usar MetalLB

 

MetalLB es una opción conveniente para el equilibrio de carga en clústeres bare metal de Kubernetes por varias razones:

  1. Integración nativa con Kubernetes: MetalLB se integra a la perfección con Kubernetes, lo que facilita el despliegue y la gestión mediante las herramientas y prácticas habituales de Kubernetes.

  2. Compatibilidad bare metal: a diferencia de los equilibradores de carga basados en la nube, MetalLB se ha diseñado específicamente para despliegues locales en las que los sistemas de equilibrio de carga tradicionales podrían no estar disponibles o no ser viables.

  3. Compatibilidad con múltiples protocolos: MetalLB admite el modo de capa 2 y el de capa 3 de BGP (Border Gateway Protocol, protocolo de gateway de frontera), lo que proporciona flexibilidad para diferentes arquitecturas y requisitos de red.

  4. Alta disponibilidad: dado que distribuye el equilibrio de carga entre varios nodos, MetalLB garantiza una alta disponibilidad y fiabilidad para sus servicios.

  5. Escalabilidad: MetalLB puede manejar despliegues a gran escala, y se va adaptando con su clúster de Kubernetes para satisfacer la demanda creciente.

En el modo de capa 2 (L2), un nodo asume la responsabilidad de anunciar un servicio a la red local. Desde la perspectiva de la red, simplemente parece que esa máquina tiene varias direcciones IP asignadas a su interfaz de red.

La mayor ventaja del modo de capa 2 es su universalidad: funciona en cualquier red Ethernet sin necesidad de hardware especial, ni siquiera de routers sofisticados.

26.2 MetalLB en K3s (con L3)

 

En este inicio rápido, se utilizará el modo L3. Esto significa que se necesita tener router vecinos con capacidad de BGP dentro del rango de red.

26.3 Requisitos previos

 

  • Un clúster K3s donde se vaya a desplegar MetalLB.

  • Routers de la red que admiten el protocolo BGP.

  • Una dirección IP libre en el rango de red del servicio. En este ejemplo, 192.168.10.100

Importante
Importante

Debe asegurarse de que esta dirección IP no esté asignada. En un entorno DHCP, esta dirección no debe ser parte del grupo DHCP para evitar asignaciones dobles.

26.4 Configuración para anunciar direcciones IP de servicio

 

La nueva versión de BGP anuncia una dirección IP de servicio a todos los pares configurados. Estos pares, que suelen ser routers, reciben una ruta por cada dirección IP de servicio con una máscara de red de 32 bits. En este ejemplo, se usará un router basado en FRR que se encuentra en la misma red que nuestro clúster. Después, se usará la capacidad de BGP de MetalLB para anunciar un servicio a ese router basado en FRR.

26.5 Despliegue

 

Utilizaremos el chart de Helm de MetalLB publicado como parte de la solución SUSE Edge:

helm install \
  metallb oci://registry.suse.com/edge/charts/metallb \
  --namespace metallb-system \
  --create-namespace

while ! kubectl wait --for condition=ready -n metallb-system $(kubectl get\
 pods -n metallb-system -l app.kubernetes.io/component=controller -o name)\
 --timeout=10s; do
 sleep 2
done

26.6 Configuración

 

  1. Ahora, la instalación está completa. Cree un IPAddressPool:

cat <<-EOF | kubectl apply -f -
apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: bgp-pool
  namespace: metallb-system
  labels:
    app: httpd
spec:
  addresses:
  - 192.168.10.100/32
  autoAssign: true
  avoidBuggyIPs: false
  serviceAllocation:
    namespaces:
    - metallb-system
    priority: 100
    serviceSelectors:
    - matchExpressions:
      - key: serviceType
        operator: In
        values:
        - httpd
EOF

  1. Configure un BGPPeer.

Nota
Nota

El router FRR tiene ASN 1000, mientras que nuestro BGPPeer tendrá 1001. También se puede observar que el router FRR tiene la dirección IP 192.168.3.140.

cat <<-EOF | kubectl apply -f -
apiVersion: metallb.io/v1beta2
kind: BGPPeer
metadata:
  namespace: metallb-system
  name: mypeertest
spec:
  peerAddress: 192.168.3.140
  peerASN: 1000
  myASN: 1001
  routerID: 4.4.4.4
EOF

  1. Cree el BGPAdvertisement (L3):

cat <<-EOF | kubectl apply -f -
apiVersion: metallb.io/v1beta1
kind: BGPAdvertisement
metadata:
  name: bgpadvertisement-test
  namespace: metallb-system
spec:
  ipAddressPools:
  - bgp-pool
EOF

26.7 Uso

 

  1. Cree una aplicación de ejemplo con un servicio. En este caso, la dirección IP de IPAddressPool es 192.168.10.100 para ese servicio.

cat <<- EOF | kubectl apply -f -
apiVersion: apps/v1
kind: Deployment
metadata:
  name: httpd-deployment
  namespace: metallb-system
  labels:
    app: httpd
spec:
  replicas: 3
  selector:
    matchLabels:
      pod-label: httpd
  template:
    metadata:
      labels:
        pod-label: httpd
    spec:
      containers:
      - name: httpdcontainer
        image: image: docker.io/library/httpd:2.4
        ports:
          - containerPort: 80
            protocol: TCP
      restartPolicy: Always

---
apiVersion: v1
kind: Service
metadata:
  name: http-service
  namespace: metallb-system
  labels:
    serviceType: httpd
spec:
  selector:
    pod-label: httpd
  type: LoadBalancer
  ports:
  - protocol: TCP
    port: 8080
    name: 8080-tcp
    targetPort: 80
EOF

  1. Para verificar, inicie sesión en el router FRR para comprobar las rutas creadas desde el anuncio BGP.

42178089cba5# show ip bgp all

For address family: IPv4 Unicast
BGP table version is 3, local router ID is 2.2.2.2, vrf id 0
Default local pref 100, local AS 1000
Status codes:  s suppressed, d damped, h history, * valid, > best, = multipath,
               i internal, r RIB-failure, S Stale, R Removed
Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self
Origin codes:  i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

   Network          Next Hop            Metric LocPrf Weight Path
* i172.16.0.0/24    1.1.1.1                  0    100      0 i
*>                  0.0.0.0                  0         32768 i
* i172.17.0.0/24    3.3.3.3                  0    100      0 i
*>                  0.0.0.0                  0         32768 i
*= 192.168.10.100/32
                    192.168.3.162                          0 1001 i
*=                  192.168.3.163                          0 1001 i
*>                  192.168.3.161                          0 1001 i

Displayed  3 routes and 7 total paths
kubectl get svc -n hello-kubernetes
NAME               TYPE           CLUSTER-IP     EXTERNAL-IP      PORT(S)        AGE
hello-kubernetes   LoadBalancer   10.43.127.75   192.168.122.11   80:31461/TCP   8s

  1. Si este router en el gateway por defecto para la red, puede ejecutar el comando curl desde un cuadro en esa red para verificar que pueden acceder a la aplicación HTTPD de ejemplo.

# curl http://192.168.10.100:8080
<html><body><h1>It works!</h1></body></html>
#