Configure NGINX Ingress with annotations and ConfigMaps - Container Service for Kubernetes

Prerequisites

The NGINX Ingress controller is installed.
You have obtained the cluster KubeConfig and connected to the cluster by using a kubectl client.
You have created a sample application.

Configuration

The NGINX Ingress controller configuration methods in ACK are fully compatible with the community version. For a complete list of configuration options, see NGINX Configuration.

The following configuration methods are supported:

Using an annotation: You can add an annotation to the YAML file of an NGINX Ingress. The annotation takes effect only on that specific Ingress. For more information, see Annotations.
Using a ConfigMap: You can modify the kube-system/nginx-configuration ConfigMap. This is a global configuration that applies to all NGINX Ingresses. For more information, see ConfigMaps.
Using a custom NGINX template: You can use this method if annotations or a ConfigMap do not meet your special requirements for the NGINX template of the NGINX Ingress controller. For more information, see Custom NGINX template.

Configure URL redirection

When you use the NGINX Ingress controller, it forwards requests based on the full path. For example, a request to /service1/api is forwarded to the /service1/api path of the backend pod. If your backend service's path is /api, a path mismatch occurs, resulting in a 404 error. To resolve this issue, you can add 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's Kubernetes version.

Kubernetes 1.19 and 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:
    # For Ingress controller versions 0.22.0 and later, you must define the path by using a regular expression and use capture groups in the rewrite-target annotation.
      - path: /svc(/|$)(.*)
        backend:
          service: 
            name: web1-service
            port: 
              number: 80
        pathType: ImplementationSpecific

Kubernetes 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:
      # For Ingress controller versions 0.22.0 and later, you must define the path by using a regular expression and use capture groups in the rewrite-target annotation.
      - path: /svc(/|$)(.*)
        backend:
          serviceName: web1-service
          servicePort: 80

Access the NGINX service.

Run the following command to get the 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

Run the following command. Replace <ADDRESS> with the IP address of the Ingress.
```
curl -k -H "Host: foo.bar.com"  http://<ADDRESS>/svc/foo
```
Expected output:
```
web1: /foo
```

Rewrite rules

You can use the nginx.ingress.kubernetes.io/rewrite-target annotation for basic rewrite configurations. For more information, see Configure URL redirection.

For complex or advanced rewrite requirements, you can use the following annotations:

nginx.ingress.kubernetes.io/server-snippet: Adds custom configurations to the server block.
nginx.ingress.kubernetes.io/configuration-snippet: Adds custom configurations to the location block.

These annotations give you the flexibility to customize the NGINX configuration for various use cases by adding custom code snippets.

The following is a configuration 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;

Run the following command to view the NGINX configuration file in the NGINX Ingress controller pod:

kubectl exec nginx-ingress-controller-xxxxx --namespace kube-system -- cat /etc/nginx/nginx.conf   # Replace the pod name with the actual one from your environment.

The generated nginx.conf file includes the following:

# 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 more information about how to use the rewrite directive, see the official NGINX documentation for this directive.

Configure Ingress HTTPS certificates

You can configure an HTTPS certificate for a website directly in the Ingress resource.

Prepare your service certificate.

