Total Pageviews

Friday, December 29, 2023

Hands-on – MetalLB Load Balancer: External Traffic into Kubernetes

To connect an application running inside the Kubernetes Cluster, a traffic routing mechanism is required. This mechanism is generally known as the Proxy Service. In this hands-on tutorial, we will be using the MetalLB load balancer which is widely used in bare metal Kubernetes environment and supports both L2 and BGP mode.

A pod in Kubernetes is ephemeral in nature so each time a pod restarts on the same or a different node, Kubernetes assigns a new IP. Although a nodePort IP can be used from outside the Kubernetes Cluster, the application connection string will need to be changed if the pod starts on a different cluster node. To solve this problem a “Service Proxy” is required and this service proxy will reroute (routing) the external traffic to the appropriate pod automatically.

There are three supported ways of installing MetalLB: using plain Kubernetes manifests, using Kustomize, or using Helm. In this tutorial, we will use the Kubernetes manifests method in our bare metal Kubernetes cluster.

Step#1: Installing MetalLB:

Before installing MetalLB, please review the official documentation for any further requirements. Note that we’ll need to perform all steps on the control plane as the root user.

Apply the MetalLB manifest:
# kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/v0.13.12/config/manifests/metallb-native.yaml

If firewall is enabled, then open tcp and udp port:
# ufw allow 7946/tcp
# ufw allow 7946/udp
# ufw reload


Verify that MetalLB is up and running:
# kubectl get pods -n metallb-system

MetalLB pods are up and running

Step#2: Create CRD for MetalLB:

We need to create an IP address pool for the Load Balancer Service. Please note that multiple instances of IPAddressPools can co-exist and addresses can be defined by CIDR notation, by range for both IPV4 and IPV6 addresses.

Create a Yaml file “metallb.yaml” file with the following contents. This will create two MetalLB custom resources (CRD). You will need to change the IP range as per your network.

 
# Create IP Address pool
apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: nat
  namespace: metallb-system
spec:
  addresses:
    - 192.168.0.70-192.168.0.75
  autoAssign: true

---

# Define as L2 mode
apiVersion: metallb.io/v1beta1
kind: L2Advertisement
metadata:
  name: empty
  namespace: metallb-system
 

Step#3: Creating LoadBalancer Type Service:

In our NFS deployment tutorial, we had created NodePort Services for external traffic. We can delete those NodePort services and then create new LoadBalancer type services for our pods. Please note that assigning NodePort IP is not recommended; it is best to let Kubernetes assign the IP to eliminate any possibility of IP conflicts.

Make sure that the app selector in service definition matches the pod selector.

 
# first Load Balancer Example
apiVersion: v1
kind: Service
metadata:
  name: srvsql01-svc
spec:
  type: LoadBalancer
  selector:
    app: srvsql01
  ports:
    - name: srvsql01
      port: 1433
      targetPort: 1433
      protocol: TCP

# second eaxmple
apiVersion: v1
kind: Service
metadata:
  name: srvsql02-svc
spec:
  type: LoadBalancer
  selector:
    app: srvsql02
  ports:
    - name: srvsql02
      port: 2433
      targetPort: 2433
      protocol: TCP
 
# third Load balancer
apiVersion: v1
kind: Service
metadata:
  name: srvsql03-svc
spec:
  type: LoadBalancer
  selector:
    app: srvsql03
  ports:
    - name: srvsql03
      port: 3433
      targetPort: 3433
      protocol: TCP
 

MetalLB: Load balancer services
Example#1: A simple deployment with LoadBalancer

Following is a complete example of a simple deployment of SQL Server pod using MeltalLB LoadBalancer:


# Simple deployment of SQL Server 
apiVersion: apps/v1
kind: Deployment
metadata:
  name: srvsql02
spec:
  replicas: 1
  strategy:
    type: Recreate  
  selector:
    matchLabels:
      app: srvsql02
  template:
    metadata:
      labels:
        app: srvsql02
    spec:
      terminationGracePeriodSeconds: 0
      hostname: srvsql02
      securityContext:
        fsGroup: 10001
      containers:
      - name: srvsql02
        image: mcr.microsoft.com/mssql/server:2019-latest
        ports:
        - containerPort: 2433
        env:
        - name: MSSQL_SA_PASSWORD
          value: "YourPassowrdHere"
        - name: MSSQL_PID
          value: "XXXXX-KKKKK-NNNNN-KKKKK-YYYYY"
        - name: ACCEPT_EULA
          value: "Y"
        - name: MSSQL_TCP_PORT
          value: "2433"
        - name: MSSQL_AGENT_ENABLED
          value: "true"  
        resources:
          requests:
            memory: 4Gi
            cpu: '2'
          limits:
            memory: 4Gi
        volumeMounts:
        - name: srvsql02-vol
          mountPath: /var/opt/mssql
          subPath: srvsql02
      volumes:
      - name: srvsql02-vol
        persistentVolumeClaim:
          claimName: nfs-srvsql02-pvc

---
# Load balance service
apiVersion: v1
kind: Service
metadata:
  name: srvsql02-svc
spec:
  type: LoadBalancer
  selector:
    app: srvsql02
  ports:
    - name: srvsql02
      port: 2433
      targetPort: 2433
      protocol: TCP

Example#2: A StateFul deployment with LoadBalancer

Following is a complete example of StateFulSet deplyment of SQL Server pod using MeltalLB LoadBalancer:

 
# StateFulSet deployment of SQL Server
apiVersion: v1
kind: Service
metadata:
  name: srvsql03-svc
spec:
  type: LoadBalancer
  selector:
    app: srvsql03
  ports:
    - name: srvsql03
      port: 3433
      targetPort: 3433
      protocol: TCP
---
# Create the stateful replica
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: srvsql03
spec:
  replicas: 1
  selector:
    matchLabels:
      app: srvsql03
  serviceName: "srvsql03-svc"    
  template:
    metadata:
      labels:
        app: srvsql03
    spec:
      terminationGracePeriodSeconds: 10
      hostname: srvsql03
      securityContext:
        fsGroup: 10001
      containers:
      - name: srvsql03
        image: mcr.microsoft.com/mssql/server:2022-latest
        ports:
        - containerPort: 3433
        env:
        - name: MSSQL_SA_PASSWORD
          value: "YourPasswordHere"
        - name: MSSQL_PID
          value: "QQQQQ-PPPPP-DDDDD-GGGGG-XXXXX"
        - name: ACCEPT_EULA
          value: "Y"
        - name: MSSQL_TCP_PORT
          value: "3433"
        - name: MSSQL_AGENT_ENABLED
          value: "true"  
        resources:
          requests:
            memory: 4Gi
            cpu: '2'
          limits:
            memory: 4Gi
        volumeMounts:
        - name: nfs-srvsql03-pvc
          mountPath: /var/opt/mssql
          subPath: srvsql03
  # Dynamic volume claim goes here
  volumeClaimTemplates:
  - metadata:
      name: nfs-srvsql03-pvc
    spec:
      accessModes: [ "ReadWriteOnce" ]
      storageClassName: "nfs-data"
      resources:
        requests:
          storage: 6Gi


Screenshot #1: Using SSMS to connect SQL Server using MetalLB Load Balancer:

Using SSMS: externernal traffic to Kubernetes using load balancer
 
References:
Service Proxy:
https://landscape.cncf.io/card-mode?category=service-proxy

MetalLB:
https://metallb.universe.tf/installation/

No comments:

Post a Comment