Rule is a Custom Resource(CR) that defines how incoming requests are matched and processed by the ALB.
Ingresses handled by ALB can be auto translated to rules.
Here is a demo rule to give you a quick first impression of how to use rules.
rule must be attached to a frontend and alb via label.
Frontend
to which this rule belongs.DSLX is a domain-specific language used to describe the matching criteria. For example, the rule below matches a request that satisfies all the following criteria:
Priority is an integer ranging from 0 to 10, where lower values indicate higher priority. To configure the priority of a rule in ingress, you can use the following annotation format:
For rules, simply set the priority directly in .spec.priority
using an integer value.
After a request matches a rule, you can apply the following actions to the request
Feature | Description | Link |
---|---|---|
Timeout | Configures the timeout settings for requests. | timeout |
Redirect | Redirects incoming requests to a specified URL. | redirect |
CORS | Enables Cross-Origin Resource Sharing (CORS) for the application. | cors |
Header Modification | Allows modification of request or response headers. | header modification |
URL Rewrite | Rewrites the URL of incoming requests before forwarding them. | url-rewrite |
WAF | Integrates Web Application Firewall (WAF) for enhanced security. | waf |
OTEL | Enables OpenTelemetry (OTEL) for distributed tracing and monitoring. | otel |
Keepalive | Enables or disables the keepalive feature for the application. | keepalive |
By default, the backend protocol is set to HTTP. If you want to use TLS re-encryption, you can configure it as HTTPS.
You can configure one or more services within a rule.
By default, the ALB uses a round-robin (RR) algorithm to distribute requests among backend services. However, you can assign weights to individual services or choose a different load balancing algorithm.
For more details, refer to Balance Algorithm.
Each input item on the webui corresponds to a field of the CR
If the frontend protocol (ft) is HTTPS or GRPCS, the rule can also be configured to use HTTPS. You can specify the certificate either in the rule or in the ingress to match the certificate for that specific port.
Termination is supported, and re-encryption is possible if the backend protocol is HTTPS. However, you cannot specify a certificate for communication with the backend service.
Certificates can be referenced across namespaces via annotation.
In .spec.certificate_name
, the format is $secret_namespace/$secret_name
In edge mode, the client communicates with the ALB using HTTPS, and ALB communicates with backend services using HTTP protocol. To achieve this:
.spec.certificate_name
In re-encrypt mode, the client communicates with the ALB using HTTPS, and ALB communicates with backend services using HTTPS protocol. To achieve this:
.spec.certificate_name
Each ALB creates an IngressClass with the same name and handles ingresses within the same project.
When an ingress namespace has a label like cpaas.io/project: demo
, it indicates that the ingress belongs to the demo
project.
ALBs that have the project name demo
in their .spec.config.projects
configuration will automatically translate these ingresses into rules.
ALB listens to ingress and automatically creates a Frontend
or Rule. source
field is defined as follows:
spec.source.type
currently only supports ingress
.spec.source.name
is ingress name.spec.source.namespace
is ingress namespace.For ingresses that do not have certificates configured, ALB provides a strategy to use a default certificate.
You can configure the ALB custom resource with the following settings:
.spec.config.defaultSSLStrategy
: Defines the SSL strategy for ingresses without certificates.spec.config.defaultSSLCert
: Sets the default certificate in the format $secret_ns/$secret_name
Available SSL strategies: