You have read that Ingresses have benefits compared to Services. You know the two are different for routing external traffic to reach a Kubernetes cluster. When would you want to use a Service instead of an Ingress?
- When you want to direct traffic to Pods based on a selector and not an IP address. Ingresses use IP addresses*, but Services use pod selectors**. Labels can be designed arbitrarily. For performance and functionality, you may want to design a nuanced assignment of web traffic to specific pods. For more information, see this.
- When you want to keep the Ingress Controller off.*** For security reasons you may want to keep the Ingress Controller off. All things constant, Ingresses would be safer than Services, but we cannot deny that keeping a component (the Ingress Controller) off has its security benefits too.
- If you have a hardened Kubernetes deployment, network traffic at and above layer 5 of the OSI model may be substantially filtered/blocked. Thus Ingress controllers would not work; they operate at layer 7 of the OSI model. Services with NodePort operate at layer 4 of the OSI model.
- If you want to leverage BGP with networking on baremetal. If this is a requirement, a Service of the LoadBalancer type would be preferred over an Ingress. The source link for this one is here.
For more information on the differences between the two, see this posting.
*"The Nginx installations route directly to the pods' IP addresses, bypassing the associated Service's virtual IP. " Taken from https://www.joyfulbikeshedding.com/blog/2018-03-26-studying-the-kubernetes-ingress-system.html
** "The set of Pods targeted by a Service is usually determined by a selector…" Taken from https://kubernetes.io/docs/concepts/services-networking/service/#service-resource
*** "…Ingress controllers are not started automatically with a cluster." Taken from https://kubernetes.io/docs/concepts/services-networking/ingress-controllers/