Updated on 2024-01-26 GMT+08:00

Creating Nginx Ingresses on the Console

Prerequisites

  • An ingress provides network access for backend workloads. Ensure that a workload is available in a cluster. If no workload is available, deploy a workload by referring to Creating a Deployment, Creating a StatefulSet, or Creating a DaemonSet.
  • A ClusterIP or NodePort Service has been configured for the workload. For details about how to configure the Service, see ClusterIP or NodePort.
  • To add an Nginx ingress, ensure that the nginx-ingress add-on has been installed in the cluster. For details, see Installing the Add-on.

Precautions

  • It is not recommended modifying any configuration of a load balancer on the ELB console. Otherwise, the Service will be abnormal. If you have modified the configuration, uninstall the nginx-ingress add-on and reinstall it.
  • 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.
  • The selected or created load balancer must be in the same VPC as the current cluster, and it must match the load balancer type (private or public network).
  • The load balancer has at least two listeners, and ports 80 and 443 are not occupied by listeners.

Creating an Nginx Ingress

This section uses an Nginx workload as an example to describe how to create an Nginx ingress.

  1. Log in to the CCE console and click the cluster name to access the cluster console.
  2. Choose Networking in the navigation pane, click the Ingresses tab, and click Create Ingress in the upper right corner.
  3. Configure ingress parameters.

    • Name: Specify a name of an ingress, for example, nginx-ingress-demo.
    • Namespace: Select the namespace to which the ingress is to be added.
    • nginx-ingress: This option is displayed only when the NGNIX Ingress Controller add-on has been installed in the cluster.

      After you switch on , nginx-ingress is interconnected to provide layer-7 access. You can configure the following parameters:

      TLS: nginx-ingress supports HTTP and HTTPS. The default listening port reserved during nginx-ingress installation is 80 for HTTP requests and 443 for HTTPS requests. To use HTTPS, configure the server certificate.

      • Server Certificate: When creating an HTTPS listener, bind a TLS certificate to support encrypted authentication for HTTPS data transmission. For details on how to create a secret, see Creating a Secret.
      • SNI: Server Name Indication (SNI) is an extended protocol of TLS. It allows multiple TLS-based access domain names to be provided for external systems using the same IP address and port. 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.
    • Forwarding Policy: When the access address of a request matches the forwarding policy (a forwarding policy consists of a domain name and URL), the request is forwarded to the corresponding target Service for processing. Click Add Forwarding Policies to add multiple forwarding policies.
      • Domain Name: actual domain name. Ensure that the entered domain name has been registered and archived. After the ingress is created, bind the domain name to the IP address of the automatically created load balancer (IP address of the ingress access address). If a domain name rule is configured, the domain name must always be used for access.
      • URL Matching Rule
        • Default: Prefix match is used by default.
        • 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.
      • URL: access path to be registered, for example, /healthz.
        • The access path matching rule of Nginx ingress is based on the path prefix separated by the slash (/) and is case-sensitive. If the subpath separated by a slash (/) matches the prefix, the access is normal. However, if the prefix is only a part of the character string in the subpath, the access is not matched. For example, if the URL is set to /healthz, /healthz/v1 is matched, but /healthzv1 is not matched.
        • 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 that your Nginx application contains the same URL, that is, /usr/share/nginx/html/test, otherwise, 404 is returned.

      • Destination Service: Select an existing Service or create a Service. Services that do not meet search criteria are automatically filtered out.
      • Destination Service Port: Select the access port of the destination Service.
      • Operation: Click Delete to delete the configuration.
    • Annotation: The value is in the format of key:value. You can use annotations to query the configurations supported by nginx-ingress.

  4. After the configuration is complete, click OK.

    After the ingress is created, it is displayed in the ingress list.