Creating a LoadBalancer Ingress on the Console

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

• Only clusters v1.17 or later support dedicated load balancers.
• It is recommended that other resources not use the load balancer automatically created by an ingress. Otherwise, the load balancer will be occupied when the ingress is deleted, resulting in residual resources.
• After an ingress is created, upgrade and maintain the configuration of the selected load balancers on the CCE console. Do not modify the configuration on the ELB console. Otherwise, the ingress service may be abnormal.
• The URL registered in an ingress forwarding policy must be the same as the URL used to access the backend Service. Otherwise, a 404 error will be returned.
• In an IPVS cluster, if the LoadBalancer ingress and Service share the same load balancer, the ingress cannot be accessed from within the cluster's nodes and containers. This is because kube-proxy binds the LoadBalancer Service address to the ipvs-0 bridge, which intercepts the ELB traffic. Use different load balancers for the LoadBalancer ingress and Service.
• A dedicated load balancer must be of the application type (HTTP/HTTPS) and support private networks (with a private IP address).
• If multiple ingresses access the same ELB port in a cluster, the listener configuration items (such as the certificate associated with the listener and the HTTP/2 attribute of the listener) are subject to the configuration of the first ingress.

This section uses an Nginx workload as an example to describe how to add a LoadBalancer ingress.

