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
    • Start testing with double trial credits
    • Cloud credits to scale your IT product
    • Gateway to Russia
    • Cloud for Startups
    • Education and Science
    • Yandex Cloud Partner program
  • Blog
  • Pricing
  • Documentation
© 2025 Direct Cursus Technology L.L.C.
Yandex Managed Service for Kubernetes
  • Comparison with other Yandex Cloud services
  • Getting started
  • Access management
  • Pricing policy
  • Terraform reference
  • Monitoring metrics
  • Audit Trails events
    • Overview
      • Ingress
      • HttpBackendGroup
      • GrpcBackendGroup
      • IngressClass
      • Service for Ingress
  • Release notes
  1. Application Load Balancer tools
  2. Ingress controller
  3. HttpBackendGroup

HttpBackendGroup resource fields

Written by
Yandex Cloud
Improved by
Alexey M.
Updated at April 22, 2025

HttpBackendGroup enables you to combine Kubernetes service backends into a group. The Application Load Balancer Ingress controller uses these resources to create backend groups.

You need to add a reference to HttpBackendGroup to the Ingress resource.

Using HttpBackendGroup enables extended Application Load Balancer functionality. A backend group can route traffic to either Kubernetes services or Yandex Object Storage buckets. HttpBackendGroup allows you to distribute traffic across backends proportionally using relative weights.

HttpBackendGroup is a custom resource from the alb.yc.io API group provided by an Ingress controller.

HttpBackendGroup

apiVersion: alb.yc.io/v1alpha1
kind: HttpBackendGroup
metadata:
  name: <string>
spec:
  backends:
    - name: <string>
      weight: <int64>
      useHttp2: <bool>
      service:
         name: <int64>
         port:
           name: <string>
           number: <int32>
      storageBucket:
        name: <string>
      tls:
        sni: <string>
        trustedCa: <string>
      healthChecks:
        - http:
            path: <string>
          port: <int32>
          healthyThreshold: <int32>
          unhealthyThreshold: <int32>
          timeout: <string>
          interval: <string>
      loadBalancingConfig:
        balancerMode: <string>
        panicThreshold: <int64>
        localityAwareRouting: <int64>
    - ...

Where:

  • apiVersion: alb.yc.io/v1alpha1

  • kind: HttpBackendGroup

  • metadata (ObjectMeta, required)

    Resource metadata.

    • name (string, required)

      Resource name. For more information about the name format, see the relevant Kubernetes guides.

      You must specify this name in the spec.rules.http.paths.backend.resource.name field of the Ingress resource. For more information, see the relevant configuration.

      Do not mistake this name for the Application Load Balancer backend group name.

  • spec (HttpBackendGroupSpec)

    Resource specification.

    • backends ([]HttpBackend)

      Group backends.

      • name (string, required)

        Backend name.

      • weight (int64)

        Backend weight. Backends in a group receive traffic in proportion to their weights.

        You should either specify weights for all backends in a group, or not specify them at all. If weights are not specified, traffic will be equally distributed across backends.

        A backend with zero or negative weight will not be receiving traffic.

      • useHttp2 (bool)

        Enables HTTP/2 connections between load balancer nodes and backend endpoints.

        The default value is false, which means only HTTP/1.1 connections are allowed.

      • service (ServiceBackend)

        Kubernetes service backend for processing requests.

        The referred Service resource must be described per the standard configuration.

        You must specify a service or an Object Storage bucket, i.e.,storageBucket, for the backend. You cannot specify both at the same time.

        • name (string, required):

          Kubernetes service name.

        • port (ServiceBackendPort, required):

          Service port to which Ingress will direct traffic.

          The field is designed for ingress controller operation and has no equivalents in Application Load Balancer.

          • name (string):

            Service port name.

            This name must match one of the Service resource spec.ports.name values. For more information, see the resource specification.

            You must specify either the service port name or its number, but not both.

          • number (int32):

            Service port number.

            This number must match one of the Service resource spec.ports.port values. For more information, see the resource specification.

            You must specify either the service port name or its number, but not both.

      • storageBucket (StorageBucketBackend)

        Yandex Object Storage bucket backend for processing requests. To learn more about using a bucket as a backend, see Backend types.

        Warning

        To use a bucket as a backend, grant public access to the list of objects in the bucket and permission to read them.

        You must specify a bucket or Kubernetes service for the backend. You cannot specify both at the same time.

        • name (string, required)

          Bucket name.

      • tls (BackendTLS)

        TLS connection settings for the load balancer nodes and backend endpoints.

        If this field is specified, the load balancer will establish TLS connections to the backend, comparing received certificates with the one specified in the trustedCa field. Otherwise, the load balancer will use unencrypted connections to the backend.

        • sni (string)

          SNI domain name for TLS connections.

        • trustedCa (string)

          X.509 certificate in PEM format.

      • healthChecks ([]HealthChecks)

        Custom health checks settings for Managed Service for Kubernetes cluster applications.

        By default, the Application Load Balancer Ingress controller receives L7 load balancer health check requests on TCP port 10501. Then it checks kube-proxy pods on each cluster node. Given that kube-proxy is healthy, the process is as follows: if an application does not respond in a particular pod, Kubernetes redirects traffic to a different pod or node.

        You can use healthChecks settings to customize application health checks.

        • http (HttpBackend)

          Specifies HTTP as the health check protocol.

          • path (string)

            Application endpoint URI path for health check requests, e.g. /health.

        • port (int32)

          Cluster node port for checking application availability. This port should match the spec.ports.nodePort value of the NodePort Service resource.

          The application will listen for health check requests on http://<node_IP_address>:<port>/<path>.

        • healthyThreshold (int32)

          Number of consecutive successful checks required before considering the application endpoint healthy.

        • unhealthyThreshold (int32)

          Number of consecutive failed checks required before considering the application endpoint unhealthy.

        • timeout (string)

          Response timeout in seconds. You can specify values between 1s and 60s.

        • interval (string)

          Health check request interval in seconds.

          You can specify values between 1s and 60s. interval must exceed timeout by at least one second.

        Note

        You can also configure application health checks using the ingress.alb.yc.io/health-checks annotation of the Service resource.

      • loadBalancingConfig (LoadBalancingConfig)

        Load balancing settings.

        • balancerMode (string)

          Traffic distribution mode. It is an algorithm according to which the load balancer distributes traffic across backend endpoints. Possible values: ROUND_ROBIN, RANDOM, LEAST_REQUEST, and MAGLEV_HASH. Learn more about each mode.

        • panicThreshold (int64)

          Minimum percentage of healthy endpoints. If the percentage of healthy endpoints falls below the specified value, it will trigger the panic mode.

          The default value is 0, which means the panic mode will never be activated.

        • localityAwareRouting (int64)

          Share of incoming traffic the load balancer will forward to its availability zone backends. The remaining traffic will be evenly distributed across other availability zones. More on locality-aware routing.

          The default value is 0.

Was the article helpful?

Previous
Ingress
Next
GrpcBackendGroup
© 2025 Direct Cursus Technology L.L.C.