# Basic Configuration

The example below shows a basic Ingress resource definition. It load balances requests for two services – coffee and tea – comprising a hypothetical cafe app hosted at cafe.example.com:

apiVersion: extensions/v1beta1
kind: Ingress
name: cafe-ingress
spec:
tls:
- hosts:
- cafe.example.com
secretName: cafe-secret
rules:
- host: cafe.example.com
http:
paths:
- path: /tea
backend:
serviceName: tea-svc
servicePort: 80
- path: /coffee
backend:
serviceName: coffee-svc
servicePort: 80


Here is a breakdown of what this Ingress resource definition means:

• The metadata.name field defines the name of the resource cafe‑ingress.
• In the spec.tsl field we set up SSL/TLS termination:
• In the secretName, we reference a secret resource by its name, cafe‑secret. This resource contains the SSL/TLS certificate and key and it must be deployed prior to the Ingress resource.
• In the hosts field, we apply the certificate and key to our cafe.example.com host.
• In the spec.rules field, we define a host with domain name cafe.example.com.
• In the paths field, we define two path‑based rules:
• The rule with the path /tea instructs NGINX to distribute the requests with the /tea URI among the pods of the tea service, which is deployed with the name tea‑svc in the cluster.
• The rule with the path /coffee instructs NGINX to distribute the requests with the /coffee URI among the pods of the coffee service, which is deployed with the name coffee‑svc in the cluster.
• Both rules instruct NGINX to distribute the requests to port 80 of the corresponding service (the servicePort field).
For complete instructions on deploying the Ingress and Secret resources in the cluster, see the complete-example in our GitHub repo.
• When defining an Ingress resource, the host field is required.
• The host value must be unique for each ingress resource.