Yandex Cloud
Search
Contact UsGet started
  • Blog
  • Pricing
  • Documentation
  • All Services
  • System Status
    • Featured
    • Infrastructure & Network
    • Data Platform
    • Containers
    • Developer tools
    • Serverless
    • Security
    • Monitoring & Resources
    • ML & AI
    • Business tools
  • All Solutions
    • By industry
    • By use case
    • Economics and Pricing
    • Security
    • Technical Support
    • Customer Stories
    • Gateway to Russia
    • Cloud for Startups
    • Education and Science
  • Blog
  • Pricing
  • Documentation
Yandex project
© 2025 Yandex.Cloud LLC
Yandex Application Load Balancer
  • Getting started
    • All tutorials
    • Setting up virtual hosting
    • Creating an L7 load balancer with a Smart Web Security security profile through an Application Load Balancer Ingress controller
    • Integrating an L7 load balancer with CDN and Object Storage
    • Blue-green and canary deployment of service versions
    • Writing load balancer logs to PostgreSQL
    • Deploying and load testing a gRPC service with scaling in Yandex Managed Service for Kubernetes
    • Setting up Gateway API in Yandex Managed Service for Kubernetes
    • Configuring an Application Load Balancer L7 load balancer using an Ingress controller
    • Configuring logging for an Application Load Balancer L7 load balancer using an Ingress controller
    • Health checking your apps in a Managed Service for Kubernetes cluster using an Application Load Balancer L7 load balancer
    • Implementing a secure high-availability network infrastructure with a dedicated DMZ based on the next-generation firewall
    • Creating an L7 load balancer in Application Load Balancer with a Smart Web Security profile
  • Access management
  • Pricing policy
  • Terraform reference
  • Monitoring metrics
  • Audit Trails events
  • L7 load balancer logs
  • Release notes

In this article:

  • Required paid resources
  • Getting started
  • Set up the Ingress resource and test applications
  • (Optional) Configure the Ingress resource group
  • Make sure the applications are accessible via the L7 load balancer
  • Delete the resources you created
  1. Tutorials
  2. Configuring an Application Load Balancer L7 load balancer using an Ingress controller

Configuring an Yandex Application Load Balancer L7 load balancer using an Ingress controller

Written by
Yandex Cloud
Updated at April 28, 2025
  • Required paid resources
  • Getting started
  • Set up the Ingress resource and test applications
  • (Optional) Configure the Ingress resource group
  • Make sure the applications are accessible via the L7 load balancer
  • Delete the resources you created

The Yandex Application Load Balancer service is designed for load balancing and traffic distribution across applications. To use it for managing ingress traffic of applications running in a Managed Service for Kubernetes cluster, you need an Ingress controller.

To set up access to the applications running in your Managed Service for Kubernetes cluster via an Application Load Balancer L7 load balancer:

  1. Set up the Ingress resource and test applications.
  2. (Optional) Configure the Ingress resource group.
  3. Make sure the Managed Service for Kubernetes cluster applications are accessible via Application Load Balancer.

For full configuration of the resources for the Application Load Balancer Ingress controller, see the following sections:

  • Ingress: Backend traffic distribution and load balancer configuration rules.
  • HttpBackendGroup, GrpcBackendGroup: Combining backends into groups.
  • IngressClass: Managing multiple Ingress controllers in a Kubernetes cluster.
  • Service: Description of Kubernetes services used as backends.

Required paid resourcesRequired paid resources

The support cost includes:

  • Fee for a DNS zone and DNS requests (see Cloud DNS pricing).
  • Fee for the Managed Service for Kubernetes cluster: using the master and outgoing traffic (see Managed Service for Kubernetes pricing).
  • Cluster nodes (VM) fee: using computing resources, operating system, and storage (see Compute Cloud pricing).
  • Fee for using the computing resources of the L7 load balancer (see Application Load Balancer pricing).
  • Fee for public IP addresses for cluster nodes and L7 load balancer (see Virtual Private Cloud pricing).
  • Object Storage bucket fee: Storing data and performing operations with it (see Object Storage pricing).

Getting startedGetting started

  1. Register a public domain zone and delegate your domain.

  2. If you already have a certificate for the domain zone, add its details to the Yandex Certificate Manager service. Alternatively, you can add a new Let's Encrypt® certificate.

  3. Get the ID of the certificate you added:

    yc certificate-manager certificate list
    

    What the command should return:

    +----------------------+-----------+----------------+---------------------+----------+--------+
    |          ID          |   NAME    |    DOMAINS     |      NOT AFTER      |   TYPE   | STATUS |
    +----------------------+-----------+----------------+---------------------+----------+--------+
    | fpq8diorouhp******** | sert-test |    test.ru     | 2022-01-06 17:19:37 | IMPORTED | ISSUED |
    +----------------------+-----------+----------------+---------------------+----------+--------+
    
  4. Create security groups for the Managed Service for Kubernetes cluster and its node groups.

    Also configure the security groups required for Application Load Balancer.

    Warning

    The configuration of security groups determines the performance and availability of the cluster and the services and applications running in it.

  5. Create a Managed Service for Kubernetes cluster. When creating a cluster, specify the preconfigured security groups.

    For Yandex Cloud internal network usage, your cluster does not need a public IP address. To enable internet access to your cluster, assign it a public IP address.

  6. Create a node group. To enable internet access for your node group (e.g., for Docker image pulls), assign it a public IP address. Specify the preconfigured security groups.

  7. Install an Application Load Balancer Ingress controller.

  8. Optionally, install ExternalDNS with a plugin for Yandex Cloud DNS to automatically create a DNS record in Yandex Cloud DNS when creating an Ingress controller.

  9. Install kubect and configure it to work with the new cluster.

    If a cluster has no public IP address assigned and kubectl is configured via the cluster's private IP address, run kubectl commands on a Yandex Cloud VM that is in the same network as the cluster.

Set up the Ingress resource and test applicationsSet up the Ingress resource and test applications

The Ingress resource defines:

  • L7 load balancer parameters set using annotations.

  • Rules for distribution of incoming traffic between Kubernetes services.

    Services acting as Application Load Balancer backends may be specified in the Ingress resource either directly or as part of HttpBackendGroup/GrpcBackendGroup backend groups.

Create test applications and an Ingress resource:

Ingress resource for Kubernetes services
Ingress resource for a backend group
  1. In a separate directory, create the demo-app-1.yaml and demo-app-2.yaml application configuration files:

    demo-app-1.yaml
    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: alb-demo-1
    data:
      nginx.conf: |
        worker_processes auto;
        events {
        }
        http {
          server {
            listen 80 ;
            location = /_healthz {
              add_header Content-Type text/plain;
              return 200 'ok';
            }
            location / {
              add_header Content-Type text/plain;
              return 200 'Index';
            }
            location = /app1 {
              add_header Content-Type text/plain;
              return 200 'This is APP#1';
            }
          }
        }
    ---
    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: alb-demo-1
      labels:
        app: alb-demo-1
        version: v1
    spec:
      replicas: 2
      selector:
        matchLabels:
          app: alb-demo-1
      strategy:
        type: RollingUpdate
        rollingUpdate:
          maxSurge: 1
          maxUnavailable: 0
      template:
        metadata:
          labels:
            app: alb-demo-1
            version: v1
        spec:
          terminationGracePeriodSeconds: 5
          volumes:
            - name: alb-demo-1
              configMap:
                name: alb-demo-1
          containers:
            - name: alb-demo-1
              image: nginx:latest
              ports:
                - name: http
                  containerPort: 80
              livenessProbe:
                httpGet:
                  path: /_healthz
                  port: 80
                initialDelaySeconds: 3
                timeoutSeconds: 2
                failureThreshold: 2
              volumeMounts:
                - name: alb-demo-1
                  mountPath: /etc/nginx
                  readOnly: true
              resources:
                limits:
                  cpu: 250m
                  memory: 128Mi
                requests:
                  cpu: 100m
                  memory: 64Mi
    ---
    apiVersion: v1
    kind: Service
    metadata:
      name: alb-demo-1
    spec:
      selector:
        app: alb-demo-1
      type: NodePort
      ports:
        - name: http
          port: 80
          targetPort: 80
          protocol: TCP
          nodePort: 30081
    
    demo-app-2.yaml
    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: alb-demo-2
    data:
      nginx.conf: |
        worker_processes auto;
        events {
        }
        http {
          server {
            listen 80 ;
            location = /_healthz {
              add_header Content-Type text/plain;
              return 200 'ok';
            }
            location / {
              add_header Content-Type text/plain;
              return 200 'Add app#';
            }
            location = /app2 {
              add_header Content-Type text/plain;
              return 200 'This is APP#2';
            }
          }
        }
    ---
    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: alb-demo-2
      labels:
        app: alb-demo-2
        version: v1
    spec:
      replicas: 2
      selector:
        matchLabels:
          app: alb-demo-2
      strategy:
        type: RollingUpdate
        rollingUpdate:
          maxSurge: 1
          maxUnavailable: 0
      template:
        metadata:
          labels:
            app: alb-demo-2
            version: v1
        spec:
          terminationGracePeriodSeconds: 5
          volumes:
            - name: alb-demo-2
              configMap:
                name: alb-demo-2
          containers:
            - name: alb-demo-2
              image: nginx:latest
              ports:
                - name: http
                  containerPort: 80
              livenessProbe:
                httpGet:
                  path: /_healthz
                  port: 80
                initialDelaySeconds: 3
                timeoutSeconds: 2
                failureThreshold: 2
              volumeMounts:
                - name: alb-demo-2
                  mountPath: /etc/nginx
                  readOnly: true
              resources:
                limits:
                  cpu: 250m
                  memory: 128Mi
                requests:
                  cpu: 100m
                  memory: 64Mi
    ---
    apiVersion: v1
    kind: Service
    metadata:
      name: alb-demo-2
    spec:
      selector:
        app: alb-demo-2
      type: NodePort
      ports:
        - name: http
          port: 80
          targetPort: 80
          protocol: TCP
          nodePort: 30082
    
  2. In the same directory, create a file named ingress.yaml and specify in it the previously delegated domain name, ID of the certificate obtained earlier, and settings for the Application Load Balancer L7 load balancer:

    apiVersion: networking.k8s.io/v1
    kind: Ingress
    metadata:
      name: alb-demo-tls
      annotations:
        ingress.alb.yc.io/subnets: <list_of_subnet_IDs>
        ingress.alb.yc.io/security-groups: <list_of_security_group_IDs>
        ingress.alb.yc.io/external-ipv4-address: <IP_address_assignment_method>
        ingress.alb.yc.io/group-name: my-ingress-group
    spec:
      tls:
        - hosts:
            - <domain_name>
          secretName: yc-certmgr-cert-id-<TLS_certificate_ID>
      rules:
        - host: <domain_name>
          http:
            paths:
              - path: /app1
                pathType: Prefix
                backend:
                  service:
                    name: alb-demo-1
                    port:
                      number: 80
              - path: /app2
                pathType: Prefix
                backend:
                  service:
                    name: alb-demo-2
                    port:
                      number: 80
              - pathType: Prefix
                path: "/"
                backend:
                  service:
                    name: alb-demo-2
                    port:
                      name: http
    

    Where:

    • ingress.alb.yc.io/subnets: One or more subnets hosting the Application Load Balancer L7 load balancer.

    • ingress.alb.yc.io/security-groups: One or more security groups for the load balancer. If you skip this parameter, the default security group will be used. At least one of the security groups must allow an outgoing TCP connection to port 10501 in the Managed Service for Kubernetes node group subnet or to its security group.

    • ingress.alb.yc.io/external-ipv4-address: Public access to the load balancer from the internet. Enter the IP address you got earlier or set auto to get a new IP address automatically.

      If you set auto, deleting the load balancer from the cloud will also delete the IP address. To avoid this, use an existing reserved IP address.

    • ingress.alb.yc.io/group-name: Group name. Ingress resources are grouped together, each group served by a separate load balancer.

      You can replace my-ingress-group with any group name you like. Make sure it meets the naming requirements.

    In ALB Ingress Controller versions prior to 0.2.0, each backend group corresponds to a bundle of host, http.paths.path, and http.paths.pathType parameters. In versions 0.2.0 and later, the backend group corresponds to the backend.service parameter. This may cause collisions when updating the ALB Ingress Controller. To avoid them, find out whether upgrade restrictions apply to your infrastructure.

    (Optional) Enter the advanced settings for the load balancer:

    Additional settings

    Note

    The settings listed below will only apply to the virtual hosts of the Ingress resource in which the corresponding annotations are configured.

    They will not apply to the virtual hosts of the group's other Ingress resources.

    Available settings:

    • ingress.alb.yc.io/group-settings-name: Name for the Ingress resource group settings to be described in the optional IngressGroupSettings resource. For more information, see Configure the Ingress resource group.

    • ingress.alb.yc.io/internal-ipv4-address: Provide internal access to the load balancer. Enter the internal IP address or use auto to obtain the IP address automatically.

      Note

      You can only use one type of access to the load balancer at a time: ingress.alb.yc.io/external-ipv4-address or ingress.alb.yc.io/internal-ipv4-address.

    • ingress.alb.yc.io/internal-alb-subnet: Subnet to host the load balancer. This parameter is required if the ingress.alb.yc.io/internal-ipv4-address parameter is selected.

    • ingress.alb.yc.io/protocol: Connection protocol used between the load balancer and backends:

      • http: HTTP/1.1, default
      • http2: HTTP/2
      • grpc: gRPC
    • ingress.alb.yc.io/transport-security: Encryption protocol for connections between the load balancer and backends.

      Warning

      In ALB Ingress Controller version 0.2.0 and later, you can only use an annotation in the Service object.

      If you annotate Ingress resources that use a single service with the same settings for backend groups, such annotation will apply correctly. However, this mechanism is obsolete and will not be supported going forward.

      The valid value is tls: TLS with no certificate challenge.

      If no annotation is specified, the load balancer connects to the backends with no encryption.

    • ingress.alb.yc.io/prefix-rewrite: Replace the path for the specified value.

    • ingress.alb.yc.io/upgrade-types: Valid values of the Upgrade HTTP header, e.g., websocket.

    • ingress.alb.yc.io/request-timeout: Maximum period for which a connection can be established.

    • ingress.alb.yc.io/idle-timeout: Maximum connection keep-alive time without data transmission.

      The request-timeout and idle-timeout values must be specified with units of measurement, e.g., 300ms or 1.5h. Valid units of measurement:

      • ns, nanoseconds
      • us, microseconds
      • ms, milliseconds
      • s, seconds
      • m, minutes
      • h, hours
    • ingress.alb.yc.io/security-profile-id: Support for Yandex Smart Web Security that allows you to get protected against DDoS attacks and bots, plus enable WAF and limit the load on the resource you are protecting.

      To enable support for Yandex Smart Web Security, specify the previously created Smart Web Security security profile in the Ingress annotation:

      ingress.alb.yc.io/security-profile-id: <security_profile_ID>
      

      Note

      To connect your security profile to an Application Load Balancer virtual host, the service account used to operate the Ingress controller must have the smart-web-security.editor role for the folder hosting Application Load Balancer and Smart Web Security resources. For more information, see Assigning a role to a service account.

    • ingress.alb.yc.io/use-regex: Support for RE2 regular expressions when matching the request path. If the true string is provided, the support is enabled. Only applies if the pathType parameter is set to Exact.

    • ingress.alb.yc.io/balancing-panic-threshold: Panic mode threshold. The mode will be activated if the percentage of healthy endpoints falls below this value. The default value is 0, which means the panic mode will never be activated.

    • ingress.alb.yc.io/balancing-locality-aware-routing: Percentage of incoming traffic the load balancer forwards to backends from its availability zone. The remaining traffic is evenly distributed between other availability zones. The default value is 0. More on locality aware routing.

    • ingress.alb.yc.io/autoscale-max-size: Maximum total number of resource units. By default, this number is unlimited. Make sure the value is more or equal to the number of load balancer availability zones multiplied by the minimum number of resource units per zone. Learn more about the autoscaling settings here.

    • ingress.alb.yc.io/modify-header-response-append: Adds a string to the response header value. The header and string should be specified in the following format:

      ingress.alb.yc.io/modify-header-response-append: <name_of_header_to_edit>=<string>
      
    • ingress.alb.yc.io/modify-header-response-replace: Replaces the response header value. The header and its new value should be specified in the following format:

      ingress.alb.yc.io/modify-header-response-replace: <name_of_header_to_edit>=<new_header_value>
      
    • ingress.alb.yc.io/modify-header-response-rename: Renames the response header. The header and its new name should be specified in the following format:

      ingress.alb.yc.io/modify-header-response-rename: <name_of_header_to_edit>=<new_header_name>
      
    • ingress.alb.yc.io/modify-header-response-remove: Removes the response header. The header to remove should be specified in the following format:

      ingress.alb.yc.io/modify-header-response-remove: <name_of_header_to_delete>=true
      
      
    • ingress.alb.yc.io/modify-header-request-append: Adds a string to the request header value. The header and string should be specified in the following format:

      ingress.alb.yc.io/modify-header-request-append: <name_of_header_to_edit>=<string>
      
    • ingress.alb.yc.io/modify-header-request-replace: Replaces the request header value. The header and its new value should be specified in the following format:

      ingress.alb.yc.io/modify-header-request-replace: <name_of_header_to_edit>=<new_header_value>
      
    • ingress.alb.yc.io/modify-header-request-rename: Renames the request header. The header and its new name should be specified in the following format:

      ingress.alb.yc.io/modify-header-request-rename: <name_of_header_to_edit>=<new_header_name>
      
    • ingress.alb.yc.io/modify-header-request-remove: Removes the request header. The header to remove should be specified in the following format:

      ingress.alb.yc.io/modify-header-request-remove: <name_of_header_to_delete>=true
      

    If you use several Ingress controllers, create an IngressClass resource for each of them. In the Ingress configuration, specify the IngressClass you need in the spec.ingressClassName field.

    For more information about the Ingress resource settings, see Ingress resource fields and annotations.

  3. Create Kubernetes applications and the Ingress resource:

    kubectl apply -f .
    

    ALB Ingress Controller will automatically deploy the L7 load balancer using Ingress resource configuration.

  4. Wait until the Application Load Balancer L7 load balancer is created and gets a public IP address. This may take several minutes.

    To follow the load balancer's creation and make sure it is error-free, open the logs of the pod the creation process was run in:

    1. In the management console, navigate to the folder page and select Managed Service for Kubernetes.

    2. Click your cluster's name and select Workload in the left-hand panel.

    3. Select one of the alb-demo-*** pods the load balancer's creation was run in.

    4. Go to the Logs tab on the pod page.

      The load balancer's creation logs are generated and displayed in real time. Any errors that occur will also be logged.

  5. Make sure the load balancer was created. To do this, run the appropriate command and check that the command output shows the following value in the ADDRESS field:

    kubectl get ingress alb-demo-tls
    

    Result:

    NAME          CLASS   HOSTS           ADDRESS     PORTS    AGE
    alb-demo-tls  <none>  <domain_name>  <IP_address>  80,443  15h
    
  1. Create a backend group with a bucket:

    1. Create a public bucket in Object Storage.
    2. Configure the website home page and error page.
  2. Create a configuration file named demo-app-1.yaml for your application:

    demo-app-1.yaml
    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: alb-demo-1
    data:
      nginx.conf: |
        worker_processes auto;
        events {
        }
        http {
          server {
            listen 80 ;
            location = /_healthz {
              add_header Content-Type text/plain;
              return 200 'ok';
            }
            location / {
              add_header Content-Type text/plain;
              return 200 'Index';
            }
            location = /app1 {
              add_header Content-Type text/plain;
              return 200 'This is APP#1';
            }
          }
        }
    ---
    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: alb-demo-1
      labels:
        app: alb-demo-1
        version: v1
    spec:
      replicas: 2
      selector:
        matchLabels:
          app: alb-demo-1
      strategy:
        type: RollingUpdate
        rollingUpdate:
          maxSurge: 1
          maxUnavailable: 0
      template:
        metadata:
          labels:
            app: alb-demo-1
            version: v1
        spec:
          terminationGracePeriodSeconds: 5
          volumes:
            - name: alb-demo-1
              configMap:
                name: alb-demo-1
          containers:
            - name: alb-demo-1
              image: nginx:latest
              ports:
                - name: http
                  containerPort: 80
              livenessProbe:
                httpGet:
                  path: /_healthz
                  port: 80
                initialDelaySeconds: 3
                timeoutSeconds: 2
                failureThreshold: 2
              volumeMounts:
                - name: alb-demo-1
                  mountPath: /etc/nginx
                  readOnly: true
              resources:
                limits:
                  cpu: 250m
                  memory: 128Mi
                requests:
                  cpu: 100m
                  memory: 64Mi
    ---
    apiVersion: v1
    kind: Service
    metadata:
      name: alb-demo-1
    spec:
      selector:
        app: alb-demo-1
      type: NodePort
      ports:
        - name: http
          port: 80
          targetPort: 80
          protocol: TCP
          nodePort: 30081
    
  3. In a separate directory, create a file named http-group.yaml with the HttpBackendGroup resource settings:

    apiVersion: alb.yc.io/v1alpha1
    kind: HttpBackendGroup
    metadata:
      name: example-backend-group
    spec:
      backends: # List of backends.
        - name: alb-demo-1
          weight: 70 # Backend relative weight when distributing traffic. The load will be distributed in proportion to the weights of the group's other backends. Specify the weight even if you have only one backend in the group.
          service:
             name: alb-demo-1
             port:
               number: 80
        - name: bucket-backend
          weight: 30
          storageBucket:
            name: <bucket_name>
    

    (Optional) Enter the advanced settings for the backend group:

    • spec.backends.useHttp2: HTTP/2 mode.
    • spec.backends.tls: Certificate from the certificate authority the load balancer will trust when establishing a secure connection with backend endpoints. Specify the certificate contents in the trustedCa field in plain text.

    For more information, see Backend groups.

  4. In the same directory, create a file named ingress-http.yaml and specify in it the previously delegated domain name, ID of the certificate obtained earlier, and settings for the Application Load Balancer L7 load balancer:

    apiVersion: networking.k8s.io/v1
    kind: Ingress
    metadata:
      name: alb-demo-tls
      annotations:
        ingress.alb.yc.io/subnets: <list_of_subnet_IDs>
        ingress.alb.yc.io/security-groups: <list_of_security_group_IDs>
        ingress.alb.yc.io/external-ipv4-address: <IP_address_assignment_method>
        ingress.alb.yc.io/group-name: my-ingress-group
    spec:
      tls:
        - hosts:
          - <domain_name>
          secretName: yc-certmgr-cert-id-<TLS_certificate_ID>
      rules:
        - host: <domain_name>
          http:
            paths:
              - path: /app1
                pathType: Exact
                backend:
                  resource:
                    apiGroup: alb.yc.io
                    kind: HttpBackendGroup
                    name: example-backend-group
    

    Where:

    • ingress.alb.yc.io/subnets: One or more subnets hosting the Application Load Balancer L7 load balancer.

    • ingress.alb.yc.io/security-groups: One or more security groups for the load balancer. If you skip this parameter, the default security group will be used. At least one of the security groups must allow an outgoing TCP connection to port 10501 in the Managed Service for Kubernetes node group subnet or to its security group.

    • ingress.alb.yc.io/external-ipv4-address: Public access to the load balancer from the internet. Enter the IP address you got earlier or set auto to get a new IP address automatically.

      If you set auto, deleting the load balancer from the cloud will also delete the IP address. To avoid this, use an existing reserved IP address.

    • ingress.alb.yc.io/group-name: Group name. Ingress resources are grouped together, each group served by a separate load balancer.

      You can replace my-ingress-group with any group name you like. Make sure it meets the naming requirements.

    (Optional) Enter the advanced settings for the load balancer.

    Note

    The settings listed below will only apply to the virtual hosts of the Ingress resource in which the corresponding annotations are configured.

    They will not apply to the virtual hosts of the group's other Ingress resources.

    Available settings:

    • ingress.alb.yc.io/group-settings-name: Name for the Ingress resource group settings to be described in the optional IngressGroupSettings resource. For more information, see Configure the Ingress resource group.

    • ingress.alb.yc.io/internal-ipv4-address: Provide internal access to the load balancer. Enter the internal IP address or use auto to obtain the IP address automatically.

      Note

      You can only use one type of access to the load balancer at a time: ingress.alb.yc.io/external-ipv4-address or ingress.alb.yc.io/internal-ipv4-address.

    • ingress.alb.yc.io/internal-alb-subnet: Subnet to host the load balancer. This parameter is required if the ingress.alb.yc.io/internal-ipv4-address parameter is selected.

    • ingress.alb.yc.io/protocol: Connection protocol used between the load balancer and backends:

      • http: HTTP/1.1. Default
      • http2: HTTP/2
      • grpc: gRPC
    • ingress.alb.yc.io/prefix-rewrite: Replace the path for the specified value.

    • ingress.alb.yc.io/upgrade-types: Valid values of the Upgrade HTTP header, e.g., websocket.

    • ingress.alb.yc.io/request-timeout: Maximum period for which a connection can be established.

    • ingress.alb.yc.io/idle-timeout: Maximum connection keep-alive time without data transmission.

      The request-timeout and idle-timeout values must be specified with units of measurement, e.g., 300ms or 1.5h. Valid units of measurement:

      • ns, nanoseconds
      • us, microseconds
      • ms, milliseconds
      • s, seconds
      • m, minutes
      • h, hours
    • ingress.alb.yc.io/security-profile-id: Support for Yandex Smart Web Security that allows you to get protected against DDoS attacks and bots, plus enable WAF and limit the load on the resource you are protecting.

      To enable support for Yandex Smart Web Security, specify the previously created Smart Web Security security profile in the Ingress annotation:

      ingress.alb.yc.io/security-profile-id: <security_profile_ID>
      

      Note

      To connect your security profile to an Application Load Balancer virtual host, the service account used to operate the Ingress controller must have the smart-web-security.editor role for the folder hosting Application Load Balancer and Smart Web Security resources. For more information, see Assigning a role to a service account.

    • ingress.alb.yc.io/use-regex: Support for RE2 regular expressions when matching the request path. If the true string is provided, the support is enabled. Only applies if the pathType parameter is set to Exact.

    For more information about the Ingress resource settings, see Ingress resource fields and annotations.

  5. Create the Kubernetes app, HttpBackendGroup resource, and Ingress resource:

    kubectl apply -f .
    

