Knowledge Search


[Contrail] Understanding Floating IP Pool Scopes in Kubernetes environment

  [KB35083] Show Article Properties


The 'floating IP', or 'FIP' for short, is a "traditional" concept that Contrail supports. It is an openstack concept to "map" a VM IP, which is typically a private IP address, to a public IP (the "floating IP" in this context) that is reachable from the outside of the cluster. Internally, the one-to-one mapping is implemented by NAT.

Whenever a vrouter receives packets from outside of the cluster destined to the floating IP, it will translate it to the VM's private IP and forward the packet to the VM. Similarly, it will do the translation on reverse direction. Eventually, both the VM and Internet host can talk to each other, and both can initiate the communication.

This article discusses three different FIP pool scopes that is available in Contrail5 Kubernetes environment.


There are different ways to refer a Floating IP Pool in Contrail5 Kubernetes environment, and correspondingly the scope of the pools will also be different. Here are 3 possible levels with descending priority:

  1. .object specific - This is the most specific level of scope. Object specific FIP pool binds itself only to the object that you specified. It does not affect any other objects in the same namespace (NS) or the cluster. For instance, you can specify a service object, 'web' to get FIP from FIP pool 'pool1', a service object, 'dns' to get FIP from another FIP pool, 'pool2', etc.  This gives the most granular control of where the FIP will be allocated from for an object. The cost is that you need to explicitly specify it in your yaml file for every object.

  2. .NS level - In a multi tenancy environment, each namespace would be associated to a tenant, and each tenant would have a dedicated FIP pool. In that case, it is better to have an option to define at "NS level" FIP pool, so that all objects created in that NS will get FIP assignment from that pool. With NS level pool defined (e.g. 'pool-ns-default'), there is no need to specify the FIP-pool name in each object's yaml file anymore. You can still give a different pool name, such as 'my-webservice-pool' in an object 'webservice'. In that case, the object 'webservice' will get the FIP from 'my-webservice-pool' instead of from the NS level pool, 'pool-ns-default' because the former is more specific.

  3. .global level - The scope of the "global" level pool will be the whole cluster. Objects in any namespaces can use the "global" FIP pool. You can combine all 3 methods to take advantage of the flexibility. Here is a practical example:

    • Define a global pool 'pool-global-default', so that any objects in a NS that has no NS-level or object-level pool defined will get an FIP from this pool.
    • For NS 'dev', define an FIP pool 'pool-dev', so that all objects created in NS 'dev' will by default get FIP from 'pool-dev'.
    • For NS 'sales', define a FIP pool 'pool-sales', so all objects created in NS 'sales' will by default get FIP from 'pool-dev'.
    • For NS 'test-only', do NOT define any NS level pool, so by default objects created in it will get FIP from the 'pool-global-default'.
    • When a service 'dev-webservice' in NS 'dev' needs an FIP from 'pool-sales' instead of 'pool-dev', specify 'pool-sales' in 'dev-webservice' object yaml file will achieve this goal.

Note: Keep in mind the rule of thumb - The most specific scope will always prevail.

Related Links: