[Yandex Cloud documentation](../../index.md) > [Yandex Managed Service for Kubernetes](../index.md) > [Concepts](index.md) > Load balancer target groups

# Load balancer target groups

Target group management is configured in [Kubernetes](service.md#type)'s `LoadBalancer` type `Service` resource. Based on the service configuration, the Managed Service for Kubernetes controller automatically creates a [Network Load Balancer](../../network-load-balancer/concepts/index.md) 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](load-balancer-target-groups.md) 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.

{% note warning %}

The `v2` mode is available in the `RAPID` [release channel](release-channels-and-updates.md) and must first be enabled on the Yandex Cloud side. To have it enabled, contact [support](../../support/overview.md) and provide the [cloud ID](../../resource-manager/operations/cloud/get-id.md) and [cluster ID](../operations/kubernetes-cluster/kubernetes-cluster-list.md#list) info.

Once it is enabled, configure the `v2` mode as detailed in [this guide](../operations/configure-load-balancer-target-groups.md).

{% endnote %}

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](../operations/configure-load-balancer-target-groups.md).

## Management mode and policy combinations {#management-modes}

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

#|
|| **Management mode** | **Traffic policy** | **Target group composition** ||
|| `legacy` | `Local` or `Cluster` | Shared group with all cluster nodes ||
|| `v2` | `Local` | Dedicated group with the nodes hosting the application’s pods ||
|| `v2` | `Cluster` | Shared group with all cluster nodes ||
|#

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](../../network-load-balancer/concepts/limits.md) for groups and targets.
* The `v2` mode does not increase [Managed Service for Kubernetes quotas](limits.md), address space, or master resources.
* If there is no annotation or the value is invalid, the `legacy` mode is used.

## Updating a target group {#target-group-updates}

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](../../network-load-balancer/concepts/health-check.md) 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 cases {#examples}

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 links {#see-also}

* [Configuring the management mode for network load balancer target groups](../operations/configure-load-balancer-target-groups.md)
* [Granting access to an application running in a Kubernetes cluster](../operations/create-load-balancer.md)
* [Fields and annotations of the Service resource](../nlb-ref/service.md)