All Products
Search

This Product

    Container Service for Kubernetes:Advanced NGINX Ingress configurations

    Document Center

    Container Service for Kubernetes:Advanced NGINX Ingress configurations

    Last Updated:Mar 26, 2026

    In a Kubernetes cluster, an NGINX Ingress manages external access to services and provides Layer 7 load balancing. You can use an NGINX Ingress to configure externally accessible URLs, rewrite rules, HTTPS services, and canary release features. This topic describes how to configure secure routing, set up HTTPS mutual authentication, use regular expressions and wildcard domain names, and request free HTTPS certificates.

    Prerequisites

    Before you begin, make sure you have:

    Configuration methods

    The NGINX Ingress controller in Container Service for Kubernetes (ACK) is fully compatible with the open source community. For more information, see NGINX Configuration.

    Three configuration methods are supported:

    Method Scope Reference
    Annotation-based Per-Ingress — configure annotations in the YAML file of a specific NGINX Ingress Annotations
    ConfigMap-based Global — configure the kube-system/nginx-configuration ConfigMap to apply settings to all NGINX Ingresses ConfigMaps
    Custom NGINX template Advanced — modify the internal NGINX template directly when annotation-based and ConfigMap-based methods cannot meet your requirements Custom NGINX template

    Configure URL redirection

    By default, the NGINX Ingress controller forwards requests based on the full request path. For example, a request to /service1/api is forwarded directly to /service1/api on the backend pod. If the backend service path is /api, a 404 error is returned because the path does not match. Use the nginx.ingress.kubernetes.io/rewrite-target annotation to rewrite the request path to the correct directory.

    Create an NGINX Ingress based on your cluster version.

    Clusters that run Kubernetes 1.19 or later

    apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: foo.bar.com
  namespace: default
  annotations:
    # URL redirection.
    nginx.ingress.kubernetes.io/rewrite-target: /$2
spec:
  rules:
  - host: foo.bar.com
    http:
      paths:
    # If the Ingress controller version is 0.22.0 or later, you must use a regular expression to define the path in the path field and use it with a capturing group in the rewrite-target annotation.
      - path: /svc(/|$)(.*)
        backend:
          service:
            name: web1-service
            port:
              number: 80
        pathType: ImplementationSpecific

    Clusters that run Kubernetes versions earlier than 1.19

    apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: foo.bar.com
  namespace: default
  annotations:
    # URL redirection.
    nginx.ingress.kubernetes.io/rewrite-target: /$2
spec:
  rules:
  - host: foo.bar.com
    http:
      paths:
      # If the Ingress controller version is 0.22.0 or later, you must use a regular expression to define the path in the path field and use it with a capturing group in the rewrite-target annotation.
      - path: /svc(/|$)(.*)
        backend:
          serviceName: web1-service
          servicePort: 80

    After deploying the Ingress, verify the configuration:

    1. Get the Ingress address.

      kubectl get ingress

      Expected output:

      NAME           CLASS   HOSTS                ADDRESS          PORTS   AGE
foo.bar.com    nginx   foo.bar.com        172.16.XX.XX       80      46m

    2. Test the rewrite rule. Replace ADDRESS with the IP address from the previous step.

      curl -k -H "Host: foo.bar.com"  http://<ADDRESS>/svc/foo

      Expected output:

      web1: /foo

    Configure advanced rewrite rules

    For basic URL rewrite, use the nginx.ingress.kubernetes.io/rewrite-target annotation as described in Configure URL redirection.

    For complex rewrite requirements, use the following annotations to add custom snippets to the NGINX configuration:

    Annotation Where it applies
    nginx.ingress.kubernetes.io/server-snippet Adds a configuration snippet to the NGINX server block
    nginx.ingress.kubernetes.io/configuration-snippet Adds a configuration snippet to the NGINX location block

    Example:

    annotations:
     nginx.ingress.kubernetes.io/server-snippet: |
         rewrite ^/v4/(.*)/card/query http://foo.bar.com/v5/#!/card/query permanent;
     nginx.ingress.kubernetes.io/configuration-snippet: |
         rewrite ^/v6/(.*)/card/query http://foo.bar.com/v7/#!/card/query permanent;

    To view the generated NGINX configuration, run the following command. Replace the pod name with the actual NGINX Ingress controller pod name in your cluster.

    kubectl exec nginx-ingress-controller-xxxxx --namespace kube-system -- cat /etc/nginx/nginx.conf

    The configuration above generates the following nginx.conf output:

    # start server foo.bar.com
    server {
        server_name foo.bar.com ;
        listen 80;
        listen [::]:80;
        set $proxy_upstream_name "-";
    # server-snippet configuration.
        rewrite ^/v4/(.*)/card/query http://foo.bar.com/v5/#!/card/query permanent;
        ...
    # configuration-snippet configuration.
      rewrite ^/v6/(.*)/card/query http://foo.bar.com/v7/#!/card/query permanent;
      ...
    }
    # end server foo.bar.com

    The snippet annotations also support global configurations. For more information, see server-snippet. For the full NGINX rewrite directive reference, see the official NGINX documentation.

    Configure an HTTPS certificate

    Use the native Ingress TLS semantics to configure an HTTPS certificate for your service.

    1. Prepare your TLS certificate.

      1. Generate a self-signed certificate and private key. ``bash openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout tls.key -out tls.crt -subj "/CN=foo.bar.com/O=foo.bar.com" ``

      2. Create a Kubernetes Secret from the certificate and private key. Reference this Secret in the Ingress.

        kubectl create secret tls tls-test-ingress --key tls.key --cert tls.crt
      The certificate's CN (Common Name) must match the host configured in the Ingress. If they do not match, the NGINX Ingress controller cannot load the certificate.

    2. Create an Ingress resource that references the Secret in the tls field. Kubernetes 1.19 or later

      Clusters that run Kubernetes 1.19 or later

      apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: test-test-ingress
spec:
  # Reference the TLS certificate.
  tls:
  - hosts:
    - foo.bar.com # The domain name that corresponds to the certificate.
    secretName: tls-test-ingress
  rules:
  - host: tls-test-ingress.com
    http:
      paths:
      - path: /foo
        backend:
          service:
            name: web1-svc
            port:
              number: 80
        pathType: ImplementationSpecific

      Clusters that run Kubernetes versions earlier than 1.19

      apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: test-test-ingress
spec:
  # Reference the TLS certificate.
  tls:
  - hosts:
    - foo.bar.com # The domain name that corresponds to the certificate.
    secretName: tls-test-ingress
  rules:
  - host: tls-test-ingress.com
    http:
      paths:
      - path: /foo
        backend:
          serviceName: web1-svc
          servicePort: 80

    3. Update your /etc/hosts file or use a real domain name to access the TLS service at https://tls-test-ingress.com/foo.

    Configure HTTPS mutual authentication

    HTTPS mutual authentication (mTLS) requires both the server and the client to present certificates, providing stronger connection security than one-way TLS. The NGINX Ingress controller supports mTLS through annotations.

    Step 1: Create the certificates

    1. Create a self-signed CA certificate.

      openssl req -x509 -sha256 -newkey rsa:4096 -keyout ca.key -out ca.crt -days 356 -nodes -subj '/CN=Fern Cert Authority'

      Expected output:

      Generating a 4096 bit RSA private key
.............................................................................................................++
.....................................................................................++
writing new private key to 'ca.key'

    2. Create the server-side certificate.

      1. Generate the certificate signing request (CSR).

        openssl req -new -newkey rsa:4096 -keyout server.key -out server.csr -nodes -subj '/CN=foo.bar.com'

        Expected output:

        Generating a 4096 bit RSA private key
................................................................................................................................++
.................................................................++
writing new private key to 'server.key'

      2. Sign the CSR with the CA certificate.

        openssl x509 -req -sha256 -days 365 -in server.csr -CA ca.crt -CAkey ca.key -set_serial 01 -out server.crt

        Expected output:

        Signature ok
subject=/CN=foo.bar.com
Getting CA Private Key

    3. Create the client-side certificate.

      1. Generate the client CSR.

        openssl req -new -newkey rsa:4096 -keyout client.key -out client.csr -nodes -subj '/CN=Fern'

        Expected output:

        Generating a 4096 bit RSA private key
.......................................................................................................................................................................................++
..............................................++
writing new private key to 'client.key'
-----

      2. Sign the client CSR with the CA certificate.

        openssl x509 -req -sha256 -days 365 -in client.csr -CA ca.crt -CAkey ca.key -set_serial 02 -out client.crt

        Expected output:

        Signature ok
