Skip to main content
The Pools & IPAM tab is the single home for every IP pool on a supervisor. One table lists all three kinds, each tagged with a kind chip and a usage bar; IP allocations and per-project allocations sit below it. VM identity pools carry a live-migration capable badge and have their own page — see VM identity pools. The Pools & IPAM tab — unified pool table with kind chips and usage, allocations below

​
LoadBalancer pools

A LoadBalancer pool defines the addresses Cilium’s LB-IPAM may assign to Services. Create one with Add pool and fill in:
Disabled is the safe way to drain a pool: Services that already hold an address keep it, while new Services are steered to other pools. Deleting the pool instead would strip addresses from live Services.
Leave Allow first/last IPs off for CIDR blocks unless you know the fabric routes them. The network (.0) and broadcast (.255 on a /24) addresses are technically assignable, and some upstream equipment drops traffic to them.

​
Utilization and conflicts

Each pool row shows live numbers read from the pool’s own status conditions — total, used, and available addresses — rendered as a usage bar. A freshly created /27 pool carrying one Service reads 32 total · 1 used · 31 available; the bar turns from healthy to warning as the pool fills. The same conditions surface pool conflicts: when two pools overlap, Cilium marks the newer one conflicting and stops allocating from it. A conflicting pool is flagged in the table; fix the overlap rather than working around it, because a conflicted pool silently serves nothing.

​
Project and tenant pools

Pools created by a project — its LoadBalancer slice, carved from the supervisor’s addressing plan — appear in the same table, grouped under the owning project. Tenant clusters get a pool of their own too, with a service selector that scopes it to that cluster’s published services. Both kinds are managed through their owning lifecycle — edit the project or cluster, not the pool object. Project networking explains how the slices are carved and what else a project provisions.

​
Pod IP pools

Pod IP pools give different workloads addresses from different ranges — multi-tenant pod networking, per-pool masquerade control, or per-pool BGP advertisement. A pool defines: Cilium picks a pool for a pod in this order:
1

Pod annotation

An explicit ipam.cilium.io/ip-pool=<pool> annotation on the pod wins outright.
2

Selectors

Otherwise the pod is matched against each pool’s pod and namespace selectors.
3

Default pool

Otherwise the pool named default serves it.
A pod must match exactly one pool per IP family. Overlapping selectors do not merge — they make allocation fail, and the pod sticks in ContainerCreating. Keep selectors disjoint.

​
Allocation views

Two views below the pool table answer “who holds what”. IP allocations assembles the supervisor’s full address picture: Owner resolution goes one step past the Service: an address held by the supervisor-side mirror of a tenant cluster’s Service is attributed to that tenant cluster, not to the mirror object. This is the view to check before shrinking any pool. Project allocations rolls the same data up per project — its LoadBalancer range, its egress IP, which prefix kinds it advertises over BGP (pod, LoadBalancer, egress), its egress routing mode, and its default isolation policy. It answers “what does this project’s network footprint look like” in one row; the intent behind each column is set on the project itself — see Project networking.

​
Looking up an IP

Any single address can be resolved to its owner: a Service, a pod, a VM, a node, or an infrastructure interface. The answer includes what kind of thing holds it and a plain description — “Kubernetes Service (LoadBalancer)” — and, for infrastructure interfaces, the subnet and VLAN the address belongs to. Use it when an unfamiliar address turns up in a flow log or a firewall rule and you need to know what it is before acting on it.

​
Address plan and guest networks

The Address plan card below the pools compares the supervisor’s declared plan with every pool, egress policy, project and guest cluster on the supervisor. It flags conflicts and orphans. Edit plan opens the plan in onboarding’s Networking step. Reading the card needs cilium:GetState.

​
Guest networks

Guest networks on the address plan card sets where guest clusters get their pod and service networks. If you create a guest cluster without its own pod or service CIDR, it gets the next free slice of these supernets. Celum reserves that slice in the supervisor’s cluster config until the cluster’s Cluster object exists.
Networking → Pools & IPAM → Address plan → Guest networks. The drawer’s description shows the values in effect, and whether they are declared here, partly declared, or the deployment default. If you leave a field empty, that field keeps its deployment default. Return to the deployment default clears all four.
  • Celum refuses a mask that is not longer than its supernet or that is longer than /28. It also refuses pod and service supernets that overlap, and a supernet that overlaps the supervisor’s address block.
  • The change applies only to clusters you create after it. Existing clusters keep their networks.
  • When nothing is declared, every supervisor uses the deployment’s values: GUEST_POD_SUPERCIDR, GUEST_POD_CIDR_MASK, GUEST_SERVICE_SUPERCIDR and GUEST_SERVICE_CIDR_MASK.
Size the pod mask by the number of nodes, not pods. Each guest node takes a /24 of its cluster’s pod network, so a /19 holds 32 nodes and a /22 holds only 4.

​
Permissions

Both are scoped to krn:celum:supervisor:<supervisor>:cilium:*.

VM identity pools

The third pool kind — addresses that survive live migration.

BGP & Egress

How pool prefixes get advertised to the fabric.

Project networking

Where a project’s LoadBalancer slice and egress IPs come from.

Networking overview

The engine model behind this page.