Live data from Hacker News

Kubernetes for personal projects? No thanks

carlosrdrz.es

41–50 of 278 posts

Re: Kubernetes for personal projects? No thanks

#41

> Do you want to do all of this because you think is fun? Or because you want to learn the technology? or just because? Please, be my guest! [...] Kubernetes is likely here to stay. If you're interested in running a cluster to undestand what the hype is all about and to learn something new, you should do it. Also, ignore everybody telling you that this platform wasn't meant for that. Complexity is a weak argument. On…

I will also invite everyone to try it and I also believe K8S is here to stay. I think K8S makes a lot of sense for lots of workloads, but I don't think it makes sense to maintain a k8s cluster to run personal projects.

About complexity, what you're saying is true, but I think "once your cluster is running" is making a lot of assumptions about what is actually running in the cluster in terms of infra and what workloads you can run there.

Re: Kubernetes for personal projects? No thanks

#42

> Do you want to do all of this because you think is fun? Or because you want to learn the technology? or just because? Please, be my guest! [...] Kubernetes is likely here to stay. If you're interested in running a cluster to undestand what the hype is all about and to learn something new, you should do it. Also, ignore everybody telling you that this platform wasn't meant for that. Complexity is a weak argument. On…

> Complexity is a weak argument I see you've never tried to upgrade a running kubernetes cluster or been in an on call schedule for one. It's a new technology that is still maturing but it has a lot of moving parts all of which require a fair bit of understanding and which change on a regular basis. Hell, just a few months ago the ACM agent totally got rewritten and now you have a choice between alpha software or a d…

I treat my cluster as immutable. My setup is open source: https://github.com/hobby-kube/guide

Re: Kubernetes for personal projects? No thanks

#43
The point about complexity is exactly right.

Every new thing that you add, adds complexity. If that thing interfaces with another, then there is complexity at the interfaces of both.

Modern tools that atomise everything reduce density (and thus complexity), but people aren't paying attention to the amount of abstractions they are adding and their cost.

Re: Kubernetes for personal projects? No thanks

#44

Earlier quoted context omitted.

Well I think that's more of a cost question -- AWS can get expensive pretty quickly. Three t2.micros (one coordinator, 2 nodes) are absolutely pitiful in terms of processing power but that's already ~$30/month when you could get a way beefier machine on Hetzner whether dedicated or cloud (also Scaleway[0]). I'm a fan of Hetzner because I think their cheap dedicated machines are worth the operational costs for me, and…

I'd be really interested in how you're approaching persistence? I've also found self managing clusters provisioned with kuibeadm fairly hassle free until persistence is involved. Not so much setting it up (e.g. rook is fairly easy to get going with now), but the ongoing maintenance, dealing with transitioining workloads between nodes etc etc.

tl;dr - Rook is the way to go, with automatic backups set up -- using rook means your cluster resources are ceph-managed, you basically have a mini EBS -- Ceph does replication across machines for you in the background, and all you have to do is write out snapshots of the volume contents from time to time just in case you get spectacularly unlucky and X nodes fail all at once, in just the right order to make you lose data. Things get better/easier with CSI (Container Storage Interface) adoption and support, snapshotting is right in the standard and restore is as well -- barring catastrophic failures you can just lean super hard on Ceph (and probably one more cluster-external place for colder backups).

I'd love to share! In the past I've handled persistence in two ways:

- hostPath setting on pods[0]

- Rook[1] (operator-provisioned ceph[2] clusters, I free up one drive on my dedicated server and give it to rook to manage, usually /dev/sdb)

While Rook worked well for me for a long time, It didn't quite work for me in two situations:

- Setting up a new server without visiting Hetzner's rescue mode (which is where you would be able to disassemble RAID properly)

- Using rkt as my container runtime. The Rook controller/operator does a lot of things which require a bunch of privileges, which rkt doesn't give you by default and I was too lazy to work it out. I use and am happy with containerd[3] (and will be in the future) as my runtime however, so I just switched off rkt.

right now, I actually use hostPath volumes, which isn't the greatest (for example you can't really limit them properly) -- I had to switch from Rook due to my distaste for needing to go into Hetzner rescue mode to disassemble the pre-configured RAID (there's no way currently to ensure they don't raid the two drives you normally get after the automated operating system setup). Normally RAID1 on the two drives they give you is a great thing, but in this case I actually don't really care much for main server contents since I try to treat my servers as cattle (if the main HDD somehow goes down it should be OK), and I know that as long as ceph is running on the second drive I should have reliability as long as I have more machines which is the only way to really improve reliability, anyway.

Supposedly, you can actually just "shrink" the raid cluster to one drive, and then remove the second drive from the cluster -- then I could format the drive and give it to Rook. With Rook though (from the last time I set up the cluster and went through the raid disassembly shenanigans ), things are really awesome -- you can store PVC specs right next to the resources that need them -- this is much better/safer than just giving the deployment/daemonset/pod a hostpath.

These days, there's also local volumes[4], which are similar to hostPath, but offer a benefit in that your pod will know where to go because the node affinity is written right into the volume. Your pod won't ever try and run on a node where the PVC it's expecting isn't present. The downside is that local volumes have to be pre-provisioned, which is basically a non starter for me.

I haven't found a Kubernetes operator/add-on that can dynamically provision/move/replicate local volumes, and I actually wanted to write a simple PoC one of these weekends -- I think it can be done naively by maintaining a folder full of virtual disk images[4] and creating/mounting them locally when someone asks for a volume. If you pick your virtual disk filesystem wisely, you can get a lot of snapshotting, replication, and other things for free/near-free.

