expose NodePort like functionality to Ingress about voyager HOT 8 CLOSED

Thanks @tamalsaha, tested, it works, waiting to be able to manually set the ports!

from voyager.

@skuda , I am bit confused by this part of your issue:
Then when the daemonset starts in the selected node it automatically binds to the tcp port 80, that makes obviously sense, but it would be great if the user is able to use NodePort as well as an alternative.

In DaemonSet mode, HAProxy is running with hostNetwork = true. For HTTP ingress, Voyager will only bind HAProxy to port 80 or 443. But for TPC ingress, Voyager will bind HAProxy to any port on that node. Does that solve your use-case?

from voyager.

for L4 ingress, yes, but I am speaking about L7 ingress, we have lots of micro-services for example, I wouldn't like to expose all of them in 4 HAProxy, one per node.

I even prefer to expose most of our backend apis in non default ports, just for security purposes.

from voyager.

We are going to look into this.

from voyager.

@skuda , I think one option we can take is allow users to specify port for L7 ingress. Example:

apiVersion: appscode/v1beta1
kind: Ingress
metadata:
  name: test-ingress
spec:
  rules:
  - http:
      port: <non-standard-port>
      paths:
      - path: /testpath
        backend:
          serviceName: test
          servicePort: 80

Do you think that will suffice your use-case?

from voyager.

Sure, but NodePort has one specific advantage over that, I will explain what we are doing to host some game servers.

Imagine we have these nodes:
worker-01: 50.50.50.1 <--- game server is running here.
worker-02: 50.50.50.2
worker-03: 50.50.50.3

You have this domain awesome.game-server.com pointing to 50.50.50.1, with a ttl of 60 secs.
You are using udp port 50000, so people are connecting to awesome.game-server.com:50000, or using a SRV record if your game support reading them.

Nodeport allows two different things in a convenient way:

• You could be load-balacing public traffic using dns round robin, usually you have a different, faster, internal network so internal traffic is not, usually, a problem.
• In case worker-01 reboots, because of system upgrades or temporary problem, or simply because you drain the node, and because of that, the pod is moved to a different worker, you can use a hook to change the ip pointed from awesome.game-servers.com to the new node running the pod, but you will have to deal with dns caches that not always respect the ttl. When the worker-01 node comes up it will be serving those clients sending automatically them to the new pod.

Sometimes use a loadbalancer to offer ha in front of a game server is not possible, for a lot of reason, your hosting provider, the protocol used is not supported, it is too expensive to your use case or the constant bandwidth you are using is too big, those connections are not short lived, 1 busy game server can be easily using 500Mbit/s.

I think NodePort is very useful for a lot of cases, specifically for those out of cloud providers or unsupported cloud providers.

This is the reason why I think it would be better for voyager to directly support NodePort, given said that, what you are proposing is enough for my current use-case.

Thanks!!

from voyager.

TODO:

• Expose HAProxy via a NodePort service. HAProxy will be run using a deployment.
• Add a new new type NodePort.

from voyager.

@skuda , 1.5.5 is released with support for NodePort mode. https://github.com/appscode/voyager/tree/master/docs/user-guide#configuration-options

We are going to look into running HTTP services in non-std port in a future version. #73

from voyager.