Skip to main content
In this lesson we cover Cilium’s LoadBalancer IPAM: how Cilium can allocate external IP addresses for Kubernetes LoadBalancer Services and how to make those IPs reachable from your network. Why this matters
  • In cloud providers (for example, EKS on AWS) creating a Service of type LoadBalancer usually triggers the cloud provider to provision a load balancer and return an external IP or DNS name (for example, an AWS ELB DNS entry).
  • On-premise clusters typically use components like MetalLB to provide external IPs.
  • Cilium’s LoadBalancer IPAM eliminates the need for separate tooling by allocating external IPs directly from configured pools and exposing them as the Service EXTERNAL-IP.
How it looks in Kubernetes When Cilium assigns an external IP to a Service, it appears in the Service listing: 
user1@control-plane:~$ kubectl get svc
NAME              TYPE           CLUSTER-IP     EXTERNAL-IP   PORT(S)          AGE
kubernetes        ClusterIP      10.96.0.1      <none>        443/TCP          36d
myapp-service     LoadBalancer   10.98.13.153   10.0.10.1     80:30699/TCP     170m
Traffic sent to that EXTERNAL-IP will be routed to the Service and then to the pods backing it, provided the network fabric advertises or forwards that IP to the cluster. How to configure LoadBalancer IPAM (CiliumLoadBalancerIPPool) Create a Cilium custom resource of kind CiliumLoadBalancerIPPool describing the address ranges Cilium can use and optional selectors that control which Services may receive external IPs. Example manifest: 
apiVersion: cilium.io/v2alpha1
kind: CiliumLoadBalancerIPPool
metadata:
  name: blue-pool
spec:
  blocks:
    - cidr: "10.0.10.0/24"
    - cidr: "2004::0/64"
    - start: "20.0.20.100"
      stop: "20.0.20.200"
    - start: "1.2.3.4"
  serviceSelector:
    matchLabels:
      color: red
Spec fields explained
  • apiVersion / kind / metadata.name: standard Kubernetes CR metadata.
  • spec.blocks: one or more blocks from which external IPs are allocated.
  • spec.serviceSelector: (optional) restricts allocation to Services matching the provided labels.
Types of blocks supported
Block typeDescriptionExample
CIDRA CIDR range (IPv4 or IPv6) from which Cilium will allocate IPscidr: "10.0.10.0/24"
Start/Stop rangeAn explicit sequential range between two addressesstart: "20.0.20.100", stop: "20.0.20.200"
Single IPA start-only entry to represent a single IPstart: "1.2.3.4"
Service selector behavior
  • If you include spec.serviceSelector, only Services that match those labels will be eligible for external IP allocation from this pool.
  • In the example above, only Services labeled color: red will be assigned IPs from blue-pool.
Making the allocated external IPs reachable Allocating an IP on the Service resource is only half the job — you must ensure external routing/forwarding directs traffic for those IPs to the cluster nodes. Common methods:
MechanismWhen to useNotes
BGP advertisementsData center or network fabric supports BGP peeringUse a BGP speaker to advertise pool prefixes to upstream routers
L2 announcements (ARP/NDP)Simple L2 networks or when BGP is not availableCluster nodes respond to neighbor discovery for allocated IPs
Static routing (network config)Small deployments or lab environmentsAdd static routes pointing to cluster nodes or load balancer devices
Verification and troubleshooting
  • Verify the pool CR exists:
    • kubectl get ciliumloadbalancerippool -A
    • kubectl describe ciliumloadbalancerippool blue-pool
  • Check Service allocation:
    • kubectl get svc myapp-service -o wide
    • kubectl describe svc myapp-service
  • Confirm network reachability:
    • From outside the cluster, ping or curl the EXTERNAL-IP.
    • Use network tools on upstream routers to verify routes or BGP advertisements.
  • Logs and Cilium status:
    • Check Cilium agent logs on nodes for IPAM-related messages.
    • Inspect Cilium control plane status (see Cilium documentation for cluster-specific commands).
Best practices
  • Only include pool ranges that your network fabric can route to the cluster.
  • Use selectors to separate pools by environment (prod/staging) or by tenant.
  • Prefer advertising the entire pool prefix via BGP when possible — it simplifies routing and scales better than per-IP static routes.
Links and references Important: you must ensure that external routing/forwarding is configured so traffic destined to those allocated external IPs actually reaches your cluster. Common ways to advertise or make those routes reachable include:
  • BGP advertisements from the cluster (peering with a router or BGP speaker).
  • L2 (ARP/NDP) announcements so the cluster responds to neighbor discovery for the IPs.
BGP and other advertisement mechanisms are commonly used to advertise those allocated external IPs to the wider network so they become reachable.
When creating pools, include only ranges that your network fabric can actually route to the cluster. Otherwise external traffic won’t reach the assigned IPs even though Services will show the EXTERNAL-IP.

Watch Video