1. Log in to the CCE console and click the cluster name to access the cluster console.
2. Choose Services and Ingresses in the navigation pane, click the Ingresses tab, and click Create Ingress in the upper right corner.
3. Configure ingress parameters.
   • Name: Enter a name for the ingress, for example, ingress-demo.
   • Interconnect with Nginx: This option is displayed only after the NGINX Ingress Controller add-on is installed. If this option is available, the NGINX Ingress Controller add-on has been installed. Enabling this option will create an Nginx ingress. Disable it if you want to create a LoadBalancer ingress. For details, see Creating an Nginx Ingress on the Console.
   • Protocol Version: Select a protocol version of the LoadBalancer ingress. This parameter is only available for IPv4/IPv6 dual-stack clusters.
   • Load Balancer: Select a load balancer type and creation mode.

     A load balancer can be dedicated or shared. A dedicated load balancer must be of the application type (HTTP/HTTPS) and support private networks.

     You can select Use existing or Auto create to obtain a load balancer. For details about the configuration of different creation modes, see Table 1.

     Table 1 Load balancer configuration

     How to Create	Configuration
     Use existing	Only the load balancers in the same VPC as the cluster can be selected. If no load balancer is available, click Create Load Balancer to create one on the ELB console.
     Auto create	Instance Name: Enter a load balancer name. Enterprise Project: This parameter is available only for enterprise users who have enabled an enterprise project. Enterprise projects facilitate project-level management and grouping of cloud resources and users. AZ: available only to dedicated load balancers. You can create load balancers in multiple AZs to improve service availability. If disaster recovery is required, you are advised to select multiple AZs. Frontend Subnet: available only to dedicated load balancers. It is used to allocate IP addresses for load balancers to provide services externally. Backend Subnet: available only to dedicated load balancers. It is used to allocate IP addresses for load balancers to access the backend service. Network Specifications, Application-oriented Specifications, or Specifications (available only to dedicated load balancers) Elastic: applies to fluctuating traffic, billed based on total traffic. Clusters v1.21.10-r10, v1.23.8-r10, v1.25.3-r10, and later versions support elastic specifications. Fixed: applies to stable traffic, billed based on specifications. EIP: If you select Auto assign, you can configure the bandwidth size for the public network. Resource Tag: You can add resource tags to classify resources. You can create predefined tags on the TMS console. These tags are available to all resources that support tags. You can use these tags to improve the tag creation and resource migration efficiency.

   • Listener: An ingress configures a listener for the load balancer, which listens to requests from the load balancer and distributes traffic. After the configuration is complete, a listener is created on the load balancer. The default listener name is k8s_<Protocol type>_<Port number>, for example, k8s_HTTP_80.
     • Frontend Protocol: Set the protocol of the load balancer listener for establishing connections with clients.
     • External Port: port number that is open to the ELB service address. The port number is configurable. If you select an existing load balancer, the listener ports of different clusters cannot be reused. Multiple ingresses within the same cluster can share the same listener port, but the listener configuration that works is determined by the earliest ingress configuration.
     • Access Control
       • Inherit ELB Configurations: CCE does not modify the existing access control configurations on the ELB console.
       • Allow all IP addresses: No access control is configured.
       • Trustlist: Only the selected IP address group can access the load balancer.
       • Blocklist: The selected IP address group cannot access the load balancer.
       Note

       For clusters v1.25.16-r10, v1.27.16-r10, v1.28.15-r0, v1.29.10-r0, v1.30.6-r0, v1.31.1-r0, or later, when using a dedicated load balancer, you can select a maximum of five IP address groups at a time for access control.

     • Certificate Source: TLS secret and ELB server certificates are supported.
       • TLS secret: For details about how to create a secret certificate, see Creating a Secret.
       • ELB server certificate: Use a certificate created on ELB.
     • Server Certificate: When an HTTPS listener is created for a load balancer, bind a certificate to the load balancer to support encrypted authentication for HTTPS data transmission.
       Note

       If there is already an HTTPS ingress for the chosen port on the load balancer, the certificate of the new HTTPS ingress must be the same as the certificate of the existing ingress. This means that a listener has only one certificate. If two certificates, each with a different ingress, are added to the same listener of the same load balancer, only the certificate added earliest takes effect on the load balancer.

     • SNI: stands for Server Name Indication (SNI), which is an extended protocol of TLS. SNI allows multiple TLS-compliant domain names for external access using the same IP address and port number, and different domain names can use different security certificates. After SNI is enabled, the client is allowed to submit the requested domain name when initiating a TLS handshake request. After receiving the TLS request, the load balancer searches for the certificate based on the domain name in the request. If the certificate corresponding to the domain name is found, the load balancer returns the certificate for authorization. Otherwise, the default certificate (server certificate) is returned for authorization.
       Note

       • The SNI option is available only when HTTPS is used.

       • This function is supported only in clusters v1.15.11 or later.
       • Only one domain name can be specified for each SNI certificate. Wildcard-domain certificates are supported.
       • For ingresses connected to the same ELB port, do not configure SNIs with the same domain name but different certificates. Otherwise, the SNIs will be overwritten.
     • Security Policy: combinations of different TLS versions and supported cipher suites available to HTTPS listeners. The default value is TLS-1-2.

       For details about security policies, see Elastic Load Balance User Guide.

       Note

       • Security Policy is available only when HTTPS is selected.
       • This function is supported only in clusters v1.17.9 or later.
     • Backend Protocol:

       When the listener is HTTP-compliant, only HTTP can be selected.

       If it is an HTTPS listener, this parameter can be set to HTTP or HTTPS.

     • Advanced Options

       Configuration	Description	Constraint
       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.	This function is available only for dedicated load balancers.
       Transfer Port Number in the Request	If this function is enabled, the source port of the client can be transferred to backend servers through the HTTP header of the packet.	This function is available only for dedicated load balancers.
       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.	This function is available only for dedicated load balancers.
       Data Compression	If this function is enabled, specific files will be compressed. If it is not enabled, files will not be compressed. Brotli can compress all file formats. GZIP can compress the files of the following types: text/xml, text/plain, text/css, application/javascript, application/x-javascript, application/rss+xml, application/atom+xml, application/xml, and application/json	This function is available only for dedicated load balancers.
       Idle Timeout	The duration for which a client connection can remain idle before being terminated. If there are no requests reaching the load balancer during this period, the load balancer will disconnect the connection from the client and establish a new connection when there is a new request.	This configuration is not supported if the port of a shared load balancer uses UDP.
       Request Timeout	The duration within which a request from a client must be received. There are two cases: If the client fails to send a request header to the load balancer during this period, the request will be interrupted. If the interval between two consecutive request bodies reaching the load balancer exceeds this period, the connection will be disconnected.	This function is available only for HTTP and HTTPS listeners.
       Response Timeout	The duration within which a response from the backend server is expected. If the backend server does not respond within this period after receiving a request, the load balancer will stop waiting and return an HTTP 504 error.	This function is available only for HTTP and HTTPS listeners.
       Enable HTTP/2	Whether to enable HTTP/2 for HTTPS requests between the client and the load balancer. Request forwarding using HTTP/2 improves access performance between your application and the load balancer. However, the load balancer still uses HTTP/1.x to forward requests to the backend server.	This function is available only when the listener is HTTPS-compliant.

   • Forwarding Policy: When a request's access address matches the forwarding policy (which consists of a domain name, port, and URL, for example, 10.117.117.117:80/helloworld), the request is forwarded to the target Service for processing. You can click to add multiple forwarding policies.
     • 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:
       • Prefix match: If the URL is set to /healthz, the URL that meets the prefix can be accessed, for example, /healthz/v1 and /healthz/v2.
       • Exact match: The URL can be accessed only when it is fully matched. For example, if the URL is set to /healthz, only /healthz can be accessed.
       • RegEx match: The URL is matched based on the regular expression. For example, if the regular expression is /[A-Za-z0-9_.-]+/test, all URLs that comply with this rule can be accessed, for example, /abcA9/test and /v1-Ab/test. Two regular expression standards are supported: POSIX and Perl.
     • Path: access path, for example, /healthz
       Note

       The access path added here must exist in the backend application. Otherwise, the forwarding fails.

       For example, the default access URL of the Nginx application is /usr/share/nginx/html. When adding /test to the ingress forwarding policy, ensure the access URL of your Nginx application contains /usr/share/nginx/html/test. Otherwise, error 404 will be returned.

     • 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.
     • Set ELB:
       • Algorithm: You can select Weighted round robin, Weighted least connections, or Source IP hash.
         Note

         • Weighted round robin: Requests are forwarded to different servers based on their weights, which indicate server processing performance. Backend servers with higher weights receive proportionately more requests, whereas equal-weighted servers receive the same number of requests. This algorithm is often used for short connections, such as HTTP services.
         • Weighted least connections: In addition to the weight assigned to each server, the number of connections processed by each backend server is considered. Requests are forwarded to the server with the lowest connections-to-weight ratio. This algorithm is based on the least connections algorithm and assigns a weight to each server based on their processing capability. This algorithm is often used for persistent connections, such as database connections.
         • Source IP hash: The source IP address of each request is calculated using the hash algorithm to obtain a unique hash key, and all backend servers are numbered. The generated key allocates the client to a particular server. This enables requests from different clients to be distributed in load balancing mode and ensures that requests from the same client are forwarded to the same server. This algorithm applies to TCP connections without cookies.
       • Sticky Session: This function is disabled by default. Options are as follows:
         • Load balancer cookie: Enter the Stickiness Duration, which ranges from 1 to 1440 minutes.
         • Application cookie: Enter Cookie Name, which ranges from 1 to 64 characters.
         Note

         • When the distribution policy uses the source IP hash, the sticky session cannot be set.
         • Dedicated load balancers in the clusters earlier than v1.21 do not support sticky sessions. If sticky sessions are required, use shared load balancers.
       • Health Check: Set the health check configuration of the load balancer. If this function is enabled, the following configurations are supported:

         Parameter	Description
         Protocol	TCP, HTTP are supported. Check Path: This parameter is only available for HTTP health checks. It specifies the URL for health checks. The check path must start with a slash (/) and contain 1 to 80 characters.
         Port	By default, the service port (NodePort or container port of the Service) is used for health check. You can also specify another port for health check. After the port is specified, a service port named cce-healthz will be added for the Service. Node Port: If a shared load balancer is used or no ENI instance is associated, the node port is used as the health check port. If this parameter is not specified, a random port is used. The value ranges from 30000 to 32767. Container Port: When a dedicated load balancer is associated with a network interface, the container port is used for health check. The value ranges from 1 to 65535.
         Check Period (s)	Specifies the maximum interval between health checks. The value ranges from 1 to 50.
         Timeout (s)	Specifies the maximum timeout for each health check. The value ranges from 1 to 50.
         Max. Retries	Specifies the maximum number of health check retries. The value ranges from 1 to 10.

     • Operation: Click Delete to delete the configuration.
   • Annotation: Ingresses provide some advanced CCE functions, which are implemented by annotations. When you use kubectl to create a container, annotations will be used. For details, see Automatically Creating a Load Balancer While Creating an Ingress or Associating an Existing Load Balancer to an Ingress While Creating the Ingress.

4. Click OK. After the ingress is created, it is displayed in the ingress list.

   On the ELB console, you can check the load balancer automatically created through CCE. The default name is cce-lb-<ingress.UID>. Click the load balancer name to go to the details page. On the Listeners tab page, check the listener and forwarding policy of the target ingress.

   Notice

   After an ingress is created, upgrade and maintain the selected load balancer on the CCE console. Do not modify the configuration on the ELB console. Otherwise, the ingress service may be abnormal.

5. Access the /healthz interface of the workload, for example, workload defaultbackend.
   1. Obtain the access address of the /healthz interface of the workload. The access address consists of the load balancer IP address, external port, and mapping URL, for example, 10.**.**.**:80/healthz.
   2. Enter the URL of the /healthz interface, for example, http://10.**.**.**:80/healthz, in the address box of the browser to access the workload, as shown in Figure 1.

      Figure 1 Accessing the /healthz interface of defaultbackend