<p>I have a Kubernetes cluster with a master node and two other nodes:</p>

<pre><code>sudo kubectl get nodes
NAME                STATUS    ROLES     AGE       VERSION
kubernetes-master   Ready     master    4h        v1.10.2
kubernetes-node1    Ready     &lt;none&gt;    4h        v1.10.2
kubernetes-node2    Ready     &lt;none&gt;    34m       v1.10.2
</code></pre>

<p>Each of them is running on a VirtualBox Ubuntu VM, accessible from the guest computer:</p>

<pre><code>kubernetes-master (192.168.56.3)
kubernetes-node1  (192.168.56.4)
kubernetes-node2 (192.168.56.6)
</code></pre>

<p>I deployed an nginx server with two replicas, having one pod per kubernetes-node-x:</p>

<pre><code>sudo kubectl get pods -o wide
NAME                                READY     STATUS    RESTARTS   AGE       IP               NODE
nginx-deployment-64ff85b579-5k5zh   1/1       Running   0          8s        192.168.129.71   kubernetes-node1
nginx-deployment-64ff85b579-b9zcz   1/1       Running   0          8s        192.168.22.66    kubernetes-node2
</code></pre>

<p>Next I expose a service for the nginx-deployment as a NodePort to access it from outside the cluster:</p>

<pre><code>sudo kubectl expose deployment/nginx-deployment --type=NodePort

sudo kubectl get services 
NAME               TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)        AGE
kubernetes         ClusterIP   10.96.0.1      &lt;none&gt;        443/TCP        4h
nginx-deployment   NodePort    10.96.194.15   &lt;none&gt;        80:32446/TCP   2m

sudo kubectl describe service nginx-deployment
Name:                     nginx-deployment
Namespace:                default
Labels:                   app=nginx
Annotations:              &lt;none&gt;
Selector:                 app=nginx
Type:                     NodePort
IP:                       10.96.194.15
Port:                     &lt;unset&gt;  80/TCP
TargetPort:               80/TCP
NodePort:                 &lt;unset&gt;  32446/TCP
Endpoints:                192.168.129.72:80,192.168.22.67:80
Session Affinity:         None
External Traffic Policy:  Cluster
Events:                   &lt;none&gt;
</code></pre>

<p>I can access each pod in a node directly using their node IP </p>

<pre><code>kubernetes-node1 http://192.168.56.4:32446/
kubernetes-node2 http://192.168.56.6:32446/
</code></pre>

<p>But, I thought that K8s provided some kind of external cluster ip that balanced the requests to the nodes from the outside. What is that IP??</p>

codependent
<blockquote>
  <p>But, I thought that K8s provided some kind of external cluster ip that balanced the requests to the nodes from the outside. What is that IP??</p>
</blockquote>

<ul>
<li><p>Cluster IP is internal to Cluster. Not exposed to outside, it is for intercommunication across the cluster.</p></li>
<li><p>Indeed, you have LoadBanacer type of service that can do such a trick that you need, only it is dependent on cloud providers or minikube/docker edge to work properly.</p></li>
</ul>

<blockquote>
  <p>I can access each pod in a node directly using their node IP </p>
</blockquote>

<ul>
<li>Actually you don't access them individually that way. NodePort does a bit different trick, since it is essentially loadbalancing requests from outside on ANY exposed node IP. In a nutshell, if you hit any of node's IPs with exposed NodePort, kube-proxy will make sure that required service gets it and then service is doing round-robin through active pods, so although you hit specific node IP, you don't necessarily get pod running on that specific node. More details on that you can find here: <a href="https://medium.com/google-cloud/kubernetes-nodeport-vs-loadbalancer-vs-ingress-when-should-i-use-what-922f010849e0" rel="noreferrer">https://medium.com/google-cloud/kubernetes-nodeport-vs-loadbalancer-vs-ingress-when-should-i-use-what-922f010849e0</a>, as author there said, not technically most accurate representation, but attempt to show on logical level what is happening with NodePort exposure:</li>
</ul>

<p><a href="https://i.stack.imgur.com/3aN0Am.png" rel="noreferrer"><img src="https://i.stack.imgur.com/3aN0Am.png" alt="NodePort Illustration"></a></p>

