<p>I still have a question about Kubernetes NodePort service.</p>

<p>NodePort: Exposes the service on <strong>each</strong> Node’s IP at a static port (the NodePort). A ClusterIP service, to which the NodePort service will route, is automatically created. You’ll be able to contact the NodePort service, from outside the cluster, by requesting :.</p>

<p>If I have two Node: nodeA and nodeB, and if I deploy an app only on nodeA then create a NodePort service, then can I use both nodeA and nodeB ips to access this service?</p>

<p>I had some tests, the result is no....</p>

<p>I did two kinds of tests:</p>

<p><strong>Test1:</strong></p>

<p>I deployed a deployment with two pods, one is on NodeA, another is on NodeB. then create a NodePort service to access it.
I can access the service by using both NodeA and NodeB ips. then I delete pod on NodeA, then try again. I found that I cannot access the service by using NodeA ip, but can access by using NodeB ip. After the pod is startup on NodeA, then I can access by using NodeA ip</p>

<p><strong>Test2:</strong></p>

<p>I deployed a deployment with only one pod, it is on NodeA. then create a NodePort service to access it.
I can only access the service by using NodeA ip but cannot by NodeB ip.</p>

<p>So my question is:</p>

<p>For the NodePort type, it can only be used that the pod/pods are on the same Node? If I use NodeA ip, service won't load balance the request to the pod on NodeB?</p>

<p>Thanks a lot! :)</p>

<blockquote>
<p>If I have two Node: nodeA and nodeB, and if I deploy an app only on nodeA then create a NodePort service, then can I use both nodeA and nodeB ips to access this service?</p>
<p>I had some tests, the result is no....</p>
</blockquote>
<p>In that case, it sounds very much like one of three things is not happening: you do not have <code>kube-proxy</code> running on all the Nodes, or the Nodes are firewalled off from one another in a very restrictive way, or you are not using a software-defined network (such as flannel, calico, etc).</p>
<p>That NodePort behavior is, to the best of my knowledge, implemented using <code>iptables</code> applied to all the machines, causing traffic received on port X of machine A to be effectively NAT-ed to one of the machine(s) where the actual Pods are running, back to machine A, back to the requester. It is <code>kube-proxy</code>'s job to install the initial <code>iptables</code> rules for doing that, and then subsequently keep them up to date as the Pods come and go from the cluster. One can observe the correct behavior by running <code>iptables -L -n -t nat</code> on a Node that <strong>is</strong> running <code>kube-proxy</code>, and observe the rules named for the various kubernetes services. They even helpfully include comments in the <code>iptables</code> rules, which I thought was nice</p>
<p>The firewalling case I think speaks for itself</p>
<p>I actually have never run kubernetes without a software-defined network, so I am not in a good place to offer troubleshooting steps (aside from: install flannel or calico and rejoice in their awesomeness). Perhaps others will be able to weigh in, if that is in fact your circumstance</p>