ALB Ingress Controller will automatically deploy the L7 load balancer using Ingress resource configuration.

  1. Wait until the Application Load Balancer L7 load balancer is created and gets a public IP address. This may take several minutes.

    To follow the load balancer's creation and make sure it is error-free, open the logs of the pod the creation process was run in:

    1. In the management console, navigate to the folder page and select Managed Service for Kubernetes.

    2. Click your cluster's name and select Workload in the left-hand panel.

    3. Select one of the alb-demo-*** pods the load balancer's creation was run in.

    4. Go to the Logs tab on the pod page.

      The load balancer's creation logs are generated and displayed in real time. Any errors that occur will also be logged.

  2. Make sure the load balancer was created. To do this, run the appropriate command and check that the command output shows the following value in the ADDRESS field:

    kubectl get ingress alb-demo-tls
    

    Result:

    NAME          CLASS   HOSTS           ADDRESS     PORTS    AGE
    alb-demo-tls  <none>  <domain_name>  <IP_address>  80,443  15h
    

By default, the Application Load Balancer Ingress controller receives application health check requests from the L7 load balancer at TCP port 10501 and health checks the kube-proxy pods on each cluster node. If kube-proxy is healthy, then, even though an application does not respond in a particular pod, Kubernetes will redirect traffic to a different pod with that application or to a different node.

