Hacker News Reader

Comment by ghshephard | Hacker News Reader

Docker by itself probably doesn't make any sense to an engineer until they get a chance to see kubernetes in action. There is nothing more awesome than seeing, on the fly, your worker pool being scaled out by 100x by nothing more than

  kubectl --context k8s-uw1a-gcp -n customerx scale deploy someapp_worker --replicas 100

to make you appreciate what docker can do for you.

View on HN

I am absolutely sure there are usecases for that.

But the truth is, most websites will happily run on a single dedicated machine you rent for a few hundred dollars. (OK, two, so you have a hot spare, if you so fancy.) This fact often gets overlooked despite even Stackexchange tweeted once or twice they could run their site with a single DB server. But: cloud! Kubernetes! Hype. Meh.

Stack exchange has spent an obscene amount of time optimizing their infrastructure for efficiency on dedicated known hardware. Their DB instances also have 1.5TB of ram. You're not getting that for a few hundred dollars.

https://stackexchange.com/performance

Your average site wouldn't get anywhere near the same performance as them.

I think GP was pointing out the inefficiencies rife in "cloud scale" architecture these days, not saying that anyone can scale to StackExchange levels on a single instance.

Let's unpack my statement because it might have been too dense.

1. Almost all websites can run on a single dedicated server.

2. This is true for even something as big as Stackexchange which most sites are not.

3. If your site is indeed smaller than SE then that server is likely to be a few hundred dollars a month.

Also: getting a 512GB RAM server for 5-700 USD or so is definitely possible these days. But, again, most sites won't need anywhere near that. Based not only on information and belief ;) but first hand experience I sincerely doubt most sites would need more than 64GB.

The heavy uses of Docker in my (limited) experience are enterprise stacks with their 15+ components per application and many worker threads that they use to speed up ETL/Parsing/Analytics. Essentially Docker/VMs have replaced the thousands of servers that used to reside in corporate data centers, with the benefit now being that developers can launch those same complex Application stacks with little effort on their laptop.

What used to be a 30+ day procurement process became <7 days with VMs, became < 15 minutes with docker/kubernetes.

You can also do things that you would have never even considered doing prior to Docker - like run the application stack in the cloud, but launch one of the components (still in the same deployment) - on your laptop using tools like https://github.com/telepresenceio/telepresence.

Having a worker pool in the first place, with carefully automated agents that magicically begin working when spawned, makes the complexity of managing their launch almost negligible.

For those who haven't used k8s, note that `--context` and `-n` are mostly of multi-tenant/RBAC cases, so the command is more like `kubectl scale deploy <deployment name> --replicas <number of containers>`

Spinning up 100 nodes kubernetes clusters w/ a single button click across multiple public clouds with Rancher is pretty exciting too. You can scale up your worker pool by clicking on a spinner input in the Rancher UI instead of typing the kubectl commands. Heck, its built right into the Kubernetes GUI as well. Pretty cool.

There is nothing more awesome than seeing, on the fly, your worker pool being scaled out by 100x

This was possible, and done, long before kubernetes or docker. The frequent counter-argument I hear is that "kubernetes makes it easy" - which is often espoused by people that don't have to build or manage kubernetes in prod.

One could do the same thing with other stuff too. Everything from bare metal to other application containers, and everything in between.

I do think that docker is very overhyped, but it does also solve some problems in a good way, even though it also creates new problems.

Whereas my AWS autoscale group does it for me while I go get me a foo foo drink at $ESTABLISHMENT

Kubernetes also has auto scale.

You can use one of the two container autoscalers to handle the scaling automatically based on any metric(s) you like, and the cluster autoscaler will scale the ASG as needed :)

This is useful for workloads that need to scale on some metric other than CPU/MEM, e.g. request rate, worker queue length...

sadly it's not cheap to built aws on bare metal.

And you think k8s is simple to run on bare metal ?

To care and maintain ?

Do you understand the kernel tuning and routing Google does to avoid the NAT hell you are going to run into when you manage k8s on your own ?

I actually run 3 small bare metal clusters in production.

Maintain is basically just a `kubeadm upgrade` on all nodes + reboot (easily scriptable), after some updates get announced. OS Upgrades are done through container-linux-update-operator.

NAT is not a problem if you are below or equal to 50 nodes. Not sure if you run into problems if there are more nodes, thought. Also BGP+metallb is quite good.

(P.S.: openstack uses NAT heavily as well. and IPVS for k8s should fix most problems if you are running into problems)

ok but here you are really advocating kubernetes, not docker.

Sure - but Kubernetes (and many other things) are enabled by Docker. To overuse the Metaphor, containers in shipping weren't a big deal until Container Ports/Cranes/Ships/Trucks came along - we say that "Containers" revolutionized transport as a short hand for all those systems that were built on them.

Reply on news.ycombinator.com