I am quite confused about the roles of Ingress and Load Balancer in Kubernetes.
As far as I understand Ingress is used to map incoming traffic from the internet to t
TL:DR
Let's start with practical use case: you have multiple Apis backed by service implementation packages (ASIP for clariy and brevity) to deploy under one single domain name. As you are a cutting edge developer, you implemented a micro-services architecture that requires separate deployments for each ASIP so they can be upgraded or scaled individually. Of course,these ASIPs are encapsulated in individual docker container and available to Kubernetes (K8s) from container repository.
Let's say now that you want to deploy this on Google's GKE K8s. To implement sustained availability, each ASIP instance (replica) is deployed on different nodes (VM) where each VM has it's own cloud internal IP address. Each ASIP deployment is configured in an aptly name "deployment.yaml" file where you declaratively specify, among other things, the number of replicas of the given ASIP K8s should deploy.
The next step is to expose the API to the ouside world and funnel requests to one of the deployed ASIP instance. Since we have many replicas of the same ASIP running on different nodes, we need something that will distribute the request among those replicas. To resolve this, we can create and apply a "service.yaml" file that will configure a K8s service (KServ) that will be externally exposed and accessible through an IP address. This KServ will take charge of the API's request distribution among it's configured ASIPs. Note that a KServ will be automatically reconfigured by the K8s master when an ASIP's node fail and is restarted. Internal IP address are never reused in such case and the KServ must be advised of the new ASIP's deployment location.
But we have other Api service packages that shall be exposed on the same domain name. Spinning a new KServ will create a new external IP address and we won't be able to expose it on the same domain name. Well, this is where Ingress comes in.
Ingress sit's between the Internet and all the KServices we expose to to the outside world. Ingress is capable to provide load balancing, SSL termination and name-based virtual hosting. The latter capacity is able to route an incoming request to the right service by analysing it's URL. Of Course, Ingress must be configured and applied with an... "ingress.yaml" file that will specify the rewrites and the routes required to send a request to the right KServ.
Internet -> Ingress -> K8s Services -> Replicas
So, with the right ingress, KServices and ASIPs configuration, we can securely expose many API's using the same domain name.