[Yandex Cloud documentation](../../../index.md) > [Yandex Managed Service for Kubernetes](../../index.md) > [Application Load Balancer tools](../index.md) > [Ingress controller](index.md) > How it works

# How the Application Load Balancer ingress controller works

{% note tip %}

We recommend using the new [Yandex Cloud Gwin](../gwin-index.md) controller instead of an ALB Ingress controller and Gateway API.

{% endnote %}

An [Application Load Balancer ingress controller for Managed Service for Kubernetes](index.md) is running two [pods](../../concepts/index.md#pod):

* 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](../../../application-load-balancer/concepts/backend-group.md#health-checks) 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](https://kubernetes.io/docs/reference/command-line-tools-reference/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](../../tutorials/custom-health-checks.md) to monitor your applications across all pods.

{% note warning %}

Do not manually update Application Load Balancer resources created by the controller's leader pod. The system will automatically revert any manual modifications. Use the standard Managed Service for Kubernetes cluster management methods instead.

{% endnote %}

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

* Based on [Ingress](../ingress.md) 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:

    ```yaml
    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](../ingress.md#default-backend).

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

  * Specify relevant Kubernetes services directly in `Ingress` [rules](../ingress.md#rule). Use this method for routing traffic to backend groups containing only one service.

    Pre-0.2.0 [ALB Ingress Controller](https://yandex.cloud/en/marketplace/products/yc/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 controller. To avoid them, check the [upgrade restrictions](../../operations/applications/upgrade-alb-ingress-controller.md) for your infrastructure.

  * Describe your backend groups using [HttpBackendGroup](../http-backend-group.md) resources. These [custom resources](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/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](../../../storage/concepts/bucket.md). `HttpBackendGroup` allows you to distribute traffic across backends proportionally using relative weights.

  * Describe your backend groups using [GrpcBackendGroup](../grpc-backend-group.md) resources. These [custom resources](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/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](../service-for-ingress.md) resources.

  {% note warning %}
  
  Kubernetes backend services referenced in `Ingress` rules (directly or via `HttpBackendGroup`/`GrpcBackendGroup`), must be of type `NodePort`. For more on this type, see [this Kubernetes guide](https://kubernetes.io/docs/concepts/services-networking/service/#type-nodeport).
  
  {% endnote %}

## Application Load Balancer-to-Kubernetes resource mapping {#mapping}

| Application Load Balancer | Kubernetes |
| ----- | ----- |
| [Load balancer](../../../application-load-balancer/concepts/application-load-balancer.md) | [Ingress](../ingress.md) resources with the same `ingress.alb.yc.io/group-name` annotations |
| HTTP router [virtual hosts](../../../application-load-balancer/concepts/http-router.md#virtual-host) | `Ingress.spec.rules` |
| Virtual host [routes](../../../application-load-balancer/concepts/http-router.md#routes) | `Ingress.spec.rules[*].http.paths` |
| [Backend group](../../../application-load-balancer/concepts/backend-group.md) | [HttpBackendGroup](../http-backend-group.md)/[GrpcBackendGroup](../grpc-backend-group.md) or [services](../service-for-ingress.md) |
| [Target group](../../../application-load-balancer/concepts/target-group.md) | Cluster [node group](../../concepts/index.md#node-group) |

## Load balancer resource IDs within a Kubernetes cluster {#alb-ids}

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:

{% list tabs group=instructions %}

- Management console {#console}

  1. In the [management console](https://console.yandex.cloud), select the folder where you created the required Managed Service for Kubernetes cluster.
  1. In the list of services, select **Managed Service for&nbsp;Kubernetes**.
  1. Select the Managed Service for Kubernetes cluster whose `Ingress` configuration was used to create the load balancer.
  1. On the Managed Service for Kubernetes cluster page, navigate to the ![shapes-3](../../../_assets/console-icons/shapes-3.svg) **Custom resources** tab.
  1. Select `ingressgroupstatuses.alb.yc.io` and navigate to the **Resources** tab.
  1. Select a resource that has its `Ingress` resource group name specified in the `ingress.alb.yc.io/group-name` annotation and navigate to the **YAML** tab.

- kubectl CLI {#kubectl}

  1. [Install kubect](https://kubernetes.io/docs/tasks/tools/install-kubectl) and [configure it to work with the new cluster](../../operations/connect/index.md#kubectl-connect).
  1. Run this command:

      ```bash
      kubectl describe IngressGroupStatus
      ```

{% endlist %}