Cloud Avenue Wiki
< All Topics

Understanding network exposure on Hosted OpenShift on VCD

The network exposure of an application on a Cloud Avenue OpenShift Hosted Cluster is unique:
the IaaS environment does not allow directly attaching a public IP address to a Kubernetes workload.

This behavior is intentional, inherited from the Cloud Avenue secure model.

This guide explains:

  • why a public IP address cannot be directly attached,
  • how Cloud Avenue uses MetalLB by default,
  • how to create an internal IP address pool for your applications,
  • and how to publish your services via DNAT on the tenant’s Edge Gateway.

1. Why can’t a public IP address be assigned directly to a Load Balancer Service?

In Cloud Avenue, each tenant has its own Edge Gateway.

This gateway manages:

  • public IP addresses,
  • NAT rules,
  • network security, and
  • tenant isolation.

Therefore:

  • no public IP address can be assigned to a worker,
  • no public IP address can be assigned to a Kubernetes service,
  • andall internet access must go through the tenant’s Edge Gateway.

In summary:

A public IP address can never point directly to a pod. Access is only possible via DNAT rules on the Edge Gateway.

2. Why does Cloud Avenue deploy MetalLB by default?

IaaS environments (like Cloud Avenue) do not have a native Kubernetes load balancer.
Therefore, OpenShift cannot automatically assign external IPs without an additional component.

This is why Cloud Avenue installs MetalLB by default.

MetaLB, what’s this ?

MetalLB is a load balancer for Kubernetes designed for bare-metal and IaaS environments.

It allows you to:

  • assign internal IPs to Load Balancer services,
  • respond to ARP/Layer 2 requests on the worker network, and
  • provide a stable internal IP for each exposed application.

However, these IPs remain internal.
To make them public, DNAT is required.

3. The default MetaLB pool that comes with each cluster

Upon delivery, Cloud Avenue configures a very limited initial MetalLB pool.

This pool is used solely for:

  • access to the OpenShift console,
  • access to Ingress routes *.apps..kaas.cav.

This pool contains a single IP address (or a very small range).

It must not be used for the client’s applications.

4. How to expose your applications?

    → You need to create an additional MetalLB pool

    To expose your applications via LoadBalancer, you must create your own MetalLB pool.

    This pool must:

    • be on the same network as the workers,
    • not overlap with the OpenShift pool,
    • use available IP addresses within your network range.

    Example

    Let’s assume your workers use the network:
    192.168.10.0/24

    You can reserve a pool for your apps:
    192.168.10.50-192.168.10.100

    5. Create MetalLB pool (AddressPool + L2Advertissement)

    Here is a complete example to adapt according to your network.

    IPAddressPool

    apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: pool-applications
  namespace: metallb-system
spec:
  addresses:
    - 192.168.10.50-192.168.10.100

    L2Advertisement

    apiVersion: metallb.io/v1beta1
kind: L2Advertisement
metadata:
  name: pool-applications
  namespace: metallb-system
spec:
  ipAddressPools:
    - pool-applications

    Apply configuration :

    oc apply -f pool-applications.yaml

    Check :

    oc -n metallb-system get ipaddresspool
oc -n metallb-system get l2advertisement

    6. Deploy your LoadBalancer Service (assign an internal MetalLB IP)

    Example :

    oc expose deployment myapp --type=LoadBalancer --port=8080

    Check :

    oc get svc myapp

    You will see an internal IP address from the pool, for example

    EXTERNAL-IP   192.168.10.55

    ⚠️ This IP address is not public.

    It is only accessible within the tenant’s network.

    7. Make the application accessible from the Internet: create a DNAT rule

    To expose your application to the public, you need to create a DNAT rule on the tenant’s Edge Gateway:

    Public IP → IP MetalLB → Pod

    Example DNAT :

    • Public IP : 164.2.123.45
    • IP MetalLB service : 192.168.10.55
    • Port public : 443
    • Port internal : 8080

    The rule will look something like this:

    DNAT:
164.2.123.45:443  →  192.168.10.55:8080

    From this moment on:

    • l’IP publique répond,
    • la Edge translate vers l’IP MetalLB interne,
    • Kubernetes route ensuite vers votre application.

    Résumé global

    ElementRole
    Public IPManaged by the tenant’s Edge Gateway
    MetalLBAssigns internal IPs LoadBalancer
    Default MetalLB poolReserved for OpenShift (*.apps + console)
    MetalLB pool customerAllows you to showcase your applications
    DNAT Edge GatewayMakes the application accessible via the Internet

    In short:

    MetalLB provides an internal IP address, the Edge publishes it via DNAT, and the application becomes accessible from the internet.