How MetalLB Transforms Load Balancing for Bare‑Metal Kubernetes Clusters

Basic Overview

1. Service

Kubernetes assigns each pod an IP that may change; Service abstracts this and provides a stable virtual IP and load balancing.

Type

Service types: ClusterIP (internal), NodePort (nodeIP:nodePort external), LoadBalancer (cloud LB).

Port

Three ports: port (ClusterIP entry), NodePort (external entry), TargetPort (container port).

IP

Service uses ClusterIP, Pod IP, and Node IP.

Working Method

Service selector creates Endpoints; kube-proxy updates iptables for load balancing.

MetalLB Overview

MetalLB provides a LoadBalancer implementation for bare‑metal clusters where cloud LB is unavailable.

This project was released at the end of 2017 and is currently in Beta.

MetalLB supports network plugins such as Canal, Cilium, Flannel, Kube‑ovn. When kube-proxy runs in IPVS mode, set strictARP: true.

Kubernetes does not provide a native LB for bare‑metal; only NodePort and externalIPs are available, which have drawbacks.

MetalLB solves this by allocating IPs from a pool and announcing them via ARP/NDP or BGP.

Address Allocation

MetalLB needs an IP pool; the controller (deployment) watches Services and assigns IPs, which can be manual or automatic.

External Announcement

The speaker (daemonset) announces the allocated IP using Layer2 (ARP/NDP) or BGP.

Architecture

MetalLB consists of a controller (deployment) and a speaker (daemonset). The controller watches Service changes, allocates IPs, and the speaker broadcasts them.

Installation

Pre‑installation Checks

If using IPVS mode, enable strict ARP in kube-proxy config (since v1.14.2).

# kubectl edit configmap -n kube-system kube-proxy

apiVersion: kubeproxy.config.k8s.io/v1alpha1
kind: KubeProxyConfiguration
mode: "ipvs"
ipvs:
  strictARP: true

Update kube-proxy pods, then apply MetalLB manifests:

# mkdir metallb && cd metallb
# wget https://github.com/metallb/metallb/blob/main/config/manifests/metallb-native.yaml
# kubectl apply -f metallb-native.yaml
# kubectl -n metallb-system get all

Create secret for speaker:

# kubectl create secret generic -n metallb-system memberlist --from-literal=secretkey="$(openssl rand -base64 128)"

Configuration

Create ConfigMap with address pool:

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

Apply the ConfigMap.

Testing

Deploy a LoadBalancer Service and a Deployment, then verify the assigned external IP.

# vim nginx.yaml
apiVersion: v1
kind: Service
metadata:
  name: nginx-svc
spec:
  selector:
    app: nginx
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80
  type: LoadBalancer
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: myapp:v1

Observe internal and external access via the allocated IP.

MetalLB with Ingress

Modify Ingress manifest to use the LoadBalancer Service provided by MetalLB, adjust network mode, and change speaker from DaemonSet to Deployment if needed. # kubectl apply -f ingress-demo.yml Access flow: user → MetalLB VIP → ingress‑nginx → Service → Pod.

Calico Network Plugin

Introduction

Calico provides pod‑to‑pod isolation using BGP routing without NAT or overlay, suitable for large‑scale environments.

Architecture

Felix configures pod interfaces and ACLs; BIRD propagates routes via BGP; IPIP mode for cross‑subnet pods; BGP mode for same‑subnet large networks.

Reference: https://www.cnblogs.com/hahaha111122222/p/17222696.html