Yandex Cloud
Search
Contact UsGet started
  • Pricing
  • Customer Stories
  • Documentation
  • Blog
  • All Services
  • System Status
    • Featured
    • Infrastructure & Network
    • Data Platform
    • Containers
    • Developer tools
    • Serverless
    • Security
    • Monitoring & Resources
    • AI for business
    • Business tools
  • All Solutions
    • By industry
    • By use case
    • Economics and Pricing
    • Security
    • Technical Support
    • Start testing with double trial credits
    • Cloud credits to scale your IT product
    • Gateway to Russia
    • Cloud for Startups
    • Center for Technologies and Society
    • Yandex Cloud Partner program
  • Pricing
  • Customer Stories
  • Documentation
  • Blog
© 2025 Direct Cursus Technology L.L.C.
Yandex Application Load Balancer
  • Getting started
    • Overview
      • Overview
      • Installing the Gateway API
    • Configuring security groups
    • Working with service accounts
    • Creating and updating resources via ingress controller configurations
  • Access management
  • Pricing policy
  • Terraform reference
  • Monitoring metrics
  • Audit Trails events
  • L7 load balancer logs
  • Release notes

In this article:

  • Route order in virtual hosts
  • Sample configuration
  • Installation and requirements
  1. Tools for Managed Service for Kubernetes
  2. Gateway API
  3. Overview

Gateway API for Managed Service for Kubernetes

Written by
Yandex Cloud
Updated at August 7, 2025
  • Route order in virtual hosts
  • Sample configuration
  • Installation and requirements

Application Load Balancer provides the Gateway API tool for creating and managing load balancers in Yandex Managed Service for Kubernetes clusters. To learn more about the Gateway API project, visit its official website.

Once you install the Gateway API, you can use it to create the Gateway resource as well as the linked HTTPRoute and GRPCRoute resources:

  • The Gateway resource is managed by the cluster operator. The resource describes the incoming traffic reception and routing (HTTPRoute and GRPCRoute) rules. The system creates an L7 load balancer to handle traffic for the Gateway. The load balancer uses HTTP routers to route incoming traffic.
  • Managed by developers of Kubernetes service apps, the HTTPRoute and GRPCRoute resources describe the route for received incoming traffic. According to this description, traffic can be routed to the Kubernetes service operating as a backend or redirected to another URI. With HTTPRoute and GRPCRoute you create virtual hosts and routes in HTTP routers and backend groups.

See the full configuration of Gateway API resources in the following sections:

  • Gateway: Incoming traffic reception and routing (HTTPRoute) rules.
  • GatewayPolicy: Gateway resource policy, incoming traffic processing configuration.
  • YCCertificate: Certificate Manager certificate parameters for setting up TLS connections in the Gateway resource.
  • HTTPRoute and GRPCRoute: Rules for traffic routing between backends or redirection.
  • RoutePolicy: HTTPRoute resource policy and backend access rule configuration.
  • YCStorageBucket: Object Storage bucket parameters for setting up a backend in the HTTPRoute resource.
  • Service: Kubernetes backend service description.

Route order in virtual hostsRoute order in virtual hosts

The order of routes in virtual hosts is as per the algorithms described in the Gateway API specification. These algorithms are different for HTTP requests and gRPC calls.

HTTP requests
gRPC calls

The algorithm sorts routes by how well their parameters match those of the incoming HTTP request.

Match conditions in descending order of priority:

  1. Exact path match.
  2. Longest path prefix match.
  3. Method match.
  4. Greatest number of matching headers.
  5. Greatest number of matching request parameters.

For requests matching none of the rules associated with the current parent element, code 404 will be returned.

The algorithm sorts routes by the number of characters in the parameters of the route and the incoming gRPC call. Matches are counted only based on headers.

Comparison conditions in descending order of priority:

  1. Greatest number of characters in domain name without asterisks *.
  2. Greatest number of characters in domain name.
  3. Greatest number of characters in service name.
  4. Greatest number of characters in method name.
  5. Greatest number of matching headers.

If these conditions still leave routes of equal precedence from different resources, such routes will first be prioritized based on their timestamp (older routes first), then alphabetically by name in {namespace}/{name} format.

If there are still routes of equal precedence within the same HTTPRoute/GRPCRoute, the system will select the first suitable one listed based on the foregoing criteria.

The route order may have an impact on the request/call processing logic.

Sample configurationSample configuration

Below you can see a sample Gateway and HTTPRoute resource configuration describing a load balancer that receives HTTPS requests and routes them to one of two service backends based on their URI paths.

Example
---
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: alb-gwapi-gw
spec:
  gatewayClassName: yc-df-class
  listeners:
    - name: alb-gwapi-listener
      protocol: HTTPS
      port: 443
      hostname: <domain_name>
      allowedRoutes:
        namespaces:
          from: Selector
          selector:
            matchLabels:
              gatewayName: alb-gwapi-gw
      tls:
        certificateRefs:
          - kind: Secret
            group: ""
            name: alb-gwapi-cert
            namespace: alb-gwapi-ns
---
apiVersion: v1
kind: Namespace
metadata:
  name: alb-gwapi-apps-ns
  labels:
    gatewayName: alb-gwapi-gw

---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: alb-gwapi-route
  namespace: alb-gwapi-apps-ns
spec:
  hostnames:
    - "<domain_name>"
  parentRefs:
    - name: alb-gwapi-gw
      namespace: default
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /app1
      backendRefs:
        - name: alb-demo-1
          port: 80
    - matches:
        - path:
            type: PathPrefix
            value: /app2
      backendRefs:
        - name: alb-demo-2
          port: 80
    - backendRefs: # Default match (implicit "/" path prefix)
        - name: alb-demo-2
          port: 80

Installation and requirementsInstallation and requirements

To install the Gateway API, you need:

  • Managed Service for Kubernetes cluster.
  • Cluster node group.
  • Cluster namespace to store your service account key.

To learn how to install the Gateway API, see this guide.

See alsoSee also

  • Security group configuration for a Kubernetes cluster and a load balancer.
  • Service account to support controller operation.
  • Gateway API in Yandex Cloud Marketplace.

Was the article helpful?

Previous
Ingress service
Next
Installing the Gateway API
© 2025 Direct Cursus Technology L.L.C.