Service labels and their life cycle

Any Subnet object may contain ipam/SVC-<serviceName> labels. All IP addresses allocated from the Subnet object that has service labels defined, will inherit those labels.

When a particular IpamHost uses IP addresses allocated from such labeled Subnet objects, the ServiceMap field in IpamHost.Status will contain information about which IPs and interfaces correspond to which service labels (that have been set in the Subnet objects). Using ServiceMap, you can understand what IPs and interfaces of a particular host are used for network traffic of a given service.

Currently, Container Cloud uses the following service labels that allow for the use of specific subnets for particular Container Cloud services:

  • ipam/SVC-k8s-lcm

  • ipam/SVC-ceph-cluster

  • ipam/SVC-ceph-public

  • ipam/SVC-dhcp-range

  • ipam/SVC-MetalLB

  • ipam/SVC-LBhost


The use of the ipam/SVC-k8s-lcm label is mandatory for every cluster.

You can also add own service labels to the Subnet objects the same way you add Container Cloud service labels. The mapping of IPs and interfaces to the defined services is displayed in IpamHost.Status.ServiceMap.

You can assign multiple service labels to one network. You can also assign the ceph-* and MetalLB services to multiple networks. In the latter case, the system sorts the IP addresses in the ascending order:

    - ifName: ceph-br2
    - ifName: ceph-br1
    - ifName: ceph-public
    - ifName: k8s-lcm

You can add service labels during creation of subnets as described in Create subnets for a managed cluster using CLI.