At Datacake, we provide our customers with the option to white-label their IoT platform. To do this, they set their DNS to point to a Load Balancer on our Kubernetes cluster, which is running on Digital Ocean.
In an ideal world, all customers would use a CNAME on a subdomain or an ALIAS on a top-level domain. In the real world, not all domain providers support the introduced-in-2011 ALIAS record type, so most customers with a top-level domain resort to using a classic A-record.
Recently, we upgraded our Kubernetes to a new cluster (for various reasons we couldn’t use the old one anymore). Unfortunately, Load Balancers on Digital Ocean still don’t support floating IPs in 2021 and so we somehow had to move the existing Load Balancer to prevent our customers from having to update their DNS. Turns out, according to their support, there’s no way to do this. Spoiler: there is.
While going through the resource definition of the old service, I noticed an annotation called kubernetes.digitalocean.com/load-balancer-id. The value of this annotation looked a lot like a UUID and, as it turned out, it’s exactly what it says it is: It’s the ID of the Load Balancer object on Digital Ocean.
So I spun up a test Load Balancer, copied its ID, created a new K8S service of type LoadBalancer with an annotation containing the ID and voilà, the Load Balancer quickly became populated with our nodes. To prevent the old K8S from interfering with the new K8S, I first created another LB, changed the annotation on the old service to this new ID, and created a service on the new K8S containing the ID of the old Load Balancer. After that, I went ahead and deleted the old service which also removed the temporary Load Balancer.
Mission accomplished.
Tl;Dr: You can create a Kubernetes service of type LoadBalancer with an annotation called
kubernetes.digitalocean.com/load-balancer-id, which will tell the system to use an existing Digital Ocean Load Balancer instead of creating a new one.
Top comments (0)