Application Load Balancer Ingress controller operating principles
- 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.
Do not manually update Application Load Balancer resources created by the controller's primary pod. Any changes you make will be rolled back automatically. Use the standard Managed Service for Kubernetes cluster control methods instead.
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
Ingressresources. All the
Ingressfields utilized by the controller are described in the reference.
Ingressresources have the same
ingress.alb.yc.io/group-nameannotation values, they are combined in a single load balancer.
For a load balancer to be able to accept HTTPS traffic, the
spec.tlsfield in the
Ingressdescription 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 Permanentlystatus code. The traffic distribution rules for the same domain names that are explicitly specified in other
Ingressresources lacking the
spec.tlsfield, will be given priority with respect to HTTP-to-HTTPS redirects.
secretNamefield only supports references to certificates from Certificate Manager as
yc-certmgr-cert-id-<certificate ID>. Do not enter Kubernetes internal secrets in this field.
Ingressdescription lacks the
spec.tlsfield, 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
Ingressrules 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.
HttpBackendGroupresources that support explicit backend group descriptions. These are custom resources from the API
alb.yc.iogroup exposed by an Ingress controller. All the
HttpBackendGroupfields are described in the reference.
You need to refer to
Ingressrules same as to services (
HttpBackendGroupmakes extended Application Load Balancer functionality available. A group like this may have Kubernetes services or Yandex Object Storage buckets as backends. In
HttpBackendGroup, you can also specify relative backend weight to allocate traffic to them proportionately.
Services referenced in
HttpBackendGroupare deployed to backends. These can be configured using
Serviceresources. All the
Servicefields utilized by the controller are described in the reference.
The Kubernetes services used as backends (as specified in the
Ingressrules directly or in
HttpBackendGroup), must be of
NodePorttype. For more details on this type, please see the Kubernetes documentation.
Mapping between Application Load Balancer and Kubernetes resources
|Application Load Balancer||Kubernetes|
|HTTP router virtual hosts||
|Virtual host routes||
|Target group||Cluster node group|
IDs of load balancer resources in a Kubernetes cluster
IDs of resources of an Application Load Balancer load balancer deployed in the
Ingress configuration are specified in the custom
IngressGroupStatus resource of the Managed Service for Kubernetes cluster. To view them:
- In the management console, select the folder where the required Managed Service for Kubernetes cluster was created.
- In the list of services, select Managed Service for Kubernetes.
- Select the Managed Service for Kubernetes cluster whose
Ingressconfiguration was used to create a load balancer.
- On the Managed Service for Kubernetes cluster page, go to the Custom resources tab.
ingressgroupstatuses.alb.yc.ioand open the Resources tab.
- Select a resource with the
Ingressresource group name specified in the
ingress.alb.yc.io/group-nameannotation and go to the YAML tab.