Configuring an HTTP/HTTPS Header 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.13-r0 or later
  • v1.25: v1.25.8-r0 or later
  • v1.27: v1.27.5-r0 or later
  • v1.28: v1.28.3-r0 or later
  • Other clusters of later versions
• An available workload has been deployed in the cluster for external access. If no workload is available, deploy a workload by referring to Creating a Deployment, Creating a StatefulSet, or Creating a DaemonSet.
• A Service for external access has been configured for the workload. Services Supported by LoadBalancer Ingresses lists the Service types supported by LoadBalancer ingresses.

Notes and Constraints

• Ingresses support HTTP to HTTPS headers only when dedicated load balancers are used.
• If multiple ingresses share the same external port on a load balancer, you are advised to use the same HTTP/HTTPS header for these ingresses. Otherwise, the configuration of the first created ingress will take precedence. For details, see Configuring Multiple Ingresses to Use the Same External ELB Port.

Using the CCE Console to Configure an HTTP/HTTPS Header

1. Log in to the CCE console and click the cluster name to access the cluster console.
2. In the navigation pane, choose Services & Ingresses. Click the Ingresses tab and click Create Ingress in the upper right corner.
3. Configure ingress parameters.
   Note

   This example explains only key parameters for configuring HTTP/HTTPS headers. You can configure other parameters as required. For details, see Creating a LoadBalancer Ingress on the Console.

   Table 2 Key parameters

   Parameter	Description	Example
   Name	Enter an ingress name.	ingress-test
   Load Balancer	Select a load balancer to be associated with the ingress or automatically create a load balancer. In this example, only dedicated load balancers are supported.	Dedicated
   Listener	External Protocol: HTTP and HTTPS are available. External Port: specifies the port of the load balancer listener. Advanced Options Transfer Listener Port Number: If this function is enabled, the listening port on the load balancer can be transferred to backend servers through the HTTP header of the packet. Transfer Port Number in the Request: If this function is enabled, the source port on the client can be transferred to backend servers through the HTTP header of the packet. Rewrite X-Forwarded-Host: If this function is enabled, X-Forwarded-Host will be rewritten using the Host field in the client request header and transferred to backend servers.	External Protocol: HTTP External Port: 80 Advanced Options Transfer Listener Port Number: Enable Transfer Port Number in the Request: Enable Rewrite X-Forwarded-Host: Enable
   Forwarding Policy	Domain Name: Enter an actual domain name to be accessed. If it is left blank, the ingress can be accessed through the IP address. Ensure that the domain name has been registered and licensed. Once a forwarding policy is configured with a domain name specified, you must use the domain name for access. Path Matching Rule: Select Prefix match, Exact match, or RegEx match. Path: Enter the path provided by a backend application for external access. The path added must be valid in the backend application, or the forwarding cannot take effect. Destination Service: Select an existing Service. Only Services that meet the requirements are automatically displayed in the Service list. Destination Service Port: Select the access port of the destination Service.	Domain Name: You do not need to configure this parameter. Path Matching Rule: Prefix match Path: / Destination Service: nginx Destination Service Port: 80

4. Click OK.

Using kubectl to Configure an HTTP/HTTPS Header

1. Use kubectl to access the cluster. For details, see Accessing 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 associated with an existing load balancer is as follows:

   apiVersion: networking.k8s.io/v1
   kind: Ingress 
   metadata: 
     name: ingress-test
     annotations: 
       kubernetes.io/elb.id: <your_elb_id>                 # Replace it with the ID of your existing load balancer.
       kubernetes.io/elb.class: performance                # Load balancer type
       kubernetes.io/elb.port: '80'
       kubernetes.io/elb.x-forwarded-port: 'true'         # Obtain the listener port number.
       kubernetes.io/elb.x-forwarded-for-port: 'true'     # Obtain the client port number for requests.
       kubernetes.io/elb.x-forwarded-host: 'true'         # Rewrite X-Forwarded-Host.
   spec:
     rules: 
     - host: ''
       http: 
         paths: 
         - path: '/'
           backend: 
             service:
               name: <your_service_name>  # Replace it with the name of your target Service.
               port: 
                 number: 80             # Replace 80 with the port number of your target Service.
           property:
             ingress.beta.kubernetes.io/url-match-mode: STARTS_WITH
           pathType: ImplementationSpecific
     ingressClassName: cce     
   
   

   Table 3 Key parameters

   Parameter	Type	Description
   kubernetes.io/elb.x-forwarded-port	String	A load balancer can obtain the port number of a listener using X-Forwarded-Port and transmit the port number to the packets of the backend server. true: Enable the function of obtaining a listener port number. false: Disable the function of obtaining a listener port number.
   kubernetes.io/elb.x-forwarded-for-port	String	A load balancer can obtain a client port number for requests using X-Forwarded-For-Port and transmit the port number to the packets of the backend server. true: Enable the function of obtaining a client port number for requests. false: Disable the function of obtaining a client port number for requests.
   kubernetes.io/elb.x-forwarded-host	String	true: Enable the function of rewriting X-Forwarded-Host. Then, the X-Forwarded-Host header will be rewritten using the Host header of the client request and transmitted to backend servers. false: Disable the function of rewriting X-Forwarded-Host. Then, the X-Forwarded-Host header of the client will be transmitted to backend servers.

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