Create a load balancer

If you are creating a load balancer to work with a Managed Kubernetes cluster, use the Configure a load balancer in a Managed Kubernetes cluster for Ingress or Create and configure a load balancer in a Managed Kubernetes cluster for Envoy Gateway instruction. For the load balancer to function correctly in the cluster, all operations with the load balancer must be performed using kubectl.

Control panel

1. Select the configuration and network.
2. Create a target group.
3. Create rules and HTTP policies.

1. Select a configuration and network

warning

The load balancer subnet must always have a free IP address for automatically recreating load balancer ports in case of issues — one for a non-redundant load balancer, two for a redundant one. If there is no free IP address, the load balancer will transition to the ERROR.
If the load balancer and servers are to be placed in the same subnet, its size must be at least /28.

1. In the control panel, from the top menu, click Products and select Cloud Servers.

2. Go to the Load Balancers section → Load Balancers tab.

3. Click Create load balancer.

4. Select the location where the load balancer will be created.

5. Select a configuration based on the project load.

6. Enter a load balancer name.

7. Optional: enter a comment — any additional information about the load balancer, which will be displayed only in the Control panel.

8. Optional: to access the load balancer logs, enable logging. Logging uses some of the load balancer's computing resources.

   8.1. Select the Collect technical load balancer logs checkbox.

   8.2. Select a log group or create a new group.

   8.3. If you selected a new group, enter its name.

9. Select a subnet:

   • private subnet — we recommend this option. Traffic balancing will only occur within the subnet. You can attach a public floating IP address to a private address — the load balancer will be accessible from the internet via NAT; ;
   • public subnet — the load balancer will be accessible from the internet and will be able to proxy requests from the public subnet to cloud servers in the private subnet.

10. Specify an IP address in the subnet — a free address that will be assigned to the load balancer.

11. Optional: if you selected a private subnet in step 9, attach a public floating IP address. If there is no free IP address, create a public floating IP address. The private subnet where you are creating the load balancer must be prepared for attaching a public floating IP address.

12. Click Next.

2. Create a target group

1. Open the Servers tab.

2. Optional: to change the name of the target group, click , enter the name, and click .

3. Select the traffic destination protocol that the load balancer will use to forward traffic to the target group. The following protocol combinations for receiving traffic on the load balancer and forwarding traffic to the target group are available:

   • TCP–TCP — classic L4 load balancing;
   • TCP–PROXY — client information is not lost and is transmitted in a separate connection header;
   • UDP–UDP — the UDP protocol is faster than TCP but less reliable;
   • HTTP–HTTP — L7 load balancing;
   • HTTPS–HTTP — L7 load balancing with encryption and SSL certificate termination on the load balancer.

4. For the selected protocol, the standard port will be selected automatically — change it if necessary. The port value will be common to all servers in the group.

5. Select the servers to be added to the target group.

6. Specify settings for each selected server:

   6.1. Select an IP address.

   6.2. Optional: modify the port.

   6.3. Specify the server weight — this is a proportional measure indicating the share of requests that the server processes. If the weight values are equal, the servers handle an equal number of requests. For example, if there is one server with a weight of "2" and two servers with a weight of "1" in a group, the first server will receive 50% of all requests, and the other two will receive 25% each. The maximum weight value is 256.

   6.4. Optional: to direct traffic to a server only when other servers in the group are unavailable, select the Backup checkbox.

7. Open the Algorithm tab.

8. Select the request distribution algorithm — Round Robin or Least connections.

9. Optional: to enable the Sticky Sessions method, select the Sticky sessions checkbox and choose a session identifier. For the APP-cookie identifier, enter the cookie name.

10. Open the Availability Checks tab.

11. Select the availability check type. You cannot change the check type after creating the group.

12. If the HTTP check type is selected, specify the request parameters — method, path, and expected response codes.

13. Specify the check interval — the interval in seconds at which the load balancer sends check requests to the servers.

14. Specify the connection timeout — the maximum wait time for a response in seconds, which must be less than the interval between checks.

15. Specify the success threshold — the number of consecutive successful requests after which a server is moved to the working state.

16. Specify the failure threshold — the number of consecutive unsuccessful requests after which server operation is suspended.

17. Optional: to add another target group, click Add target group and configure it.

18. Click Next.

3. Create rules and HTTP policies

1. Select the protocol for receiving traffic on the load balancer — TCP, UDP, HTTP, or HTTPS. The Prometheus option is also available for configuring load balancer monitoring.

TCP or UDP traffic

2. For the selected protocol, the standard port on which the load balancer will listen for traffic will be selected automatically — change it if necessary.

