How to migrate from Load Balancer for MKS (IOLB) to Public Cloud Load Balancer (Octavia)

Learn how to migrate from an existing Load Balancer for Managed Kubernetes to a Public Cloud Load Balancer.

Public Cloud Load Balancer is the default Load Balancer for MKS clusters using Kubernetes version 1.31 or later.

Load Balancer for Managed Kubernetes is deprecated for MKS clusters using Kubernetes version 1.32 or later.

This guide explains the steps required to make this transition safely, minimizing service interruptions. Finally, it provides recommendations on DNS management, particularly reducing the TTL to optimize the propagation of changes and ensure a smooth migration.

Comparison

Below is a comparison between Load Balancer for Kubernetes and Public Cloud Load Balancer, highlighting their key differences and capabilities. Public Cloud Load Balancer introduces several sizes/flavors, you can find the detailed specifications on the Public Cloud Load Balancer page.

Annotations

Below is a comparison of existing annotations supported on Load Balancer for Managed Kubernetes and their equivalent on Public Cloud Load Balancer.

You can find full details on the official documentation pages:

• Load Balancer for Managed Kubernetes annotations
• Public Cloud Load Balancer annotations

Migration of your Load Balancer

There are two methods to move from a Load Balancer for Managed Kubernetes to a Public Cloud Load Balancer, you can either Migrate or Replace your Load Balancer.

Your existing Load Balancer Service using Load Balancer for Managed Kubernetes should have the following annotation:

annotations:
  loadbalancer.ovhcloud.com/class: "iolb"

Therefore, please read the entire guide (and especially the "How to perform a DNS switch" section) before you proceed with the steps below.

Migration

Migrating from an existing Load Balancer for Kubernetes to a Public Cloud Load Balancer involves creating a new Load Balancer service using Public Cloud Load Balancer with the same label selector to expose your application. For a short period of time, your application will be accessible using both Load Balancers.

At this time you can perform a DNS switch and then delete the old Load Balancer.

To migrate from an existing Load Balancer for Kubernetes to a Public Cloud Load Balancer, follow these steps:

Step 1 - Create a new Load Balancer service

You need to create a new Load Balancer service using the Public Cloud Load Balancer while keeping the existing one active:

• Ensure that the new service has the same labelSelector as the old one so that it exposes the same application.
• You can set the annotation loadbalancer.ovhcloud.com/class: "octavia" for Kubernetes version 1.30 (or earlier). Public Cloud Load Balancer Octavia will be the default load balancer for Kubernetes version 1.31 (or later).

labelSelector:

spec:
  selector:
    app: my-app

annotations:

annotations:
  loadbalancer.ovhcloud.com/class: "octavia" # if your cluster <1.31
  loadbalancer.ovhcloud.com/flavor: "small" # Available values: small (default) | medium | large | xl
  loadbalancer.openstack.org/timeout-client-data: 180000 # The default value (in milliseconds) on the iolb solution, can be customized
  loadbalancer.openstack.org/timeout-member-connect: 20000 # The default value (in milliseconds) on the iolb solution, can be customized
  loadbalancer.openstack.org/timeout-member-data: 180000 # The default value (in milliseconds) on the iolb solution, can be customized

Apply the new service with:

kubectl apply -f your-service-manifest.yaml

This will create a new Public Cloud Load Balancer with a new public IP.

Step 2 - Test Application access

Once the new Load Balancer is created, get the Public IPs of both services:

kubectl get svc -o wide

You should see two Load Balancer services pointing to the same application with different Public IPs.

Test accessibility via both IPs:

curl http://<OLD_LOADBALANCER_IP>
curl http://<NEW_LOADBALANCER_IP>

Both should return a successful response from your application.

Step 3 - Perform a DNS switch

To perform a DNS switch, refer to the How to perform a DNS switch? part of this guide.

Step 4 - Remove the Load Balancer service for Kubernetes (a.k.a. IOLB)

Once you confirm that traffic is flowing through the new Load Balancer and the old one is no longer needed, remove the old Load Balancer service by deleting it:

kubectl delete svc old-loadbalancer-service

Replacement

Replacing an existing Load Balancer for Managed Kubernetes with a Public Cloud Load Balancer involves modifying the existing service and changing the loadbalancer class from iolb to octavia. This will lead to Kubernetes reconciling the loadbalancer class by deleting the old one and creating a new loadbalancer.

Once the new Load Balancer delivered, you can perform a DNS switch using the new public IP.

Step 1 - Edit your Service to change the Load Balancer class to 'octavia'

annotations:
  loadbalancer.ovhcloud.com/class: "octavia" // not required for clusters running kubernetes version 1.31 or later, you can just remove the annotation.

Apply the service update using:

kubectl apply -f your-service-manifest.yaml

Step 2 - Perform a DNS switch

To perform a DNS switch, follow the steps right below.

How to perform a DNS switch?

Check the current TTL

By default, DNS servers cache the IP address of a domain for a period defined by the TTL (Time-To-Live).

A TTL that is too long can slow down the transition by forcing some users to wait several hours before accessing the new Load Balancer. To avoid this, we recommend temporarily reducing the TTL before updating the IP.

Before changing the TTL, it is important to know its current value. To do this, run the following command in a terminal:

dig yourdomain.com +noall +answer

yourdomain.com.             600     IN      A       17*.***.**.*4

Here, 600 corresponds to the TTL in seconds (approximately 10 minutes). This means that the DNS servers keep this IP in cache for this length of time before checking for an update.

Lower the TTL before migration

To lower the TTL, follow these steps:

• Access your DNS management console.
• Find the A record (or CNAME) associated with your domain.
• Change the TTL of your A or CNAME record by reducing it to 300 seconds (5 minutes).
• Wait 24 to 48 hours for this new TTL to propagate.

Update the Load Balancer IP

Once the TTL reduction has been propagated:

• Replace the old IP with the one of the new Load Balancer in your DNS record.
• Thanks to the short TTL value, users will quickly see the update.
• Check that the change is effective using the same dig command used previously. You should see the new IP address displayed in the command output.

Restore TTL after migration

Once the transition has been validated and the old Load Balancer disconnected, reconfigure the TTL with a higher value.

Other resources

• Exposing applications using services of Load Balancer type
• Using Octavia Ingress Controller
• OVHcloud Load Balancer concepts
• How to monitor your Public Cloud Load Balancer with Prometheus

Go further

• Visit the Github examples repository.

Browse all the Managed Kubernetes Service (MKS) guides.

Browse the rest of the OVHcloud US documentation for guides on our other products and services.

Learn more about Managed Kubernetes on the OVHcloud US website.

If you need training or technical assistance to implement our solutions, contact your sales representative or click on this link to get a quote and ask our Professional Services experts for a custom analysis of your project.