subject=/CN=Fern
Getting CA Private Key

    4. Confirm all certificate files are present.

      ls

      Expected output:

      ca.crt  ca.key  client.crt  client.csr  client.key  server.crt  server.csr  server.key

    Step 2: Create Secrets

    1. Create a Secret for the CA certificate.

      kubectl create secret generic ca-secret --from-file=ca.crt=ca.crt

      Expected output:

      secret/ca-secret created

    2. Create a Secret for the server certificate.

      kubectl create secret generic tls-secret --from-file=tls.crt=server.crt --from-file=tls.key=server.key

      Expected output:

      secret/tls-secret created

    Step 3: Deploy the Ingress

    Deploy the following template to create an mTLS-enabled NGINX Ingress.

    Clusters that run Kubernetes 1.19 or later

    apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/auth-tls-verify-client: "on"
    nginx.ingress.kubernetes.io/auth-tls-secret: "default/ca-secret"
    nginx.ingress.kubernetes.io/auth-tls-verify-depth: "1"
    nginx.ingress.kubernetes.io/auth-tls-pass-certificate-to-upstream: "true"
  name: nginx-test
  namespace: default
spec:
  rules:
  - host: foo.bar.com
    http:
      paths:
      - backend:
          service:
            name: http-svc
            port:
              number: 80
        path: /
        pathType: ImplementationSpecific
  tls:
  - hosts:
    - foo.bar.com
    secretName: tls-secret

    Clusters that run Kubernetes versions earlier than 1.19

    apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/auth-tls-verify-client: "on"
    nginx.ingress.kubernetes.io/auth-tls-secret: "default/ca-secret"
    nginx.ingress.kubernetes.io/auth-tls-verify-depth: "1"
    nginx.ingress.kubernetes.io/auth-tls-pass-certificate-to-upstream: "true"
  name: nginx-test
  namespace: default
spec:
  rules:
  - host: foo.bar.com
    http:
      paths:
      - backend:
          serviceName: http-svc
          servicePort: 80
        path: /
  tls:
  - hosts:
    - foo.bar.com
    secretName: tls-secret

    Expected output:

    ingress.networking.k8s.io/nginx-test configured

    Step 4: Verify

    1. Get the Ingress IP address.

      kubectl get ing

      The ADDRESS field contains the Ingress IP address:

      NAME         HOSTS                    ADDRESS         PORTS     AGE
nginx-test   foo.bar.com              39.102.XX.XX    80, 443   4h42m

    2. Update /etc/hosts. Replace the placeholder IP address with the actual Ingress IP address.

      echo "39.102.XX.XX  foo.bar.com" | sudo tee -a /etc/hosts

    3. Test access without a client certificate — the server should reject the request.

      curl --cacert ./ca.crt  https://foo.bar.com

      Expected output:

      <html>
<head><title>400 No required SSL certificate was sent</title></head>
<body>
<center><h1>400 Bad Request</h1></center>
<center>No required SSL certificate was sent</center>
<hr><center>nginx/1.19.0</center>
</body>
</html>

    4. Test access with a client certificate — the request should succeed.

      curl --cacert ./ca.crt --cert ./client.crt --key ./client.key https://foo.bar.com

      Expected output:

      <!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
    body {
        width: 35em;
        margin: 0 auto;
        font-family: Tahoma, Verdana, Arial, sans-serif;
    }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>

<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>

<p>Thank you for using nginx!</p>
</body>
</html>

    Forward traffic to an HTTPS backend

    By default, the NGINX Ingress controller forwards requests to backend containers over HTTP. If your backend container uses HTTPS, add the nginx.ingress.kubernetes.io/backend-protocol: "HTTPS" annotation to forward traffic over HTTPS.

    Clusters that run Kubernetes 1.19 or later

    apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: backend-https
  annotations:
    # Note: You must specify that the backend service is an HTTPS service.
    nginx.ingress.kubernetes.io/backend-protocol: "HTTPS"
