Load balancing
In this article:
Load balancing#
General information#
The Load balancing service automatically distributes inbound traffic across a target group of instances in one or more availability zones.This helps to distribute the request processing more evenly among virtual machines and improve availability and reliability of supported applications.
The resources included in the target group are regularly polled to check their health. If any instance fails, no traffic is routed to it. When a failed instance recovers, it starts receiving traffic again. You can always add new instances to, or exclude unnecessary ones from, the target group to maintain the current load level.
There are special entities, listeners, for receiving inbound traffic during load balancing. The listener receives requests from clients at the specified IP address, port, and protocol.
K2 Cloud supports network load balancers (NLB) and application load balancers (ALB). The former operate on OSI Layer 4 and distribute TCP and UDP traffic, while the latter operate on OSI Layer 7 and distribute HTTP and HTTPS traffic.
Depending on the traffic source, load balancers are divided into:
internet-facing load balancers;
internal load balancers.
The former have public (external) IP addresses and are accessible from the Internet. The latter have private (internal) IP addresses and are accessible only within the VPC where they were created. Both types of balancers use internal IP addresses to forward traffic to target resources.
Key concepts#
Load balancer offers as a single point of entry for client traffic, which is evenly distributed among the targets. It can receive traffic at multiple addresses/ports.
Network Load Balancer operates on OSI Layer 4 and distributes TCP and UDP traffic.
Application load balancer works on OSI Layer 7 and distributes HTTP and HTTPS traffic.
Internet-facing balancer distributes traffic from clients in the Internet. Elastic IP addresses are assigned to the network interfaces of the balancer.
Internal network balancer distributes traffic only from clients in the same VPC. Network interfaces of the balancer can only have internal IP addresses.
Listener monitors requests from clients at a given IP address, port and protocol and forwards them to the target group for further processing. For each listener, only one target group can be specified in the default action; however, different listeners of the same balancer can be associated with different target groups.
Target group aggregates target resources, i.e. instances among which traffic is distributed. A target group can only be associated with one load balancer but used by multiple traffic listeners of this load balancer.
Balancer instance is created along with a dedicated network interface on each subnet that was specified when the balancer is created. One balancer instance can be created in each availability zone. A network load balancer instance, unlike an application load balancer instance, can only distribute traffic among target resources in the same availability zone.
Before you begin#
To be able to work with ** Load balancing** service, a user needs to have ELBFullAccess project grants. For instance, such grants are available to administrators in ELBAdministrators and CloudAdministrators groups. If necessary, you can create a separate user, add the user to the project, and either attac the ELBFullAccess policy to the user or add the user to one of the groups of administrators in this project.
In addition, the project should have the following resources:
Note
Security groups must include the required permitting rules so that the targets can receive traffic from the load balancer.
Using DNS with load balancers#
User traffic is routed to the load balancer using its DNS name. A domain name is generated for each balancer when it is created.
Attention
The examples below show DNS records for network load balancers. For application load balancers, change nlb
to alb
.
The DNS name of an internet-facing load balancer looks as follows: <name>-<nlb-id>.nlb.k2.cloud
, while that of an internal load balancer looks as follows: <name>-<nlb-id>.nlb.<vpc-id>.internal
.
Note
The domain name of an internal load balancer is resolved only by a DNS server inside the respective VPC.
Traffic forwarding#
If a user domain (for example, service1.example.com) needs to be forwarded to a load balancer, then create a DNS resource record of the CNAME type in the example.com zone and specify the DNS name of the balancer, for example:
private-service.example.com. IN CNAME service1.lb-12345678.nlb.k2.cloud.
public-service.example.com. IN CNAME service2.lb-90abcdef.nlb.vpc-12345678.internal.
DNS records for a specific availability zone#
If a balancer has its instances in multiple availability zones and its traffic needs to be forwarded to an instance in a specific availability zone, then zonal DNS records can be used. Such a record is created when a subnet is added for the balancer. Thus, for example, for an internet-facing load balancer with subnets in two availability zones, az1 and az2, the DNS names will be as follows:
az1.service1.nlb-12345678.nlb.k2.cloud. IN A 192.0.2.1
az2.service1.nlb-12345678.nlb.k2.cloud. IN A 192.0.2.2
For comparison, global DNS records look like this:
service1.nlb-12345678.nlb.k2.cloud. IN A 192.0.2.1
service1.nlb-12345678.nlb.k2.cloud.ru. IN A 192.0.2.2
DNS records for availability zones always return one and the same IP address, regardless of the state of the targets.
If all targets in an availability zone are unavailable, then traffic forwarded to the corresponding balancer instance according to the DNS record will not be handled until at least one target returns to the OK
state.
Load balancer quotas#
The following load balancer quotas are established:
up to 50 load balancers of each type per project;
up to 50 listeners per load balancer;
up to 500 target groups per project;
up to 100 targets per target group;
up to 20 certificates per load balancer (in addition to the default ones).
If necessary, you can increase quotas. To do this, contact the support service.