Application Load Balancer Ingress controller operating principles

A Application Load Balancer Ingress controller for Managed Service for Kubernetes owns two pods:

• The primary yc-alb-ingress-controller-* pod handles Application Load Balancer resource creation and updates. You can track communication with resources through this pod's logs.
• A status check pod called yc-alb-ingress-controller-hc-* deploys containers on backend nodes to accept test requests on TCP port 10501.

The primary pod manages the Application Load Balancer resource architecture using the following principles:

• Load balancers and HTTP routers to accept and distribute traffic to backend groups are created based on Ingress resources. All the Ingress fields utilized by the controller are described in the reference.

  If several Ingress resources have the same ingress.alb.yc.io/group-name annotation values, they are combined in a single load balancer.

  • For a load balancer to be able to accept HTTPS traffic, the spec.tls field in the Ingress description must contain the domain names and the certificate IDs from Certificate Manager:

    spec:
      tls:
        - hosts:
            - <domain name>
          secretName: yc-certmgr-cert-id-<certificate ID from Certificate Manager>
    

    This will create two types of listeners for the load balancer: one will accept HTTPS traffic on port 443 while the other will redirect HTTP requests (port 80) to HTTPS with the 301 Moved Permanently status code. The traffic distribution rules for the same domain names that are explicitly specified in other Ingress resources lacking the spec.tls field, will be given priority with respect to HTTP-to-HTTPS redirects.

    Warning

    The secretName field only supports references to certificates from Certificate Manager as yc-certmgr-cert-id-<certificate ID>. Do not enter Kubernetes internal secrets in this field.

  • If an Ingress description lacks the spec.tls field, a load balancer will only have listeners to receive HTTP traffic on port 80.

• You can create backend groups to process incoming traffic:

  • Based on Kubernetes services referenced in Ingress rules directly (spec.rules[*].http.paths[*].backend.service). This method is useful if you need to bind a simple backend group consisting of a single service to a route.

  • Based on HttpBackendGroup resources that support explicit backend group descriptions. These are custom resources from the API alb.yc.io group exposed by an Ingress controller. All the HttpBackendGroup fields are described in the reference.

    You need to refer to HttpBackendGroupin Ingress rules same as to services (spec.rules[*].http.paths[*].backend.resource).

    Using HttpBackendGroup makes extended Application Load Balancer functionality available. A group like this may have Kubernetes services or Object Storage buckets as backends. In HttpBackendGroup, you can also specify relative backend weight to allocate traffic to them proportionately.

• Services referenced in Ingress or in HttpBackendGroup are deployed to backends. These can be configured using Service resources. All the Service fields utilized by the controller are described in the reference.

  Warning

  The Kubernetes services used as backends (as specified in the Ingress rules directly or in HttpBackendGroup), must be of NodePort type. For more details on this type, please see the Kubernetes documentation.

Mapping between Application Load Balancer and Kubernetes resourcesMapping between Application Load Balancer and Kubernetes resources