spec:
  tls:
  - hosts:
    - <YOUR-HOST-NAME>
    secretName: <YOUR-SECRET-CERT-NAME>
  rules:
  - host: <YOUR-HOST-NAME>
    http:
      paths:
      - path: /
        backend:
          service:
            name: <YOUR-SERVICE-NAME>
            port:
              number: <YOUR-SERVICE-PORT>
        pathType: ImplementationSpecific

    Clusters that run Kubernetes versions earlier than 1.19

    apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: backend-https
  annotations:
    # Note: You must specify that the backend service is an HTTPS service.
    nginx.ingress.kubernetes.io/backend-protocol: "HTTPS"
spec:
  tls:
  - hosts:
    - <YOUR-HOST-NAME>
    secretName: <YOUR-SECRET-CERT-NAME>
  rules:
  - host: <YOUR-HOST-NAME>
    http:
      paths:
      - path: /
        backend:
          serviceName: <YOUR-SERVICE-NAME>
          servicePort: <YOUR-SERVICE-PORT>

    Configure domain names with regular expressions

    Kubernetes Ingress resources do not support regular expressions in the host field natively. Use the nginx.ingress.kubernetes.io/server-alias annotation to add regex-based domain name matching.

    1. Deploy the following Ingress. This example uses the regular expression ~^www\.\d+\.example\.com. Kubernetes 1.19 or later

      Clusters that run Kubernetes 1.19 or later

      apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ingress-regex
  namespace: default
  annotations:
    nginx.ingress.kubernetes.io/server-alias: '~^www\.\d+\.example\.com$, abc.example.com'
spec:
  rules:
  - host: foo.bar.com
    http:
      paths:
      - path: /foo
        backend:
          service:
            name: http-svc1
            port:
              number: 80
        pathType: ImplementationSpecific

      Clusters that run Kubernetes versions earlier than 1.19

      apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: ingress-regex
  namespace: default
  annotations:
    nginx.ingress.kubernetes.io/server-alias: '~^www\.\d+\.example\.com$, abc.example.com'
spec:
  rules:
  - host: foo.bar.com
    http:
      paths:
      - path: /foo
        backend:
          serviceName: http-svc1
          servicePort: 80

    2. Verify the configuration in the NGINX Ingress controller.

      1. List the NGINX Ingress controller pods.

        kubectl get pods -n kube-system | grep nginx-ingress-controller

        Expected output:

        nginx-ingress-controller-77cd987c4c-c****         1/1     Running   0          1h
nginx-ingress-controller-77cd987c4c-x****         1/1     Running   0          1h

      2. Inspect the server_name field in the generated NGINX configuration.

        kubectl exec -n kube-system nginx-ingress-controller-77cd987c4c-c**** cat /etc/nginx/nginx.conf | grep -C3 "foo.bar.com"

        Expected output:

          # start server foo.bar.com
  server {
--
  server {
    server_name foo.bar.com abc.example.com ~^www\.\d+\.example\.com$ ;
    listen 80  ;
    listen 443  ssl http2 ;
--
--
    }
  }
  # end server foo.bar.com

    3. Get the Ingress IP address.

      kubectl get ing

      Expected output:

      NAME            HOSTS         ADDRESS          PORTS     AGE
ingress-regex   foo.bar.com   101.37.XX.XX     80        11s

    4. Test service access with different host headers. Replace IP_ADDRESS with the Ingress IP address from the previous step.

      • Access using foo.bar.com:

        curl -H "Host: foo.bar.com" <IP_ADDRESS>/foo

        Expected output:

        /foo

      • Access using www.123.example.com (matches the regex):

        curl -H "Host: www.123.example.com" <IP_ADDRESS>/foo

        Expected output:

        /foo

      • Access using www.321.example.com (also matches the regex):

        curl -H "Host: www.321.example.com" <IP_ADDRESS>/foo

        Expected output:

        /foo

    Configure wildcard domain names

    NGINX Ingress supports wildcard domain names. The following example configures *.ingress-regex.com to match any subdomain.

    1. Deploy the following Ingress.

      Clusters that run Kubernetes 1.19 or later

      apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ingress-regex
  namespace: default
spec:
  rules:
  - host: *.ingress-regex.com
    http:
      paths:
      - path: /foo
        backend:
          service:
            name: http-svc1
            port:
              number: 80
        pathType: ImplementationSpecific

      Clusters that run Kubernetes versions earlier than 1.19

      apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: ingress-regex
  namespace: default