You can use the HttpBackendGroup/GrpcBackendGroup resource parameters to customize health checks. For more information, see Health checking your apps in a Yandex Managed Service for Kubernetes cluster using a Yandex Application Load Balancer L7 load balancer.

(Optional) Configure the Ingress resource group(Optional) Configure the Ingress resource group

If you specified a name for the Ingress resource group settings in the ingress.alb.yc.io/group-settings-name annotation when setting up the Ingress resource, you can specify logging settings for the L7 load balancer. To do this, create a custom log group and specify the Ingress resource group settings in the optional IngressGroupSettings resource:

  1. Create a settings.yaml file with your logging settings and the custom log group ID, e.g.:

    apiVersion: alb.yc.io/v1alpha1
    kind: IngressGroupSettings
    metadata:
      name: <name_for_Ingress_resource_group_settings>
    logOptions:
      logGroupID: <user_log_group_ID>
      discardRules:
        - discardPercent: 50
          grpcCodes:
            - OK
            - CANCELLED
            - UNKNOWN
        - discardPercent: 67
          httpCodeIntervals:
            - HTTP_1XX
        - discardPercent: 20
          httpCodes:
            - 200
            - 404
    

    Where name is the name for the Ingress resource group settings in the ingress.alb.yc.io/group-settings-name annotation.

  2. Apply the settings for the Ingress resource group:

    kubectl apply -f settings.yaml
    

