Load balancer target groups

Target group management is configured in Kubernetes's LoadBalancer type Service resource. Based on the service configuration, the Managed Service for Kubernetes controller automatically creates a Network Load Balancer that routes traffic to the cluster nodes.

By default, load balancers use a shared target group that includes all the cluster nodes. The load balancer checks all the cluster nodes for availability, even if the pods of the application it send traffic to are deployed only on some of them.

To reduce the number of nodes to check, you can configure the v2 target group management mode for your service with externalTrafficPolicy: Local. The controller will create for the network load balancer a separate target group with nodes hosting the application pods and will update it as needed. You can set the mode when creating a new service or configure it for an already existing one.

To enable the v2 mode for a new or existing network load balancer, follow the steps in Configuring the management mode for network load balancer target groups.

Management mode and policy combinationsManagement mode and policy combinations

The target group composition depends on the combination of the management mode and traffic policy.

Consider the following:

• You can only reduce the target group size when the Local policy is on.
• If the service pods are distributed across all nodes, enabling the Local policy may not scale down the target group.
• A separate group is created for each service that uses the Local policy. Check the Network Load Balancer quotas and limits for groups and targets.
• The v2 mode does not increase Managed Service for Kubernetes quotas, address space, or master resources.
• If there is no annotation or the value is invalid, the legacy mode is used.

Updating a target groupUpdating a target group

In v2 mode with the Local policy, the controller uses EndpointSlice objects to discover nodes hosting the application pods. If a pod of your application appears on a new node, the controller adds the node to the group. When a node no longer hosts any pods, the controller removes it from the group.

Health checks of target group nodes are handled by Network Load Balancer. Just because a node belongs to a group does not mean it is actually healthy. The controller decides which nodes to include in the group, while health checks confirm availability of individual nodes.

EndpointSlice changes, cloud resource updates, and health checks are performed asynchronously. The group composition may not immediately reflect the new pod placement.

Do not manually edit the composition of groups managed by the controller. To switch modes, use the Service object annotation.

Use casesUse cases

Let’s assume there is a hundred node cluster where an application runs three pods across three nodes. In legacy mode, the load balancer's target group includes all hundred nodes, but only the three ones hosting the application pods pass the health checks. In v2 mode, the load balancer's target group contains three nodes.

This mode is useful for large clusters running multiple applications, where each app only sits on a small handful of nodes. When you add new nodes for other applications, this app’s target group will not scale until its pods appear on the new nodes.

Useful linksUseful links

• Configuring the management mode for network load balancer target groups
• Granting access to an application running in a Kubernetes cluster
• Fields and annotations of the Service resource