spec:
  rules:
  - host: *.ingress-regex.com
    http:
      paths:
      - path: /foo
        backend:
          serviceName: http-svc1
          servicePort: 80

    2. Check the server_name field in the NGINX configuration. Replace <nginx-ingress-pod-name> with the actual NGINX Ingress pod name.

      kubectl exec -n kube-system <nginx-ingress-pod-name> cat /etc/nginx/nginx.conf | grep -C3 "*.ingress-regex.com"

      Expected output:

      # start server *.ingress-regex.com
  server {
    server_name *.ingress-regex.com ;
    listen 80;
    listen [::]:80;
...
  }
  # end server *.ingress-regex.com

      In newer versions of the NGINX Ingress controller, the output is:

      ## start server *.ingress-regex.com
  server {
    server_name ~^(?<subdomain>[\w-]+)\.ingress-regex\.com$ ;
    listen 80;
    listen [::]:80;
...
  }
  ## end server *.ingress-regex.com

    3. Get the Ingress IP address.

      kubectl get ing

      Expected output:

      NAME            HOSTS                 ADDRESS           PORTS     AGE
ingress-regex   *.ingress-regex.com   101.37.XX.XX      80        11s

    4. Test access with different subdomains. Replace IP_ADDRESS with the Ingress IP address from the previous step.

      • Access using abc.ingress-regex.com:

        curl -H "Host: abc.ingress-regex.com" <IP_ADDRESS>/foo

        Expected output:

        /foo

      • Access using 123.ingress-regex.com:

        curl -H "Host: 123.ingress-regex.com" <IP_ADDRESS>/foo

        Expected output:

        /foo

      • Access using a1b1.ingress-regex.com:

        curl -H "Host: a1b1.ingress-regex.com" <IP_ADDRESS>/foo

        Expected output:

        /foo

    Implement canary releases

    Use canary annotations to route a subset of traffic to a new service version without a full deployment. Enable canary routing by setting nginx.ingress.kubernetes.io/canary: "true" on the canary Ingress, then combine it with one or more routing strategy annotations.

    Annotation Type Description
    nginx.ingress.kubernetes.io/canary-weight Integer (0–100) Percentage of requests routed to the canary service
    nginx.ingress.kubernetes.io/canary-by-header String Route based on a request header. When the header value is always, all traffic goes to the canary service. When the value is never, no traffic goes to the canary service. Other values fall through to lower-priority rules.
    nginx.ingress.kubernetes.io/canary-by-header-value String Use with canary-by-header — routes to the canary service only when the header matches this exact value
    nginx.ingress.kubernetes.io/canary-by-cookie String Route based on a cookie. Supports always and never only.
    Rule priority from highest to lowest: header-based → cookie-based → weight-based. Cookie-based canary routing supports only the always and never values.

    The following examples show common canary configurations. For a complete guide including blue-green deployments, see Use an NGINX Ingress to implement canary releases and blue-green deployments.

    Weight-based canary release — route 20% of traffic to the canary service:

    apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    kubernetes.io/ingress.class: nginx
    nginx.ingress.kubernetes.io/canary: "true"
    nginx.ingress.kubernetes.io/canary-weight: "20"

    Header-based canary release — when the request header ack is always, route to the canary service; when it is never, skip the canary service; for other header values, route based on weight:

    apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    kubernetes.io/ingress.class: nginx
    nginx.ingress.kubernetes.io/canary: "true"
    nginx.ingress.kubernetes.io/canary-weight: "50"
    nginx.ingress.kubernetes.io/canary-by-header: "ack"

    Header-based canary release with a custom value — route to the canary service only when the ack header is exactly alibaba; otherwise apply weight-based routing:

    apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    kubernetes.io/ingress.class: nginx
    nginx.ingress.kubernetes.io/canary: "true"
    nginx.ingress.kubernetes.io/canary-weight: "20"
    nginx.ingress.kubernetes.io/canary-by-header: "ack"
    nginx.ingress.kubernetes.io/canary-by-header-value: "alibaba"

    Cookie-based canary release — when no header rule matches and the cookie hangzhou_region is always, route to the canary service:

    apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    kubernetes.io/ingress.class: nginx
    nginx.ingress.kubernetes.io/canary: "true"
    nginx.ingress.kubernetes.io/canary-weight: "20"
    nginx.ingress.kubernetes.io/canary-by-header: "ack"
    nginx.ingress.kubernetes.io/canary-by-header-value: "alibaba"
    nginx.ingress.kubernetes.io/canary-by-cookie: "hangzhou_region"

    Request a free HTTPS certificate with cert-manager

    cert-manager is an open source certificate management tool that provisions and automatically renews HTTPS certificates in a cluster.

    Important

    cert-manager is an open source component that ACK does not maintain. Use it with caution in production environments. To upgrade the version, see Upgrading cert-manager.

    1. Deploy cert-manager.

      kubectl apply -f https://github.com/cert-manager/cert-manager/releases/latest/download/cert-manager.yaml

    2. Verify the cert-manager pods are running.

      kubectl get pods -n cert-manager

      Expected output:

      NAME                     READY   STATUS    RESTARTS   AGE
