ALB Ingress supports custom forwarding rules. A forwarding rule consists of forwarding conditions and forwarding actions. You can define custom forwarding conditions based on the domain name, path, request header, query string, request method, cookie, or source IP of a request. You can also define custom forwarding actions, such as returning a fixed response, creating a redirection, inserting or deleting a request header, mirroring traffic, forwarding requests to multiple backend server groups, or rewriting requests. You can configure these custom forwarding rules in the console or by adding annotations to an Ingress resource.
Scenario index
Prerequisites
The ALB Ingress Controller component is installed. The component version must be v2.5.0 or later. For more information, see Manage components.
Forwarding conditions
A forwarding rule can have a maximum of 10 conditions.
The `ResponseHeader` and `ResponseStatusCode` forwarding conditions are valid only for custom response forwarding rules.
Introduction to forwarding conditions
You can configure forwarding conditions in the alb.ingress.kubernetes.io/conditions.<service-name> annotation for an ALB Ingress. Different condition blocks are joined by an AND logical operator. Values within the same condition block are joined by an OR logical operator. For example, if you configure two different `Header` condition blocks, they are joined by an AND logical operator. However, the values specified within a single `Header` condition block are joined by an OR logical operator. The following table describes the forwarding conditions.
Forwarding condition | Description |
Domain name | Matches the request domain name. Only requests with a matching domain name can access the service. The following code provides an example.
|
Path | Matches the request path. Only requests with a matching path can access the service. The following code provides an example.
|
Header | Matches the request header. Only requests with a matching header can access the service. The following code provides an example.
|
Query string | Matches the query string. Only requests that contain a matching query string can access the service. The following code provides an example.
|
Request method | Matches the request method. Only requests with a matching method can access the service. The following code provides an example.
|
Cookie | Matches the cookie. Only requests that contain a matching cookie can access the service. The following code provides an example.
|
Source IP | Matches the source IP address of the request. Only requests from a matching source IP address can access the service. The following code provides an example.
|
ResponseHeader | Matches the response header. The forwarding action is performed only on responses that carry a matching header. Note that this must be used with a response forwarding action and the
|
ResponseStatusCode | Matches the response status code. Only responses that return a matching status code can access the service. Note that this must be used with a response forwarding action and the
|
Scenario 1: Distribute traffic based on source IP and header
You can specify a maximum of five source IP addresses for the custom conditions of a forwarding rule.
The following code block defines a rule that forwards traffic to the target only when the request's source IP, header, and path match the configuration.
If the source IP address of a request is in the 192.168.0.0/16 or 172.16.0.0/16 CIDR block, the request header contains gray-hello with a value of value1 or value2, and the request path is /hello, the request is forwarded to the gray-hello-svc service. Otherwise, the request is forwarded to other services.
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
alb.ingress.kubernetes.io/order: "1"
alb.ingress.kubernetes.io/conditions.gray-hello-svc: | # Note: The "gray-hello-svc" in this annotation must match the backend service name configured in spec.rules. The forwarding conditions configured in the annotation apply to the corresponding backend service.
[{
"type": "Header",
"headerConfig": {
"key":"gray-hello",
"values": [
"value1",
"value2"
]
}
},
{
"type": "SourceIp",
"sourceIpConfig": {
"values": [
"192.168.0.0/16",
"172.16.0.0/16"
]
}
}]
name: gray-hello-ingress
spec:
ingressClassName: alb
rules:
- http:
paths:
- path: /hello
pathType: ImplementationSpecific
backend:
service:
name: gray-hello-svc # Note: The backend service name configured here must match "gray-hello-svc" in the custom forwarding condition annotation. The forwarding conditions configured in the annotation apply to this backend service.
port:
number: 88alb.ingress.kubernetes.io/order: Specifies the priority of the Ingress. A smaller number indicates a higher priority.
Scenario 2: Distribute traffic based on domain name, request method, and cookie
The following code block defines a rule that forwards traffic to the target only when the request's domain name, request method, and request cookie match the configuration.
If the request method is GET or HEAD, the request domain name is example.com or *.edu, the request cookie has the key cookiekey1 with the value cookievalue1, and the request path is /test, the request is forwarded to the service-a service. Otherwise, the request is forwarded to the service-b service.
Forwarding rules based on domain names support wildcard domain names.
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
alb.ingress.kubernetes.io/conditions.service-a: | # Note: The "service-a" in this annotation must match the backend service name configured in spec.rules. The forwarding conditions configured in the annotation apply to the corresponding backend service.
[{
"type": "Cookie",
"cookieConfig": {
"values": [
{
"key":"cookiekey1",
"value":"cookievalue1"
}
]
}
},
{
"type": "Method",
"methodConfig": {
"values": [
"GET",
"HEAD"
]
}
},
{
"type": "Host",
"hostConfig": {
"values": [
"example.com",
"*.edu"
]
}
}]
name: ingress-example
spec:
ingressClassName: alb
rules:
- http:
paths:
- path: /test
pathType: ImplementationSpecific
backend:
service:
name: service-a # Note: The backend service name configured here must match "service-a" in the custom forwarding condition annotation. The forwarding conditions configured in the annotation apply to this backend service.
port:
number: 88
- path: /test
pathType: ImplementationSpecific
backend:
service:
name: service-b
port:
number: 88Scenario 3: Distribute traffic based on a query string, multiple headers, and multiple paths
The following code block defines a rule that forwards traffic to the target only when the request's query string, headers, and path match the configuration.
If the request path is /pathvalue1, /pathvalue2, or /test, the query string has the key querystringkey1 with the value querystringvalue2, the request header contains both the headerkey1 and headerkey2 headers, the headerkey1 header has a value of headervalue1 or headervalue2, and the headerkey2 header has a value of headervalue3 or headervalue4, the request is forwarded to the service-a service. Otherwise, the request is forwarded to the service-b service.
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
alb.ingress.kubernetes.io/conditions.service-a: | # Note: The "service-a" in this annotation must match the backend service name configured in spec.rules. The forwarding conditions configured in the annotation apply to the corresponding backend service.
[{
"type": "Path",
"pathConfig": {
"values": [
"/pathvalue1",
"/pathvalue2"
]
}
},
{
"type": "QueryString",
"queryStringConfig": {
"values": [
{
"key":"querystringkey1",
"value":"querystringvalue2"
}
]
}
},
{
"type": "Header",
"headerConfig": {
"key":"headerkey1",
"values": [
"headervalue1",
"headervalue2"
]
}
},
{
"type": "Header",
"headerConfig": {
"key":"headerkey2",
"values": [
"headervalue3",
"headervalue4"
]
}
}]
name: ingress-example
spec:
ingressClassName: alb
rules:
- http:
paths:
- path: /test
pathType: ImplementationSpecific
backend:
service:
name: service-a # Note: The backend service name configured here must match "service-a" in the custom forwarding condition annotation. The forwarding conditions configured in the annotation apply to this backend service.
port:
number: 88
- path: /test
pathType: ImplementationSpecific
backend:
service:
name: service-b
port:
number: 88Forwarding actions
Introduction to forwarding actions
You can configure forwarding actions for requests and responses using the alb.ingress.kubernetes.io/actions.<service-name> annotation. Supported actions include returning a fixed response, creating a redirection, inserting or deleting a request header, traffic mirroring, forwarding requests to multiple backend server groups, and rewriting requests.
For the
alb.ingress.kubernetes.io/actions.<service-name>annotation, make sure that the service name in the annotation matches the service name underbackendin therulefield.In the same forwarding rule, you can use only one terminal forwarding action, such as redirection, a fixed response, or forwarding to multiple server groups.
When you configure redirection, a fixed response, or forwarding to multiple server groups, you must set
backend.service.port.nametouse-annotation.
Request forwarding actions
Forwarding action | Description |
Fixed response | Returns a fixed response to the client through the ALB. You can set the response status code, content, and content type. The following code provides an example.
|
Redirection | Uses an HTTP 3xx status code to direct the client to another address to access the service. The following code provides an example. Important Except for httpCode, other redirection parameters cannot all be set to their default values.
|
Traffic mirroring | Sets the ID of the server group for traffic mirroring. This copies the request and forwards it to the traffic mirroring server group. The following code provides an example. Important
|
Forward to multiple backend server groups | Forwards ALB requests to multiple backend server groups. You can specify the backend server groups using ServerGroupID, or create or attach server groups using ServiceName+ServicePort. You can set the weight for request forwarding to each backend server group and enable session persistence between server groups. Important
|
Rewrite | Enables the rewrite feature for the ALB, which overwrites the request's domain name, path, and query string. The following code provides an example. Important
For more information about rewrite rules, see Support for rewrite. |
Insert request header | Sets the header field name and content. This overwrites any existing header variables in the request. The following code provides an example.
|
Remove request header | Removes the header field name and content. The following code provides an example. type: The type of forwarding action. Set this to RemoveHeader to configure removing a request header. key: The field name of the request header. |
QPS throttling | When setting forwarding rules for an ALB, you can configure both an overall request rate limit and a request rate limit based on the client source IP. The following code provides a configuration example: Important
|
Response forwarding actions
Forwarding action | Description |
Insert request header | Sets the header field name and content. This overwrites any existing header variables in the request. The following code provides an example.
|
Remove request header | Removes the header field name and content. The following code provides an example. type: The type of forwarding action. Set this to key: The field name of the request header. |
Scenario 1: Set a fixed response with a 503 status code and content
Console
Log on to the ACK console. In the left navigation pane, click Clusters.
On the Clusters page, find the cluster you want and click its name. In the left-side pane, choose .
On the Ingresses page, click Create Ingress. In the Create Ingress dialog box, configure the Ingress.
Configuration item
Description
Example
Gateway Type
You can select ALB Ingress, MSE Ingress, or Nginx Ingress.
For more information about the differences between these gateway types, see Comparison of Nginx Ingresses, ALB Ingresses, and MSE Ingresses.
ALB
Name
The custom name of the Ingress.
ingress
Ingress Class
Specify the class of the Ingress that is associated with the AlbConfig.
alb
Rules
Click + Add Rule to add an Ingress rule.
Domain Name: Specify a custom domain name.
Mappings: Configure the following parameters:
Path: Specify the URL path of the backend Service.
Rule:
Prefix (Prefix-based Match): matches the prefix of the requested URL path.
Exact (Exact Match): exactly matches the requested URL path.
ImplementationSpecific (Default Value): depends on the logic implemented by the ALB Ingress controller.
For more information, see Forward requests based on URL paths.
Service: Select the backend Service.
Port: Specify the Service port that you want to expose.
You can configure multiple paths for a domain name. Click + Add to add a path.
Domain Name: Leave empty
Mappings:
Path: /
Rule: ImplementationSpecific (Prefix)
Service: response-503
Port: 80
Custom Forwarding Rules
Enable custom forwarding rules to manage inbound traffic with fine-grained control.
NoteA forwarding rule can have a maximum of 10 conditions.
From the Add Condition drop-down list, select one of the following:
Host:
Matches the request domain name. If you specify multiple domain names, they have an OR relationship. After setting this, the
alb.ingress.kubernetes.io/conditions.host-exampleannotation is added.Path:
Matches the request path. If you specify multiple paths, they have an OR relationship. After setting this, the
alb.ingress.kubernetes.io/conditions.path-exampleannotation is added.HTTP Header:
Matches the request header information in a key-value pair format. For example, Key:
headernameand Value:headervalue1. If you specify multiple header values, they have an OR relationship. After setting this, thealb.ingress.kubernetes.io/conditions.http-header-exampleannotation is added.
From the Action drop-down list, select the following:
Return Fixed Response
Returns a fixed response to the client through the ALB. You can set the response status code, content, and content type. Configure Response Status Code, Response Content Type (Optional), and Response Content (Optional) as needed.
Response Content Type:
text/plain: Plain text content type.
text/css: Indicates CSS content.
text/html: HTML content type.
application/javascript: JavaScript content type.
application/json: JSON content type.
Condition: Select Path. (Keep the default)
Action: Return Fixed Response
Response Status Code: 503
Response Content Type (Optional): text/plain
Response Content (Optional): error
Keep the default values for other configurations.
After the configuration is complete, click OK.
kubectl
The following code block shows an example of how to return a 503 status code and the text 503 error text when a request is made to the service.
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
namespace: default
name: ingress
annotations:
alb.ingress.kubernetes.io/actions.service-name: | # Note: The "service-name" in this annotation must match the backend service name configured in spec.rules. The forwarding action configured in the annotation applies to the corresponding backend service.
[{
"type": "FixedResponse",
"FixedResponseConfig": {
"contentType": "text/plain",
"httpCode": "503",
"content": "503 error text"
}
}]
spec:
ingressClassName: alb
rules:
- http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: service-name # Note: The backend service name configured here must match "service-name" in the custom forwarding action annotation alb.ingress.kubernetes.io/actions.service-name. The forwarding action configured in the annotation applies to this backend service.
port:
name: use-annotation # The name of the servicePort must be use-annotation.Scenario 2: Use an HTTP 301 status code to redirect to an HTTPS port
The following code block shows an example of how to redirect a request to the service's HTTPS port.
Redirection
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
namespace: default
name: ingress
annotations:
alb.ingress.kubernetes.io/actions.redirect: | # Note: The "redirect" in this annotation must match the backend service name configured in spec.rules. The forwarding action configured in the annotation applies to the corresponding backend service.
[{
"type": "Redirect",
"RedirectConfig": {
"host": "${host}",
"path": "${path}",
"port": "443",
"protocol": "https",
"query": "${query}",
"httpCode": "301"
}
}]
spec:
ingressClassName: alb
rules:
- http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: redirect # Note: The backend service name configured here must match "redirect" in the custom forwarding action annotation alb.ingress.kubernetes.io/actions.redirect. The forwarding action configured in the annotation applies to this backend service.
port:
name: use-annotation # The name of the servicePort must be use-annotation.Multiple redirections
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
namespace: default
name: ingress
annotations:
alb.ingress.kubernetes.io/actions.redirect-1: |
[{
"type": "Redirect",
"RedirectConfig": {
"host": "${host}",
"path": "${path}",
"port": "443",
"protocol": "https",
"query": "${query}",
"httpCode": "301"
}
}]
alb.ingress.kubernetes.io/actions.redirect-2: |
[{
"type": "Redirect",
"RedirectConfig": {
"host": "${host}",
"path": "${path}",
"port": "443",
"protocol": "https",
"httpCode": "301"
}
}]
spec:
ingressClassName: alb
rules:
- http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: redirect
port:
name: use-annotation # The name of the servicePort must be use-annotation.Scenario 3: Insert the source: alibaba request header
The following code block shows an example of how to overwrite the original request header with source: alibaba when a request is made to the service.
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
namespace: default
name: ingress
annotations:
alb.ingress.kubernetes.io/actions.insert-header: | # Note: The "insert-header" in this annotation must match the backend service name configured in spec.rules. The forwarding action configured in the annotation applies to the corresponding backend service.
[{
"type": "InsertHeader",
"InsertHeaderConfig": {
"key": "source",
"value": "alibaba",
"valueType": "UserDefined"
}
}]
spec:
ingressClassName: alb
rules:
- http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: insert-header # Note: The backend service name configured here must match "insert-header" in the custom forwarding action annotation alb.ingress.kubernetes.io/actions.insert-header. The forwarding action configured in the annotation applies to this backend service.
port:
number: 80Scenario 4: Mirror traffic to a server group
The following code block shows an example of how to mirror a request to a traffic mirroring server group.
Log on to the Application Load Balancer (ALB) console. In the navigation pane on the left, choose . On the Server Groups page, obtain the server group ID.
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: traffic-mirror-ingress
annotations:
# mirror-svc must be one of the backend.services entered below.
# ALB Ingress mirrors traffic forwarded to mirror-svc to the backend server specified in "ServerGroupID".
# To configure traffic mirroring for multiple Services, add a separate annotation for each Service.
alb.ingress.kubernetes.io/actions.mirror-svc: | # Note: The "mirror-svc" in this annotation must match the backend service name configured in spec.rules. The forwarding action configured in the annotation applies to the corresponding backend service.
[{
"type": "TrafficMirror",
"TrafficMirrorConfig": {
"TargetType" : "ForwardGroupMirror",
"MirrorGroupConfig": {
"ServerGroupTuples" : [{
"ServerGroupID": "sgp-2auud2fxj1r46*****"
}]
}
}
}]
spec:
ingressClassName: alb
rules:
- host: demo.domain.ingress.top
http:
paths:
- path: /test
pathType: Prefix
backend:
service:
name: mirror-svc # Note: The backend service name configured here must match "mirror-svc" in the custom forwarding action annotation alb.ingress.kubernetes.io/actions.mirror-svc. The forwarding action configured in the annotation applies to this backend service.
port:
number: 80Scenario 5: Forward requests to multiple backend server groups
Console
Log on to the ACK console. In the left navigation pane, click Clusters.
On the Clusters page, find the cluster you want and click its name. In the left-side pane, choose .
On the Ingresses page, click Create Ingress. In the Create Ingress dialog box, configure the Ingress.
Configuration item
Description
Example
Gateway Type
You can select ALB Ingress, MSE Ingress, or Nginx Ingress.
For more information about the differences between these gateway types, see Comparison of Nginx Ingresses, ALB Ingresses, and MSE Ingresses.
Application Load Balancer (ALB)
Name
The custom name of the Ingress.
forward-ingress
Ingress Class
Specify the class of the Ingress that is associated with the AlbConfig.
alb
Rules
Click + Add Rule to add an Ingress rule.
Domain Name: Specify a custom domain name.
Mappings: Configure the following parameters:
Path: Specify the URL path of the backend Service.
Rule:
Prefix (Prefix-based Match): matches the prefix of the requested URL path.
Exact (Exact Match): exactly matches the requested URL path.
ImplementationSpecific (Default Value): depends on the logic implemented by the ALB Ingress controller.
For more information, see Forward requests based on URL paths.
Service: Select the backend Service.
Port: Specify the Service port that you want to expose.
You can configure multiple paths for a domain name. Click + Add to add a path.
Domain Name: demo.domain.ingress.top
Mappings:
Path: /path
Rule: Prefix match (default)
Service: forward
Port: 80
Custom Forwarding Rules
Enable custom forwarding rules to manage inbound traffic with fine-grained control.
NoteA forwarding rule can have a maximum of 10 conditions.
From the Add Condition drop-down list, select one of the following:
Host:
Matches the request domain name. If you specify multiple domain names, they have an OR relationship. After setting this, the
alb.ingress.kubernetes.io/conditions.host-exampleannotation is added.Path:
Matches the request path. If you specify multiple paths, they have an OR relationship. After setting this, the
alb.ingress.kubernetes.io/conditions.path-exampleannotation is added.HTTP Header:
Matches the request header information in a key-value pair format. For example, Key:
headernameand Value:headervalue1. If you specify multiple header values, they have an OR relationship. After setting this, thealb.ingress.kubernetes.io/conditions.http-header-exampleannotation is added.
From the Action drop-down list, select the following:
Forward To
Forwards to multiple backend server groups. In Service Name, select the target service. In Port, select the target port number. Then, configure a custom weight value.
NoteClusterIP services are not supported for clusters with the Flannel network plug-in.
When you select Forward To, you do not need to configure path mapping in the rule.
Condition: Select Domain Name. Domain Name: demo.domain.ingress.top
Action: Forward to
Service Name: tea-svc
Port: 80
Configure weight: 80
Add Service
Service Name: coffee-svc
Port: 80
Configure weight: 20
Keep the default values for other configurations.
After the configuration is complete, click OK.
kubectl
The following code block shows an example of how to forward a request to multiple services within the cluster.
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: forward-ingress
annotations:
# The service in the annotation must exist in the cluster, and its name must match the service name under backend in the rule field.
alb.ingress.kubernetes.io/actions.service-name: | # Note: The "service-name" in this annotation must match the backend service name configured in spec.rules. The forwarding action configured in the annotation applies to the corresponding backend service.
[{
"type": "ForwardGroup",
"ForwardConfig": {
"ServerGroups" : [{
"ServiceName": "tea-svc",
"Weight": 80,
"ServicePort": 80
},
{
"ServiceName": "coffee-svc",
"Weight": 20,
"ServicePort": 80
}]
}
}]
spec:
ingressClassName: alb
rules:
- host: demo.domain.ingress.top
http:
paths:
- path: /path
pathType: Prefix
backend:
service:
name: service-name # Note: The backend service name configured here must match "service-name" in the custom forwarding action annotation alb.ingress.kubernetes.io/actions.service-name. The forwarding action configured in the annotation applies to this backend service.
port:
name: use-annotation # The name of the servicePort must be use-annotation.Scenario 6: Rewrite request configurations
The following code block shows an example of how to rewrite the domain name, path, and query string of a request.
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
namespace: default
name: rewrite-ingress
annotations:
alb.ingress.kubernetes.io/actions.service-name: | # Note: The "service-name" in this annotation must match the backend service name configured in spec.rules. The forwarding action configured in the annotation applies to the corresponding backend service.
[{
"type": "Rewrite",
"RewriteConfig": {
"Host": "demo.domain.ingress.top",
"Path": "/test",
"Query": "querystring"
}
}]
spec:
ingressClassName: alb
rules:
- http:
paths:
- path: /path
pathType: Prefix
backend:
service:
name: service-name # Note: The backend service name configured here must match "service-name" in the custom forwarding action annotation alb.ingress.kubernetes.io/actions.service-name. The forwarding action configured in the annotation applies to this backend service.
port:
number: 80Scenario 7: Modify the request header in the response based on ResponseHeader
By default, custom ALB Ingress forwarding rules apply to requests. To create a forwarding rule for responses, you must set the
alb.ingress.kubernetes.io/rule-direction.<service-name>annotation to Response. The default value is Request.When you create a forwarding rule for responses, you must set
backend.service.port.nametouse-annotation.
The following code block shows an example of how to insert a new request header (source: alibaba) if the ResponseHeader condition is met. The condition is met if the header contains response-hello with a value of value1 or value2.
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
alb.ingress.kubernetes.io/rule-direction.response-header: Response
alb.ingress.kubernetes.io/conditions.response-header: | # Note: The "response-header" in this annotation must match the backend service name configured in spec.rules. The forwarding conditions configured in the annotation apply to the corresponding backend service.
[{
"type": "ResponseHeader",
"responseHeaderConfig": {
"key": "response-hello",
"values": [
"value1",
"value2"
]
}
}]
alb.ingress.kubernetes.io/actions.response-header: | # Note: The "response-header" in this annotation must match the backend service name configured in spec.rules. The forwarding action configured in the annotation applies to the corresponding backend service.
[{
"type": "InsertHeader",
"InsertHeaderConfig": {
"key": "source",
"value": "alibaba",
"valueType": "UserDefined"
}
}]
name: response-header
spec:
ingressClassName: alb
rules:
- http:
paths:
- path: /
pathType: ImplementationSpecific
backend:
service:
name: response-header # Note: The backend service name configured here must match "response-header" in the custom forwarding condition/action annotations. The forwarding conditions/actions configured in the annotations apply to this backend service.
port:
name: use-annotation # The name of the servicePort must be use-annotation.Scenario 8: Modify the request header in the response based on the response status code
By default, custom ALB Ingress forwarding rules apply to requests. To create a forwarding rule for responses, you must set the
alb.ingress.kubernetes.io/rule-direction.<service-name>annotation to Response. The default value is Request.When you create a forwarding rule for responses, you must set
backend.service.port.nametouse-annotation.
The following code block shows an example of how to remove the response-hello header from the request header if the response status code is 200 or 300.
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
alb.ingress.kubernetes.io/rule-direction.response-hello: Response
alb.ingress.kubernetes.io/conditions.response-hello: | # Note: The "response-hello" in this annotation must match the backend service name configured in spec.rules. The forwarding conditions configured in the annotation apply to the corresponding backend service.
[{
"type": "ResponseStatusCode",
"responseStatusCodeConfig": {
"values": [
"200",
"300"
]
}
}]
alb.ingress.kubernetes.io/actions.response-hello: | # Note: The "response-hello" in this annotation must match the backend service name configured in spec.rules. The forwarding action configured in the annotation applies to the corresponding backend service.
[{
"type": "RemoveHeader",
"RemoveHeaderConfig": {
"key": "response-hello"
}
}]
name: response-hello
spec:
ingressClassName: alb
rules:
- http:
paths:
- path: /*
pathType: ImplementationSpecific
backend:
service:
name: response-hello # Note: The backend service name configured here must match "response-hello" in the custom forwarding condition/action annotations. The forwarding conditions/actions configured in the annotations apply to this backend service.
port:
name: use-annotation # The name of the servicePort must be use-annotation.Practice with forwarding conditions and actions
Scenario 1: Forward traffic to a specific service based on domain name conditions and actions
This section describes how to forward traffic to a specific service by configuring domain name-based forwarding conditions and corresponding forwarding actions in the ACK console.
Log on to the ACK console. In the left navigation pane, click Clusters.
On the Clusters page, find the cluster you want and click its name. In the left-side pane, choose .
On the Ingresses page, click Create Ingress. In the Create Ingress dialog box, configure the Ingress.
Configuration item
Description
Example
Gateway Type
You can select ALB Ingress, MSE Ingress, or Nginx Ingress.
For more information about the differences between these gateway types, see Comparison of Nginx Ingresses, ALB Ingresses, and MSE Ingresses.
ALB Ingress
Name
The custom name of the Ingress.
alb_ingress
Ingress Class
Specify the class of the Ingress that is associated with the AlbConfig.
alb
Rules
Click + Add Rule to add an Ingress rule.
Domain Name: Specify a custom domain name.
Mappings: Configure the following parameters:
Path: Specify the URL path of the backend Service.
Rule:
Prefix (Prefix-based Match): matches the prefix of the requested URL path.
Exact (Exact Match): exactly matches the requested URL path.
ImplementationSpecific (Default Value): depends on the logic implemented by the ALB Ingress controller.
For more information, see Forward requests based on URL paths.
Service: Select the backend Service.
Port: Specify the Service port that you want to expose.
You can configure multiple paths for a domain name. Click + Add to add a path.
Domain Name: *.example.com
Mappings:
Path: /tes
Rule: ImplementationSpecific
Service: tea-svc
Port: 80
Custom Forwarding Rules
Enable custom forwarding rules to manage inbound traffic with fine-grained control.
NoteA forwarding rule can have a maximum of 10 conditions.
From the Add Condition drop-down list, select one of the following:
Host:
Matches the request domain name. If you specify multiple domain names, they have an OR relationship. After setting this, the
alb.ingress.kubernetes.io/conditions.host-exampleannotation is added.Path:
Matches the request path. If you specify multiple paths, they have an OR relationship. After setting this, the
alb.ingress.kubernetes.io/conditions.path-exampleannotation is added.ImportantAfter you set a path forwarding condition, the console automatically adds a forwarding rule with the path
/created-by-<ALB-ID>to the Ingress.HTTP Header:
Matches the request header information in a key-value pair format. For example, Key:
headernameand Value:headervalue1. If you specify multiple header values, they have an OR relationship. After setting this, thealb.ingress.kubernetes.io/conditions.http-header-exampleannotation is added.
From the Action drop-down list, select the following:
Forward To
Forwards to multiple backend server groups. In Service Name, select the target service. In Port, select the target port number. Then, configure a custom weight value.
NoteClusterIP services are not supported for clusters with the Flannel network plug-in.
When you select Forward To, you do not need to configure the Path Mapping in the rule.
Condition: Select Domain Name, Path, and HTTP Header.
Host: example.com.
Action: Select Forward To.
Service Name: tea-svc
Port: 80
Weight: 100
Keep the default values for other configurations.
After the configuration is complete, click OK.