Application Load Balancer (ALB) Ingresses allow you to configure custom routing rules. A routing rule consists of routing conditions and actions. You can add routing conditions to match domain names, paths, request headers, query strings, request methods, cookies, or source IP addresses in requests. You can also add routing actions to return fixed responses, redirect requests, insert request headers, delete request headers, mirror traffic, forward requests to multiple backend server groups, or rewrite requests. This topic describes how to customize the routing rules of an ALB Ingress.
Prerequisites
ALB Ingress controller 2.5.0 or later is installed in your cluster.
You can configure custom routing rules of an ALB Ingress in the ALB console. This feature is in canary release. To use this feature, submit a ticket.
Routing conditions
You can add at most 10 routing conditions to one routing rule.
Routing conditions ResponseHeader and ResponseStatusCode take effect only in custom outbound routing rules.
Introduction to routing conditions
ALB Ingresses allow you to configure routing conditions in the alb.ingress.kubernetes.io/conditions.<Service name>
annotation. The logical relationship among different rule blocks is AND. If multiple values are specified in a rule block, the logical relationship among the values is OR. For example, if you configure two header rule blocks, the logical relationship between the two header rule blocks is AND. If you configure multiple headers in a header rule block, the logical relationship among the headers is OR. The following table describes the routing rules that you can create for an ALB Ingress.
Routing condition | Description |
Domain name | You can add this condition to route only requests that are destined for the specified domain names. Sample code:
|
Path | You can add this condition to route only requests that are sent to the specified paths. Sample code:
|
Header | You can add this condition to route only requests that contain the specified headers. Sample code:
|
Query string | You can add this condition to route only requests that contain the specified query strings. Sample code:
|
Request method | You can add this condition to route only requests that use the specified request methods. Sample code:
|
Cookie | You can add this condition to route only requests that contain the specified cookies. Sample code:
|
SourceIP | You can add this condition to route only requests from the specified source IP addresses. Sample code:
|
ResponseHeader | You can add this condition to route only responses that contain the specified response headers. Sample code:
|
ResponseStatusCode | You can add this condition to route only requests that return the specified status codes. Sample code:
|
Scenario 1: Route traffic based on source IP addresses and request headers
You can add at most five source IP addresses to the custom conditions for one routing rule.
The following code block is used to route packets based on source IP addresses, request headers, and paths.
In the following code block, the source IP addresses are set to 192.168.0.0/16 and 172.16.0.0/16, the header key is set to gray-hello, the header values are set to value1 and value2, and the path is set to /hello. Only requests whose source IP addresses, headers, and paths match all of the preceding conditions are routed to the gray-hello Service. Other requests are 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: |
[{
"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
spec:
ingressClassName: alb
rules:
- http:
paths:
- path: /hello
pathType: ImplementationSpecific
backend:
service:
name: gray-hello
port:
number: 88
alb.ingress.kubernetes.io/order: the priority of the Ingress. A smaller value indicates a higher priority.
Scenario 2: Route traffic based on domain names, request methods, and cookies
The following code block is used to route packets based on domain names, request methods, and cookies.
In the following code block, the request methods are set to GET and HEAD, the domain names are set to www.hostvalue1.edu and www.hostvalue2.edu, the key of the cookie is set to cookiekey1, the value of the cookie is set to cookievalue1, and the path is set to /test. Only requests whose domain names, request methods, cookies, and paths match all of the preceding conditions are routed to the gray-hello Service. Other requests are routed to the service-b Service.
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
alb.ingress.kubernetes.io/conditions.service-a: |
[{
"type": "Cookie",
"cookieConfig": {
"values": [
{
"key":"cookiekey1",
"value":"cookievalue1"
}
]
}
},
{
"type": "Method",
"methodConfig": {
"values": [
"GET",
"HEAD"
]
}
},
{
"type": "Host",
"hostConfig": {
"values": [
"www.hostvalue1.edu",
"www.hostvalue2.edu"
]
}
}]
name: ingress-example
spec:
ingressClassName: alb
rules:
- http:
paths:
- path: /test
pathType: ImplementationSpecific
backend:
service:
name: service-a
port:
number: 88
- path: /test
pathType: ImplementationSpecific
backend:
service:
name: service-b
port:
number: 88
Scenario 3: Route traffic based on query strings, multiple request headers, and multiple paths
The following code block is used to route packets based on query strings, multiple request headers, and multiple paths.
In the following code block, the paths are set to /pathvalue1, /pathvalue2, and /test, the query string key is set to querystringkey1, and the query string value is set to querystringvalue2. In addition, the code block specifies that the request must contain headerkey1 and headerkey2. The header value for headerkey1 must be headervalue1 or headervalue2, and the header value for headervalue2 must be headervalue3 or headervalue4. Only requests whose query strings, request headers, and paths match all of the preceding conditions are routed to the service-a Service. Other requests are routed to the service-b Service.
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
alb.ingress.kubernetes.io/conditions.service-a: |
[{
"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
port:
number: 88
- path: /test
pathType: ImplementationSpecific
backend:
service:
name: service-b
port:
number: 88
Routing actions
Introduction to routing actions
ALB Ingresses allow you to configure routing actions for inbound and outbound routing rules in the alb.ingress.kubernetes.io/actions.<Service name>
annotation. You can add routing actions to return fixed responses, redirect requests, insert request headers, delete request headers, mirror traffic, forward requests to multiple backend server groups, or rewrite requests. ALB Ingresses allow you to define different routing actions to process requests and responses on demand.
The Service name in the
alb.ingress.kubernetes.io/actions.<Service name>
annotation must be the same as the Service name specified inbackend
in therule
field.In the same routing rule, you cannot add multiple termination actions at the same time. For example, you cannot add routing actions to return fixed responses, redirect requests, or forward requests to multiple backend server groups at the same time.
When you add routing actions to return fixed responses, redirect requests, or forward requests to multiple backend server groups, the name of the servicePort specified in
backend
in therule
field must be use-annotation.
Routing actions for inbound routing rules
Routing action | Description |
Return fixed responses | You can configure the ALB Ingress to return fixed content to clients. You can specify the status code, content, and type of content that are returned to clients. Sample code:
|
Redirect requests | You can use the HTTP 3XX status codes to redirect requests to other Service addresses. Sample code: Important You cannot keep the default settings for all redirect parameters at the same time, excluding httpCode.
|
Mirror traffic | You can specify the ID of a server group to mirror traffic to the specified server group. Sample code: Important
|
Forward requests to multiple backend server groups | To forward requests to multiple backend server groups, you need to set the ServerGroupID field to specify server group IDs or set the ServiceName and ServicePort fields to create or associate server groups. You can also specify the weight of each backend server group. Sample code: Important
|
Rewrite requests | After you configure a rewrite rule for an ALB instance, the domain names, paths, and query strings of requests are rewritten. Sample code: Important
For more information about rewrite rules, see Configure rewrite rules. |
Insert request headers | You can specify the names and values of header fields to overwrite the existing header variables in requests. Sample code:
|
Delete request headers | You can delete the keys and values of request headers. Sample code:
|
QPS throttling | When you configure forwarding rules for an ALB instance, you can set the global request rate limit and a request rate limit based on a client IP address. Sample code: Important
|
Routing actions for outbound routing rules
Routing action | Description |
Insert request headers | You can specify the names and values of header fields to overwrite the existing header variables in requests. Sample code:
|
Delete request headers | You can delete the keys and values of request headers. Sample code:
|
Scenario 1: Return status code 503 and fixed content
Use the ACS console
Log on to the ACS console. In the left-side navigation pane, click Clusters.
On the Clusters page, find the cluster that you want to manage 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.
Parameter
Description
Example
Gateway Type
You can select ALB or Nginx based on your business requirements.
ALB
Name
Specify the name of the Ingress.
ingress
Ingress Class
Specify the class of the Ingress.
alb
Listener/Port
The listener port and protocol of the ALB instance that you specify in the AlbConfig. The listener and protocol define how the ALB instance receives and processes traffic.
HTTP:80
Rules
Click +Add Rule to add an Ingress rule.
Domain Name: Enter a custom domain name.
Mappings: Specify the following parameters:
Path: Enter the URL path of the backend Service. In this example, the root path / is used.
Rule: You can select Prefix (Prefix-based Match), Exact (Exact Match), or ImplementationSpecific (Default Value).
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 this parameter empty.
Mappings:
Path: /
Rule: Prefix (Prefix-based Match) is selected by default.
Service: response-503
Port: 80
TLS Settings
Specifies whether to enable TLS authentication. You can enable TLS authentication for the Ingress.
Domain Name: the custom domain name.
Secret: the Secret used in the cluster. Select a Secret based on your business requirements.
Turn off TLS Settings. In this example, you do not need to configure a TLS certificate.
More
Canary Release: Enable canary releases. You can configure canary release rules based on request headers, cookies, and weights.
NoteYou can configure canary release rules based on only one of the following elements: request headers, cookies, and weights. You can also configure canary release rules based on request headers, cookies, and weights at the same time. In this case, request headers, cookies, and weights take effect in descending order of precedence.
Based on Request Header: Distribute traffic based on request headers by adding the
nginx.ingress.kubernetes.io/canary-by-header
,nginx.ingress.kubernetes.io/canary-by-header-value
, ornginx.ingress.kubernetes.io/canary-by-header-pattern
annotation.Based on Cookie: Distribute traffic based on cookies by adding the
nginx.ingress.kubernetes.io/canary-by-cookie
annotation.Based on Weight: Distribute traffic based on Service weights (integers from 0 to 100) by adding the
nginx.ingress.kubernetes.io/canary-weight
annotation.
Protocol: Select the protocol used by the backend Service by adding the
nginx.ingress.kubernetes.io/backend-protocol
annotation.HTTP, HTTPS, gRPC, and gRPCS are supported.
Rewrite Path: Add the
nginx.ingress.kubernetes.io/rewrite-target
annotation to rewrite the paths in client requests before the requests are forwarded to the backend Service.
Turn off Canary Release. Use the default values of the Protocol and Rewrite Path parameters. In this example, you do not need to configure these parameters.
Custom Forwarding Rules
NoteYou can configure custom routing rules of an ALB Ingress in the ALB console. This feature is in canary release. To use this feature, submit a ticket.
You can enable custom forwarding rules to manage inbound traffic in a fine-grained manner.
NoteYou can add up to 10 conditions to a forwarding rule.
The following condition types are available in the Add Condition drop-down list:
Domain Name:
Only requests that contain the specified one or more domain names are routed. The logical relationship between multiple domain names is OR. After you specify the domain names, the system adds the
alb.ingress.kubernetes.io/conditions.host-example
annotation.Path:
Only requests that contain the specified one or more paths are routed. The logical relationship between multiple paths is OR. After you specify the paths, the system adds the
alb.ingress.kubernetes.io/conditions.path-example
annotation.HTTP Header:
Only requests that contain the specified one or more HTTP headers are routed. Each HTTP request header is a key-value pair. For example, you can set the key to
headername
and value toheadervalue1
. The logical relationship between multiple headers is OR. After you specify the headers, the system adds thealb.ingress.kubernetes.io/conditions.http-header-example
annotation.
The following actions are available in the Action drop-down list:
Forward To
Forwards the inbound traffic to multiple backend server groups. To forward the inbound traffic, perform the following operations: Select the Service that you want to access from the Service drop-down list. Select the port used to connect to the Service From the Port drop-down list. Specify a custom weight for each backend server group.
NoteIf the cluster uses the Flannel component, the ClusterIP Service is not supported.
If you select Forward To from the Action drop-down list, you do not need to configure the Mappings parameter for the rule.
Return Fixed Response
You can configure the ALB Ingress to return fixed content to clients. You can specify the status code, content, and type of content that are returned to clients. Configure the Response Status Code, Response Content Type (Optional), and Response Content (Optional) parameters based on your business requirements.
Valid values of the Response Content Type parameter:
text/plain: indicates that the content is in plaintext.
text/css: indicates that the content is in the XML format.
text/html: indicates that the content is in the HTML format.
application/javascript: indicates that the content is in the JavaScript format.
application/json: indicates that the content is in the JSON format.
You can specify multiple conditions and actions in a custom forwarding rule. You can configure domain names, paths, and HTTP request headers as forwarding conditions and forward the inbound traffic to backend server groups or return fixed content to clients.
In the Add Condition drop-down list, Path is selected by default.
In the Action drop-down list, Return Fixed Response is selected.
Response Status Code: 503
Response Content Type (Optional): text/plain
Response Content (Optional): error
Annotations
You can enter custom annotation names and values. You can also select or search for annotations by name from the drop-down list. For more information about Ingress annotations, see ALB Ingress GlobalConfiguration dictionary.
Click +Add Annotation to add an annotation. ACS does not limit the number of Ingress annotations that you can add.
In this example, you do not need to configure annotations.
Labels
You can add labels to describe the characteristics of the Ingress.
Click +Add Label to add a label. No limit is imposed on the number of Ingress labels that you can add.
In this example, you do not need to configure labels.
After the configuration is complete, click OK.
kubectl
The following code block is used to return the status code 503 and 503 error text
:
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
namespace: default
name: ingress
annotations:
alb.ingress.kubernetes.io/actions.response-503: |
[{
"type": "FixedResponse",
"FixedResponseConfig": {
"contentType": "text/plain",
"httpCode": "503",
"content": "503 error text"
}
}]
spec:
ingressClassName: alb
rules:
- http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: response-503
port:
name: use-annotation # The name of the Service port must be use-annotation.
Scenario 2: Use 301 redirect to redirect requests to an HTTPS port
The following code block is used to redirect requests to an HTTPS port:
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
namespace: default
name: ingress
annotations:
alb.ingress.kubernetes.io/actions.redirect: |
[{
"type": "Redirect",
"RedirectConfig": {
"host": "${host}",
"path": "${path}",
"port": "${port}",
"protocol": "https",
"query": "${query}",
"httpCode": "301"
}
}]
spec:
ingressClassName: alb
rules:
- http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: redirect
port:
name: use-annotation # The name of the Service port must be use-annotation.
Scenario 3: Insert the source: alibaba header to requests
The following code block is used to overwrite the existing header in requests with the source: alibaba header:
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
namespace: default
name: ingress
annotations:
# The Service specified in the annotation must be an existing Service in the cluster, and the Service name must be the same as the Service name specified in backend of the rule field.
alb.ingress.kubernetes.io/actions.insert-header: |
[{
"type": "InsertHeader",
"InsertHeaderConfig": {
"key": "source",
"value": "alibaba",
"valueType": "UserDefined"
}
}]
spec:
ingressClassName: alb
rules:
- http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: insert-header
port:
number: 80
Scenario 4: Mirror traffic to a server group
The following code block is used to mirror traffic to the specified server group:
Log on to the Server Load Balancer (SLB) console. In the left-side navigation pane, choose . On the Server Groups page, you can view the ID of the server group.
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: traffic-mirror-ingress
annotations:
# The Service specified in the annotation must be an existing Service in the cluster, and the Service name must be the same as the Service name specified in backend of the rule field.
alb.ingress.kubernetes.io/actions.traffic-mirror: |
[{
"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: traffic-mirror
port:
number: 80
Scenario 5: Forward requests to multiple backend server groups
Use the ACS console
Log on to the ACS console. In the left-side navigation pane, click Clusters.
On the Clusters page, find the cluster that you want to manage 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.
Parameter
Description
Example
Gateway Type
You can select ALB or Nginx based on your business requirements.
ALB
Name
Specify the name of the Ingress.
forward-ingress
Ingress Class
Specify the class of the Ingress.
alb
Listener/Port
The listener port and protocol of the ALB instance that you specify in the AlbConfig. The listener and protocol define how the ALB instance receives and processes traffic.
HTTP:80
Rules
Click +Add Rule to add an Ingress rule.
Domain Name: Enter a custom domain name.
Mappings: Specify the following parameters:
Path: Enter the URL path of the backend Service. In this example, the root path / is used.
Rule: You can select Prefix (Prefix-based Match), Exact (Exact Match), or ImplementationSpecific (Default Value).
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 (Prefix-based Match) is selected by default.
Service: forward
Port: 80
TLS Settings
Specifies whether to enable TLS authentication. You can enable TLS authentication for the Ingress.
Domain Name: the custom domain name.
Secret: the Secret used in the cluster. Select a Secret based on your business requirements. To create a Secret, perform the following steps:
Click Create to the right of the Secret field.
In the Create Secret dialog box, configure the Name, Cert, and Key parameters. Then, click OK.
Select the Secret that you create from the Secret drop-down list.
Turn off TLS Settings. In this example, you do not need to configure a TLS certificate.
More
Canary Release: Enable canary releases. You can configure canary release rules based on request headers, cookies, and weights.
NoteYou can configure canary release rules based on only one of the following elements: request headers, cookies, and weights. You can also configure canary release rules based on request headers, cookies, and weights at the same time. In this case, request headers, cookies, and weights take effect in descending order of precedence.
Based on Request Header: Distribute traffic based on request headers by adding the
nginx.ingress.kubernetes.io/canary-by-header
,nginx.ingress.kubernetes.io/canary-by-header-value
, ornginx.ingress.kubernetes.io/canary-by-header-pattern
annotation.Based on Cookie: Distribute traffic based on cookies by adding the
nginx.ingress.kubernetes.io/canary-by-cookie
annotation.Based on Weight: Distribute traffic based on Service weights (integers from 0 to 100) by adding the
nginx.ingress.kubernetes.io/canary-weight
annotation.
Protocol: Select the protocol used by the backend Service by adding the
nginx.ingress.kubernetes.io/backend-protocol
annotation.HTTP, HTTPS, gRPC, and gRPCS are supported.
Rewrite Path: Add the
nginx.ingress.kubernetes.io/rewrite-target
annotation to rewrite the paths in client requests before the requests are forwarded to the backend Service.
Turn off Canary Release. Use the default values of the Protocol and Rewrite Path parameters. In this example, you do not need to configure these parameters.
Custom Forwarding Rules
NoteYou can configure custom routing rules of an ALB Ingress in the ALB console. This feature is in canary release. To use this feature, submit a ticket.
You can enable custom forwarding rules to manage inbound traffic in a fine-grained manner.
NoteYou can add up to 10 conditions to a forwarding rule.
The following condition types are available in the Add Condition drop-down list:
Domain Name:
Only requests that contain the specified one or more domain names are routed. The logical relationship between multiple domain names is OR. After you specify the domain names, the system adds the
alb.ingress.kubernetes.io/conditions.host-example
annotation.Path:
Only requests that contain the specified one or more paths are routed. The logical relationship between multiple paths is OR. After you specify the paths, the system adds the
alb.ingress.kubernetes.io/conditions.path-example
annotation.HTTP Header:
Only requests that contain the specified one or more HTTP headers are routed. Each HTTP request header is a key-value pair. For example, you can set the key to
headername
and value toheadervalue1
. The logical relationship between multiple headers is OR. After you specify the headers, the system adds thealb.ingress.kubernetes.io/conditions.http-header-example
annotation.
The following actions are available in the Action drop-down list:
Forward To
Forwards the inbound traffic to multiple backend server groups. To forward the inbound traffic, perform the following operations: Select the Service that you want to access from the Service drop-down list. Select the port used to connect to the Service From the Port drop-down list. Specify a custom weight for each backend server group.
NoteIf the cluster uses the Flannel component, the ClusterIP Service is not supported.
If you select Forward To from the Action drop-down list, you do not need to configure the Mappings parameter for the rule.
Return Fixed Response
You can configure the ALB Ingress to return fixed content to clients. You can specify the status code, content, and type of content that are returned to clients. Configure the Response Status Code, Response Content Type (Optional), and Response Content (Optional) parameters based on your business requirements.
Valid values of the Response Content Type parameter:
text/plain: indicates that the content is in plaintext.
text/css: indicates that the content is in the XML format.
text/html: indicates that the content is in the HTML format.
application/javascript: indicates that the content is in the JavaScript format.
application/json: indicates that the content is in the JSON format.
You can specify multiple conditions and actions in a custom forwarding rule. You can configure domain names, paths, and HTTP request headers as forwarding conditions and forward the inbound traffic to backend server groups or return fixed content to clients.
In the Add Condition drop-down list, Domain Name is selected. Domain Name: demo.domain.ingress.top
In the Action drop-down list, Forward To is selected.
Service: tea-svc
Port: 80
Weight: 80
Add a Service
Service: coffee-svc
Port: 80
Weight: 20
Annotations
You can enter custom annotation names and values. You can also select or search for annotations by name from the drop-down list. For more information about Ingress annotations, see ALB Ingress GlobalConfiguration dictionary.
Click +Add Annotation to add an annotation. ACS does not limit the number of Ingress annotations that you can add.
In this example, you do not need to configure annotations.
Labels
You can add labels to describe the characteristics of the Ingress.
Click +Add Label to add a label. No limit is imposed on the number of Ingress labels that you can add.
In this example, you do not need to configure labels.
After the configurations are complete, click OK in the lower-left corner of the Create Ingress panel.
kubectl
The following code block defines an Ingress that forwards requests to multiple Services in the cluster:
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: forward-ingress
annotations:
# The Service specified in the annotation must be an existing Service in the cluster, and the Service name must be the same as the Service name specified in backend of the rule field.
alb.ingress.kubernetes.io/actions.forward: |
[{
"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: forward
port:
name: use-annotation # The name of the Service port must be use-annotation.
Scenario 6: Rewrite requests
The following code block defines an Ingress that rewrites the domain names, paths, and query strings of requests.
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
namespace: default
name: rewrite-ingress
annotations:
alb.ingress.kubernetes.io/actions.rewrite: |
[{
"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: rewrite
port: 80
Scenario 7: Modify the response header based on ResponseHeader
By default, custom routing rules take effect in the inbound direction. To enable custom routing rules to take effect in the outbound direction, set the
alb.ingress.kubernetes.io/rule-direction.<Service name>
annotation to Response. The annotation is set to Request by default.When you create a custom outbound routing rule, the name of the
servicePort
in theingressSpec.rules.backend
field must beuse-annotation
.
The following code block defines that when a response header
is matched (the header contains response-hello
and the value must be value1
or value2
), a new request header source: alibaba
is inserted into the header.
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: |
[{
"type": "ResponseHeader",
"responseHeaderConfig": {
"key": "response-hello",
"values": [
"value1",
"value2"
]
}
}]
alb.ingress.kubernetes.io/actions.response-header: |
[{
"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
port:
name: use-annotation # The name of the Service port must be use-annotation.
Scenario 8: Modify the response header based on the response status code
By default, custom routing rules take effect in the inbound direction. To enable custom routing rules to take effect in the outbound direction, set the
alb.ingress.kubernetes.io/rule-direction.<Service name>
annotation to Response. The annotation is set to Request by default.When you create a custom outbound routing rule, the name of the
servicePort
in theingressSpec.rules.backend
field must beuse-annotation
.
The following code block defines that the request header is removed (response-hello
is removed from the request header) only when 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: |
[{
"type": "ResponseStatusCode",
"responseStatusCodeConfig": {
"values": [
"200",
"300"
]
}
}]
alb.ingress.kubernetes.io/actions.response-hello: |
[{
"type": "RemoveHeader",
"RemoveHeaderConfig": {
"key": "response-hello"
}
}]
name: response-hello
spec:
ingressClassName: alb
rules:
- http:
paths:
- path: /*
pathType: ImplementationSpecific
backend:
service:
name: response-hello
port:
name: use-annotation # The name of the Service port must be use-annotation.