Configuring Header Writing or Deletion for a LoadBalancer Ingress
Dedicated LoadBalancer ingresses allow for custom header rewriting in forwarding policies. This means you can modify or remove headers in a request before it reaches a backend Service.
The ability to rewrite headers in dedicated load balancer ingresses is dependent on the ELB's header writing and deletion capabilities. If you want to use this function, submit a service ticket to request these capabilities for your ELB.
Prerequisites
- A CCE standard or Turbo cluster is available, and the cluster version meets the following requirements:
- v1.23: v1.23.18-r10 or later
- v1.25: v1.25.16-r0 or later
- v1.27: v1.27.16-r0 or later
- v1.28: v1.28.13-r0 or later
- v1.29: v1.29.8-r0 or later
- v1.30: v1.30.4-r0 or later
- Other clusters of later versions
- The cluster can be accessed using kubectl. For details, see Connecting to a Cluster Using kubectl.
Using kubectl
- Use kubectl to access the cluster. For details, see Connecting to a Cluster Using kubectl.
- Create a YAML file named ingress-test.yaml. The file name can be customized.
vi ingress-test.yaml
An example YAML file of an ingress created using an existing load balancer is as follows:apiVersion: networking.k8s.io/v1 kind: Ingress metadata: annotations: kubernetes.io/elb.class: performance kubernetes.io/elb.id: 034baaf0-40e8-4e39-b0d9-bf6e5b883cf9 kubernetes.io/elb.port: "80" # When the Service that matches the rule is test-service, the ability to rewrite headers will be included in the final forwarding policy. kubernetes.io/elb.actions.test-service: | [{ "type": "InsertHeader", "InsertHeaderConfig": { "key": "aa", "value_type": "USER_DEFINED", "value": "aa" } }, { "type": "InsertHeader", "InsertHeaderConfig": { "key": "bb", "value_type": "SYSTEM_DEFINED", "value": "ELB-ID" } }, { "type": "InsertHeader", "InsertHeaderConfig": { "key": "cc", "value_type": "REFERENCE_HEADER", "value": "cc" } }, { "type": "RemoveHeader", "RemoveHeaderConfig": { "key": "dd" } }, { "type": "RemoveHeader", "RemoveHeaderConfig": { "key": "ee" } }] name: test namespace: default spec: ingressClassName: cce rules: - http: paths: - backend: service: name: test-service port: number: 8888 path: / pathType: ImplementationSpecific property: ingress.beta.kubernetes.io/url-match-mode: STARTS_WITH
Table 1 Annotations for rewriting headers in forwarding policies Parameter
Type
Description
kubernetes.io/elb.actions.${svc_name}
String
Rewrite the header of the Service associated with an ingress. ${svc_name} indicates the Service name, which contains a maximum of 51 characters.
If the annotation value is set to [], the header rewriting policy is deleted.
An annotation value is in the form of a JSON array. For details, see Table 2.
[{"type":"InsertHeader","InsertHeaderConfig":{"key":"aa","value_type":"USER_DEFINED","value":"aa"}}]
NOTE:A maximum of five configurations are allowed for writing or deleting a header.
Table 2 Array structure Parameter
How to Use
Example
type
Type of header rewriting. Options:
- InsertHeader: indicates that the header will be written. This field must be used with InsertHeaderConfig.
- RemoveHeader: indicates that the header will be deleted. This field must be used with RemoveHeaderConfig.
Other fields are not supported.
None
InsertHeaderConfig
Indicates that the header will be written. This parameter is used only when type is set to InsertHeader.
- key: key of the rewritten header. A key consists of 1 to 40 characters. Only letters, digits, underscores (_), and hyphens (-) are allowed. A key cannot contain any of the following characters (case-insensitive):
connection, upgrade, content-length, transfer-encoding, keep-alive, te, host, cookie, remoteip, authority, x-forwarded-host, x-forwarded-for, x-forwarded-for-port, x-forwarded-tls-certificate-id, x-forwarded-tls-protocol, x-forwarded-tls-cipher, x-forwarded-elb-ip, x-forwarded-port, x-forwarded-elb-id, x-forwarded-elb-vip, x-real-ip, x-forwarded-proto, x-nuwa-trace-ne-in, or x-nuwa-trace-ne-out
- value_type: type of the header to be written. If the header is deleted, this parameter becomes invalid. Options:
- USER_DEFINED: custom header
- REFERENCE_HEADER: header referenced by a user
- SYSTEM_DEFINED: header defined by the system
- value: value of the header to be written. If the header is deleted, this parameter becomes invalid.
If value_type is set to SYSTEM_DEFINED, the value can only be CLIENT-PORT, CLIENT-IP, ELB-PROTOCOL, ELB-ID, ELB-PORT, ELB-EIP, or ELB-VIP.
{ "type": "InsertHeader", "InsertHeaderConfig": { "key": "aa", "value_type": "USER_DEFINED", "value": "aa" } }
RemoveHeaderConfig
Indicates that the header will be deleted. This parameter is used only when type is set to RemoveHeader.
- key: key of the deleted header. A key consists of 1 to 40 characters. Only letters, digits, underscores (_), and hyphens (-) are allowed. A key cannot contain any of the following characters (case-insensitive):
connection, upgrade, content-length, transfer-encoding, keep-alive, te, host, cookie, remoteip, authority, x-forwarded-host, x-forwarded-for, x-forwarded-for-port, x-forwarded-tls-certificate-id, x-forwarded-tls-protocol, x-forwarded-tls-cipher, x-forwarded-elb-ip, x-forwarded-port, x-forwarded-elb-id, x-forwarded-elb-vip, x-real-ip, x-forwarded-proto, x-nuwa-trace-ne-in, or x-nuwa-trace-ne-out
{ "type": "RemoveHeader", "RemoveHeaderConfig": { "key": "ee" } }
- Create an ingress.
kubectl create -f ingress-test.yaml
If information similar to the following is displayed, the ingress has been created:
ingress/ingress-test created
- Check the created ingress.
kubectl get ingress
If information similar to the following is displayed, the ingress has been created:NAME CLASS HOSTS ADDRESS PORTS AGE ingress-test cce * 121.**.**.** 80 10s
Feedback
Was this page helpful?
Provide feedbackThank you very much for your feedback. We will continue working to improve the documentation.See the reply and handling status in My Cloud VOC.
For any further questions, feel free to contact us through the chatbot.
Chatbot