When pods are created, they have their own IP address, sometimes they crash and a new instance of the pod gets deployed with a new IP address. How pods manage this change of IP addresses in order to be able to communicate with each other after a Pod get redeployed with a new IP. To keep consistency of pod IP addresses, we use service. Services provide an interface through which groups of pods can be accessible even if the IP of the Pod changes when it is redeployed after a crash.
Ingress is a way to "publish" or expose a service like a Web server running inside a container to the outside world.
Ingress uses communicates through HTTP at the application level. Ingress has a fixed IP address through which clients can have access to lot of services (Databases, Web servers, ...). Ingress is a controller that uses the rules provided by "Ingress resources file" to make a decision about which services to forward the request to. In the case of an HTTP request which is the typical use of Ingress, the Ingress controller decides which service to forward the request to based on the address and the path. Different paths lead to different services on the same or on different hosts.
A Service is the entry point to a pod or a group of pods that have the same label.
The requests for the host.example.com/intro is forwarded by the ingress to the pods responsible for handling intro.
The requests for the host.example.com/info is forwarded by the ingress to the pods responsible for handing info.
Ingress resources file:
Below is a snippet of the Ingress resource file:
The above file publishes two services on the same host but on two different paths.
Most of the Ingress controllers don't forward the request directly to the services, they just query them to get the information about which pod to forward the request to.
For the Ingress to work, the kubernetes cluster must have a Ingress controller like nginx for example.