Yandex Cloud
Search
Contact UsTry it for free
  • Customer Stories
  • Documentation
  • Blog
  • All Services
  • System Status
  • Marketplace
    • Featured
    • Infrastructure & Network
    • Data Platform
    • AI for business
    • Security
    • DevOps tools
    • Serverless
    • Monitoring & Resources
  • 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
    • Price calculator
    • Pricing plans
  • Customer Stories
  • Documentation
  • Blog
© 2026 Direct Cursus Technology L.L.C.
Yandex Application Load Balancer
  • Getting started
    • Overview
      • Overview
      • How it works
      • Installing an ingress controller
      • Upgrading an ingress controller
        • Ingress
        • HttpBackendGroup
        • GrpcBackendGroup
        • IngressClass
        • Ingress service
    • 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:

  • Service
  • ObjectMeta
  • Annotations (metadata.annotations)
  • ServiceSpec
  • ServicePort
  1. Tools for Managed Service for Kubernetes
  2. Ingress controller
  3. Resource configuration
  4. Ingress service

Fields and annotations of the Service resource for the Ingress controller

Written by
Yandex Cloud
Updated at January 26, 2026
  • Service
  • ObjectMeta
    • Annotations (metadata.annotations)
  • ServiceSpec
  • ServicePort

The Service resource represents a Kubernetes service. For the Ingress controller, Application Load Balancer services are backends across which incoming traffic is distributed within a Managed Service for Kubernetes cluster. Services operating as Application Load Balancer backends may be specified in the Ingress resource either directly or as part of HttpBackendGroup groups.

Tip

We recommend using the new Yandex Cloud Gwin controller instead of an ALB Ingress controller and Gateway API.

Service is a standard Kubernetes resource. Below, we describe its fields and annotations used by the Application Load Balancer tools for Managed Service for Kubernetes. For resource configuration details, see this Kubernetes guide.

ServiceService

apiVersion: v1
kind: Service
metadata: <ObjectMeta>
spec: <ServiceSpec>

Field

Value / Type

Description

apiVersion

v1

This is a required field.

Kubernetes API version.

kind

Service

Resource type.

metadata

ObjectMeta

This is a required field.

Resource metadata.

spec

ServiceSpec

This is a required field.

Resource specification.

Example
apiVersion: v1
kind: Service
metadata:
  name: alb-demo-1
spec:
  selector:
    app: alb-demo-1
  type: NodePort
  ports:
    - name: http
      port: 80
      protocol: TCP
      nodePort: 30081

ObjectMetaObjectMeta

name: <string>
annotations:
  ingress.alb.yc.io/protocol: <string>
  ingress.alb.yc.io/transport-security: <string>
  ingress.alb.yc.io/health-checks: <string>

Field

Value / Type

Description

name

string

This is a required field.

Resource name.

This name is not the balancer name in Application Load Balancer.

annotations

map[string]string

This is a required field.

Resource annotations.

Annotations (metadata.annotations)Annotations (metadata.annotations)

Annotations are collections of key:value pairs for assigning metadata to objects. Annotation values have the string data type. For more information on annotations, see this Kubernetes guide.

In Application Load Balancer, annotations are only used in Service resources to set up ingress controllers.

You can add the following annotations to ObjectMeta:

  • ingress.alb.yc.io/protocol

    Protocol for connections between the load balancer and backends defined in Ingress:

    • http: HTTP/1.1. This is a default value.
    • http2: HTTP/2.
    • grpc: gRPC.
  • ingress.alb.yc.io/transport-security

    Encryption protocol for connections between the load balancer and backends specified in Ingress directly, without using HttpBackendGroup.

    The acceptable value is tls: TLS without certificate validation.

    If this annotation is not specified, the load balancer will connect to the backends without encryption.

    This annotation is ignored for grouped backends. When encrypting a connection between a load balancer and grouped backends, configure the encryption via the spec.backend.tls field of the HttpBackendGroup resource (see the resource configuration).

  • ingress.alb.yc.io/health-checks

    Parameters for configuring custom application health checks in a cluster. We recommend configuring health checks for all backends.

    • http-path: Path to the application endpoint in the request URI for health checks (only for http or http2 connections to backends). The default value is /healthz.

    • grpc-service-name: Application gRPC service name for health checks (only for grpc connections to backends). If not specified, the entire backend will be health-checked.

    • port: Port on the cluster nodes used to check the application's availability. The application will be available for health checks at http://<node_IP_address>:<port>/<path>.

    • healthy-threshold: Number of consecutive successful checks to consider the application endpoint healthy. The default value is 1.

    • unhealthy-threshold: Number of consecutive failed checks to consider the application endpoint unhealthy. The default value is 1.

    • timeout: Response timeout in seconds. The values range from 1s to 60s. The default value is 2s.

    • interval: Interval between health check requests in seconds. The values range from 1s to 60s. The default value is 5s. interval must exceed timeout by at least one second.

    port is a required parameter. If you omit the other parameters, they will be set to their default values.

    The parameters are given as a comma-separated list. Here is an example:

    ...
    annotations:
      ingress.alb.yc.io/health-checks: port=30103,http-path=/health-1,timeout=10s,interval=20s,healthy-threshold=3,unhealthy-threshold=2
    ...
    

ServiceSpecServiceSpec

type: NodePort
ports:
  - <ServicePort>
  -

Field

Value / Type

Description

type

NodePort

This is a required field.

Service type.

Warning

Kubernetes backend services referenced in Ingress rules (directly or via HttpBackendGroup/GrpcBackendGroup), must be of type NodePort. For more information about this type, see the relevant Kubernetes article.

ports

[]ServicePort

This is a required field.

List of ports the service is available on.

ServicePortServicePort

port: <int32>
name: <string>
protocol: <protocol>
nodePort: <int32>

Field

Value / Type

Description

port

int32

This is a required field.
Number of the port the service is available on.

You can use this number if you designate a service as a backend:

  • In Ingress, in the spec.rules.http.paths.backend.service.port.number field (see the configuration).
  • In HttpBackendGroup, in the spec.backends.service.port.number field (see the configuration).

name

string

Service port name.

You can use this name if you designate a service as a backend:

  • In Ingress, in the spec.rules.http.paths.backend.service.port.name field (see the configuration).
  • In HttpBackendGroup, in the spec.backends.service.port.name field (see the configuration).

protocol

TCP

Port network protocol; TCP only.

nodePort

int32

Number of the port opened on the cluster nodes where the service is deployed. The load balancer routes traffic to this port, and Kubernetes forwards the traffic to the service on its port in the port parameter.

The value matches the backend port in the Application Load Balancer backend group.

Was the article helpful?

Previous
IngressClass
Next
Overview
© 2026 Direct Cursus Technology L.L.C.