[solatic]

> using it for anything less than dozens of machines is overkill

The question isn't really whether you need dozens of machines, it's whether you can foresee eventually maybe needing dozens of machines.

Remember the bad old days when people said that relational databases were worthless because they "don't scale", that using Mongo and other NoSQL databases were practically a necessity for doing anything modern and "web-scale" because otherwise after you got your big break and you got popular you would need to keep up with all the new traffic and not crash? A lot of engineers have this tendency to worry about scalability long before it's ever a problem. Something about the delusions of grandeur incurred by people who got into engineering because they were inspired by great people building big things.

Starting out by running Kubernetes on a three-node cluster is actually the correct call for a small project if you can reasonably foresee needing to elastically scale your cluster in the future, and don't want to waste days or weeks porting to Kubernetes down the line to deal with your scalability problems that you foresaw having in the first place.

Again, that doesn't mean that Kubernetes is right for every hobbyist project. But there is definitely a (small) subset of hobbyist projects for which it is not overkill.

[toyg]

> A lot of engineers have this tendency to worry about scalability long before it's ever a problem.

"Premature optimization is the root of all evil" -- Donald Knuth

Translating the old suggestions [1] to the realm of devops, I think the point really is: if you are fairly certain that your optimization (k8, docker and so on) will result in "better" code and practices right away, then you should do it. If not, you shouldn't.

I personally find this stuff to be way overkill in a lot of cases. Does Kubernetes really accelerate your development process? If you are a two-men startup, your objective is to find ways to deliver value as quickly as possible, not to play at being Facebook. When you become Facebook (or even just Basecamp), you will then have enough resources to do this optimization. But if you feel your development process is really so much better with K8 and friends (because it's what you used in a previous job or something), by all means go for it.

[1] http://wiki.c2.com/?PrematureOptimization

[wpietri]

100% agreed. If a dev thinks they might want to put something in Kubernetes eventually, there are a few best practices that they could adopt early on to make that easy. But basic hygiene aside, the should wait.

The number of projects that might scale up is much, much smaller than the number of projects that do. If I actually want my project to serve a zillion users, the right place for me to focus my effort is not on Kubernetes, but on user context interviews, user tests, and fast iteration based on the results of experiments.

[crdoconnor]

Kubernetes has a definite whiff of NoSQL - a massively hyped tool/technique originating from Google with oversold benefits.

I tried it about 6 months back with the intent of using it in a corporate prod environment and getting set up was... a massive pain in the ass to say the least - compared to the existing ansible set up. It was supposed to solve headaches, not cause them.

I wasn't impressed. I wouldn't be surprised if it ends up being "Angular 1.0" to someone else's react.

[y4mi]

i set up a kubernetes cluster 1 year ago at work and a private one last weekend.

last year took, i think 2 days. my private one was up and running within ~1h, including writing the ansible role to first install binaries/dependencies and join the cluster as a worker node.

either you didn't use kubeadm to set it up or ... i have no idea how you could've possibly failed.

its pretty much

    (all) ${packagemanager} install docker-ce kubectl kubelet kubeadm
    (master) kubeadm init -> prints token
    (node) kubeadm join ${token}

[colonelpopcorn]

Jeff Geerling even wrote an Ansible role to do all of the heavy lifting for you. I've used it alongside vagrant to spin up a three node cluster in ~15 minutes.

https://github.com/geerlingguy/ansible-role-kubernetes

[mcguire]

I've used OpenStack a good bit, but not Kubernetes directly, and I have never set it up. Is there an up-to-date, in-depth tutorial around?

[geggam]

https://github.com/kelseyhightower/kubernetes-the-hard-way

https://github.com/kubernetes/kops

Be aware of this bug at scale ... its interesting

https://blog.quentin-machu.fr/2018/06/24/5-15s-dns-lookups-o...

[jkmcf]

He's written so many useful and maintained ansible roles.

[crdoconnor]

I didn't fail, I just couldn't see a strong ROI after doing a spike.

I did use kubeadm. It required considerably more than just 3 simple steps required to get a basic working cluster up. Two days was more like it.

[zinclozenge]

Managing kubernetes yourself is a headache and why I more or less only consider managed services like Google Kubernetes Engine for real use-cases. That's why the original article showing that you could install and run it on a set of 3 micro preemptible instances for ~5 month was so compelling to me.

[codegladiator]

https://github.com/kubernetes/kops

[cdelsolar]

how does kubeadm take two days. I had to rebuild my cluster recently and it literally took me 20 minutes.

[y4mi]

I didn't use it last time. It was marketed as beta iirc

[vel0city]

You don't really need to jump into Kubernetes to be prepared to eventually migrate to it. As long as you're using some kind of compatible containerization platform it is not incredibly hard to shift those workloads to Kubernetes. If you're really only needing to run a small handful of containers, running them directly in Docker or rkt isn't challenging and has very little operational overhead compared to running a full k8 cluster.

[giobox]

This echoes my thoughts as well. You can get pretty far with just a simple Docker-Compose file for many personal projects, and still leave the door open to a relatively easy transition to more advanced orchestration tooling should the project grow large enough to require it.

Personally I really like Docker Compose files - virtually no overhead to maintain alongside a handful of Dockerfiles coupled with really simple syntax for expressing the relationships between them. Containers themselves seems conceptually challenging for some newcomers in my experience (concepts like image immutability etc don't have many similar analogues I'd argue if you are new to containers, and I've seen some very experienced developers get stuck trying to map them conceptually to VM images which is not a good fit), but the payoff in the ease of deploying your work is huge. It's nothing a reasonable developer can't learn in a few hours though, and the documentation is pretty good.

I especially find Docker great for projects I worked on years ago - I no longer really need to keep track of how to install/configure the side project I haven't touched in age's software dependencies, just hit 'docker-compose up' and I'm running.

I also really like Docker-Compose as a replacement for things like Vagrant scripts to create developer environments in some scenarios - way less overhead than a vagrant script spinning up multiple VMs on your laptop, and generally much faster deployments.

[geggam]

The question isn't really whether you need dozens of machines, it's whether you can foresee eventually maybe needing dozens of machines.

Kubernetes doesnt manage the machines. It manages the applications on machines that are managed with something else.

You have to do something else to manage the machines

[subhajeet2107]

cluster-autoscaler can mange the machines easily, the point is kubernetes is an abstraction layer, using this level of abstraction is upto the user itself. Should i keep going down with container or using the node itself is the question, in production environment it makes all the sense to use something which has the potential to scale infinitely, but for hobby projects mental overhead doesn't justify using k8

[HelloNurse]

You could say that Kubernetes "manages the machines" from the point of view of the application, by providing a suitable environment to execute in (including actually starting the application)