Note
The domain name in the certificate must match the host that you specify in the Ingress. Otherwise, the NGINX Ingress controller cannot load the certificate.
1. Run the following command to generate a certificate file named tls.crt and a private key file named tls.key.
```
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. Run the following command to create a Secret.
  Use the certificate and private key to create a Kubernetes Secret named tls-test-ingress. You will reference this Secret when you create the Ingress.
```
kubectl create secret tls tls-test-ingress --key tls.key --cert tls.crt
```

Deploy the following template to create an Ingress resource. The tls field references the Secret that you created in the previous step.

Kubernetes 1.19 and 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 associated with the certificate. 
    secretName: tls-test-ingress
  rules:
  - host: foo.bar.com
    http:
      paths:
      - path: /foo
        backend:
          service:
            name: web1-svc
            port:
              number: 80
        pathType: ImplementationSpecific

Kubernetes 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 associated with the certificate.
    secretName: tls-test-ingress
  rules:
  - host: foo.bar.com
    http:
      paths:
      - path: /foo
        backend:
          serviceName: web1-svc
          servicePort: 80

Configure your hosts file or DNS records to access the TLS service.

You can access the web1-svc Service at https://foo.bar.com/foo.

Configure mutual TLS authentication

In some scenarios, you may need to configure mutual TLS authentication to enhance security. The NGINX Ingress controller allows you to configure this feature by using annotations.

Run the following command to create a self-signed certificate authority (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'

Create a server certificate.

Run the following command to generate a certificate signing request (CSR) for the server certificate:

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'

Run the following command to use the root certificate to sign the server CSR and generate the server 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

Create a client certificate.

Generate a CSR for the client certificate.

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'
-----

Run the following command to use the root certificate to sign the client CSR and generate the client 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

Run the following command to check the created certificate files:

ls

Expected output:

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

Run the following command to 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

Run the following command to 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

Deploy the following template to create a sample NGINX Ingress for testing.

Kubernetes 1.19 and 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

Kubernetes 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

Run the following command to view the IP address of the Ingress.

kubectl get ing

The IP address in the ADDRESS column is the IP address of the Ingress.

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

Run the following command to update your hosts file. Replace the IP address with the actual IP address of your Ingress.

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

Verify the configuration:

Access the service without a client certificate:

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>

Access the service with a client certificate:

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><em>Thank you for using nginx.</em></p>
</body>
</html>

Forward requests to HTTPS backends

By default, the NGINX Ingress controller uses HTTP to forward requests to backend pods. If your backend service uses HTTPS, you can add the nginx.ingress.kubernetes.io/backend-protocol: "HTTPS" annotation to configure the controller to use HTTPS for backend connections.

The following is a sample NGINX Ingress configuration:

Kubernetes 1.19 and later

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: backend-https
  annotations:
    # Note: You must specify that the backend service uses HTTPS.
    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

Kubernetes earlier than 1.19

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: backend-https
  annotations:
    # Note: You must specify that the backend service uses HTTPS.
    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>

Use regular expressions in domain names

By default, Kubernetes Ingress resources do not support regular expressions in hostnames. However, you can enable this feature by using the nginx.ingress.kubernetes.io/server-alias annotation.

Deploy the following template. This example uses the regular expression ~^www\.\d+\.example\.com.

Kubernetes 1.19 and 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

Kubernetes 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

Check the configuration of the NGINX Ingress controller.

Run the following command to view the pods of the NGINX Ingress controller:

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

Run the following command to view the configuration of the NGINX Ingress controller. The output shows that the server_name field is updated.

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

Run the following command to get the IP address of the Ingress:

kubectl get ing

Expected output:

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

Run the following commands to test service access with different rules.
Replace <IP_ADDRESS> with the IP address that you obtained in the previous step.
- Run the following command to access the service by using Host: foo.bar.com:
```
curl -H "Host: foo.bar.com" <IP_ADDRESS>/foo
```
  Expected output:
```
/foo
```
- Run the following command to access the service by using Host: www.123.example.com:
```
curl -H "Host: www.123.example.com" <IP_ADDRESS>/foo
```
  Expected output:
```
/foo
```
- Run the following command to access the service by using Host: www.321.example.com:
```
curl -H "Host: www.321.example.com" <IP_ADDRESS>/foo
```
  Expected output:
```
/foo
```

Use wildcard domain names

NGINX Ingress resources in Kubernetes clusters support wildcard domain names. For example, you can configure a host such as *.ingress-regex.com.

Deploy the following template to create an NGINX Ingress.

Kubernetes 1.19 and 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

Kubernetes 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

Run the following command to check the configuration of the NGINX Ingress controller. The output shows that the server_name field is updated.

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

Note

Replace nginx-ingress-pod-name with the actual name of your NGINX Ingress controller pod.

Expected output:

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

Expected output for newer versions of the NGINX Ingress controller:

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

Run the following command to get the IP address of the Ingress:

kubectl get ing

Expected output:

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

Run the following commands to test service access with different rules.
Replace <IP_ADDRESS> with the IP address that you obtained in the previous step.
- Run the following command to access the service by using Host: abc.ingress-regex.com:
```
curl -H "Host: abc.ingress-regex.com" <IP_ADDRESS>/foo
```
  Expected output:
```
/foo
```
- Run the following command to access the service by using Host: 123.ingress-regex.com:
```
curl -H "Host: 123.ingress-regex.com" <IP_ADDRESS>/foo
```
  Expected output:
```
/foo
```
- Run the following command to access the service by using Host: a1b1.ingress-regex.com:
```
curl -H "Host: a1b1.ingress-regex.com" <IP_ADDRESS>/foo
```
  Expected output:
```
/foo
```

Canary releases with annotations

You can implement a canary release by using annotations. To enable the canary feature, you must set the nginx.ingress.kubernetes.io/canary: "true" annotation. You can then use different annotations to control traffic:

nginx.ingress.kubernetes.io/canary-weight: Specifies the percentage of traffic (an integer from 0 to 100) to route to the canary service.
nginx.ingress.kubernetes.io/canary-by-header: Splits traffic based on a request header. If the value of the configured header is always, requests are routed to the canary service. If the header value is never, requests are not routed to the canary service. Other header values are ignored, and requests are routed to canary services that are defined by other rules based on canary priority.
nginx.ingress.kubernetes.io/canary-by-header-value and nginx.ingress.kubernetes.io/canary-by-header: When the header and header-value in a request match the specified values, traffic is routed to the canary service. Other header values are ignored, and traffic is routed to canary services specified in other rules based on the canary priority.
nginx.ingress.kubernetes.io/canary-by-cookie: Splits traffic based on a cookie. If the value of the specified cookie is always, request traffic is routed to the canary service. If the value of the specified cookie is never, request traffic is not routed to the canary service.

The following examples show how to configure some of these annotations. For more information, see Use the NGINX Ingress controller to implement canary releases and blue-green deployments.

Weight-based canary release: Set the weight of the canary service to 20%.

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: If the request header is ack:always, the request is routed to the canary service. If the request header is ack:never, the request is not routed to the canary service. For other values of the ack header, traffic is routed to the canary service based on the canary 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 (custom header value): If the request header is ack:alibaba, the request is routed to the canary service. For other values of the ack header, traffic is routed to the canary service based on the canary 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: "20"
    nginx.ingress.kubernetes.io/canary-by-header: "ack"
    nginx.ingress.kubernetes.io/canary-by-header-value: "alibaba"

Cookie-based canary release: If the header does not match, and the request cookie is hangzhou_region=always, the request is routed 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"

Note

Cookie-based canary release only supports the values always and never. It does not support custom values.
The priority of canary rules is as follows (from highest to lowest): header-based > cookie-based > weight-based.

Free HTTPS certificates with cert-manager

cert-manager is an open source certificate management tool that automatically provisions and renews HTTPS certificates in a Kubernetes cluster. The following example shows how to use cert-manager to apply for a free certificate and enable auto-renewal.

Important

cert-manager is an open source component and is not maintained by ACK. Use it with caution in production environments. To upgrade cert-manager, see Upgrading cert-manager.

Run the following command to deploy cert-manager.

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

Run the following command to check the pod status.

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

Create a ClusterIssuer by using the following template.

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_n***@gmail.com>  # Replace this with your email address.
    privateKeySecretRef:
      name: letsencrypt-http01
    solvers:
    - http01: 
        ingress:
          class: nginx

Run the following command to check the ClusterIssuer status.

kubectl get clusterissuer

Expected output:

NAME                         READY   AGE
letsencrypt-prod-http01      True    17s

Create an Nginx Ingress resource object.

Kubernetes 1.19 and 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

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

Note

The domain name that you specify for <YOUR_DOMAIN_NAME> must meet the following conditions:

The domain name cannot exceed 64 characters in length.
Wildcard domain names are not supported.
The domain must be accessible from the internet over HTTP.

Run the following command to check the certificate status:
```
kubectl get cert
```
Expected output:
```
NAME          READY   SECRET        AGE
ingress-tls   True    ingress-tls   52m
```
Note
If the READY status is not True, you can run kubectl describe cert ingress-tls to view the certificate processing details.

Run the following command to check the Secret:

kubectl get secret  ingress-tls

Expected output:

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

Open your web browser and enter https://<YOUR_DOMAIN_NAME> to access your domain.

HTTP-to-HTTPS redirect

You can enforce the redirection of HTTP traffic to HTTPS by adding the nginx.ingress.kubernetes.io/ssl-redirect annotation to your NGINX Ingress. The following is an example:

Kubernetes 1.19 and later

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

Kubernetes earlier than 1.19

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