Support creating and attaching floating IPs to lb

[chi-quita-a]

What type of PR is this?

• kind feature
• kind admin-change

What this PR does / why we need it:

Background

UpCloud does not support Cluster API, so Kubernetes clusters are provisioned using Terraform for infrastructure creation and Kubespray for cluster bootstrapping.

UpCloud provides CSI support, enabling dynamic volume provisioning via PVCs, but there is no cloud controller manager. Consequently:

• Kubernetes Service type=LoadBalancer cannot be used.
• Load balancers are provisioned directly via Terraform.
• Worker nodes are registered as backends.
• Ingress is exposed via NodePort, fronted by the Terraform-managed load balancer.

Until now, UpCloud load balancers exposed only a stable DNS name. While the DNS name is persistent, it does not provide a stable IP address suitable for firewall whitelisting in customer environments.

Problem

Customers require stable IP addresses to whitelist cluster ingress endpoints.

Solution

UpCloud introduced support for attaching floating IPs directly to load balancers.

This PR:

• Upgrades the UpCloud Terraform provider to a version supporting ip_addresses on upcloud_loadbalancer
• Extends the loadbalancers variable schema with two optional fields:
  • create_floating_ip = optional(bool, false) — lets Terraform create and manage the floating IP automatically
  • ip_addresses = optional(list(object({...})), []) — allows attaching pre-existing floating IPs manually
• When create_floating_ip = true, Terraform creates a upcloud_floating_ip_address resource and wires it into the LB automatically
• When ip_addresses is set, pre-existing floating IPs are attached directly
• Existing configurations without either field remain unaffected

Which issue(s) this PR fixes:

Fixes #

Special notes for your reviewer:

Floating IPs can now be attached to UpCloud Load Balancers in two ways:

Option A — Terraform managed (recommended):

loadbalancers = {
  apiserver = {
    plan               = "development"
    public_network     = true
    private_network    = true
    create_floating_ip = true

    targets = {
      kubernetes_api = {
        proxy_protocol  = false
        port            = 6443
        target_port     = 6443
        listen_public   = true
        listen_private  = true
        backend_servers = ["control-plane-0"]
      }
    }
  }
}

Option B — Pre-existing floating IP:

loadbalancers = {
  apiserver = {
    plan            = "development"
    public_network  = true
    private_network = true
    ip_addresses    = [{ address = "xx.xx.xxx.xx", network_name = "Public-Net" }]

    targets = { ... }
  }
}

• No migration steps are required.
• Existing configurations without either field remain unaffected.

How to test:

1. Set create_floating_ip = true in your cluster.tfvars
2. Run:

terraform init
terraform plan -var-file=cluster.tfvars
terraform apply -var-file=cluster.tfvars

3. Verify the floating IP was created and attached:

terraform state show 'module.kubernetes.upcloud_floating_ip_address.lb_floating_ip["apiserver"]'

4. Verify traffic routes through it:

curl -k https://<floating-ip>:6443

Expected response is a 403 from the Kubernetes API, confirming traffic is successfully routed through the floating IP and load balancer.

References:

