Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

The only downside is that k3s takes almost half a gig of ram. That does bump up the minimum VPS side a bit. It is overkill, but, in my mind, it is wonderful & greatly liberating overkill.

It feels a little silly setting up a webserver the first time with a 45 line yaml file, but as you continue to make your way in the world, kubernetes is just such an amazingly pleasant top-down way of controlling systems, where it's so easy to see what you have, to see what is behaving and what isn't, and it's so easy to talk & share & communicate with other people about what you are doing versus trying to understand some handjammed nonsense a previous sysop scratched together 4 years ago.

I'm rapidly planning out how to extend my Kubernetes life further. I've spent years writing Ansible scripts to automate setting up workstations, but I'd really like to switch over the bulk of the things I rely on to being more Kubernetes based. For example, I run prometheus's node-exporter to monitor the health of my systems. But if the config changes, or if I add a plugin, or if I start using a new laptop, I need to go re-run the script, and any other scripts. With Kubernetes, I can create a daemonset and it's fire and forget. It'll run on every node, and any changes I make will get applied to all nodes, whenever the node comes online or joins. Also my prometheus server wont need to be manually updated to point to these nodes when they get added.

Quick note: K3s embed kubectl and helm in it; the install script symlinks helm and kubectl to the k3s binary. Also crictl for the container runtime tool. If you ask for k3s, you get these other things.



This particular problem you mentioned can easily be solved in ways that do not involve Kubernetes, for example, having a linux image w/ prometheus daemon running and some sort of service discovery (consul) that prometheus hooks to to discover the infrastructure.


Kubernetes is more all encompassing than the alternatives. I see no incentive to go about cobblimg together specific tools to get one capability, when I can start using a much more powerful consistent cloud architecture to manage my everything.


I have preferred smaller tools that do one thing only and are easy to manage / break in predictable ways.


An opinion we see thoroughly, adamantly expressed throughout the comments on this posting. Everyone seems very opposed.

It seems odd to me, because Kubernetes is so new, and there have been few attempts to manage things consistently & well, under one umbrella, that have happened. Certainly none have gotten anywhere near this successful.

I think there's a lot of value to trying to find core abstractions & use them throughout. Managing each resource via totally separate tooling is how we've always done things from an ops perspective, but the coders have been trying to distill & create enduring shareable value for a long time, find ways to share value. It's weird to me how resistant, how much people think they know what their opinion is, how certain they are that only small specific tools can help them, and how convinced they are that bigger attempts are going to be hard to manage, or convinced that they won't be able to see or understand breakage. I don't think we have the experience to know, yet people seem deeply committed already.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: