Additional networks for LoadBalancerMachines

[dergeberl]

Implemented in PR #80

CC: @einfachnuralex @breuerfelix @SimonKienzler

What?

A LoadBalancerMachine should be in additional networks, so it can loadbalance traffic in more than one network.

Why?

If a Loadbalancer is in two or more networks, you can listen on one network, and the endpoints can be in a different network.
Example:

This will make it possible to use the LoadBalancer also as a "gateway" between two networks.

How?

I think there is no change needed in how to get a FloatingIP/ListenerIP. The only affected controller is the LoadBalancerMachine-Controller. This needs to add the additional networks to the server/instance.

Currently, the Network is defined in the LoadBalancerInfrastructure part of the loadbalancer:

// LoadBalancerInfrastructure defines infrastructure defaults for the LoadBalancer
type LoadBalancerInfrastructure struct {
	// FloatingNetID defines a openstack ID for the floatingNet.
	// +optional
	FloatingNetID *string `json:"floatingNetID,omitempty"`
	// NetworkID defines a openstack ID for the network.
	NetworkID string `json:"networkID"`
	// Flavor defines openstack flavor for the LoadBalancer. Uses a default if not defined.
	// +optional
	Flavor *OpenstackFlavorRef `json:"flavor,omitempty"`
	// Image defines openstack image for the LoadBalancer. Uses a default if not defined.
	// +optional
	Image *OpenstackImageRef `json:"image,omitempty"`
	// AvailabilityZone defines the openstack availability zone for the LoadBalancer.
	// +optional
	AvailabilityZone string `json:"availabilityZone"`
	// AuthSecretRef defines a secretRef for the openstack secret.
	AuthSecretRef corev1.SecretReference `json:"authSecretRef"`
}

I would suggest the following API changes to be able to add additional Networks to the LoadBalancer Machine

// LoadBalancerInfrastructure defines infrastructure defaults for the LoadBalancer
type LoadBalancerInfrastructure struct {
	// DEPRICATED: use listernerNetwork instead
	// FloatingNetID defines a openstack ID for the floatingNet.
	// +optional
	FloatingNetID *string `json:"floatingNetID,omitempty"`
	// DEPRICATED: use listernerNetwork instead
	// NetworkID defines a openstack ID for the network.
	NetworkID string `json:"networkID"`
	// DefaultNetwork defines the default/listener network for the Loadbalancer.
	DefaultNetwork LoadBalancerDefaultNetwork `json:"defaultNetwork"`
	// AdditionalNetworks defines additional networks that will be added to the LoadBalancerMachines.
	// +optional
	AdditionalNetworks []LoadBalancerAdditionalNetworks `json:"additionalNetworks,omitempty"`
	// Flavor defines openstack flavor for the LoadBalancer. Uses a default if not defined.
	// +optional
	Flavor *OpenstackFlavorRef `json:"flavor,omitempty"`
	// Image defines openstack image for the LoadBalancer. Uses a default if not defined.
	// +optional
	Image *OpenstackImageRef `json:"image,omitempty"`
	// AvailabilityZone defines the openstack availability zone for the LoadBalancer.
	// +optional
	AvailabilityZone string `json:"availabilityZone"`
	// AuthSecretRef defines a secretRef for the openstack secret.
	AuthSecretRef corev1.SecretReference `json:"authSecretRef"`
}

// LoadBalancerAdditionalNetworks defines additional networks for the LoadBalancer
type LoadBalancerAdditionalNetworks struct {
	// NetworkID defines a openstack ID for the network.
	NetworkID string `json:"networkID"`
}

// LoadBalancerDefaultNetwork defines the default/listener network for the Loadbalancer
type LoadBalancerDefaultNetwork struct {
	// FloatingNetID defines a openstack ID for the floatingNet.
	// +optional
	FloatingNetID *string `json:"floatingNetID,omitempty"`
	// NetworkID defines a openstack ID for the network.
	NetworkID string `json:"networkID"`
}

Now it would be possible to add additional networks. The movement from the FloatingNetID and NetworkID to DefaultNetwork is not necessary, but I think it makes it much more clear what this configures. I am also not sure if DefaultNetwork is the right name for it, maybe ListenerNetwork would be a better name. What do you think?

Problems

How do deal with an IP Address overlay (If 2 Networks have the same IP-Adress range)

Additional notes

• A annotation for the yawol-cloud-controller is also needed to be able to add this to a Service-Object.

[nightlyone]

How does this interact with security groups related to those networks? Maybe define it as out of scope for this proposal.

What is the relation to endpoints here:

1. Are all endpoints supposed to be in one network?
2. Is a grouping by network desirable?
3. Do you want to support migration of endpoint pool(s) between 2 distinct networks?

[dergeberl]

How does this interact with security groups related to those networks? Maybe define it as out of scope for this proposal.

Currently only SecurityGroups for the listener (ingress) is set, I would not see it in scope of this change.

1. Are all endpoints supposed to be in one network?

I would say no. If you configure 2 Endpoints in different networks, the envoy reach the endpoints with normal routing. The only question is how to make sure that the IPs from the network don't overlap. Check it while creation to return an error or add some order for the additionalNetworks to make clear in which order the routing will be done.

2. Is a grouping by network desirable?

What do you mean with grouping by network?

3. Do you want to support migration of endpoint pool(s) between 2 distinct networks?

See 1.