Overview of load balancing for Google Distributed Cloud

This document explains the load balancing options supported by Google Distributed Cloud.

There are two load balancing options available to you. Choose the option that seems most suited to your environment and your needs. For example, you might choose an option that requires minimal configuration. Or you might choose an option that aligns with the load balancers you already have in your network.

These are the available options:

  • MetalLB bundled

  • Manual load balancing for any third-party load balancer, such as F5 BIG-IP Citrix

MetalLB

The MetalLB load balancer is bundled with Google Distributed Cloud and is especially easy to configure. The MetalLB components run on your cluster nodes, so you don't have to create separate VMs for your load balancer.

You can configure MetalLB to perform IP address management. This means that when a developer creates a Service of type LoadBalancer, they don't have to specify a VIP for the Service. Instead, MetalLB automatically chooses a VIP from an address pool that you provide ahead of time.

For more information, see Bundled load balancing with MetalLB.

Citrix

We document how to set up the Citrix load balancer as an example of setting up a load balancer manually. With any load balancer that you set up manually, you must configure mappings between VIPs, node addresses, and nodePort values. For information, on how to do this for the Citrix load balancer, see Manual load balancing with Citrix.

Manual load balancing in general

You can use any load balancer of your choice as long as you set it up manually. With any load balancer that you set up manually, you must configure mappings between VIPs, node addresses, and nodePort values. For general information on how to do this, see Manual load balancing.

Setting aside virtual IP addresses

Regardless of which load balancer you use, you must set aside several virtual IP addresses (VIPs) that you intend to use for load balancing.

For your admin cluster, you must set aside these VIPs:

  • VIP for Kubernetes API server
  • VIP for add-ons

For each user cluster you intend to create, you must set aside these VIPs:

  • VIP for the Kubernetes API server
  • VIP for the ingress service

For example, suppose you intend to have two user clusters. Then you would need two VIPs for your admin cluster and two VIPs for each of your user clusters. So you would need to set aside six VIPs.

Node IP addresses

If you choose MetalLB as your load balancer, then you can either use static IP addresses for your cluster nodes, or you can have your cluster nodes get their IP addresses from a DHCP server

If you choose a manual load-balancing option, then you must use static IP addresses for your cluster nodes.

If you choose to use static IP addresses, you must set aside enough addresses for the nodes in the admin cluster and the nodes in all the user clusters you intend to create. For details about how many node IP addresses to set aside, see Plan your IP addresses.

Creating Services in your cluster

After your user cluster is running, application developers might want to create Kubernetes Services and expose them to external clients.

For Services of type LoadBalancer, VIPs must be configured on the load balancer. How those VIPs get configured depends on your choice of load balancer.

MetalLB

In the user cluster configuration file, you specify address pools that the MetalLB controller uses to assign VIPs to Services. When a developer creates a Service of type LoadBalancer, the MetalLB controller chooses an address from a pool and assigns the address to the Service. The developer does not have to specify a value for loadBalancerIP in the Service manifest.

Manually configured load balancer

If you have chosen a manual load balancing option, developers can follow these steps to expose a Service to external clients:

  • Create a Service of type NodePort.

  • Choose a VIP for the Service.

  • Manually configure the load balancer so that traffic sent to the VIP is forwarded to the Service.