-
Notifications
You must be signed in to change notification settings - Fork 261
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add the ability to specify a configurable VIP network for loadbalancer #1809
Comments
similarly to this feature request this is possible in OCCM https://github.com/kubernetes/cloud-provider-openstack/blob/fdba36babb2c4b46e759c99cca50ac7eba2ee06f/pkg/openstack/openstack.go#L103 via configuration:
|
To be clear, you want the control plane machines to have 2 attached interfaces:
You want the API servers to listen on the LB VIP network. You want kubelet to listen on the control plane network. Or do you mean that the control plane machines should only be connected to the control plane network and the LB on the VIP network should add the port on the control plane network, which is a different network, as a member? Does that work? |
Basically the VMs only need 1 interface as they are routable across the whole DC. The VIP network is only a subnet within the routable network.
No, they only need to be attached on the Control plane network
yes
yes, because both networks are routable within the DC (we have a flat L3 network) |
the VIP network (in our case) is not meant to be used as VM interface, but is announced by our L4 balancer (standalone Cilium L4LB) and is BGP routable just like control plane network |
@mdbooth any chance you would accept support for this? If we agree on an implementation I can start right away. |
I think the API impact will be adding a @dulek What are your thoughts on this? |
This looks sane with two modifications I'd suggest:
|
Good idea! I think only subnets needs to be a list though as from the docs:
|
Oh good, it's purely for dual stack, so this simplifies it a lot. |
great thanks, will start with the implementation then |
btw regarding:
This is not yet possible as is it ok to do 1x networkID and 1x subnetID for now? |
We can work to add the required stuff to gophercloud, a single field should be a fairly simple addition and we should be able to get @EmilienM help with merging it. Nevertheless if you'd like to pursue the simpler case first, I'd still insist that API should have the subnet field as an array even if documented that secondary values are ignored. |
yeah, totally agree |
Previously when loadbalacer was created it used the same network/subnet as the control plane nodes for the VIP. This was not always the right assumption as some users might want to be able to customize this according to their env. This commit fixes the above by adding two fields into OpenStackClusterSpec/Status two fields `network` and `subnets` under `APIServerLoadBalancer` so that user can define which network/subnet to use for allocation of the loadbalancer. Fixes: kubernetes-sigs#1809 Signed-off-by: Ondrej Blazek <[email protected]>
Previously when loadbalacer was created it used the same network/subnet as the control plane nodes for the VIP. This was not always the right assumption as some users might want to be able to customize this according to their env. This commit fixes the above by adding two fields into OpenStackClusterSpec/Status two fields `network` and `subnets` under `APIServerLoadBalancer` so that user can define which network/subnet to use for allocation of the loadbalancer. Fixes: kubernetes-sigs#1809 Signed-off-by: Ondrej Blazek <[email protected]>
Previously when loadbalacer was created it used the same network/subnet as the control plane nodes for the VIP. This was not always the right assumption as some users might want to be able to customize this according to their env. This commit fixes the above by adding two fields into OpenStackClusterSpec/Status two fields `network` and `subnets` under `APIServerLoadBalancer` so that user can define which network/subnet to use for allocation of the loadbalancer. Fixes: kubernetes-sigs#1809 Signed-off-by: Ondrej Blazek <[email protected]>
/kind feature
Describe the solution you'd like
Based on an API documentation of openstack/octavia it should be possible to specify a VIP network for the loadbalancer:
which is possible in the openstack API
and used in CAPO here, but is strictly filled by this ->
openStackCluster.Status.Network.Subnets[0].ID
.Unfortunately this is expecting that loadbalancer is supposed to be created on the same network/subnet as the VM itself which is not always the correct assumption. In our case we have a separate network for the loadbalancer from which the VIP should be allocated and a separate network for the control plane and worker nodes (VMs).
This is a setup with octavia and our own specific cloud provider, so there are no amphoras nor floating IPs (the openstack is using calico as network driver).
So either
OpenStackCluster
and/orOpenStackMachineTemplate
should have the possibility to specify which network/subnet ID should be used just for the VIP/loadbalancer separately fromOpenStackMachineSpec.network
orOpenStackMachineSpec.subnet
. E.g. something like, but not strictly in this way:Anything else you would like to add:
Partly similar issue is: #1558 and related thread https://kubernetes.slack.com/archives/CFKJB65G9/p1702562005631379
cc @mdbooth
The text was updated successfully, but these errors were encountered: