Configuring Advanced Forwarding Rules for a LoadBalancer Ingress

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.

Notes and Constraints

• This feature is only available when dedicated load balancers are used.
• This feature relies on the ELB advanced forwarding policies. Once the ELB advanced forwarding policies are enabled, the forwarding policy priority is not determined by the domain name or path matching. You can customize the forwarding policy priority as needed. For details about the forwarding policy priority, see Forwarding Policy Priorities of LoadBalancer Ingresses.

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: ab53c3b2-xxxx-xxxx-xxxx-5ac3eb2887be
       kubernetes.io/elb.port: '80'
       # Access the svc-hello1 service. Ensure that this service is available.
       kubernetes.io/elb.conditions.svc-hello1: |  
           [ 
             { 
               "type": "Method", 
               "methodConfig": { 
                 "values": [ 
                   "GET", 
                   "POST" 
                 ] 
               } 
             }, 
             { 
               "type": "Header", 
               "headerConfig": { 
                 "key": "gray-hello", 
                 "values": [ 
                   "value1", 
                   "value2" 
                 ] 
               } 
             }, 
             { 
               "type": "Cookie", 
               "cookieConfig": { 
                 "values": [ 
                   { 
                     "key": "querystringkey1", 
                     "value": "querystringvalue2" 
                   }, 
                   { 
                     "key": "querystringkey3", 
                     "value": "querystringvalue4" 
                   } 
                 ] 
               } 
             }, 
             { 
               "type": "QueryString", 
               "queryStringConfig": { 
                 "key": "testKey", 
                 "values": [ 
                   "testValue" 
                 ] 
               } 
             }, 
             { 
               "type": "SourceIp", 
               "sourceIpConfig": { 
                 "values": [ 
                   "192.168.0.0/16", 
                   "172.16.0.0/16" 
                 ] 
               } 
             } 
           ] 
     name: ingress-test 
   spec: 
     ingressClassName: cce 
     rules: 
      - http: 
         paths: 
         - path: /hello1 
           pathType: ImplementationSpecific 
           backend: 
             service: 
               name: svc-hello1 
               port: 
                 number: 80

   Table 1 Annotations for advanced forwarding rules

   Parameter	Type	Description
   kubernetes.io/elb.conditions.${svc_name}	String	Configure an advanced forwarding rule. ${svc_name} indicates the Service name, which can contain a maximum of 48 characters. If the annotation value is set to [], the advanced forwarding rule is deleted. An annotation value is in the form of a JSON array. For details, see Table 2. NOTICE: The rules in a condition array are connected by an AND relationship, while the values in the same rule block are connected by an OR relationship. For example, if both Method and QueryString are configured, the target traffic can be distributed only when both rules are met. However, if the Method value is GET or POST, the target traffic can be distributed only when both rules are met and the Method value must be GET or POST.

   Table 2 Array structure

   Parameter	How to Use	Example
   type	Matching type. Options: Method: HTTP requests are forwarded based on the matched method. This parameter must be used with methodConfig. This parameter can be configured only once. Header: HTTP requests are forwarded based on the matched header. This parameter must be used with headerConfig. Cookie: HTTP requests are forwarded based on the matched cookie. This parameter must be used with cookieConfig. QueryString: HTTP requests are forwarded based on the matched character string. This parameter must be used with queryStringConfig. SourceIp: HTTP requests are forwarded based on the matched CIDR block. This parameter must be used with sourceIpConfig. This parameter can be configured only once.	None
   methodConfig	An HTTP request method that is used to forward requests. This parameter is used only when type is set to Method. Multiple request methods can be concurrently configured, including GET, POST, PUT, DELETE, PATCH, HEAD, and OPTIONS.	You only need to configure values (an array) for methodConfig. { "type": "Method", "methodConfig": { "values": [ "GET", "POST" ] } }
   headerConfig	An HTTP request header that is used to forward requests. This parameter is used only when type is set to Header. A key can only contain letters, digits, underscores (_), and hyphens (-). The first letter of the User-agent and Connection HTTP request headers must be capitalized. Multiple values can be configured for a key. A value can only contain letters, digits, and special characters (!#$%&'()*+,.\/:;<=>?@[]^-_'{|}~). Asterisks (*) and question marks (?) can be used as wildcard characters.	You can only configure one key for each headerConfig rule. If you need multiple keys, configure multiple headerConfig rules. { "type": "Header", "headerConfig": { "key": "gray-hello", "values": [ "value1", "value2" ] } }
   cookieConfig	A cookie that is used to forward requests. This parameter is used only when type is set to Cookie. A cookie consists of a key and a value, which must be configured separately. A key can contain 1 to 100 characters and cannot start or end with a space. A value can contain 1 to 100 characters. Configure a value for each key. You can enter multiple key-value pairs that can contain letters, digits, and special characters (!%'"()*+,./:=?@^-_`~).	When configuring cookieConfig, you can configure multiple key-value pairs in values, and these pairs will have an OR relationship with each other. { "type": "Cookie", "cookieConfig": { "values": [ { "key": "querystringkey1", "value": "querystringvalue2" }, { "key": "querystringkey3", "value": "querystringvalue4" } ] } }
   queryStringConfig	A character string that is used to forward requests. If the character string in a request matches the one in the configured forwarding rule, the request will be forwarded. This parameter is used only when type is set to QueryString. A query string consists of a key and one or more values. Configure the key and values separately. A key can only contain letters, digits, and special characters (!$'()*+,./:;=?@^-_'). Multiple values can be configured for a key. A value can only contain letters, digits, and special characters (!$'()*+,./:;=?@^-_'). Asterisks (*) and question marks (?) can be used as wildcard characters.	You can only configure one key for each queryStringConfig rule. If you need multiple keys, configure multiple QueryStringConfig rules. { "type": "QueryString", "queryStringConfig": { "key": "testKey", "values": [ "testValue" ] } }
   sourceIpConfig	A CIDR block that is used to forward requests. This parameter is used only when type is set to SourceIp. Example CIDR block: 192.168.1.0/24 or 2020:50::44/127	You only need to configure values (an array) for sourceIpConfig. { "type": "SourceIp", "sourceIpConfig": { "values": [ "192.168.0.0/16", "172.16.0.0/16" ] } }

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