• [UpCloud Floating IP Address - Terraform Provider Docs](https://registry.terraform.io/providers/UpCloudLtd/upcloud/latest/docs/resources/floating_ip_address)

Does this PR introduce a user-facing change?:

Yes, admin-facing change, no changes for end-users.

• Admins can optionally set create_floating_ip = true to have Terraform manage the floating IP lifecycle.
• Admins can optionally set ip_addresses to attach pre-existing floating IPs.
• If neither is set, behaviour remains unchanged.

[rarescosma]

Great work ChatG(ehm) Joy, my main concern here is that if the underlying module API allows for multiple IP address attachments, why should we restrict it to one?

[simonklb]

Not super familiar with the UpCloud setup but does the UpCloud Terraform provider support creating the floating IPs as well and if so could we instead automate that too instead of having to create the floating IPs manually and adding them as input configuration?

[rarescosma]

Not super familiar with the UpCloud setup but does the UpCloud Terraform provider support creating the floating IPs as well and if so could we instead automate that too instead of having to create the floating IPs manually and adding them as input configuration?

It's worse than you think: they don't support the creation of unattached IPs at all. So in order to get it you must first create an attached one, then detach it manually from whatever random machine you chose, and then use it..

[Eliastisys]

Not super familiar with the UpCloud setup but does the UpCloud Terraform provider support creating the floating IPs as well and if so could we instead automate that too instead of having to create the floating IPs manually and adding them as input configuration?

It's worse than you think: they don't support the creation of unattached IPs at all. So in order to get it you must first create an attached one, then detach it manually from whatever random machine you chose, and then use it..

This doesn't work?

https://registry.terraform.io/providers/UpCloudLtd/upcloud/latest/docs/resources/floating_ip_address

# Create a detached floating IP address.
resource "upcloud_floating_ip_address" "my_floating_address" {
  zone = "de-fra1"
}

[chi-quita-a]

Not super familiar with the UpCloud setup but does the UpCloud Terraform provider support creating the floating IPs as well and if so could we instead automate that too instead of having to create the floating IPs manually and adding them as input configuration?

It's worse than you think: they don't support the creation of unattached IPs at all. So in order to get it you must first create an attached one, then detach it manually from whatever random machine you chose, and then use it..

This doesn't work?

https://registry.terraform.io/providers/UpCloudLtd/upcloud/latest/docs/resources/floating_ip_address

# Create a detached floating IP address.
resource "upcloud_floating_ip_address" "my_floating_address" {
  zone = "de-fra1"
}

I've looked at that as well. But from my understanding, Terraform provider does support creating detached floating IPs, but the example you shared attaches them to a server NIC via mac_address. For lb, attachment is done through the upcloud_loadbalancer.ip_addresses block instead. Correct me if I have misunderstood?

[chi-quita-a]

Great work ChatG(ehm) Joy, my main concern here is that if the underlying module API allows for multiple IP address attachments, why should we restrict it to one?

Yeah, can't argue about the restriction. Sure, if the provider happily supports multiple ip_addresses, there’s no need for us to pretend we live in a single-IP universe.

[Xartos]

I've looked at that as well. But from my understanding, Terraform provider does support creating detached floating IPs, but the example you shared attaches them to a server NIC via mac_address. For lb, attachment is done through the upcloud_loadbalancer.ip_addresses block instead. Correct me if I have misunderstood?

I think it's the one at the bottom of the snippet that's attached to the server. But the one on the top is detached (based on the comment it looks like they at least attempted to support creating detached IPs)

[simonklb]

This still does not create the floating IPs and from the looks of the discussions in the thread and the provider documentation it should be possible. If not please explain why!

[rarescosma]

Great work ChatG(ehm) Joy, my main concern here is that if the underlying module API allows for multiple IP address attachments, why should we restrict it to one?

Yeah, can't argue about the restriction. Sure, if the provider happily supports multiple ip_addresses, there’s no need for us to pretend we live in a single-IP universe.

Down with IP monogamy!

[rarescosma]

Not super familiar with the UpCloud setup but does the UpCloud Terraform provider support creating the floating IPs as well and if so could we instead automate that too instead of having to create the floating IPs manually and adding them as input configuration?

It's worse than you think: they don't support the creation of unattached IPs at all. So in order to get it you must first create an attached one, then detach it manually from whatever random machine you chose, and then use it..

This doesn't work?
https://registry.terraform.io/providers/UpCloudLtd/upcloud/latest/docs/resources/floating_ip_address

# Create a detached floating IP address.
resource "upcloud_floating_ip_address" "my_floating_address" {
  zone = "de-fra1"
}

I've looked at that as well. But from my understanding, Terraform provider does support creating detached floating IPs, but the example you shared attaches them to a server NIC via mac_address. For lb, attachment is done through the upcloud_loadbalancer.ip_addresses block instead. Correct me if I have misunderstood?

I'm fine with restricting the scope and making the assumption we have a detached IP address on hand (or multiple).

[chi-quita-a]

Testing: Verified that traffic reaches the Kubernetes API through the floating IP via the load balancer:
curl -k https://80.69.175.91:6443

{
  "kind": "Status",
  "apiVersion": "v1",
  "status": "Failure",
  "message": "forbidden: User \"system:anonymous\" cannot get path \"/\"",
  "reason": "Forbidden",
  "code": 403
}

The 403 response confirms the request successfully reached the Kubernetes API server through the floating IP and load balancer.

Rejected because no authentication credentials were provided

[chi-quita-a]

Not super familiar with the UpCloud setup but does the UpCloud Terraform provider support creating the floating IPs as well and if so could we instead automate that too instead of having to create the floating IPs manually and adding them as input configuration?

It's worse than you think: they don't support the creation of unattached IPs at all. So in order to get it you must first create an attached one, then detach it manually from whatever random machine you chose, and then use it..

This doesn't work?
https://registry.terraform.io/providers/UpCloudLtd/upcloud/latest/docs/resources/floating_ip_address

# Create a detached floating IP address.
resource "upcloud_floating_ip_address" "my_floating_address" {
  zone = "de-fra1"
}

I've looked at that as well. But from my understanding, Terraform provider does support creating detached floating IPs, but the example you shared attaches them to a server NIC via mac_address. For lb, attachment is done through the upcloud_loadbalancer.ip_addresses block instead. Correct me if I have misunderstood?

I'm fine with restricting the scope and making the assumption we have a detached IP address on hand (or multiple).

So, we shouldn't extend the scope to also handle creating floating IPs via Terraform using upcloud_floating_ip_address?

[simonklb]

Not super familiar with the UpCloud setup but does the UpCloud Terraform provider support creating the floating IPs as well and if so could we instead automate that too instead of having to create the floating IPs manually and adding them as input configuration?

It's worse than you think: they don't support the creation of unattached IPs at all. So in order to get it you must first create an attached one, then detach it manually from whatever random machine you chose, and then use it..

This doesn't work?
https://registry.terraform.io/providers/UpCloudLtd/upcloud/latest/docs/resources/floating_ip_address

# Create a detached floating IP address.
resource "upcloud_floating_ip_address" "my_floating_address" {
  zone = "de-fra1"
}

I've looked at that as well. But from my understanding, Terraform provider does support creating detached floating IPs, but the example you shared attaches them to a server NIC via mac_address. For lb, attachment is done through the upcloud_loadbalancer.ip_addresses block instead. Correct me if I have misunderstood?

I'm fine with restricting the scope and making the assumption we have a detached IP address on hand (or multiple).

So, we shouldn't extend the scope to also handle creating floating IPs via Terraform using upcloud_floating_ip_address?

I'm withholding my approval until I know the answer to this. I don't really understand why we shouldn't also manage the floating IPs using Terraform when it's such a small change for a big win. No strong opinion though.

[chi-quita-a]

Not super familiar with the UpCloud setup but does the UpCloud Terraform provider support creating the floating IPs as well and if so could we instead automate that too instead of having to create the floating IPs manually and adding them as input configuration?

It's worse than you think: they don't support the creation of unattached IPs at all. So in order to get it you must first create an attached one, then detach it manually from whatever random machine you chose, and then use it..

This doesn't work?
https://registry.terraform.io/providers/UpCloudLtd/upcloud/latest/docs/resources/floating_ip_address

# Create a detached floating IP address.
resource "upcloud_floating_ip_address" "my_floating_address" {
  zone = "de-fra1"
}

I've looked at that as well. But from my understanding, Terraform provider does support creating detached floating IPs, but the example you shared attaches them to a server NIC via mac_address. For lb, attachment is done through the upcloud_loadbalancer.ip_addresses block instead. Correct me if I have misunderstood?

I'm fine with restricting the scope and making the assumption we have a detached IP address on hand (or multiple).

So, we shouldn't extend the scope to also handle creating floating IPs via Terraform using upcloud_floating_ip_address?

I'm withholding my approval until I know the answer to this. I don't really understand why we shouldn't also manage the floating IPs using Terraform when it's such a small change for a big win. No strong opinion though.

I think that would be an optimal improvement. So, do you reckon that we should keep ip_addresses but make Terraform create them if not provided or add a boolean create_floating_ip = true/false and let Terraform create and attach it automatically, or possibly some other suggestions on the most straight forward approach?

[simonklb]

Not super familiar with the UpCloud setup but does the UpCloud Terraform provider support creating the floating IPs as well and if so could we instead automate that too instead of having to create the floating IPs manually and adding them as input configuration?

It's worse than you think: they don't support the creation of unattached IPs at all. So in order to get it you must first create an attached one, then detach it manually from whatever random machine you chose, and then use it..

This doesn't work?
https://registry.terraform.io/providers/UpCloudLtd/upcloud/latest/docs/resources/floating_ip_address

# Create a detached floating IP address.
resource "upcloud_floating_ip_address" "my_floating_address" {
  zone = "de-fra1"
}

I've looked at that as well. But from my understanding, Terraform provider does support creating detached floating IPs, but the example you shared attaches them to a server NIC via mac_address. For lb, attachment is done through the upcloud_loadbalancer.ip_addresses block instead. Correct me if I have misunderstood?

I'm fine with restricting the scope and making the assumption we have a detached IP address on hand (or multiple).

So, we shouldn't extend the scope to also handle creating floating IPs via Terraform using upcloud_floating_ip_address?

I'm withholding my approval until I know the answer to this. I don't really understand why we shouldn't also manage the floating IPs using Terraform when it's such a small change for a big win. No strong opinion though.

I think that would be an optimal improvement. So, do you reckon that we should keep ip_addresses but make Terraform create them if not provided or add a boolean create_floating_ip = true/false and let Terraform create and attach it automatically, or possibly some other suggestions on the most straight forward approach?

A boolean sounds good to me but I'm letting the final decision go to @elastisys/goto-upcloud and/or @elastisys/goto-kubespray !

[chi-quita-a]

I think that would be an optimal improvement. So, do you reckon that we should keep ip_addresses but make Terraform create them if not provided or add a boolean create_floating_ip = true/false and let Terraform create and attach it automatically, or possibly some other suggestions on the most straight forward approach?

A boolean sounds good to me but I'm letting the final decision go to @elastisys/goto-upcloud and/or @elastisys/goto-kubespray !

Exactly my thought. I actually played around with this before I PR:d on to master (wrong base) and caused multiple commit issues. I have now reapplied that resource. Have a look and give me your take on it.