3. Optional: enter allowed CIDRs — the IP addresses from which the load balancer will accept traffic using the selected protocol and port. You can enter a subnet in CIDR format or a single IP address with a /32 mask. If you leave the field empty, the load balancer will accept traffic from any IP address. You can specify allowed IP addresses in the rule after creating the load balancer.

   If the field is missing, traffic filtering (port security) is disabled in the load balancer network.

4. Select a target group. Available groups are those to which traffic can be balanced using the selected protocol for incoming traffic.

5. Optional: expand the Advanced rule settings block and specify the connection settings:

   • for incoming requests to the load balancer — specify the connection timeout and maximum connections;
   • for requests from the load balancer to servers — specify the connection timeout, inactivity timeout, and TCP packet wait timeout.

6. Optional: to add another rule, click Add rule and repeat steps 1-5. There is no limit on the number of rules.

7. Check the final cost of the load balancer.

8. Click Create load balancer.

HTTP or HTTPS traffic

2. For the selected protocol, the standard port on which the load balancer will listen for traffic will be selected automatically — change it if necessary.

3. If you selected the HTTPS protocol, choose a certificate for terminating HTTPS traffic on the load balancer — select a certificate from the secret manager or upload a new one. Learn more in the Load balancer TLS(SSL) certificates instruction.

4. Optional: to restrict access to the load balancer, enter allowed CIDRs — IP addresses from which the load balancer will accept traffic using the selected protocol and port. You can enter a subnet in CIDR format or a single IP address with a /32 mask. If you leave the field empty, the load balancer will accept traffic from any IP address. You can specify allowed IP addresses in the rule after creating the load balancer.

   If the field is missing, traffic filtering (port security) is disabled in the load balancer network.

5. Optional: select the HTTP request headers to be forwarded to servers.

6. Select a default target group — this is where traffic that does not match any HTTP policy will be directed.

7. Create HTTP policies.

8. Optional: change the connection settings: open the Advanced rule settings block and specify:

   • for incoming requests to the load balancer — specify the connection timeout and maximum connections;
   • for requests from the load balancer to servers — specify the connection timeout, inactivity timeout, and TCP packet wait timeout.

9. Optional: to add another rule, click Add rule and repeat steps 1-8. There is no limit on the number of rules.

10. Check the final cost of the load balancer.

11. Click Create load balancer.

OpenStack CLI

1. Create a load balancer.
2. Create a rule, an HTTP policy, and a target group.

Create a load balancer

warning

The load balancer subnet must always have a free IP address for automatically recreating load balancer ports in case of issues — one for a non-redundant load balancer, two for a redundant one. If there is no free IP address, the load balancer will transition to the ERROR.
If the load balancer and servers are to be placed in the same subnet, its size must be at least /28.

1. Open OpenStack CLI.

2. Install the Octavia component for working with cloud load balancers — for compatibility with the Yoga release, version 3.4.0 is required:

   pip3 install python-octaviaclient===3.4.0

3. Create a load balancer:

   openstack loadbalancer create \
     --vip-subnet-id <subnet_uuid> \
     --vip-address <loadbalancer_ip_address> \
     --flavor <flavor> \
     --name <loadbalancer_name>

   Specify:

   • <subnet_uuid> — the ID of a private or public subnet; you can view it using the openstack subnet list;
   • <loadbalancer_ip_address> — the IP address allocated for the load balancer, which must be one of the free addresses in the subnet; ;
   • <flavor> — the flavor ID or name. Flavors correspond to load balancer types and determine the number of vCPUs, RAM, and load balancer instances. For example, ac18763b-1fc5-457d-9fa7-b0d339ffb336 is the ID for creating an Advanced redundant load balancer in the ru-9 pool. A list of flavors can be viewed using the openstack loadbalancer flavor list -c id -c name command or in the List of load balancer flavors in all pools table;
   • <loadbalancer_name> — the load balancer name.

4. Check that the load balancer is in the operating states ONLINE (the operating_status parameter in the command output) and ACTIVE (provisioning_status):

   openstack loadbalancer show <loadbalancer>

   Specify <loadbalancer> — the load balancer ID or name; you can view the list using the openstack loadbalancer list.

5. Optional: if you specified a private subnet in step 3, attach a public floating IP address to the load balancer:

   openstack floating ip set --port <loadbalancer_port_uuid> <floating_ip>

   Specify:

   • <loadbalancer_port_uuid> — the load balancer port ID; you can view it using the openstack loadbalancer show <loadbalancer> command, specifically the vip_port_id value;
   • <floating_ip> — the public IP address.

