Question posted in 
I am learning about highly available distributed systems and some of the concepts that keep coming up are load balancing (Nginx) and container orchestration (Kubernetes). Right now my simplified understanding of them is as so:
Nginx
- Web server that handles Http requests
- Performs load balancing via reverse proxy to other servers (usually done in a round robin manner)
- Maps a single IP (the IP of the Nginx server) to many IPs (nodes which we are load balancing over).
Kubernetes
- Container orchestration tool which keeps a defined state of a container cluster.
- Maps a single IP (the IP of the control plane?) to many IPs (nodes which have a container instance running on them).
So my question is, do we use both of these tools in conjunction? It seems like there is some overlap?
For example, if I was creating a NodeJS app to act as a microservice which exposes a REST API, would I just simply deploy my app in a Docker container, then let Kubernetes manage it? I would not need a load balancer like Nginx in front of my Kubernetes cluster?
3
Answers
Kubernetes gives you a self-contained/sandboxed environment where your services are safe from the outside world running on private non-routable subnets. Because pods are ephemeral, their IPs can change anytime. Hence, Kubernetes has a "Service" concept. Different micro-services interact with each other using servicename:port so that they don’t have to worry about the POD IPs.
However,if you want to access your application from outside (internet) you need to configure an ingress controller. This ingress controller can be implemented using Nginx.
So, your ingress controller (nginx) will receive request and send it to the service, which can load balance it to the pods to meet the desired state.
In large system, the nginx ingress controllers may need to scale as well to serve the incoming requests.
So, long story short, you will need both if you want to scale and for routing purposes.
The short answer to your question is yes you need a load balancer in front of your Kubernetes cluster to route external traffic to the services of your application in the cluster or your application will not be accessible from outside.
Basically, Kubernetes provides built‑in HTTP load balancing with Ingress which is API object that describes the desired state for exposing services to the outside of the Kubernetes cluster (check this this_Link for more infos about Ingress).
Simply, Kubernetes alone is capable to deal with the whole state of your application
including loadBalancing.
For advanced microservices architechture Nginx developed an Ingress Controller extension for Kubernetes Load Balancing which presents the Nginx features in the Ingress K8s API.
For more Informations about Nginx and Nginx Plus for Kubernetes Ingress check link bellow:
You seem to have mixed a few concepts. Don’t look to much on the number of IP addresses, but more on the role of the different components.
Load Balancer / Gateway / Nginx
You probably want some form of Gateway or reverse proxy with a static known IP address (and DNS name) so that traffic from Internet can find its way to your services in the cluster. When using Kubernetes, it is common that your services run in a local network, but the Gateway or reverse proxy is typically the way into your cluster.
Kubernetes API / Control Plane
This is an API for managing Kubernetes resources, e.g. deploy a new version of your apps. This API is only for management / administration. Your customer traffic does not use this API. You want to use strong authentication for this, only usable by you and your team. Pods in your cluster can use this API, but they need a Service Account and proper RBAC Authorization.