cert-manager-1           1/1     Running   0          2m11s
cert-manager-cainjector  1/1     Running   0          2m11s
cert-manager-webhook     1/1     Running   0          2m10s

    3. Create a ClusterIssuer using the Let's Encrypt HTTP01 challenge.

      apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-prod-http01
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    email: <your_email@example.com>  # Replace this with your email address.
    privateKeySecretRef:
      name: letsencrypt-http01
    solvers:
    - http01:
        ingress:
          class: nginx

    4. Verify the ClusterIssuer is ready.

      kubectl get clusterissuer

      Expected output:

      NAME                         READY   AGE
letsencrypt-prod-http01      True    17s

    5. Create an Ingress resource that references the ClusterIssuer. Kubernetes 1.19 or later

      The domain name must meet the following requirements: no more than 64 characters, no wildcard domain names, and accessible over the public network using HTTP.

      Clusters that run Kubernetes 1.19 or later

      apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ingress-tls
  annotations:
    kubernetes.io/ingress.class: "nginx"
    cert-manager.io/cluster-issuer: "letsencrypt-prod-http01"
spec:
  tls:
  - hosts:
    - <YOUR_DOMAIN_NAME>        # Replace this with your domain name.
    secretName: ingress-tls
  rules:
  - host: <YOUR_DOMAIN_NAME>    # Replace this with your domain name.
    http:
      paths:
      - path: /
        backend:
          service:
            name: <YOUR_SERVICE_NAME>  # Replace this with your backend service name.
            port:
              number: <YOUR_SERVICE_PORT>  # Replace this with your service port.
        pathType: ImplementationSpecific

      Clusters that run Kubernetes versions earlier than 1.19

      apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: ingress-tls
  annotations:
    kubernetes.io/ingress.class: "nginx"
    cert-manager.io/cluster-issuer: "letsencrypt-prod-http01"
spec:
  tls:
  - hosts:
    - <YOUR_DOMAIN_NAME>        # Replace this with your domain name.
    secretName: ingress-tls
  rules:
  - host: <YOUR_DOMAIN_NAME>    # Replace this with your domain name.
    http:
      paths:
      - path: /
        backend:
          serviceName: <YOUR_SERVICE_NAME>  # Replace this with your backend service name.
          servicePort: <YOUR_SERVICE_PORT>  # Replace this with your service port.

    6. Verify the certificate is issued.

      kubectl get cert

      Expected output:

      NAME          READY   SECRET        AGE
ingress-tls   True    ingress-tls   52m

      If READY is not True, run kubectl describe cert ingress-tls to inspect the certificate processing procedure.

    7. Verify the TLS Secret.

      kubectl get secret ingress-tls

      Expected output:

      NAME          TYPE                DATA   AGE
ingress-tls   kubernetes.io/tls   2      2m

    8. Access the service at https://<YOUR_DOMAIN_NAME> in a browser.

    Configure HTTP to HTTPS redirection

    Use the nginx.ingress.kubernetes.io/ssl-redirect annotation to force HTTP traffic to redirect to HTTPS.

    Clusters that run Kubernetes 1.19 or later

    apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/ssl-redirect: "true" # Force the redirection of HTTP traffic to HTTPS.

    Clusters that run Kubernetes versions earlier than 1.19

    apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/ssl-redirect: "true" # Force the redirection of HTTP traffic to HTTPS.

    What's next