External Load Balancers
About
Generally, applications running inside a Kubernetes cluster are not available to the outside world. To expose such applications Kubernetes added support for cloud providers to implement external Load Balancers which will be synchronized with the cluster. Our cloud controller manager (CCM) supports these external Load Balancers and you can simply provision an external Load Balancer on our infrastructure by setting the spec.type property of your service configuration to LoadBalancer.
If you are interested in the general configuration of services and external Load Balancers, please read the official Kubernetes documentation found here. A simple TCP Load Balancer configuration might look like this:
For our managed Kubernetes solution you can choose to disable the external Load Balancer by updating the configuration of your cluster. Setting the Load Balancer type to internal will delete all existing Load Balancers and your services will only be available from the network interfaces of your nodes. If you have a public cluster you can still access your services over the Elastic IP attached to your master node.
Custom Annotations
Since Kubernetes only supports the minimum requirements for Load Balancers, we have added custom annotations which you can simply apply to your service YAML. The cloud-controller-manager (CCM) will interpret them and apply them to the final Load Balancer configuration. All of these annotations are optional.
General
load-balancer.flow.swiss/entry-protocol
The name of the protocol which should be used between the client and the load balancer (see Supported Protocols below).
load-balancer.flow.swiss/target-protocol
The name of the protocol which should be used between the load balancer and the nodes (see Supported Protocols below).
load-balancer.flow.swiss/algorithm
The algorithm which should be used to distribute traffic to the individual nodes (see Supported Balancing Algorithms below).
load-balancer.flow.swiss/sticky-session
If this is set to "true" the load balancer will try to always direct a client to the same node using cookies when the protocol is HTTP or Terminated HTTPS or the clients' source IP address for every other protocol.
load-balancer.flow.swiss/tls-certificate
The unique identifier of the TLS certificate which should be served by the load balancer. This option may only be set if the entry protocol is Terminated HTTPS. To set this option, you need to create a certificate on myFlow and use the ID to reference it in Kubernetes.
Networking
load-balancer.flow.swiss/internal
Set this to "true" if you want the load balancer to only be available from inside the network (no external elastic IP will be attached to the load balancer).
load-balancer.flow.swiss/network
The unique identifier of the network in which the load balancer should be spawned. This is required if your nodes have multiple network interfaces or are located in different networks.
load-balancer.flow.swiss/private-ip
A static private IP for the load balancer inside the network. The IP must be available otherwise the deployment will fail.
Health Check
A health check is used by the load balancer to determine whether a node is currently able to handle connections. If a node is marked as unhealthy by the health check it will be excluded from handling connections until the node is healthy again.
load-balancer.flow.swiss/health-check-type
The health check type determines how the load balancer can determine whether a node can currently handle requests (see supported health check types below).
load-balancer.flow.swiss/health-check-path
The HTTP path which should be called. This option may only be set for the HTTP and HTTPS health check types.
load-balancer.flow.swiss/health-check-method
The HTTP method which should be used. This option may only be set for the HTTP and HTTPS health check types.
load-balancer.flow.swiss/health-check-interval
The interval in seconds at which the health check should run. This value must be between 5 and 300 seconds.
load-balancer.flow.swiss/health-check-timeout
The timeout in seconds after which the health check should fail if a node is not responding. This value must be between 5 and 300 seconds.
load-balancer.flow.swiss/health-check-healthy-threshold
The number of successful health checks that are required before a node is considered healthy. This value must be between 1 and 10.
load-balancer.flow.swiss/health-check-unhealthy-threshold
The amount of failed health checks that are required before a node is considered unhealthy. This value must be between 1 and 10.
Supported Protocols
HTTP "http"
HTTPS "https"
Terminated HTTPS "terminated_https"
TCP "tcp"
UDP "udp"
PROXY
A list of supported load balancer protocols can always be found over the API via the https://api.flow.swiss/v4/entities/compute/load-balancer-protocols endpoint.
PROXY Protocol
The target protocol of PROXY will use the entry protocol as the pool protocol but will wrap that protocol in the proxy protocol. In the case of entry protocol TERMINATED_HTTPS, a target protocol of PROXY will be HTTP wrapped in the proxy protocol.
Protocol Combinations
The following protocol combinations are supported:
HTTP
Y
N
Y
Y
N
HTTPS
N
Y
Y
N
N
PROXY
Y
Y
Y
Y
N
TCP
N
Y
Y
N
N
UDP
N
N
N
N
Y
“Y” means the combination is valid and “N” means invalid.
Supported Balancing Algorithms
Round Robin "round_robin"
Least Connections "least_connections"
Source IP "source_ip"
A list of supported load balancer algorithms can always be found over the API via the https://api.flow.swiss/v4/entities/compute/load-balancer-algorithms endpoint.
Supported Health Check Types
Ping "ping"
TCP "tcp"
UDP Connect "upd_connect"
HTTP "http"
HTTPS "https"
A list of supported load balancer health check types can always be found over the API via the https://api.flow.swiss/v4/entities/compute/load-balancer-health-check-types endpoint.
Last updated