0

I'm pretty sure that this is a basic use case when running apps on kubernetes, but till now I wasn't able to find a tutorial, nor understand from the documentation, how to make it work.

I have an application, which is listening on a port 9000. So when run on my localhost, I can access it through a web browser on a localhost:9000. When run in a docker container, which is running on my VPS, it's also accessible on myVPSAddress:9000. Now the question is, how to deploy it on kubernetes running on the very same Virtual Private Server and expose the application to be visible as well, as when deployed on docker. I can access the application from within the VPS on the address of the cluster, but not on the IP address of the server itself. Can somebody show me some basic dockerfile with a description what is it doing or show me some idiot-proof way, how to make it work? Thanks

ffledgling
  • 11,502
  • 8
  • 47
  • 69
Martin Dvoracek
  • 1,714
  • 6
  • 27
  • 55

1 Answers1

1

While one would think that this is a very basic use-case, that is not the case for people running their own kubernetes clusters on bare metal servers. (The way you are on your VPS).

The recommended way of exposing an application to "the world" is to use kubernetes services, see this piece of documentation about exposing services. You define a kubernetes service, either of the type NodePort or of type Loadbalancer *.

Here is what a dead simple service looks like (hint: it's of the default type NodePort):

kind: Service
apiVersion: v1
metadata:
  name: my-service
spec:
  selector:
    app: MyApp
  ports:
  - protocol: TCP
    port: 9000
    targetPort: 9376

This will expose your service with label name: my-service (interally running on port 9000) on all nodes in your VPS cluster at port 9376.

Assuming your nodes have a public IP (which from your question I assume they do), you can safely do curl localhost:9376.

Because this is usually not ideal UX/UI to expose to users, people use services of type Loadbalancer. This service type provides a unique IP to each of your services instead of a port.

These services are first class citizens on cloud managed clusters, such as Google's GKE, but if you run your own Kubernetes cluster (setup using say kubeadm), then you need to deploy your Loadbalancer service provider. I've used the excellent MetalLB and it works flawlessly once it's been setup, but you need to set it up yourself. If you want dns names for you services as well, you should also look at ExternalDNS.

* Caveat here is that you can also use a service of type ExternalIP if you can somehow make that IP routable, but unless the network is in your control, this is usually not a feasible approach, and I'd recommend looking at an LB provider instead.

ffledgling
  • 11,502
  • 8
  • 47
  • 69
  • Thanks for explanation, @ffledgling. Let me to sum it up in order to see, whether I understood your post correctly (I didn't read the links you posted through yet). One thing is my application running as pods. It has a separate deployment file and is accessible only within the cluster itself. To make it accessible from outside I need to deploy some loadbalancer (ideally), which will bind the application's port to some target port. And when I try then to access the IP of my server and given port, the service will map do the load balancing and call one of the pods, correct? – Martin Dvoracek Apr 15 '18 at 18:16
  • 1
    That is more or less correct, except... you mixed up the load balancer and the nodeport mapping. If you deploy a service of type nodeport, it will map *a port on every node*, to point to your pods. If you use a service of type loadbalancer it will map an *IP* to your pods. You only need to deploy a loadbalancer, if you wish to use a service of type loadbalancer. NodePort works out of the box. – ffledgling Apr 16 '18 at 07:14
  • 1
    I made it to work with LodeBalancer. It all makes sense now! Thanks a lot, @ffledgling! – Martin Dvoracek Apr 16 '18 at 07:36