Create a load balancer

If you are creating a load balancer to work with a Managed Kubernetes cluster, use the Configure a load balancer instruction in the Managed Kubernetes section. For the load balancer to work correctly in the cluster, all operations with the load balancer must be performed via kubectl.

Control panel

1. Select a 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 automatic recreation of load balancer ports in case of failures — one for a load balancer without redundancy, two for a load balancer with redundancy. If there is no free IP address, the load balancer will enter the ERROR status.
If the balancer and servers are to be hosted in the same subnet, its size must be at least /28.

1. In the Control panel, click Products in the top menu 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 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 be performed only within the subnet. You can connect a public IP address to the 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, connect a public IP address. If there is no available public IP address, create a new IP address. The private subnet where you are creating the load balancer must be prepared for connecting a public 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 a 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 route traffic to a server only if other servers in the group are unavailable, select the Backup checkbox.

7. Open the Algorithm tab.

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

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

10. Open the Availability Checks tab.

11. Select the type of availability check. 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 traffic received by 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 with 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 all IP addresses. You can specify allowed IP addresses in the rule after creating the load balancer.

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

4. Select a target group. You can use groups to which traffic can be balanced for the selected protocol of incoming traffic.

5. Optional: expand the Advanced Rule Settings block and specify 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 to 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, select a certificate for HTTPS termination on the load balancer — choose a certificate from the Secrets Manager or upload a new one. Learn more in the Load balancer TLS(SSL) certificates instruction.

4. Optional: to limit access to the load balancer, enter allowed CIDRs — the IP addresses from which the load balancer will accept traffic with 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 all IP addresses. You can specify allowed IP addresses in the rule after creating the load balancer.

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

5. Optional: select the HTTP request headers that will be passed to the servers.

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

7. Create HTTP policies.

8. Optional: change the connection settings; to do this, 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 to 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 automatic recreation of 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 enter the ERROR status.
If the load balancer and servers are 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> — ID of the private or public subnet. You can view it using the openstack subnet list command;
   • <loadbalancer_ip_address> — an IP address allocated to the load balancer, which must be one of the free addresses in the subnet;
   • <flavor> — 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. You can view the list of flavors 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 status ONLINE (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 command.

5. Optional: if you specified a private subnet in step 3, connect a public 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, which can be viewed using the openstack loadbalancer show <loadbalancer> command (value of vip_port_id;
   • <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 load balancer port number;
   • Optional: --allowed-cidr <allowed_cidr> — the 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, provide each in a separate --allowed-cidr parameter. For the restriction to work, traffic filtering (port security) must be enabled on 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 server's private or public subnet ID. You can view it using the openstack subnet list;
   • <server_ip_address> — the server's IP address from the specified subnet;
   • <port> — the server port number;
   • <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 consecutive successful requests after which the server is set to the working state;

   • <max_retries_down> — the number of consecutive failed requests after which the server operation is suspended;

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

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

   • 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> — 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 not matched by HTTP policies in the rule will be routed 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 server's private or public subnet ID. You can view it using the openstack subnet list;
   • <server_ip_address> — the server's IP address from the specified subnet;
   • <port> — the server port number;
   • <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 consecutive successful requests after which the server is set to the working state;

   • <max_retries_down> — the number of consecutive failed requests after which the server operation is suspended;

   • <type> — the check type: HTTP, PING, or 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> — 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 load balancer port number;
   • --default-tls-container=<certificate_uuid> — ID of the TLS(SSL) certificate for HTTPS termination on the load balancer. Specify this if you chose the TERMINATED_HTTPS protocol. You can copy it in the control panel: in the top menu, click Products → Certificate Manager → in the menu of the certificate, select Copy UUID. Read more about load balancer TLS(SSL) certificates;
   • <default_pool> — ID or name of the default target group you created in step 1. You can view the list using the openstack loadbalancer pool list command;
   • Optional: --allowed-cidr <allowed_cidr> — the 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, provide each in a separate --allowed-cidr parameter. For the restriction to work, traffic filtering (port security) must be enabled on 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> — traffic balancing action:

     • REDIRECT_TO_URL — replace the entire 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 — route to a target group;
     • REJECT — reject;

   • where to direct traffic:

     • --redirect-url <url> — the full URL for redirection. Specify this if you chose the REDIRECT_TO_URL;
     • --redirect-prefix <prefix_url> — the URL prefix to replace the protocol and domain in the request, for example, https://example.com. Specify this if you chose the REDIRECT_PREFIX;
     • --redirect-pool <pool> — ID or name of the target group. Specify this if you chose the REDIRECT_TO_POOL action. 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> — policy position in the rule. Specify this if the rule contains multiple policies with the same action; the policy with position 1 will be applied first;

   • <policy_name> — the L7 policy name;

   • <listener> — 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> — comparison type for the control value:

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

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

   • <value> — control value;

   • <policy> — 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.