Ingress is a resource, which exposes the http and https from external sources to the services within the cluster, by adding the rules in the ingress resource for routing the traffic, where traffic is controlled by ingress controller.

From the above lines we can understand that ingress consists of two components:

• Ingress resource
• Ingress controller

Ingress Resource:  where we will define our routing rules to which service the request has to go. Ingres resource supports the following features.

Content-based routing:

Host-based routing: For example, routing requests with the host header abc.example.com to one group of services and the host header xyz.example.com to another group.

Path-based routing: For example, routing requests with the URI that starts with /A to service A and requests with the URI that starts with /xyz to service B.

Ingress controller: The Ingress controller is an application that runs in a cluster and configures an HTTP load balancer according to Ingress resources. The load balancer can be a software load balancer running in the cluster or a hardware or cloud load balancer running externally. Different load balancers require different Ingress controller implementations. In the case of NGINX, the Ingress controller is deployed in a pod along with the load balancer. it is typically a proxy service deployed in the cluster.it nothing but a Kubernetes deployment exposed to a service. Some popular ingress controllers are

• Traefik
• HAProxy
• Contour
• GKE ingress controller
• Nginx Ingress Controller.

We include two options for deploying the Ingress controller:

Deployment. Use a Deployment if you plan to dynamically change the number of Ingress controller replicas.

DaemonSet. Use a Daemon Set for deploying the Ingress controller on every node or a subset of nodes.

I will give the flow as per image how ingress works.

When end users access the Domain name ,the request goes to the Load balancer, the Load balancer talk to the ingress controller, ingress controller route  the traffic based on the rules defined in the ingress resource , it will be something like this, if the request comes with

demo.apps.example.com/api à route to api.service ( services running in cluster)

Demo.apps.example.com/auth à route to auth.service ( services running in cluster)

Ingress Resource:

Define path based or host based routing rules for your services.

Single DNS Sample with host and service place holders

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: ingress-resource-1
spec:
  rules:
  - host: 
    http:
      paths:
      # Default Backend (Root /)
      - backend:
          serviceName: 
          servicePort: 80

Multiple DNS Sample with hosts and servcies place holders

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: ingress-resource-1
spec:
  rules:
  - host: 
    http:
      paths:
      - backend:
          serviceName: 
          servicePort: 80
  - host: 
    http:
      paths:
      - backend:
          serviceName: 
          servicePort: 80

Path Based Routing Example

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: ingress-resource-1
spec:
  rules:
  - host: abc.example.com
    http:
      paths:
      # Default Path(/)
      - backend:
          serviceName: A
          servicePort: 80
      - path: /xyz
        backend:
          serviceName: B
          servicePort: 80

Make sure you have services created in K8’s with type ClusterIP for your applications. Which your are defining in Ingress Resource.