Hacker News Reader

Comment by merb | Hacker News Reader

Well yeah it looks great. However for ease of use in "small" scale. it would be cool to have a built in Load Balancer (a pretty pretty simple one, just http, maybe https via LetsEncrypt).

At the moment adding a Cloud Load Balancer per Project is probably not affordable in the smaller project scale (and it would make any PaaS useless). (I mean that is not a "big" problem, it's ok to build it myself (with less quality than you can ;))

But I wanna say Kubernetes is extremly good designed and the amazing part is, is that you can start with a really really really really small cluster (like 1 master 1 node) and later you can raise that pretty easily

View on HN

We've heard this quite a lot - there's actually a few ways to tackle this, one of the most common is to either use Ingress (which is a built in L7 load balancer) or run an nginx instance in a pod on the cluster (https://github.com/nginxinc/kubernetes-ingress), and, in either case, direct all traffic to your node port across your cluster.

It's really one command to do either - if you have trouble, please ping me (aronchick (at) google)!

Disclosure: I work at Google on Kubernetes

Is there a way to do this properly in AWS without nginx? It would also be great to have features to switch only percentage of the traffic to an app when doing blue/green deployments.

The best way to do blue/green is put them behind a single endpoint. So, if your endpoint is 'app: node-app', then you put the label 'app: node-app' on BOTH your existing version, and your future version, and target all traffic to a service with the selector 'app: node-app'.

Then, you slowly start to spin up your new instances from 1 -> 10 -> 100 (or whatever). The traffic will split automatically because both apps have the same label/selector, and you control the amount by how many instances of each you have.

Disclosure: I work at Google on Kubernetes

does kubernetes take care of 'connection draining', ie making sure requests in flight are completed before killing traffic to an instance?

Sort of a blend. It will send a sigterm to your process first which should be your signal to start draining and exit when they are done. If you don't finish within a configurable timeout then sigkill is sent.

I was wondering how to make this automated through some sort of pipeline that needs a human to click "go on with the next X % of the rollout and how I would do it with kubectl without too much pain.

We've been doing this with multiple deployments (e.g. 1, half, all) and updating the deployments sequentially when the previous one looked good. (these are all fronted by one service).

Take a look at Traefik (http://traefik.io/), it's a reverse proxy you use as an edge service behind the cloud providers L4/L7 LB. It is designed to change dynamically and can listen to K8s ingress changes and reconfigure itself automatically and it has let's encrypt support (although at the moment not so streamlined in k8s but that is supposed to change soon).

Take a look at Vamp (vamp.io) which also integrates with Kubernetes and is a programmable router based on HAproxy. It does loadbalancing, but also percentage and condition-based canary-releasing: http://vamp.io/documentation/installation/kubernetes/

(disclaimer: I'm the co-founder, looking forward to hear your thoughts and feedback!)

Vamp is awesome! It fits really nice into Kubernetes.

Reply on news.ycombinator.com