One thing Kubernetes has coming that excites me is the CSI (Container Storage Interface)[5] which is in beta now and standardizes all of this even more. Features like snapshotting are right in the rpc interface[6], which means once people standardize to it, you'll get a consistent means across compliant storage drivers.

What I could and should probably do is just use a hetzner storage box[7].

[0]: https://kubernetes.io/docs/concepts/storage/volumes/#hostpat...

[1]: https://rook.github.io/docs/rook/v0.8/

[2]: http://docs.ceph.com/docs/master/start/intro/

[3]: https://github.com/containerd/

[4]: https://kubernetes.io/docs/concepts/storage/volumes/#local

[5]: https://kubernetes.io/blog/2018/04/10/container-storage-inte...

[6]: https://github.com/container-storage-interface/spec/blob/mas...

[7]: https://www.hetzner.com/storage-box?country=us

Re: Kubernetes for personal projects? No thanks

#45

Frankly the article is filled with FUD and the author justifies everything with "i think/what if/my way is fine for me". You don't need to run a new cluster for every project. You can deploy multiple projects in a single cluster. I was running close to 5 different projects in a single cluster, backed by about 3-6 machines (machines added/removed on demand). Kubernetes is basically like your own heroku. You can create…

> Frankly the article is filled with FUD and the author justifies everything with "i think/what if/my way is fine for me".

It is just my opinion after all. I'm just trying to share my thoughts :)

> Yes it is. I wonder if the author has actually tried setting this themselves.

I've used K8s for months in production, maintaining a few clusters at my previous job.

Re: Kubernetes for personal projects? No thanks

#47
post #21

Oh man, the original article went way over the author's head. The point of the original article was that even though Kubernetes is primarily useful for tackling the challenges involved with running many workloads at enterprise scale, it can also be used to run small hobbyist workloads at a price point acceptable for hobbyist projects. Does that mean that Kubernetes should now be used for all hobbyist projects? No. If…

I do agree with you, but I don't think I really missed the point of the original article. From the original article: > However popular wisdom would suggest that Kubernetes is an overly complex piece of technology only really suitable for very large clusters of machines; that it carries a large operational burden and that therefore using it for anything less than dozens of machines is overkill. I think that's probably…

I have to disagree. It doesn't introduce burden and complexity. They're already there whether you use Kubernetes or not.

The difference is that if you did build it all by hand as the author said, if it ever scales, you're going to have double the job to make it scale.

It's all a question of: do I think my software will succeed?

If it's a hobby project that will never get big, it's not worth the hassle. If it actually has a chance of succeeding, the small added complexity of Kubernetes will pay dividends extremely quickly when the system needs to scale.

Even with as little as two machines, I'd argue k8s is already adding more value than managing those by hand. People can say otherwise because they're used to it, but being used to it is not the point of the discussion.

The author also talks about Ansible which is another piece of complexity that would be comparable with doing it in k8s. I'd argue you have less YAMLs with k8s than with Ansible for a small project.

The only argument I see for doing anything by hand today is if it's a play thing.

Re: Kubernetes for personal projects? No thanks

#48

> Do you want to do all of this because you think is fun? Or because you want to learn the technology? or just because? Please, be my guest! [...] Kubernetes is likely here to stay. If you're interested in running a cluster to undestand what the hype is all about and to learn something new, you should do it. Also, ignore everybody telling you that this platform wasn't meant for that. Complexity is a weak argument. On…

I will also invite everyone to try it and I also believe K8S is here to stay. I think K8S makes a lot of sense for lots of workloads, but I don't think it makes sense to maintain a k8s cluster to run personal projects. About complexity, what you're saying is true, but I think "once your cluster is running" is making a lot of assumptions about what is actually running in the cluster in terms of infra and what workload…

> About complexity, what you're saying is true, but I think "once your cluster is running" is making a lot of assumptions about what is actually running in the cluster in terms of infra and what workloads you can run there.

Already answered in a way:

> Can this be automated? Sure, but I'd rather automate my cluster provisioning.

If I need more computational power or a specific 3rd-party service that I don't have available at this point, I simply tear down my current cluster and deploy it elsewhere.

Re: Kubernetes for personal projects? No thanks

#49
post #21

Oh man, the original article went way over the author's head. The point of the original article was that even though Kubernetes is primarily useful for tackling the challenges involved with running many workloads at enterprise scale, it can also be used to run small hobbyist workloads at a price point acceptable for hobbyist projects. Does that mean that Kubernetes should now be used for all hobbyist projects? No. If…

I do agree with you, but I don't think I really missed the point of the original article. From the original article: > However popular wisdom would suggest that Kubernetes is an overly complex piece of technology only really suitable for very large clusters of machines; that it carries a large operational burden and that therefore using it for anything less than dozens of machines is overkill. I think that's probably…

> 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.

Re: Kubernetes for personal projects? No thanks

#50
post #5

I totally agree with this article. I'm giving a point of a view of a pure developer who knows nothing about DevOps things and managing servers. I kind of know what NGINX is and barely know how to configure something like systemd. I recently setup a digital ocean droplet and setup my blog there to actually understand how it works. It was great because I learned a ton and feel in control. Pretty simple setup - single d…

> I understand it gets expensive quickly, but I really want to see the cost difference of Heroku vs the time spent for the engineering team to manage all the complexities of devops, automated deploys, scaling, and I'm not even mentioning all the data/logging/monitoring things that Heroku allows to add with 1 click.

Well, if you use a k8s cluster on GKE for example, you will have literally all those things by default. Not even a click needed.

IMO running your own Kubernetes cluster for a company is insanity unless you have a very good reason to do so.

Post reply on HN