Kubernetes defines a Service resource with type
LoadBalancer, that you can use to create a managed load balancer in SysEleven Stack. To create a Kubernetes managed load balancer, use a manifest like the following:
kind: Service apiVersion: v1 metadata: name: $LOADBALANCER_NAME spec: selector: $APPLICATION_LABEL: $APPLICATION_NAME ports: - protocol: TCP port: 80 name: http - protocol: TCP port: 443 name: https type: LoadBalancer
$ kubectl get svc NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE loadbalancer LoadBalancer 10.10.10.202 220.127.116.11 80:31228/TCP,443:30279/TCP 11s
This load balancer now exposes port
80 to the outside world and maps it to port
31228 on all cluster nodes, and it exposes port
443 to the outside world and maps it to ports
30279 on all cluster nodes. This means that a loadbalancer service is also a
NodePort service (i.e. a service that exposes pods on specific "NodePorts" on all nodes).
When a service of type
LoadBalancer is created without further configuration it gets an ephemeral IP address from the OpenStack network pool of the cluster (usually
ext-net). When the load balancer is deleted the floating IP is also released. So, when a new service is created it could get the same IP but in most cases it just gets another random IP. When working with Kubernetes it can be desirable to have a more fine grained control of the used IP addresses.
This has been tested with Kubernetes 1.17 and 1.18. Please keep that in mind if you run an older version (and consider upgrading). The openstack external cloud controller is also required for this to work. You can check this requirement by running the following command in your cluster:
kubectl get csidrivers.storage.k8s.io NAME ATTACHREQUIRED PODINFOONMOUNT MODES AGE cinder.csi.openstack.org true false Persistent 96d
In the output you should see the cinder csi driver.
Two options in the LoadBalancer resource come into play: The annotation
kind: Service apiVersion: v1 metadata: name: ... annotations: loadbalancer.openstack.org/keep-floatingip: "true" spec: loadBalancerIP: "xxx.xxx.xxx.xxx" ...
loadBalancerIPcomes with a few remarks:
Among others this makes a few interesting scenarios possible:
If you need even more control of your used IP addresses you can also rent a dedicated IP space from us or bring your own IP space, please contact us if you are interested.
With the solution above you may create a workflow to migrate an existing floating IP from one loadbalancer to another (e.g. when switching the type of ingress controller or other migration cases). This only works if the floating IP stays in the same OpenStack project.
The example below configures the service to use a custom floating ip network. You will need to add the floating ip network id you have to the service.
By default the standard metakube floating ip network will be used and no further configuration is required.
kind: Service apiVersion: v1 metadata: name: ... annotations: loadbalancer.openstack.org/floating-network-id: "*****" spec: ...