Migrating services from an external NLB to an L7 ALB with the target resource (internal NLB)
Yandex Network Load Balancer can distribute traffic across your load balancer pods deployed in a Yandex Managed Service for Kubernetes cluster. If Yandex Application Load Balancer does not support your load balancer configuration, you can add an internal network load balancer for distributing traffic to your load balancer pods and connect the internal network load balancer as a target resource for the Application Load Balancer L7 load balancer with a Yandex Smart Web Security security profile.
In this tutorial, we describe the scenario where you create an internal network load balancer to distribute traffic across the NGINX Ingress controller pods deployed in a Managed Service for Kubernetes cluster and specify the internal network load balancer’s IP address in the L7 load balancer target group.
To migrate a service from an external network load balancer to an L7 load balancer:
- See recommendations for service migration.
- Complete the prerequisite steps.
- Create a Smart Web Security profile.
- Create an internal network load balancer for the NGINX Ingress controller.
- Create an L7 load balancer. At this step, you will connect your Smart Web Security profile to a virtual host of the L7 load balancer.
- Migrate user load from the external network load balancer to the L7 load balancer.
Service migration recommendations
-
In addition to DDoS protection at level L7 of the OSI model using Yandex Smart Web Security, we recommend enabling DDoS protection at L3-L4. To do this, reserve a public static IP address with DDoS protection in advance and use this address for the L7 load balancer's listener.
If the network load balancer's listener already uses a public IP address with DDoS protection, you can save it and use it for the L7 load balancer.
If the network load balancer's listener uses a public IP address without DDoS protection, the only way to enable L7 load balancer DDoS protection at level L3-L4 is to change the public IP address for your service.
When using L3-L4 DDoS protection, configure a trigger threshold for the L3-L4 protection mechanisms aligned with the amount of legitimate traffic to the protected resource. To set up this threshold, contact support
.Also, set the MTU value to
1450
for the target resources downstream of the load balancer. For more information, see Setting up MTU when enabling DDoS protection. -
We recommend performing migration during the hours when user load is at its lowest. If you plan to keep your public IP address, bear in mind that migration involves moving this IP address from the load balancer to the L7 load balancer. Your service will be unavailable during this period. Under normal conditions, this may last for several minutes.
-
When using an L7 load balancer, requests to backends come with the source IP address from the range of internal IP addresses of the subnets specified when creating the L7 load balancer. The original IP address of the request source (user) is specified in the
X-Forwarded-For
header. If you want to log public IP addresses of users on the web server, reconfigure it. -
See the autoscaling and resource units in the L7 load balancer.
Getting started
-
Create subnets in three availability zones. These will be used for the L7 load balancer.
-
Create security groups that allow the L7 load balancer to receive incoming traffic and send it to the target resources, and allow the target resources to receive incoming traffic from the load balancer.
-
When using HTTPS, add your service's TLS certificate to Yandex Certificate Manager.
-
Reserve a static public IP address with DDoS protection at level L3-L4 for the L7 load balancer. See service migration recommendations.
Create a Smart Web Security security profile
Create a Smart Web Security security profile by selecting From a preset template.
Use these settings when creating the profile:
- In the Action for the default base rule field, select
Allow
. - For the Smart Protection rule, enable Only logging (dry run).
These settings are limited to logging the info about the traffic without applying any actions to it. This will reduce the risk of disconnecting users due to profile configuration issues. As you move along, you will be able to turn Only logging (dry run) off and configure some prohibiting rules for your use case in the security profile.
Create an internal network load balancer for the NGINX Ingress controller
-
Create an internal network load balancer for the NGINX Ingress controller. Select the option consistent with the method you originally used to deploy your NGINX Ingress controller.
Using a Helm chartUsing a manifest-
Add the configuration parameters for the internal network load balancer to the
values.yaml
file you used to initially configure the NGINX Ingress controller. Leave the other parameters in the file unchanged.controller: service: external: enabled: true internal: enabled: true annotations: yandex.cloud/load-balancer-type: internal yandex.cloud/subnet-id: <subnet_ID_for_internal_network_load_balancer_IP_address> loadBalancerIP: <IP_address_of_internal_network_load_balancer_listener> externalTrafficPolicy: Local
-
Use this command to apply the NGINX Ingress controller configuration changes:
helm upgrade <NGINX_Ingress_controller_name> -f values.yaml <chart_for_NGINX_Ingress_controller> -n <namespace>
-
Create a YAML file and describe the
Service
resource in it:apiVersion: v1 kind: Service metadata: name: <resource_name> namespace: <namespace> annotations: yandex.cloud/load-balancer-type: internal yandex.cloud/subnet-id: <subnet_ID_for_internal_network_load_balancer_IP_address> spec: type: LoadBalancer externalTrafficPolicy: Local loadBalancerIP: <IP_address_of_internal_network_load_balancer_listener> ports: - port: <HTTP_port_number_e.g._80> targetPort: <HTTP_port_number_of_NGINX_Ingress_controller_pod_e.g._80> protocol: TCP name: http - port: <HTTPS_port_number_e.g._443> targetPort: <HTTPS_port_number_of_NGINX_Ingress_controller_pod_e.g._443> protocol: TCP name: https selector: <NGINX_Ingress_controller_pod_selectors>
-
Apply changes using this command:
kubectl apply -f <Service_resource_file>
-
-
Wait until the internal network load balancer is created and a matching
Service
object appears. You can use this command to view information about the services:kubectl get service
Create an L7 load balancer
-
Create a target group for the L7 load balancer. Under Targets, select Outside VPC and specify an internal IP address for the internal network load balancer. Click Add target resource and then Create.
-
Create a group of backends with the following parameters:
-
Select
HTTP
as the backend group type. -
Under Backends, click Add and set up the backend:
- Type:
Target group
. - Target groups: Target group you created earlier.
- Port: TCP port configured for your network load balancer's listener . Usually, this is port
80
for HTTP and port443
for HTTPS. - Under Protocol settings, select a protocol,
HTTP
orHTTPS
, based on your service. - Under HTTP health check, delete the health check. Do not add it, as the network load balancer used as the target resource is a fault-tolerant service.
- Type:
-
-
Under Virtual hosts, click Add virtual host and specify the virtual host settings:
-
Authority: Your service domain name.
-
Security profile: Smart Web Security profile you created earlier.
Warning
Linking your security profile to a virtual host of the L7 load balancer is the key step to connecting Smart Web Security.
-
Click Add route and specify the route settings:
- Path:
Starts with
/
. - Action:
Routing
. - Backend group: Backend group you created earlier.
- Path:
You can add multiple domains by clicking Add virtual host.
-
-
Create an L7 load balancer by selecting Manual:
-
Specify the previously created security group.
Warning
The Managed Service for Kubernetes cluster node groups must have security group rules that allow incoming connections from the L7 load balancer to a range of ports (30000-32767) from the subnets hosting the L7 load balancer or from its security group.
-
Under Allocation, select the subnets in three availability zones for the load balancer nodes. Enable traffic in these subnets.
-
Under Autoscaling settings, specify the minimum number of resource units per availability zone based on expected load.
We recommend selecting the number of resource units based on load expressed in:
- Number of requests per second (RPS)
- Number of concurrent active connections
- Number of new connections per second
- Traffic processed per second
-
Under Listeners, click Add listener and set up the listener:
-
Under Public IP address, specify:
- Port: TCP port configured for your network load balancer's listener . Usually, this is port
80
for HTTP and port443
for HTTPS. - Type:
List
. Select from the list a public IP address with DDoS protection at L3-L4. For more information, see service migration recommendations.
- Port: TCP port configured for your network load balancer's listener . Usually, this is port
-
Under Receiving and processing traffic, specify:
- Listener type:
HTTP
. - Protocol: Depending on your service, select
HTTP
orHTTPS
. - If you select
HTTPS
, specify the TLS certificate you added to Certificate Manager earlier in the Certificates field. - HTTP router: HTTP router you created earlier.
- Listener type:
-
-
-
Wait until the L7 load balancer goes
Active
. -
Go to the new L7 load balancer and select Health checks on the left. Make sure you get
HEALTHY
for all the L7 load balancer's health checks. -
Run a test request to the service through the L7 load balancer, for example, using one of these methods:
-
Add this record to the
hosts
file on your workstation:<L7_load_balancer_public_IP_address> <service_domain_name>
. Delete the record after the test. -
Execute the request using cURL
depending on the protocol type:curl http://<service_domain_name> \ --resolve <service_domain_name>:<service_port>:<public_IP_address_of_L7_load_balancer>
curl https://<service_domain_name> \ --resolve <service_domain_name>:<service_port>:<public_IP_address_of_L7_load_balancer>
-
Migrate user load from the external load balancer to the L7 load balancer
Select one of the migration options:
Keep the public IP address for your service
-
If your external network load balancer is using a dynamic public IP address, convert it to a static one.
-
Delete the external network load balancer. Select the option consistent with the method you originally used to deploy your NGINX Ingress controller.
Using a Helm chartUsing a manifest-
In the
values.yaml
file you used to initially configure the NGINX Ingress controller, undercontroller.service.external
, setenabled: false
. Leave the other parameters in the file unchanged.controller: service: external: enabled: false ...
-
Use this command to apply the NGINX Ingress controller configuration changes:
helm upgrade <NGINX_Ingress_controller_name> -f values.yaml <chart_for_NGINX_Ingress_controller> -n <namespace>
Delete the
Service
resource for the external network load balancer using this command:kubectl delete service <Service_resource_name_for_external_network_load_balancer>
-
-
Wait until the external network load balancer for NGINX Ingress controller and its respective
Service
object are deleted. You can use this command to view information about the services:kubectl get service
This will make your service unavailable through the external network load balancer.
-
In the L7 load balancer, assign to the listener the public IP address previously assigned to the external network load balancer.
CLITerraformIf you do not have the Yandex Cloud command line interface yet, install and initialize it.
The folder specified in the CLI profile is used by default. You can specify a different folder using the
--folder-name
or--folder-id
parameter.To change a public IP address, run this command:
yc application-load-balancer load-balancer update-listener <load_balancer_name> \ --listener-name <listener_name> \ --external-ipv4-endpoint address=<service_public_IP_address>,port=<service_port>
Where
address
is the public IP address previously assigned to the external network load balancer.-
Open the current Terraform configuration file with an infrastructure plan.
For how to create this file, see Creating an L7 load balancer.
For more information about the
yandex_alb_load_balancer
resource parameters in Terraform, see the provider documentation . -
In the load balancer description, change the
address
parameter value underlistener.endpoint.address.external_ipv4_address
:resource "yandex_alb_load_balancer" "<load_balancer_name>" { ... listener { ... endpoint { address { external_ipv4_address { address = <service_public_IP_address> } } ports = [ <service_port> ] } } }
Where
address
is the public IP address previously assigned to the external network load balancer. -
Apply the changes:
-
In the terminal, change to the folder where you edited the configuration file.
-
Make sure the configuration file is correct using the command:
terraform validate
If the configuration is correct, the following message is returned:
Success! The configuration is valid.
-
Run the command:
terraform plan
The terminal will display a list of resources with parameters. No changes are made at this step. If the configuration contains errors, Terraform will point them out.
-
Apply the configuration changes:
terraform apply
-
Confirm the changes: type
yes
in the terminal and press Enter.
-
-
-
After the IP addresses changes, your service will again be available through the L7 load balancer. Monitor the L7 load balancer's user load from the load balancer statistics charts.
-
Delete the now free static public IP address you selected when creating the L7 load balancer.
Do not keep the public IP address for your service
-
To migrate user load from an external network load balancer to an L7 load balancer, in the DNS service of your domain's public zone, change the A record value for the service domain name to the public IP address of the L7 load balancer. If the public domain zone was created in Yandex Cloud DNS, change the record using this guide.
Note
The propagation of DNS record updates depends on the time-to-live (TTL) value and the number of links in the DNS request chain. This process can take a long time.
-
As the DNS record updates propagate, follow the increase of requests to the L7 load balancer from the load balancer statistics charts.
-
Follow the decrease of the external network load balancer load using the
processed_bytes
andprocessed_packets
load balancer metrics. You can create a dashboard to visualize these metrics. The absence of load on the external network load balancer for a prolonged period of time indicates that the user load has been transfered to the L7 load balancer. -
(Optional) Delete the external network load balancer after migrating user load to the L7 load balancer. Select the option consistent with the method you originally used to deploy your NGINX Ingress controller.
Using a Helm chartUsing a manifest-
In the
values.yaml
file you used to initially configure the NGINX Ingress controller, undercontroller.service.external
, setenabled: false
. Leave the other parameters in the file unchanged.controller: service: external: enabled: false ...
-
Use this command to apply the NGINX Ingress controller configuration changes:
helm upgrade <NGINX_Ingress_controller_name> -f values.yaml <chart_for_NGINX_Ingress_controller> -n <namespace>
Warning
When you make changes to the NGINX Ingress controller configuration, your service will be temporarily unavailable.
Delete the
Service
resource for the external network load balancer using this command:kubectl delete service <Service_resource_name_for_external_network_load_balancer>
-
-
Wait until the external network load balancer for NGINX Ingress controller and its respective
Service
object are deleted. You can use this command to view information about the services:kubectl get service