Create a rule, an HTTP policy, and a target group

For TCP or UDP traffic

1. Create a rule:

   openstack loadbalancer listener create \
     --name <listener_name> \
     --protocol <protocol> \
     --protocol-port <port> \
     [--allowed-cidr <allowed_cidr>] \
     <loadbalancer>

   Specify:

   • <listener_name> — the rule name;
   • <protocol> — the name of the protocol: TCP or UDP; ;
   • <port> — the port number on the load balancer;
   • optional: --allowed-cidr <allowed_cidr> — an IP address from which traffic is allowed, where <allowed_cidr> is a subnet in CIDR format or a single IP address with a /32 mask. If you need to specify multiple addresses, use a separate --allowed-cidr parameter for each. For this restriction to work, traffic filtering (port security) must be enabled in the load balancer network. You can specify allowed IP addresses in the rule after creating the load balancer;
   • <loadbalancer> — the load balancer ID or name; you can view the list using the openstack loadbalancer list.

2. Create a target group:

   openstack loadbalancer pool create \
     --name <pool_name> \
     --lb-algorithm <algorithm> \
     --listener <listener_name> \
     --protocol <protocol>

   Specify:

   • <pool_name> — the target group name;
   • <algorithm> — the name of the algorithm: ROUND_ROBIN or LEAST_CONNECTIONS; ;
   • <listener_name> — the name of the rule you created in step 1;
   • <protocol> — the name of the protocol: TCP, UDP, PROXY.

3. Add a server to the target group:

   openstack loadbalancer member create \
     --subnet-id <subnet_uuid> \
     --address <server_ip_address> \
     --protocol-port <port> \
     <pool_name>

   Specify:

   • <subnet_uuid> — the ID of the server's private or public subnet; you can view it using the openstack subnet list;
   • <server_ip_address> — the server IP address from the specified subnet;
   • <port> — the port number on the server;
   • <pool_name> — the name of the target group you created in step 2.

4. Optional: create an availability check for the target group:

   openstack loadbalancer healthmonitor create \
     --delay <delay> \
     --timeout <timeout> \
     --max-retries <max_retries> \
     --max-retries-down <max_retries_down> \
     --type <type> \
     --http-method <http_method> \
     --url-path <url_path> \
     --expected-codes <codes> \
     <pool_name>

   Specify:

   • <delay> — the interval between checks in seconds;

   • <timeout> — the maximum response wait time in seconds;

   • <max_retries> — the number of successful attempts in a row after which the server is set to operational status;

   • <max_retries_down> — the number of unsuccessful attempts in a row after which the server is suspended;

   • <type> — the check type. Available types depend on the target group protocol you specified in step 2:

     • for the TCP protocol — PING, TCP; ;
     • for the UDP protocol — UDP_CONNECT, PING; ;
     • for the PROXY protocol — TLS_HELLO, HTTP, PING, TCP; ;

   • HTTP request parameters, if you selected the HTTP check type:

     • --http-method <http_method> — the check method: GET, POST, DELETE, PUT, HEAD, OPTIONS, PATCH, CONNECT, TRACE; ;
     • --url-path <url_path> — the request path without the domain name;
     • --expected-codes <codes> — the expected response codes separated by commas;
     • <pool_name> — the name of the target group you created in step 2.

For HTTP or HTTPS traffic

1. Create a target group that will serve as the default group — traffic that did not match any HTTP policies in the rule will be directed there:

   openstack loadbalancer pool create \
     --name <pool_name> \
     --lb-algorithm <algorithm> \
     --protocol HTTP \
     --loadbalancer <loadbalancer>

   Specify:

   • <pool_name> — the target group name;
   • <algorithm> — the name of the algorithm: ROUND_ROBIN or LEAST_CONNECTIONS; ;
   • <loadbalancer> — the ID or name of the load balancer you created earlier; you can view the list using the openstack loadbalancer list.

2. Add a server to the target group:

   openstack loadbalancer member create \
     --subnet-id <subnet_uuid> \
     --address <server_ip_address> \
     --protocol-port <port> \
     <pool_name>

   Specify:

   • <subnet_uuid> — the ID of the server's private or public subnet; you can view it using the openstack subnet list;
   • <server_ip_address> — the server IP address from the specified subnet;
   • <port> — the port number on the server;
   • <pool_name> — the name of the target group you created in step 1.

