Updated on 2024-11-12 GMT+08:00

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

  1. Use kubectl to access the cluster. For details, see Connecting to a Cluster Using kubectl.
  2. 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"
       }
    }

  3. 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

  4. 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