2

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:

  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.

9
  • 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)
    – Tensibai
    Commented Oct 30, 2017 at 16:45
  • 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
    Commented Oct 30, 2017 at 16:52
  • If you haev an ELB in front of your nodes with a proper healthcheck yes.
    – Tensibai
    Commented Oct 30, 2017 at 17:04
  • Cool! Beyond writing a book, is it possible to tell me at a high level when to use ingress vs elb?
    – rys
    Commented Oct 30, 2017 at 17:09
  • @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. Commented Oct 30, 2017 at 19:20

3 Answers 3

3

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

Any <Node IP>:<NodePort> 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.

6
  • 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
    Commented Oct 31, 2017 at 17:48
  • @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
    Commented Oct 31, 2017 at 22:37
  • 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
    Commented Nov 1, 2017 at 15:28
  • Yes, that is exactly what should be happening
    – Ara Pulido
    Commented Nov 6, 2017 at 11:28
  • Weird, I have tried with the 2 external IPs and only one works.
    – rys
    Commented Nov 7, 2017 at 15:34
1

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.

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.

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.
    – Tensibai
    Commented Oct 31, 2017 at 22:41
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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.