Flow Documentation
Company PagePlatform Status
  • Overview
  • Platform
    • Release Notes
    • Pricing
      • Compute
      • Kubernetes
      • App Engine
      • Object Storage
      • Mac Bare Metal
      • CI Engine
      • DevOps Services
      • Volumes & Snapshots
      • Load Balancers
      • Elastic IPs
      • VPN & Peering
      • Licenses
      • Support
      • Billing FAQ
    • Account
      • Sign Up
      • Closing account
    • Cashback Program
    • Support
      • Case severity and initial response times
    • Service Level Agreement (SLA)
    • Security & Compliance
      • Log4j Vulnerability
    • Regions
      • ALP1
      • ALP2
      • ZRH1
  • Products
    • Compute
      • Instances
        • How-to
          • Connect to instances
          • Destroy Instances
      • Volumes
      • Keypairs
      • ▫️Networking
        • Private Networks
        • Routers
        • Security Groups
        • Elastic IPs
        • Load Balancers
          • Balancing Pools
        • Certificates
        • VPN & Peering
    • Kubernetes
      • Clusters
      • Resources
        • Volumes Features (CSI)
        • External Load Balancers
        • Cluster Autoscaler
        • Traefik upgrade and tests
        • Update custom resource definitions (CRDs) for VolumeSnapshots
    • Object Storage
      • Instances
      • How-to
        • Access Storage with AWS S3 SDKs
        • Access Storage with Cyberduck
        • Access Storage with Mountainduck
      • Ressources
        • Supported Amazon S3 features
        • Replication Management
          • GET service replication
          • PUT service replication
          • DELETE service replication
    • App Engine
      • Accounts
    • Mac Bare Metal
      • Devices
      • How-to
        • Connect via Remote Desktop
        • Connect via SSH
        • Change Display Resolution
        • Connect local USB devices
      • Resources
        • Deprovisioning
    • CI Engine
      • Subscriptions
      • How-to
        • Setup GitHub Actions Integration
        • Setup Buildkite Integration
        • Customise Image
        • Enable Debug Mode
        • Change Image of Integration
      • Resources
        • Runners & Concurrency
        • Vanilla Images
          • macOS 15.2 - Vanilla
        • Golden Images
          • macOS 15.2 - Golden
        • Custom Images
  • Developer Center
    • Overview
    • API
      • Product Entities
      • Location Entities
    • CLI
    • Terraform
Powered by GitBook
On this page
  • About
  • Custom Annotations
  • General
  • Networking
  • Health Check
  • Supported Protocols
  • PROXY Protocol
  • Protocol Combinations
  • Supported Balancing Algorithms
  • Supported Health Check Types
  1. Products
  2. Kubernetes
  3. Resources

External Load Balancers

PreviousVolumes Features (CSI)NextCluster Autoscaler

Last updated 1 year ago

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 . A simple TCP Load Balancer configuration might look like this:

apiVersion: v1
kind: Service
metadata:
  name: some-application
spec:
  type: LoadBalancer
  selector:
    app: some-application
  ports:
    - protocol: TCP
      port: 80

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.

// example of a Terminated HTTPS Load Balancer
apiVersion: v1
kind: Service
metadata:
  name: some-application
  annotations:
    load-balancer.flow.swiss/entry-protocol: "terminated_https"
    load-balancer.flow.swiss/target-protocol: "http"
    load-balancer.flow.swiss/tls-certificate: "1234"
    load-balancer.flow.swiss/health-check-type: "http"
    load-balancer.flow.swiss/health-check-method: "GET"
    load-balancer.flow.swiss/health-check-path: "/health"
spec:
  type: LoadBalancer
  selector:
    app: some-application
  ports:
- port: 80

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

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:

Entry Protocol
HTTP
HTTPS
TCP
TERMINATED_HTTPS
UDP

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"

Supported Health Check Types

  • Ping "ping"

  • TCP "tcp"

  • UDP Connect "upd_connect"

  • HTTP "http"

  • HTTPS "https"

A list of supported load balancer protocols can always be found over the API via the endpoint.

A list of supported load balancer algorithms can always be found over the API via the endpoint.

A list of supported load balancer health check types can always be found over the API via the endpoint.

here
https://api.flow.swiss/v4/entities/compute/load-balancer-protocols
https://api.flow.swiss/v4/entities/compute/load-balancer-algorithms
https://api.flow.swiss/v4/entities/compute/load-balancer-health-check-types