<ul>
<li><p>As a sidenote, in order to do this on bare metal and do ssl or such, you need to provision ingress of your own. Say, place one nginx on specific node and then reference all appropriate services you want exposed (mind fqdn for service) as upstream(s) that can run on multiple nodes with as many nginx of their own  as desired - you don't need to handle exact details of that since k8s runs the show. That way you have one node point (ingress nginx) with known IP address that is handling incoming traffic and redirecting it to services inside k8s that can run across any node(s). I suck with ascii art but will give it a try:</p>

<pre><code>(outside) -&gt; ingress (nginx) +--&gt; my-service FQDN (running accross nodes):
             [node-0]        |      [node-1]: my-service-pod-01 with nginx-01
                             |      [node 2]: my-service-pod-02 with nginx-02
                             |      ...
                             +--&gt; my-second-service FQDN
                             |      [node-1]: my-second-service-pod with apache?
                             ...
</code></pre>

<p>In above sketch you have nginx ingress on node-0 (known IP) that takes external traffic and then handles my-service (running on two pods on two nodes) and my-second-service (single pod) as upstreams. You only need to expose FQDN on services for this to work without worrying about details of IPs of specific nodes. More info you can find in documentation: <a href="https://kubernetes.io/docs/tutorials/kubernetes-basics/expose/expose-intro/" rel="noreferrer">https://kubernetes.io/docs/tutorials/kubernetes-basics/expose/expose-intro/</a></p>

<p>Also way better than my ansi-art is this representation from same link as in previous point that illustrate idea behind ingress:
<a href="https://i.stack.imgur.com/Wh21i.png" rel="noreferrer"><img src="https://i.stack.imgur.com/Wh21i.png" alt="Ingress Illustration"></a></p></li>
</ul>

<h3>Updated for comments</h3>

<blockquote>
  <p>Why isn't the service load balancing the used pods from the service?</p>
</blockquote>

<ul>
<li>This can happen for several reasons. Depending on how your Liveness and Readiness Probes are configured, maybe service still don't see pod as out of service. Due to this async nature in distributed system such as k8s we experience temporary lost of requests when pods get removed during, for example rolling updates and similar. Secondly, depending on how your kube-proxy was configured, there are options where you can limit it. By official documentation (<a href="https://kubernetes.io/docs/concepts/services-networking/service/#type-nodeport" rel="noreferrer">https://kubernetes.io/docs/concepts/services-networking/service/#type-nodeport</a>) using <code>--nodeport-addresses</code> you can change node-proxy behavior. Turns out that round-robin was old kube-proxy behavior, apparently new one should be random. Finally, to exclude connection and session issues from browser, did you try this from anonymous session as well? Do you have dns cached locally maybe? </li>
</ul>

<blockquote>
  <p>Something else, I killed the pod from node1, and when calling to node1 it didn't use the pod from node 2.</p>
</blockquote>

<ul>
<li>This is a bit strange. Might be related to above mentioned probes thoug. According to official documentation this should not be the case. We had NodePort behaving inline with official documentation mentined above: <code>and each Node will proxy that port (the same port number on every Node) into your Service</code>. But if that is your case then probably LB or Ingress, maybe even ClusterIP with external address (see below) can do the trick for you.</li>
</ul>

<blockquote>
  <p>if the service is internal (ClusterIP) ... does it load balance to any of the pods in the nodes</p>
</blockquote>

<ul>
<li><p>Most definitely yes. One more thing, you can use this behavior to also expose 'load balanced' behavior in 'standard' port range as opposed to 30k+ from NodePort. Here is excerpt of service manifest we use for ingress controller.</p>

<pre><code>apiVersion: v1
kind: Service
metadata:
    namespace: ns-my-namespace
    name: svc-nginx-ingress-example
    labels:
        name: nginx-ingress-example
        role: frontend-example
        application: nginx-example
spec:
    selector:
        name: nginx-ingress-example
        role: frontend-example
        application: nginx-example
    ports:
    - protocol: TCP
      name: http-port
      port: 80
      targetPort: 80
    - protocol: TCP
      name: ssl-port
      port: 443
      targetPort: 443
    externalIPs:
    - 123.123.123.123
</code></pre>

<p>Note that in the above example imaginary 123.123.123.123 that is exposed with <code>externalIPs</code> represents ip address of one of our worker nodes. Pods running in <code>svc-nginx-ingress-example</code> service doesn't need to be on this node at all but they still get the traffic routed to them (and loadbalanced across the pods as well) when that ip is hit on specified port. </p></li>
</ul>