Make sure the applications are accessible via the L7 load balancerMake sure the applications are accessible via the L7 load balancer

  1. If you have no ExternalDNS with a plugin for Cloud DNS installed, add an A record to your domain zone. In the Value field, specify the public IP address of the Application Load Balancer L7 load balancer. If you are using ExternalDNS with a plugin for Yandex Cloud DNS, this record will be created automatically.

  2. Test the load balancer:

    Ingress resource for Kubernetes services
    Ingress resource for a backend group

    Open the application URIs in your browser:

    https://<your_domain>/app1
    https://<your_domain>/app2
    

    Make sure the applications are accessible via the Application Load Balancer L7 load balancer and return pages with the This is APP#1 and This is APP#2 text, respectively.

    Note

    If the resource is unavailable at the specified URL, make sure that the security groups for the Managed Service for Kubernetes cluster and its node groups are configured correctly. If any rule is missing, add it.

    Open the application's URI in your browser:

    https://<your_domain>/app1
    

    Make sure the target resources are accessible via the Application Load Balancer L7 load balancer.

    Note

    If the resource is unavailable at the specified URL, make sure that the security groups for the Managed Service for Kubernetes cluster and its node groups are configured correctly. If any rule is missing, add it.

Delete the resources you createdDelete the resources you created

Some resources are not free of charge. To avoid paying for them, delete the resources you no longer need:

  1. Delete the Managed Service for Kubernetes cluster.
  2. Delete the Application Load Balancer target groups.
  3. Delete the Object Storage bucket.

Was the article helpful?

Previous
Setting up Gateway API in Yandex Managed Service for Kubernetes
Next
Configuring logging for an Application Load Balancer L7 load balancer using an Ingress controller
Yandex project
© 2025 Yandex.Cloud LLC