--- title: "Create a load balancer" sidebar_label: "Create a load balancer" sidebar_position: 3 description: "How to create a cloud load balancer" toc_max_heading_level: 2 --- import Tabs from '@theme/Tabs' import TabItem from '@theme/TabItem' import {TabItemLabel} from '@selectel/docux/components' import EditIcon from '@selectel/docux/icons/edit' import CheckIcon from '@selectel/docux/icons/check' import MoreVerticalIcon from '@selectel/docux/icons/more-vertical' import Formbricks from '@theme/MDXComponents/Formbricks' # 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](/managed-kubernetes/networks/loadbalancing-with-ingress/load-balancers.mdx) or [Create and configure a load balancer in a Managed Kubernetes cluster for Envoy Gateway](/managed-kubernetes/networks/loadbalancing-with-envoy-gateway/load-balancers-for-envoy-gateway.mdx) instruction. For the load balancer to function correctly in the cluster, all operations with the load balancer must be performed using [kubectl](/managed-kubernetes/clusters/connect-to-cluster.mdx). Control panel 1. [Select the configuration and network](#choose-configuration-and-network). 2. [Create a target group](#create-target-group). 3. [Create rules and HTTP policies](#create-rules-and-http-politics). ### 1. Select a configuration and network \{#choose-configuration-and-network} :::warning The load balancer subnet must always have a free IP address for automatically recreating [load balancer ports](/cloud-servers/load-balancers/about-load-balancers/#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](https://my.selectel.ru/vpc/default/lbaas/load-balancers/), 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](/infrastructure/locations.mdx) where the load balancer will be created. 5. Select a [configuration](/cloud-servers/load-balancers/about-load-balancers.mdx#balancer-types) 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](/cloud-servers/load-balancers/manage/logs.mdx), 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](/cloud-servers/cloud-networks/public-floating-ip-addresses.mdx) 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](/cloud-servers/cloud-networks/public-floating-ip-addresses.mdx#create-public-floating-ip). The private subnet where you are creating the load balancer must be [prepared for attaching a public floating IP address](/cloud-servers/cloud-networks/public-floating-ip-addresses.mdx#configure-subnet-for-internet-access). 12. Click **Next**. ### 2. Create a target group \{#create-target-group} 1. Open the **Servers** tab. 2. Optional: to change the name of the [target group](/cloud-servers/load-balancers/about-load-balancers.mdx#target-groups), 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](/cloud-servers/load-balancers/about-load-balancers.mdx#request-distribution-algorithms) — Round Robin or Least connections. 9. Optional: to enable the [Sticky Sessions](/cloud-servers/load-balancers/about-load-balancers.mdx#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](/cloud-servers/load-balancers/about-load-balancers.mdx#availability-checks) 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 \{#create-rules-and-http-politics} 1. Select the [protocol](/cloud-servers/load-balancers/about-load-balancers.mdx#protocols) for receiving traffic on the load balancer — TCP, UDP, HTTP, or HTTPS. The Prometheus option is also available for configuring [load balancer monitoring](/cloud-servers/load-balancers/manage/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](/cloud-servers/load-balancers/manage/limit-access-to-balancer.mdx#specify-allowed-cidrs-in-rule) after creating the load balancer. If the field is missing, [traffic filtering (port security](/cloud-servers/cloud-networks/about-networks.mdx#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](/cloud-servers/load-balancers/about-load-balancers.mdx#protocols) for incoming traffic. 5. Optional: expand the **Advanced rule settings** block and specify the [connection settings](/cloud-servers/load-balancers/about-load-balancers.mdx#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](/cloud-servers/load-balancers/manage/ssl-certificates.mdx) 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](/cloud-servers/load-balancers/manage/limit-access-to-balancer.mdx#specify-allowed-cidrs-in-rule) after creating the load balancer. If the field is missing, [traffic filtering (port security](/cloud-servers/cloud-networks/about-networks.mdx#traffic-filtering-port-security)) is disabled in the load balancer network. 5. Optional: select the [HTTP request headers](/cloud-servers/load-balancers/about-load-balancers.mdx#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](/cloud-servers/load-balancers/about-load-balancers.mdx#http-policies) will be directed. 7. Create [HTTP policies](/cloud-servers/load-balancers/about-load-balancers.mdx#http-policies). 8. Optional: change the [connection settings](/cloud-servers/load-balancers/about-load-balancers.mdx#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](#create-load-balancer). 2. [Create a rule, an HTTP policy, and a target group](#create-rule-policy-and-target-group). ### Create a load balancer \{#create-load-balancer} :::warning The load balancer subnet must always have a free IP address for automatically recreating [load balancer ports](/cloud-servers/load-balancers/about-load-balancers/#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](/cloud-servers/tools/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: ```bash pip3 install python-octaviaclient===3.4.0 ``` 3. Create a load balancer: ```bash openstack loadbalancer create \ --vip-subnet-id \ --vip-address \ --flavor \ --name ``` Specify: * `` — the ID of a private or public subnet; you can view it using the `openstack subnet list`; * `` — the IP address allocated for the load balancer, which must be one of the free addresses in the subnet; ; * `` — the flavor ID or name. Flavors correspond to [load balancer types](/cloud-servers/load-balancers/about-load-balancers.mdx#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](/cloud-servers/load-balancers/about-load-balancers.mdx#balancer-flavors-full-list) table; * `` — the load balancer name. 4. Check that the load balancer is in the [operating states](/cloud-servers/load-balancers/manage/balancer-statuses.mdx) `ONLINE` (the `operating_status` parameter in the command output) and `ACTIVE` (`provisioning_status`): ```bash openstack loadbalancer show ``` Specify `` — 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: ```bash openstack floating ip set --port ``` Specify: * `` — the load balancer port ID; you can view it using the `openstack loadbalancer show ` command, specifically the `vip_port_id` value; * `` — the public IP address. ### Create a rule, an HTTP policy, and a target group \{#create-rule-policy-and-target-group} For TCP or UDP traffic 1. Create a [rule](/cloud-servers/load-balancers/about-load-balancers.mdx#rules): ```bash openstack loadbalancer listener create \ --name \ --protocol \ --protocol-port \ [--allowed-cidr ] \ ``` Specify: * `` — the rule name; * `` — the name of the [protocol](/cloud-servers/load-balancers/about-load-balancers.mdx#protocols): `TCP` or `UDP; `; * `` — the port number on the load balancer; * optional: `--allowed-cidr ` — an IP address from which traffic is allowed, where `` 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](/cloud-servers/cloud-networks/about-networks.mdx#traffic-filtering-port-security)) must be enabled in the load balancer network. You can [specify allowed IP addresses in the rule](/cloud-servers/load-balancers/manage/limit-access-to-balancer.mdx#specify-allowed-cidrs-in-rule) after creating the load balancer; * `` — the load balancer ID or name; you can view the list using the `openstack loadbalancer list`. 2. Create a [target group](/cloud-servers/load-balancers/about-load-balancers.mdx#target-groups): ```bash openstack loadbalancer pool create \ --name \ --lb-algorithm \ --listener \ --protocol ``` Specify: * `` — the target group name; * `` — the name of the [algorithm](/cloud-servers/load-balancers/about-load-balancers.mdx#request-distribution-algorithms): `ROUND_ROBIN` or `LEAST_CONNECTIONS; `; * `` — the name of the rule you created in step 1; * `` — the name of the [protocol](/cloud-servers/load-balancers/about-load-balancers.mdx#protocols): `TCP`, `UDP`, `PROXY`. 3. Add a server to the target group: ```bash openstack loadbalancer member create \ --subnet-id \ --address \ --protocol-port \ ``` Specify: * `` — the ID of the server's private or public subnet; you can view it using the `openstack subnet list`; * `` — the server IP address from the specified subnet; * `` — the port number on the server; * `` — the name of the target group you created in step 2. 4. Optional: create an [availability check](/cloud-servers/load-balancers/about-load-balancers.mdx#availability-checks) for the target group: ```bash openstack loadbalancer healthmonitor create \ --delay \ --timeout \ --max-retries \ --max-retries-down \ --type \ --http-method \ --url-path \ --expected-codes \ ``` Specify: * `` — the interval between checks in seconds; * `` — the maximum response wait time in seconds; * `` — the number of successful attempts in a row after which the server is set to operational status; * `` — the number of unsuccessful attempts in a row after which the server is suspended; * `` — 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 ` — the check method: `GET`, `POST`, `DELETE`, `PUT`, `HEAD`, `OPTIONS`, `PATCH`, `CONNECT`, `TRACE; `; * `--url-path ` — the request path without the domain name; * `--expected-codes ` — the expected response codes separated by commas; * `` — the name of the target group you created in step 2. For HTTP or HTTPS traffic 1. Create a [target group](/cloud-servers/load-balancers/about-load-balancers.mdx#target-groups) that will serve as the default group — traffic that did not match any [HTTP policies](/cloud-servers/load-balancers/about-load-balancers.mdx#http-policies) in the rule will be directed there: ```bash openstack loadbalancer pool create \ --name \ --lb-algorithm \ --protocol HTTP \ --loadbalancer ``` Specify: * `` — the target group name; * `` — the name of the [algorithm](/cloud-servers/load-balancers/about-load-balancers.mdx#request-distribution-algorithms): `ROUND_ROBIN` or `LEAST_CONNECTIONS; `; * `` — the ID or name of the load balancer you [created earlier](#create-load-balancer); you can view the list using the `openstack loadbalancer list`. 2. Add a server to the target group: ```bash openstack loadbalancer member create \ --subnet-id \ --address \ --protocol-port \ ``` Specify: * `` — the ID of the server's private or public subnet; you can view it using the `openstack subnet list`; * `` — the server IP address from the specified subnet; * `` — the port number on the server; * `` — the name of the target group you created in step 1. 3. Optional: create an [availability check](/cloud-servers/load-balancers/about-load-balancers.mdx#availability-checks) for the target group: ```bash openstack loadbalancer healthmonitor create \ --delay \ --timeout \ --max-retries \ --max-retries-down \ --type \ --http-method \ --url-path \ --expected-codes \ ``` Specify: * `` — the interval between checks in seconds; * `` — the maximum response wait time in seconds; * `` — the number of successful attempts in a row after which the server is set to operational status; * `` — the number of unsuccessful attempts in a row after which the server is suspended; * `` — the check type: `HTTP`, `PING`, `TCP; `; * HTTP request parameters, if you selected the `HTTP` check type: * `--http-method ` — the check method: `GET`, `POST`, `DELETE`, `PUT`, `HEAD`, `OPTIONS`, `PATCH`, `CONNECT`, `TRACE; `; * `--url-path ` — the request path without the domain name; * `--expected-codes ` — the expected response codes separated by commas; * `` — the name of the target group you created in step 1. 4. Create a [rule](/cloud-servers/load-balancers/about-load-balancers.mdx#rules): ```bash openstack loadbalancer listener create \ --name \ --protocol \ --protocol-port \ [--allowed-cidr ] --default-tls-container= \ --default-pool \ ``` Specify: * `` — the rule name; * `` — the name of the [protocol](/cloud-servers/load-balancers/about-load-balancers.mdx#protocols): `HTTP` or `TERMINATED_HTTPS; `; * `` — the port number on the load balancer; * `--default-tls-container=` — 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](https://my.selectel.ru/certificates/): from the top menu, click **Products** → **Certificate Manager** → in the certificate menu, select **Copy UUID**. Learn more about [load balancer TLS(SSL) certificates](/cloud-servers/load-balancers/manage/ssl-certificates.mdx); * `` — 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 ` — an IP address from which traffic is allowed, where `` 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](/cloud-servers/cloud-networks/about-networks.mdx#traffic-filtering-port-security)) must be enabled in the load balancer network. You can [specify allowed IP addresses in the rule](/cloud-servers/load-balancers/manage/limit-access-to-balancer.mdx#specify-allowed-cidrs-in-rule) after creating the load balancer. 5. Create an [HTTP policy](/cloud-servers/load-balancers/about-load-balancers.mdx#http-policies) in the rule: ```bash openstack loadbalancer l7policy create \ --action \ [--redirect-url | --redirect-prefix | --redirect-pool ] --position \ --name \ ``` Specify: * `` — 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 ` — the full URL for redirection. Specify if the `REDIRECT_TO_URL` action is selected; * `--redirect-prefix ` — 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 ` — 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](/cloud-servers/load-balancers/target-groups/create-target-group.mdx); * `--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; * `` — the L7 policy name; * `` — 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: ```bash openstack loadbalancer l7rule create \ --compare-type \ --type \ --value \ ``` Specify: * `` — the matching type for the reference value: * `EQUAL TO` — matches; * `STARTS WITH` — starts with; * `ENDS WITH` — ends with; * `CONTAINS` — contains; * `REGEX` — regular expression; * `` — the request parameter to check: `HOST_NAME`, `PATH`, `COOKIE`, `FILE_TYPE`, `HEADER; `; * `` — reference value; * `` — 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](/terraform/examples/cloud-load-balancers/create-load-balancer/); * [Example of building infrastructure with a cloud load balancer](/terraform/examples/cloud-load-balancers/create-load-balancer-and-server/).