How the Application Load Balancer ingress controller works

An Application Load Balancer ingress controller for Managed Service for Kubernetes is running two pods:

• The leader pod, i.e., yc-alb-ingress-controller-*, manages Application Load Balancer resource creation and updates. You can use its logs to monitor resource operations.

• The health check pod, i.e., yc-alb-ingress-controller-hc-*, runs a container listening on TCP port 10501 for L7 load balancer health check requests and performing health checks on kube-proxy pods across all cluster nodes. 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.

  This is the default health check workflow used by the Application Load Balancer ingress controller. You can configure custom health checks to monitor your applications across all pods.

The leader pod manages the Application Load Balancer resource architecture according to these rules:

• Based on Ingress configurations, the system creates load balancers and HTTP routers receving and distributing incoming traffic across backend groups.

  Ingress resources with the same ingress.alb.yc.io/group-name annotations are consolidated into one load balancer.

  • To enable HTTPS traffic on the load balancer, specify your service domain names and Certificate Manager certificate IDs in the Ingress spec.tls field:

    spec:
      tls:
        - hosts:
            - <domain_name>
          secretName: yc-certmgr-cert-id-<certificate_ID>
    

    Where secretName refers to the Yandex Certificate Manager certificate.

    When this field is configured, the system will create two types of load balancer listeners: HTTPS listeners to serve encrypted traffic on port 443, and HTTP listeners responding to requests on port 80 with a 301 Moved Permanently status code redirecting clients to the HTTPS endpoint. If multiple Ingress rules apply to the same domain, rules without spec.tls, i.e., HTTP-only, will take priority over HTTP-to-HTTPS redirects.

    If the certificate is not available in Certificate Manager, provide it through a Kubernetes secret by specifying its name in the secretName field. Application Load Balancer Ingress controller will automatically add this certificate to Certificate Manager.

  • If the spec.tls field is omitted in the Ingress description, the system will only create HTTP listeners processing unencrypted traffic on port 80.

  • If no traffic distribution rules are specified in the Ingress description, incoming requests will be routed to the default backend.

• To process incoming traffic, you can create backend groups using the following methods:

  • Specify relevant Kubernetes services directly in Ingress rules. Use this method for routing traffic to backend groups containing only one service.

    Pre-0.2.0 ALB Ingress Controller versions map each backend group to a distinct combination of host, http.paths.path, and http.paths.pathType values specified in an Ingress rule. ALB Ingress Controllers version 0.2.0 and later map backend groups directly to the backend.service configuration. This may cause collisions when upgrading the ALB Ingress Controller. To avoid them, check the upgrade restrictions for your infrastructure.

  • Describe your backend groups using HttpBackendGroup resources. These custom resources are defined in the alb.yc.io API group provided by an ingress controller.

    The same as services, you must specify your HttpBackendGroup resources in the Ingress rules, i.e., spec.rules[*].http.paths[*].backend.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.

  • Describe your backend groups using GrpcBackendGroup resources. These custom resources are defined in the alb.yc.io API group provided by an ingress controller.

    The same as services, you must specify your GrpcBackendGroup resources in the Ingress rules, i.e., spec.rules[*].http.paths[*].backend.resource.

• The system will deploy backend services specified in the Ingress or HttpBackendGroup/GrpcBackendGroup resources. You can configure them through Service resources.

  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.

Application Load Balancer-to-Kubernetes resource mappingApplication Load Balancer-to-Kubernetes resource mapping

Load balancer resource IDs within a Kubernetes clusterLoad balancer resource IDs within a Kubernetes cluster

For an Application Load Balancer load balancer deployed according to the Ingress configuration, its resource IDs are specified in the custom Managed Service for Kubernetes cluster resource, IngressGroupStatus. To see them, do the following: