<p>The <code>NodePort</code> will resolve correctly, no matter the node where the pods is (even if it gets rescheduled on a different node).</p>

<p>Any <code>&lt;Node IP&gt;:&lt;NodePort&gt;</code> will resolve to a <code>Service</code> type <code>NodePort</code>, no matter what node the pods are running.</p>

<p>Every node will forward traffic to that port to the <code>Service</code>.</p>

<p>You need to be on the same network (or create a SSH tunnel) or open that port in one of your nodes to the world.</p>

CC BY-SA 3.0
2017-10-31T17:48:31.790Z
Right that is the problem I am describing - the specific Node-IP is needed externally. If my 1 pod is on Node-1 and I use Node-1-IP, then all is good. If I restart/update the pod and it is now on Node-2 then Node-1-IP I am using in my scripts will no longer work. So that is the problem - I want to access this single pod externally by IP, whether it is at Node-1-IP or Node-2-IP
rys
CC BY-SA 3.0
2017-10-31T22:37:33.443Z
@rys that sounds strange for a k8s service in node port exposition, each node should route to the pod, wherever it is (that's omitting advanced network filtering but I doubt you are at this point). In raw case talking to any node on NodePort should redirect to the pod with more or less obscure redirects, explaining all in details would be rewriting k8s doc sadly and not fitting the format of this site
Tensibai
CC BY-SA 3.0
2017-11-01T15:28:06.427Z
Oh so you mean, a pod on `Node-1` with `NodePort` `12345` should render 
 *externally* from both `Node-1-IP:12345` and `Node-2-IP:12345`, even without a load balancer?
rys
CC BY-SA 3.0
2017-11-06T11:28:20.420Z
Yes, that is exactly what should be happening
Ara Pulido
CC BY-SA 3.0
2017-11-07T15:34:07.960Z
Weird, I have tried with the 2 external IPs and only one works.
rys
CC BY-SA 3.0
2017-11-08T10:48:47.973Z
Are you sure that you have opened the port to external traffic on both nodes?
Ara Pulido
CC BY-SA 3.0
2017-10-31T13:39:56.407Z
2017-10-31T13:39:56.407Z
Ara Pulido
<p>I am going to put some concreteness to @Tensibai's recommendation in the comments. I began looking into Ingress and Ingress controllers, but my knowledge/implementation was wrong. I successfully connected via an Ingress, but I felt, at least my implementation, it still depended on the node the ingress was running on.</p>

<p>So, I began looking at ELB on AWS. I couldn't find any good tutorials on implementing this specific for AWS. The official <a href="https://kubernetes.io/docs/tasks/access-application-cluster/load-balance-access-application-cluster/" rel="nofollow noreferrer">docs</a> actually helped more than I was aware. It ended up being embarrassingly easy. I made a single change to my service yaml:</p>

<pre><code>type: NodePort
</code></pre>

<p>to</p>

<pre><code>type: LoadBalancer
</code></pre>

<p>and applied it via <code>kubectl apply -f my-file.yaml</code></p>

<p>You can then find the external IP: </p>

<pre><code>$ kubectl get svc
NAME             TYPE           CLUSTER-IP      EXTERNAL-IP        PORT(S)
my-service       LoadBalancer   100.99.98.97    12.34.56.78        444:31415/TCP
</code></pre>

<p>One part I was not expecting is that the first port <code>444</code> is used, rather than the NodePort (<code>31415</code> in my case).</p>

<p>To access my app I would use: <code>12.34.56.78:444</code></p>

<p>The second part I was not expecting is that the external IP, in my case on AWS, was an ELB. It was created automatically in AWS. I am not sure if kubernetes does this, or kops? Maybe someone can clarify in the comments.</p>

CC BY-SA 3.0
2017-10-31T22:41:28.190Z
Yes kops on aws does some magic as such defining a load balancer does configure an ELB to target the correct nodes, from memory I'm unsure if it spin up a new ELB or if it modify a pre-existing one.
Tensibai
CC BY-SA 3.0
2017-10-31T18:06:36.833Z
2017-10-31T18:06:36.833Z
rys
<p>you can use the feature of port-forward using kubectl,</p>

<pre><code>Examples:
  # Listen on ports 5000 and 6000 locally, forwarding data to/from ports 5000 and 6000 in the pod
  kubectl port-forward pod/mypod 5000 6000

  # Listen on ports 5000 and 6000 locally, forwarding data to/from ports 5000 and 6000 in a pod selected by the
deployment
  kubectl port-forward deployment/mydeployment 5000 6000

  # Listen on port 8888 locally, forwarding to 5000 in the pod
  kubectl port-forward pod/mypod 8888:5000

  # Listen on a random port locally, forwarding to 5000 in the pod
  kubectl port-forward pod/mypod :5000 
</code></pre>

<p>But if you want to expose your pod, so that other pods can communicate to it, use services. 
<a href="https://kubernetes.io/docs/concepts/services-networking/service/" rel="nofollow noreferrer">K8s service</a></p>

CC BY-SA 4.0
2019-02-19T03:24:24.977Z
2019-02-19T03:24:24.977Z
rajiv reddy
<p>I am running a kubernetes cluster in AWS. I have 2 nodes. I have one pod that should be accessible externally. The problem is, that pod can be on either node.</p>

<p>The solution according to the <a href="https://kubernetes.io/docs/tasks/access-application-cluster/service-access-application-cluster/" rel="nofollow noreferrer">docs</a>:</p>

<ol>
<li>Expose the deployment as a <code>NodePort</code> service.</li>
<li><code>get pods</code> to find the name of the node running the pod.</li>
<li><code>get nodes</code> to find the IP address of the named node.</li>
<li>Open the <code>NodePort</code> port through EC2 Security Group.</li>
</ol>

<p>The problem here is that this pod could be restarted/switch nodes, I think? At that point the application will be unavailable by the previous node IP address.</p>

<p>How can I make sure an application is always available, even if this specific pod switches nodes during a restart/etc?</p>

<p>Note: I definitely only want one of this specific pod. I do not want replicas.</p>

CC BY-SA 3.0
2017-10-30T16:45:35.593Z
You misunderstood what is verification and what is configuration. The doc tells your to use a node port, the external IP is your duty and problem and very specific to how you did configure things. What you have to do is add the same security group to both nodes allowing input to the nodeport of your service, how you load balance above nodes is your choices of infrastructure. (or you'll need an ingress controller somewhere)
Tensibai
CC BY-SA 3.0
2017-10-30T16:52:05.893Z
Thanks @Tensibai. I am very naive in networking concepts. I was under the impression a load balancer would distribute the load between my 2 nodes. But this pod will ever only be available on one node at a time. Can a load balancer account for this?
rys
CC BY-SA 3.0
2017-10-30T17:04:17.340Z
If you haev an ELB in front of your nodes with a proper healthcheck yes.
Tensibai
CC BY-SA 3.0
2017-10-30T17:09:57.623Z
Cool! Beyond writing a book, is it possible to tell me at a high level when to use ingress vs elb?
rys
CC BY-SA 3.0
2017-10-30T19:20:32.790Z
@rys ELB could take virtually infinite load before a distribution to nodes and make configuration simple, but has it's own pricing and limited customization.
Ingress controllers work inside cluster so they take additional resourses to work, need some extra treatment in DNS to distribute load, have more capabilities in configuration and most of them are free to use.
chupasaurus
CC BY-SA 3.0
2017-10-30T20:45:15.497Z
@rys the book is already written and is kubernetes documentation, I agree it is not simple, but running a k8s cluster is running a datacenter and _really_ needs reading books, not just 1 but many. It can't fit in an answer here IMHO
Tensibai
CC BY-SA 3.0
2017-10-30T20:47:13.040Z
@chupasaurus free to use in license cost, far from free in compute ressources and even less free in term of knowledge, you need to learn and spend time on them, human resources and learning have a cost also.
Tensibai
CC BY-SA 3.0
2017-10-30T21:54:49.747Z
@Tensibai Of course, but I've covered these points "at a high level", as was asked.
chupasaurus
CC BY-SA 3.0
2017-10-31T06:16:52.687Z
@chupasaurus this part is so overlooked I felt it was necessary to complete :)
Tensibai
<kubernetes>
Kubernetes External Access Of A Single Pod
rys
# Kubernetes External Access Of A Single Pod

(Asked by: username_0 on 2017-10-30)

I am running a kubernetes cluster in AWS. I have 2 nodes. I have one pod that should be accessible externally. The problem is, that pod can be on either node.

The solution according to the [docs](https://kubernetes.io/docs/tasks/access-application-cluster/service-access-application-cluster/):

1. Expose the deployment as a `NodePort` service.
2. `get pods` to find the name of the node running the pod.
3. `get nodes` to find the IP address of the named node.
4. Open the `NodePort` port through EC2 Security Group.

The problem here is that this pod could be restarted/switch nodes, I think? At that point the application will be unavailable by the previous node IP address.

How can I make sure an application is always available, even if this specific pod switches nodes during a restart/etc?

Note: I definitely only want one of this specific pod. I do not want replicas.

**Tags:** kubernetes

> **Comments:**
> **username_1**: You misunderstood what is verification and what is configuration. The doc tells your to use a node port, the external IP is your duty and problem and very specific to how you did configure things. What you have to do is add the same security group to both nodes allowing input to the nodeport of your service, how you load balance above nodes is your choices of infrastructure. (or you'll need an ingress controller somewhere)  
> **username_0**: Thanks @username_1. I am very naive in networking concepts. I was under the impression a load balancer would distribute the load between my 2 nodes. But this pod will ever only be available on one node at a time. Can a load balancer account for this?  
> **username_1**: If you haev an ELB in front of your nodes with a proper healthcheck yes.  
> **username_0**: Cool! Beyond writing a book, is it possible to tell me at a high level when to use ingress vs elb?  
> **username_2**: @username_0 ELB could take virtually infinite load before a distribution to nodes and make configuration simple, but has it's own pricing and limited customization. Ingress controllers work inside cluster so they take additional resourses to work, need some extra treatment in DNS to distribute load, have more capabilities in configuration and most of them are free to use.  
> **username_1**: @username_0 the book is already written and is kubernetes documentation, I agree it is not simple, but running a k8s cluster is running a datacenter and _really_ needs reading books, not just 1 but many. It can't fit in an answer here IMHO  
> **username_1**: @username_2 free to use in license cost, far from free in compute ressources and even less free in term of knowledge, you need to learn and spend time on them, human resources and learning have a cost also.  
> **username_2**: @username_1 Of course, but I've covered these points "at a high level", as was asked.  
> **username_1**: @username_2 this part is so overlooked I felt it was necessary to complete :)  

---

## 3 answers

### Answer by username_3 on 2017-10-31. Score: 3

The `NodePort` will resolve correctly, no matter the node where the pods is (even if it gets rescheduled on a different node).

Any `:` will resolve to a `Service` type `NodePort`, no matter what node the pods are running.

Every node will forward traffic to that port to the `Service`.

You need to be on the same network (or create a SSH tunnel) or open that port in one of your nodes to the world.

> **Comments:**
> **username_0**: Right that is the problem I am describing - the specific Node-IP is needed externally. If my 1 pod is on Node-1 and I use Node-1-IP, then all is good. If I restart/update the pod and it is now on Node-2 then Node-1-IP I am using in my scripts will no longer work. So that is the problem - I want to access this single pod externally by IP, whether it is at Node-1-IP or Node-2-IP  
> **username_1**: @username_0 that sounds strange for a k8s service in node port exposition, each node should route to the pod, wherever it is (that's omitting advanced network filtering but I doubt you are at this point). In raw case talking to any node on NodePort should redirect to the pod with more or less obscure redirects, explaining all in details would be rewriting k8s doc sadly and not fitting the format of this site  
> **username_0**: Oh so you mean, a pod on `Node-1` with `NodePort` `12345` should render   *externally* from both `Node-1-IP:12345` and `Node-2-IP:12345`, even without a load balancer?  
> **username_3**: Yes, that is exactly what should be happening  
> **username_0**: Weird, I have tried with the 2 external IPs and only one works.  
> **username_3**: Are you sure that you have opened the port to external traffic on both nodes?  

---

### Answer by username_0 on 2017-10-31. Score: 1

I am going to put some concreteness to @username_1's recommendation in the comments. I began looking into Ingress and Ingress controllers, but my knowledge/implementation was wrong. I successfully connected via an Ingress, but I felt, at least my implementation, it still depended on the node the ingress was running on.
So, I began looking at ELB on AWS. I couldn't find any good tutorials on implementing this specific for AWS. The official docs actually helped more than I was aware. It ended up being embarrassingly easy. I made a single change to my service yaml:
type: NodePort

to
type: LoadBalancer

and applied it via kubectl apply -f my-file.yaml
You can then find the external IP: 
$ kubectl get svc
NAME             TYPE           CLUSTER-IP      EXTERNAL-IP        PORT(S)
my-service       LoadBalancer   100.99.98.97    12.34.56.78        444:31415/TCP

One part I was not expecting is that the first port 444 is used, rather than the NodePort (31415 in my case).
To access my app I would use: 12.34.56.78:444
The second part I was not expecting is that the external IP, in my case on AWS, was an ELB. It was created automatically in AWS. I am not sure if kubernetes does this, or kops? Maybe someone can clarify in the comments.

> **Comments:**
> **username_1**: Yes kops on aws does some magic as such defining a load balancer does configure an ELB to target the correct nodes, from memory I'm unsure if it spin up a new ELB or if it modify a pre-existing one.  

---

### Answer by username_4 on 2019-02-19. Score: 0

you can use the feature of port-forward using kubectl,
Examples:
  # Listen on ports 5000 and 6000 locally, forwarding data to/from ports 5000 and 6000 in the pod
  kubectl port-forward pod/mypod 5000 6000

  # Listen on ports 5000 and 6000 locally, forwarding data to/from ports 5000 and 6000 in a pod selected by the
deployment
  kubectl port-forward deployment/mydeployment 5000 6000

  # Listen on port 8888 locally, forwarding to 5000 in the pod
  kubectl port-forward pod/mypod 8888:5000

  # Listen on a random port locally, forwarding to 5000 in the pod
  kubectl port-forward pod/mypod :5000 

But if you want to expose your pod, so that other pods can communicate to it, use services. 
K8s service


---