3. Optional: create an availability check for the target group:

   openstack loadbalancer healthmonitor create \
     --delay <delay> \
     --timeout <timeout> \
     --max-retries <max_retries> \
     --max-retries-down <max_retries_down> \
     --type <type> \
     --http-method <http_method> \
     --url-path <url_path> \
     --expected-codes <codes> \
     <pool_name>

   Specify:

   • <delay> — the interval between checks in seconds;

   • <timeout> — the maximum response wait time in seconds;

   • <max_retries> — the number of successful attempts in a row after which the server is set to operational status;

   • <max_retries_down> — the number of unsuccessful attempts in a row after which the server is suspended;

   • <type> — the check type: HTTP, PING, TCP; ;

   • HTTP request parameters, if you selected the HTTP check type:

     • --http-method <http_method> — the check method: GET, POST, DELETE, PUT, HEAD, OPTIONS, PATCH, CONNECT, TRACE; ;
     • --url-path <url_path> — the request path without the domain name;
     • --expected-codes <codes> — the expected response codes separated by commas;
     • <pool_name> — the name of the target group you created in step 1.

4. Create a rule:

   openstack loadbalancer listener create \
     --name <listener_name> \
     --protocol <protocol> \
     --protocol-port <port> \
     [--allowed-cidr <allowed_cidr>]
     --default-tls-container=<certificate_uuid> \
     --default-pool <default_pool> \
     <loadbalancer>

   Specify:

   • <listener_name> — the rule name;
   • <protocol> — the name of the protocol: HTTP or TERMINATED_HTTPS; ;
   • <port> — the port number on the load balancer;
   • --default-tls-container=<certificate_uuid> — the ID of a TLS(SSL) certificate for terminating HTTPS traffic on the load balancer. Specify if you selected the TERMINATED_HTTPS protocol. You can copy it in the control panel: from the top menu, click Products → Certificate Manager → in the certificate menu, select Copy UUID. Learn more about load balancer TLS(SSL) certificates;
   • <default_pool> — the ID or name of the default target group you created in step 1; you can view the list using the openstack loadbalancer pool list;
   • optional: --allowed-cidr <allowed_cidr> — an IP address from which traffic is allowed, where <allowed_cidr> is a subnet in CIDR format or a single IP address with a /32 mask. If you need to specify multiple addresses, use a separate --allowed-cidr parameter for each. For this restriction to work, traffic filtering (port security) must be enabled in the load balancer network. You can specify allowed IP addresses in the rule after creating the load balancer.

5. Create an HTTP policy in the rule:

   openstack loadbalancer l7policy create \
     --action <action> \
     [--redirect-url <url> | --redirect-prefix <prefix_url> | --redirect-pool <pool> ]
     --position <position> \
     --name <policy_name> \
     <listener>

   Specify:

   • <action> — the action for traffic balancing:

     • REDIRECT_TO_URL — completely replace the request URL, including the protocol, domain name, path, and parameters;
     • REDIRECT_PREFIX — replace the protocol and domain name in the request URL;
     • REDIRECT_TO_POOL — redirect to a target group;
     • REJECT — reject;

   • where to direct traffic:

     • --redirect-url <url> — the full URL for redirection. Specify if the REDIRECT_TO_URL action is selected;
     • --redirect-prefix <prefix_url> — the URL prefix with which to replace the protocol and domain in the request, for example, https://example.com. Specify if the REDIRECT_PREFIX action is selected;
     • --redirect-pool <pool> — the ID or name of a target group. Specify if the REDIRECT_TO_POOL action is selected. You can view the list using the openstack loadbalancer pool list command. If you do not have a target group yet, create one;

   • --position <position> — the policy position in the rule. Specify if the rule will have multiple policies with the same action; the policy with position 1 will be applied first;

   • <policy_name> — the L7 policy name;

   • <listener> — the ID or name of the rule you created in step 4. You can view the list using the openstack loadbalancer listener list.

6. Create a condition in the HTTP policy:

   openstack loadbalancer l7rule create \
     --compare-type <compare_type> \
     --type <type> \
     --value <value> \
     <policy>

   Specify:

   • <compare_type> — the matching type for the reference value:

     • EQUAL TO — matches;
     • STARTS WITH — starts with;
     • ENDS WITH — ends with;
     • CONTAINS — contains;
     • REGEX — regular expression;

   • <type> — the request parameter to check: HOST_NAME, PATH, COOKIE, FILE_TYPE, HEADER; ;

   • <value> — reference value;

   • <policy> — the ID or name of the L7 policy you created in step 5.

Terraform

Use the instructions in the Terraform documentation:

• Create a cloud load balancer;
• Example of building infrastructure with a cloud load balancer.