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. 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.
Prerequisites
The ALB Ingress Controller component must be installed and at version v2.5.0 or later. For more information, see Manage components.
Forwarding conditions
A forwarding rule can contain a maximum of 10 conditions.
The
ResponseHeaderandResponseStatusCodeforwarding conditions are valid only for response-based forwarding rules.
Forwarding conditions
ALB Ingress supports configuring forwarding conditions in the alb.ingress.kubernetes.io/conditions.<service-name> annotation. Different routing rule blocks have a logical AND relationship, while values within the same routing rule block have a logical OR relationship. For example, two different Header rule blocks have a logical AND relationship, but the values specified in the same Header rule block have a logical OR relationship. Detailed descriptions of the routing rules are as follows.
Forwarding condition | Description |
Domain name | Routes requests based on a matching domain name. The following is an example.
|
Path | Routes requests based on a matching path. The following is an example.
|
Header | Routes requests based on a matching request header. The following is an example.
|
Query string | Routes requests based on a matching query string. The following is an example.
For a use case and an example, see Use case 3: Route traffic based on query string, multiple headers, and multiple paths. |
Request method | Routes requests based on a matching request method. The following is an example.
|
Cookie | Routes requests based on a matching cookie. The following is an example.
For a use case and an example, see Use case 2: Route traffic based on domain name, request method, and cookie. |
source IP | Routes requests based on a matching source IP address. The following is an example.
For a use case and an example, see Use case 1: Route traffic based on source IP and header. |
response header | Matches the response header and performs the forwarding action only on responses that contain the correct header. Note that this must be used in conjunction with the
|
response status code | Matches the response status code. The service can be accessed only if the correct status code is returned. Note that this feature must be used with a response direction forwarding action and the response direction forwarding rule annotation
|
Use case 1: Source IP and header routing
You can specify a maximum of five source IP conditions in a single forwarding rule.
This YAML defines an Ingress that routes requests only when the source IP, header, and path match the specified conditions.
If the source IP address of a request is from 192.168.0.0/16 or 172.16.0.0/16, the request header contains gray-hello with a value of value1 or value2, and the request path is /hello, the request is routed to the gray-hello-svc service. Otherwise, the request is routed 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: | # The service name must match a backend service name in spec.rules. These conditions apply to that 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 # This backend service name must match the name in the `conditions` annotation for those conditions to apply.
port:
number: 88alb.ingress.kubernetes.io/order: Specifies the priority of the Ingress. The smaller the number, the higher the priority.
Use case 2: Domain, method, and cookie routing
This YAML defines an Ingress that routes requests only when the domain name, request method, and cookie match the specified conditions.
This means that a request is routed to service-a only if the request method is GET or HEAD, the request host is example.com or *.edu, the request cookie has a key of cookiekey1 and a value of cookievalue1, and the request path is /test. Otherwise, the request is routed to service-b.
Forwarding rules for domain names support wildcards.
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
alb.ingress.kubernetes.io/conditions.service-a: | # The service name must match a backend service name in spec.rules. These conditions apply to that 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 # This backend service name must match the name in the `conditions` annotation for those conditions to apply.
port:
number: 88
- path: /test
pathType: ImplementationSpecific
backend:
service:
name: service-b
port:
number: 88Use case 3: Query string, header, and path routing
This YAML defines an Ingress that routes requests only when the query string, headers, and path match the specified conditions.
This means that a request is routed to the service-a service if the request path is /pathvalue1, /pathvalue2, or /test, the query string has the key querystringkey1 and the value querystringvalue2, and the request header must contain headerkey1 and headerkey2. Additionally, for the request header that contains headerkey1, the value must be headervalue1 or headervalue2, and for the request header that contains headerkey2, the value must be headervalue3 or headervalue4. Otherwise, the request is routed to the service-b service.
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
alb.ingress.kubernetes.io/conditions.service-a: | # The service name must match a backend service name in spec.rules. These conditions apply to that 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 # This backend service name must match the name in the `conditions` annotation for those conditions to apply.
port:
number: 88
- path: /test
pathType: ImplementationSpecific
backend:
service:
name: service-b
port:
number: 88Forwarding actions
Forwarding actions
ALB Ingress lets you configure forwarding actions for requests and responses with the alb.ingress.kubernetes.io/actions.<service-name> annotation. Supported actions include returning a fixed response, redirection, inserting or removing a header, traffic mirroring, forwarding to multiple backend server groups, and rewriting requests. By defining these forwarding actions, you can flexibly manage how requests and responses are handled in your ALB Ingress.
For the
alb.ingress.kubernetes.io/actions.<service-name>annotation, ensure the service name in the annotation matches the service name underbackendin therulefield.Use only one terminal forwarding action, such as redirection, fixed response, or forwarding to multiple server groups, in the same forwarding rule.
When you configure a redirection, a fixed response, or forwarding to multiple server groups, you must set
backend.service.port.nametouse-annotation.
Request forwarding actions
Action | Description |
Fixed response | Sends a fixed response to the client from the Application Load Balancer (ALB). You can set the response status code, content, and content type. The following code provides an example.
For a use case and an example, see Use case 1: Set a fixed response. |
Redirection | Redirects the client to a different address using an HTTP 3xx status code. The following code provides an example.
Important You can configure the host, path, port, protocol, and query parameters to use values from the original request, but at least one must be set to a non-default value. For example, if you set host to For a use case and an example, see Use case 2: Use a 301 redirection. |
Traffic mirroring | Copies the request and forwards it to a traffic mirroring server group. You must specify the ID of the server group. The following code provides an example. Important
For a use case and an example, see Use case 4: Mirror traffic. |
Forward to multiple backend server groups | Forwards ALB requests to multiple backend server groups. You can specify backend server groups by using ServerGroupID, or create or attach server groups by using ServiceName+ServicePort. You can also set a forwarding weight for each backend server group and enable session persistence between server groups. Important
For a use case and an example, see Use case 5: Forward to multiple server groups. |
Rewrite | Rewrites the request before forwarding it to the backend. The Application Load Balancer (ALB) can modify the request's host, path, and query string. Important
Important The parameters host, path, and query can be configured to use the values from the original request. However, at least one of these parameters must be set to a value other than the default. For example, if you set host to For a use case and an example, see Use case 6: Rewrite a request. |
Insert header | Sets the header field name and content. This overwrites any existing header with the same name in the request. The following code provides an example.
For a use case and an example, see Use case 3: Insert a request header. |
Remove header | Removes a header from the request. The following code provides an example. type: The type of forwarding action. Set this to RemoveHeader to remove a request header. key: The name of the header field to remove. |
QPS throttling | This action limits the request rate in queries per second (QPS). You can configure an overall limit and a separate limit for each client source IP. The following code provides a configuration example: Important
|
Response forwarding actions
Action | Description |
Insert header | When applied to a response rule, this action sets a header field and its value in the response. This overwrites any existing response header with the same name. The following code provides an example.
For use cases and examples of modifying response headers, see Use case 7: Modify response headers and Use case 8: Modify response headers by status code. |
Remove header | When applied to a response rule, this action removes a header from the response. The following code provides an example. type: The type of forwarding action. Set this to key: The name of the header field to remove. |
Use case 1: Set a fixed response
Console
Log on to the ACK console. In the left navigation pane, click Clusters.
On the Clusters page, click the name of your cluster. In the left navigation pane, click .
On the Ingresses page, click Create Ingress. In the Create Ingress dialog box, configure the Ingress.
Parameter
Description
Example
Gateway Type
You can select ALB Ingress, MSE Ingress, or Nginx Ingress based on your business requirements.
For more information about the differences among the three gateway types, see Comparison of Nginx Ingress, ALB Ingress, and MSE Ingress.
ALB Ingress
Name
A custom name for the ingress.
ingress
Ingress Class
The name of the associated Ingress Class.
alb
Rules
Click + Add Rule to add routing rules.
Host: A custom host.
Mappings: Configure the following parameters.
Match type:
Prefix match: matches the prefix of the request URL path.
Exact match: performs an exact match on the request URL path.
ImplementationSpecific (Default Value): The behavior depends on the Ingress controller's implementation. For ALB Ingress, this defaults to an exact match.
Service: Select the target service, which is a Kubernetes Service.
Port: Select the port that the service exposes.
An Ingress supports multiple paths under the same host. Click + Add to add a path.
Host: Leave empty.
Mappings:
Path: /
Match type: Prefix match
Service: response-503
Port: 80
Custom Forwarding Rules
Configure custom forwarding rules for fine-grained traffic management.
NoteA forwarding rule can have a maximum of 10 conditions.
From the Add Condition drop-down list, select an option.
Host:
Matches the request host. If you specify multiple hosts, they are evaluated using
ORlogic. After this is set, thealb.ingress.kubernetes.io/conditions.host-exampleannotation is added.Path:
Matches the request path. If you specify multiple paths, they are evaluated using
ORlogic. After this is set, thealb.ingress.kubernetes.io/conditions.path-exampleannotation is added.HTTP Header:
Matches the request header information as a key-value pair. For example, set Key to
headernameand Value toheadervalue1. If you specify multiple header values, they are evaluated usingORlogic. After this is set, thealb.ingress.kubernetes.io/conditions.http-header-exampleannotation is added.
From the Action drop-down list, select an option.
Return Fixed Response
Returns a fixed response to the client through the ALB. You can configure 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: a plain text content type.
text/css: a CSS content type.
text/html: an HTML content type.
application/javascript: a JavaScript content type.
application/json: a JSON content type.
Add Condition: Select Path. (Keep the default value)
Action: Return Fixed Response
Response Status Code: 503
Response Content Type (Optional): text/plain
Response Content (Optional): error
Keep the default values for other parameters.
After you complete the configurations, click OK.
Kubectl
The following YAML 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 name of the backend service that is configured in spec.rules. The forwarding action applies to that 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 name of the backend service must match "service-name" in the custom forwarding action annotation. The forwarding action applies to this backend service.
port:
name: use-annotation # The service port name must be set to use-annotation.Use case 2: Use a 301 redirection
This YAML example shows how to redirect requests 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 name of the backend service that is configured in spec.rules. The forwarding action applies to that backend service.
[{
"type": "Redirect",
"RedirectConfig": {
"host": "demo.domain.ingress.top",
"path": "/test",
"port": "443",
"protocol": "https",
"query": "querystring",
"httpCode": "301"
}
}]
spec:
ingressClassName: alb
rules:
- http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: redirect # Note: The name of the backend service must match "redirect" in the custom forwarding action annotation. The forwarding action applies to this backend service.
port:
name: use-annotation # The service port name must be set to use-annotation.Multiple redirections
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
namespace: default
name: ingress
annotations:
alb.ingress.kubernetes.io/listen-ports: |
[{"HTTP": 8001}]
alb.ingress.kubernetes.io/actions.redirect-1: |
[{
"type": "Redirect",
"RedirectConfig": {
"host": "demo.domain.ingress.top",
"path": "/test",
"port": "443",
"protocol": "https",
"query": "querystring",
"httpCode": "301"
}
}]
alb.ingress.kubernetes.io/actions.redirect-2: |
[{
"type": "Redirect",
"RedirectConfig": {
"host": "demo.domain.ingress.top",
"path": "/test",
"port": "443",
"protocol": "https",
"httpCode": "301"
}
}]
spec:
ingressClassName: ml-test-ingressclass-rolechain-2
rules:
- http:
paths:
- path: /foo
pathType: Prefix
backend:
service:
name: redirect-1
port:
name: use-annotation
- path: /bar
pathType: Prefix
backend:
service:
name: redirect-2
port:
name: use-annotationUse case 3: Insert a request header
This YAML example shows how to add or overwrite the request header to source: alibaba.
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 name of the backend service that is configured in spec.rules. The forwarding action applies to that 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 name of the backend service must match "insert-header" in the custom forwarding action annotation. The forwarding action applies to this backend service.
port:
number: 80Use case 4: Mirror traffic
The following YAML shows an example of how to mirror traffic to a server group.
Log on to the Application Load Balancer (ALB) console. In the left-side navigation pane, choose . On the Server Groups page, obtain the server group ID.
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: traffic-mirror-ingress
annotations:
# The mirror-svc must be one of the backend.service names specified below.
# ALB Ingress mirrors traffic that is forwarded to mirror-svc to the backend server specified by "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 name of the backend service that is configured in spec.rules. The forwarding action applies to that 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 name of the backend service must match "mirror-svc" in the custom forwarding action annotation. The forwarding action applies to this backend service.
port:
number: 80Use case 5: Forward to multiple server groups
Console
Log on to the ACK console. In the left navigation pane, click Clusters.
On the Clusters page, click the name of your cluster. In the left navigation pane, click .
On the Ingresses page, click Create Ingress. In the Create Ingress dialog box, configure the Ingress.
Parameter
Description
Example
Gateway Type
You can select ALB Ingress, MSE Ingress, or Nginx Ingress based on your business requirements.
For more information about the differences among the three gateway types, see Comparison of Nginx Ingress, ALB Ingress, and MSE Ingress.
ALB Ingress
Name
A custom name for the ingress.
forward-ingress
Ingress Class
The name of the associated Ingress Class.
alb
Rules
Click + Add Rule to add routing rules.
Host: A custom host.
Mappings: Configure the following parameters.
Match type:
Prefix match: matches the prefix of the request URL path.
Exact match: performs an exact match on the request URL path.
ImplementationSpecific (Default Value): depends on the logic implemented by the Ingress controller. ALB Ingress uses exact match logic.
Service: Select the target service, which is a Kubernetes Service.
Port: Select the port that the service exposes.
An Ingress supports multiple paths under the same host. Click + Add to add a path.
Host: demo.domain.ingress.top
Mappings:
Path: /path
Match type: Prefix match
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 an option.
Host:
Matches the request host. If you specify multiple hosts, they are evaluated using
ORlogic. After this is set, thealb.ingress.kubernetes.io/conditions.host-exampleannotation is added.Path:
Matches the request path. If you specify multiple paths, they are evaluated using
ORlogic. After this is set, thealb.ingress.kubernetes.io/conditions.path-exampleannotation is added.HTTP Header:
Matches the request header information as a key-value pair. For example, set Key to
headernameand Value toheadervalue1. If you specify multiple header values, they are evaluated usingORlogic. After this is set, thealb.ingress.kubernetes.io/conditions.http-header-exampleannotation is added.
From the Action drop-down list, select an option.
Forward To
Forwards requests to multiple backend server groups. In the Service Name field, select the target service. In the Port field, select the target port number. Then, configure a custom weight value.
NoteClusterIP services are not supported for clusters that use the Flannel network plug-in.
When you select Forward To, you do not need to configure path mappings in the rule.
Add Condition: Select Host. Host: 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 parameters.
After you complete the configurations, click OK in the lower-left corner of the Create Ingress page.
Kubectl
The following YAML 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 name of the backend service that is configured in spec.rules. The forwarding action applies to that 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 name of the backend service must match "service-name" in the custom forwarding action annotation. The forwarding action applies to this backend service.
port:
name: use-annotation # The service port name must be set to use-annotation.Use case 6: Rewrite a request
A rewrite modifies a request's URL before it is forwarded to a backend. ALB Ingress can change the host, path, and query string, which is useful for simplifying URLs, performing client-transparent redirection, and hiding backend implementation details. In the following example, a rewrite is configured by using the alb.ingress.kubernetes.io/actions.service-name annotation.
For example, if a client accesses https://example.com/api/users, the rewrite changes the URL to https://example.org/users but preserves the original query string.
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
namespace: default
name: rewrite-ingress
annotations:
alb.ingress.kubernetes.io/actions.service-name: | # The "service-name" in this annotation must match the name of the backend service that is configured in spec.rules. The forwarding action applies to that backend service.
[{
"type": "Rewrite",
"RewriteConfig": {
"Host": "example.org",
"Path": "/users",
"Query": "${query}" # ${query} indicates that the original request query string is used.
}
}]
spec:
ingressClassName: alb
rules:
- host: example.com
http:
paths:
- path: /api/users
pathType: ImplementationSpecific
backend:
service:
name: service-name # The name of the backend service must match "service-name" in the custom forwarding action annotation. The forwarding action applies to this backend service.
port:
number: 80Use case 7: Modify response headers
By default, ALB Ingress forwarding rules apply to requests. To apply a rule to a response, you must set the
alb.ingress.kubernetes.io/rule-direction.<service-name>annotation toResponse.When you create a forwarding rule for responses, you must set
backend.service.port.nametouse-annotation.
The following code block defines that when ResponseHeader is matched, which means the header contains response-hello with a value of value1 or value2, a new request header source: alibaba is inserted.
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 name of the backend service that is configured in spec.rules. The forwarding condition applies to that 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 name of the backend service that is configured in spec.rules. The forwarding action applies to that 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 name of the backend service must match "response-header" in the custom forwarding condition and action annotations. The configured conditions and actions apply to this backend service.
port:
name: use-annotation # The service port name must be set to use-annotation.Use case 8: Modify response headers by status code
By default, ALB Ingress forwarding rules apply to requests. To apply a rule to a response, you must set the
alb.ingress.kubernetes.io/rule-direction.<service-name>annotation toResponse.When you create a forwarding rule for responses, you must set
backend.service.port.nametouse-annotation.
This YAML example removes the response-hello header from the response 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 name of the backend service that is configured in spec.rules. The forwarding condition applies to that 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 name of the backend service that is configured in spec.rules. The forwarding action applies to that 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 name of the backend service must match "response-hello" in the custom forwarding condition and action annotations. The configured conditions and actions apply to this backend service.
port:
name: use-annotation # The service port name must be set to use-annotation.Forwarding conditions and actions
Use case 1: Forward traffic based on a domain name
This section shows you how to configure forwarding conditions and actions based on a domain name in the ACK console to route traffic to a specific service.
Log on to the ACK console. In the left navigation pane, click Clusters.
On the Clusters page, click the name of your cluster. In the left navigation pane, click .
On the Ingresses page, click Create Ingress. In the Create Ingress dialog box, configure the Ingress.
Parameter
Description
Example
Gateway type
You can select ALB Ingress, MSE Ingress, or Nginx Ingress based on your business requirements.
For more information about the differences among the three gateway types, see Comparison of Nginx Ingress, ALB Ingress, and MSE Ingress.
ALB Ingress
Name
A custom name for the ingress.
alb_ingress
Ingress Class
The name of the associated IngressClass.
alb
Rules
Click + Add Rule to add one or more routing rules.
Domain name: A custom domain name.
Mappings: Configure the following parameters.
Rule:
Prefix (prefix match): Matches the prefix of the request URL path.
Exact (exact match): Exactly matches the request URL path.
ImplementationSpecific (Default): The behavior depends on the Ingress controller implementation. For ALB Ingress, this option functions as an exact match.
Service name: Select the target service, which is a Kubernetes Service.
Port: Select the port that the service exposes.
An Ingress supports multiple paths under the same domain name. Click + Add Path to add more paths.
Domain name: *.example.com
Mappings:
Path: /tes
Rule: ImplementationSpecific
Service name: tea-svc
Port: 80
Custom forwarding rules
Define custom forwarding rules for fine-grained control over inbound traffic.
NoteA forwarding rule can have a maximum of 10 conditions.
From the Condition drop-down list, select an option.
Domain name:
Matches the request domain name. If you specify multiple domain names, they are evaluated using OR logic. When this condition is set, the
alb.ingress.kubernetes.io/conditions.host-exampleannotation is added.Path:
Matches the request path. If you specify multiple paths, they are evaluated using OR logic. When this condition is set, the
alb.ingress.kubernetes.io/conditions.path-exampleannotation is added.ImportantWhen you configure a path forwarding condition, the console automatically adds a forwarding rule with the path
/created-by-<ALB-ID>to the Ingress.HTTP header:
Matches a specified key-value pair in the request header. For example, set Key to
headernameand Value toheadervalue1. If you specify multiple header values, they are evaluated using OR logic. When this condition is set, thealb.ingress.kubernetes.io/conditions.http-header-exampleannotation is added.
From the Action drop-down list, select an option.
Forward to
Forwards requests to multiple backend server groups. In the Service name field, select the target service. In the Port field, select the target port. Then, configure a weight.
NoteClusterIP services are not supported in clusters that use the Flannel network plug-in.
When you select Forward to, you do not need to configure Create and use an ALB Ingress to expose services in the rule.
Condition: Select Domain Name, Path, and HTTP Header.
Domain name: example.com. Click Add domain name to add another domain name, such as test.com.
Action: Select Forward to.
Service name: tea-svc
Port: 80
Weight: 100
Keep the default values for other parameters.
The configuration is complete. In the lower-left corner of the Create Ingress page, click OK.