<p>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:</p>
<h3>Nginx</h3>
<ul>
<li>Web server that handles Http requests</li>
<li>Performs load balancing via reverse proxy to other servers (usually done in a round robin manner)</li>
<li>Maps a single IP (the IP of the Nginx server) to many IPs (nodes which we are load balancing over).</li>
</ul>
<h3>Kubernetes</h3>
<ul>
<li>Container orchestration tool which keeps a defined state of a container cluster.</li>
<li>Maps a single IP (the IP of the control plane?) to many IPs (nodes which have a container instance running on them).</li>
</ul>
<p>So my question is, do we use both of these tools in conjunction? It seems like there is some overlap?</p>
<p>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?</p>

<blockquote>
<p>So my question is, do we use both of these tools in conjunction? It seems like there is some overlap?</p>
</blockquote>
<p>You seem to have mixed a few concepts. Don't look to much on the number of IP addresses, but more on the <strong>role</strong> of the different components.</p>
<h2>Load Balancer / Gateway / Nginx</h2>
<p>You probably want some form of Gateway or reverse proxy with a <strong>static known IP address</strong> (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 <strong>Gateway</strong> or reverse proxy is typically the way into your cluster.</p>
<h2>Kubernetes API / Control Plane</h2>
<p>This is an API for <strong>managing</strong> 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 <em>can</em> use this API, but they need a <em>Service Account</em> and proper <a href="https://kubernetes.io/docs/reference/access-authn-authz/rbac/" rel="nofollow noreferrer">RBAC Authorization</a>.</p>
