...

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: cafe-ingress
spec:
#  tls:                             # Let's ignore 
#  - hosts:                         # and comment 
#    - cafe.example.com             # these lines 
#    secretName: cafe-secret        # for the moment
  rules:
  - host: cafe.example.com
    http:
      paths:
      - path: /tea                  # Use cafe.example.com/tea to target "tea" services
        backend:
          serviceName: tea-svc      # Enter the service name
          servicePort: 80           # Enter the port number on which the service is listening
      - path: /coffee               # Use cafe.example.com/coffee to target "coffee" services
        backend:
          serviceName: coffee-svc   # Enter the service name
          servicePort: 80           # Enter the port number on which the service is listening

...

We prove that everything works by moving to the browser. Since the cafe.example.com site is not registered on a DNS, we have to insert a line in the /etc/hosts file of our local machine (example on Windows the full path is C:\Windows\System32\drivers\etc\hosts)

131.154.97.164 cafe.example.com # Insert FIP of the node and the host

If we now enter cafe.example.com/tea or cafe.example.com/coffee in the address bar of our browser, we should get, respectively, a web page with the following info

Server address: 10.10.94.71:8080               # "IP:port" of the invoked pod
Server name: tea-69c99ff568-68bnr              # Name of the invoked pod
Date: 23/Sep/2020:13:20:22 +0000               # Current date and time
URI: /tea
Request ID: c2c8de16a55223239bdedee5abe4a8a4
--------------------------------------------
Server address: 10.10.94.70:8080
Server name: coffee-5f56ff9788-l5l9h
Date: 23/Sep/2020:13:07:09 +0000
URI: /coffee
Request ID: babe3fa35d62d2dc0efa6d60a58214e3

These two web pages, while very simple, assure us that the addressing mechanism works correctly.

Configuring TLS certificate

If you pay attention to the address bar Of course, if you don't enter any path (/tea or /coffee) after the host, you will notice get the message "404 Not Found". This happens because we have not associated any service in our ingress resource in the "homepage" of the host (i.e. the "- path: /" is not configured).

Configuring TLS certificate

If you pay attention to the address bar, you will notice the message "your connection to this site is not secure". your connection to this site is not secure". Our goal is to secure the connection. This will show itself visually with the appearance of the small padlock in the address bar. 

...

Now we need to de-comment the lines in cafe-ingress.yaml, related to the TLS protocol, and perform a replace of the component. Returning to the browser we should note that now "the connection is protected", as evidenced by the appearance of the padlock next to the address bar.

Further insights

Learn more about the tls.crt and tls.key keys

...

We just have to paste the output of the .pem file into the tls.crt field and the output of the .key file into the tls.key field.

Multiple sub-domains with one path

Instead of using URLs to make different applications accessible, some Ingress resource use sub-domains. So if you have an application configured this way, your .yaml file would look like below: instead of having one host and multiple path, now we have multiple host, where each host represents a sub-domain and the single path redirects the request to the service. For a secure connection, a certificate, and therefore a secret, is required for each host.

.
.
.
spec:
  tls:
  - hosts:
    - <host1>
    secretName: <secret1>
  - hosts:
    - <host2>
    secretName: <secret2>
  rules:
  - host: <host1>
    http:
      paths:
      - path: /
        backend:
          serviceName: <service1>
          servicePort: <port1>
  - host: <host2>
    http:
      paths:
      - path: /
        backend:
          serviceName: <service2>
          servicePort: <port2>

Uninstall the Ingress Controller

...