I agree with the idea the post is trying to do but not with the justifications, I think it's wrong to compare Kubernetes vs rsync or ansible, it resolves a different problem, container cluster management, a more appropriate comparison would had been to compare with simpler solutions in the same domain, such as docker swarm or nomad.
Kubernetes for personal projects? No thanks
121–130 of 278 posts
Re: Kubernetes for personal projects? No thanks
#122Earlier quoted context omitted.
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…
Let's talk about complexity for a moment, for one aspect of a simple service: ingress. Kubernetes: apiVersion: extensions/v1beta1 kind: Ingress metadata: name: test-ingress spec: rules: - http: paths: - path: /testpath backend: serviceName: test servicePort: 80 Nginx: location /testpath { proxy_path http://127.0.0.1:8080 } Which is less complex? Which is beta, and thus could be changed over time (it happens a lot). W…
I think this is proving my point. They're basically the same, but one is completely dynamic and the other will have to be changed as soon as anything changes.
We've been using Kubernetes in production for almost two years now and I have yet to face a big API change that breaks everything. The core APIs are stable. There's a lot of new stuff added, but nothing that breaks backwards compatibility.
As you just said, if it's a simple project, you can upgrade the infrastructure by clicking "upgrade" on GKE. We've only ever hit problems when upgrading when using the bleeding edge stuff and the occasional bug (once since Kubernetes 1.1 to 1.10 for a large Rails app).
Regarding the yaml document per resource, I mean... that's spaghetti Ansible. If you want to have a proper Ansible setup you will have separate tasks and roles. If we're going down the route of just have "less files" you can have all the Kubernetes resources in a single YAML file. I would definitely not recommend that tho.
While Kubernetes is a lot more verbose, it is light years better than the Ansible jinja2 weird syntax. Even someone that never heard of Kubernetes can read that Ingress resource and guess what it does. If we're being really picky actually, the proxy_path should be pointing to some "test" thing that would have to be an upstream that would already make the NGINX config more obscure.
I feel like people just hate Kubernetes to avoid change. These arguments are never about Kubernetes' strengths or faults but about why "I think my way is better". You can always do things in millions of ways and they all have tradeoffs. The fact is: ROI on Kubernetes is a lot bigger than any other kind of manual setup.
I'll repeat what I said on another comment: the only reason to do anything by hand today is if it's a play thing
Re: Kubernetes for personal projects? No thanks
#123I agree with the idea the post is trying to do but not with the justifications, I think it's wrong to compare Kubernetes vs rsync or ansible, it resolves a different problem, container cluster management, a more appropriate comparison would had been to compare with simpler solutions in the same domain, such as docker swarm or nomad.
Or with smth even simpler, like condo (https://github.com/prepor/condo)
Re: Kubernetes for personal projects? No thanks
#124Oh 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…
>But maybe I envision my side project turning into full-time startup some day. Maybe I see all the news about Kubernetes and think it would be cool to be more familiar with it. Nah, probably too expensive. Oh wait, I can get something running for $5? Hey, that's pretty neat! Exactly. Or maybe "I would love to advance my career and work for a larger company that is using Kubernetes, and I can get some hands on experie…
FYI the last part of the conclusion mentions this as well:
"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! But really, would I do all of this just to run a personal project? No thanks."
Re: Kubernetes for personal projects? No thanks
#125This whole line of debate is really getting tiresome. Kubernetes has proven its value in production use cases across a wide variety of application domains. That doesn't mean everybody should be using it, any more than the proven value of containers means that everyone should be deploying in them. I've been working with k8s for three years and run multiple production clusters, but if I had some little thing I might ve…
I wholeheartedly agree with this. It's one of many HN debates that boil down to whether X is the right tool. Thing is, you can't judge about the usefulness of a tool without factoring in its users. If you and your team have experience with Kubernetes and its ecosystem, you'll have no problems reaping its advantages even for small deployments. If that's not the case, then by all means, pick something else.
Re: Kubernetes for personal projects? No thanks
#126You could also have told that it is a very complex system where one still just runs Bash scripts to solve exactly the same problems as on bare metal, VMs, etc.
Re: Kubernetes for personal projects? No thanks
#127I looked into using Kubernetes for my personal servers, but I abandoned the idea when I saw that the minimal Kubernetes setup uses more compute resources than all the services [1] it's supposed to manage combined (e.g. 0.5 GiB RAM vs. 0.25 GiB, which is substantial on a 1/1 VM). And that's before you consider that a single-server setup is not The Right Way (TM) in k8s land. [1] Gitea (Github clone), Murmur (voice-cha…
IMHO Kubernetes only makes sense if you can, or want to, run multiples of things that are either stateless or clustered in some way, or another copy for a different purpose.
Run two instances of something if you want to survive a single crash or a node update. Run another copy of your application stack if you want to try out a different version or config.
Without looking at the docs, most of the things in your list are single-instance stateful applications, so unless you plan to run another copy of them for a different purpose, K8S is overkill.
Re: Kubernetes for personal projects? No thanks
#128Oh 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 think the number of containers rather than the number of machines should be the leading factor.
IMHO it makes sense for most setups that have multiple micro-services that need to interact with each other. A single node cluster running a single container is kind of pointless; I agree. And you are not going to run much more than that on a micro instance. So, I agree with the main point of the article that this probably is not an appropriate setup for any kind of home setup unless of course you really want to have kubernetes (which would be a valid reason for attempting this).
If you run multiple microservices you have most of the problems that kubernetes solves out of the box and attempting to solve those by manually gobbling together bits of infrastructure outweighs the financial overhead of running kubernetes. So any moderately small setup where you are in any case going to have 2 or 3 machines running multiple containers, you probably should be looking at kubernetes.
So, if you are in Google or amazon, hosted kubernetes is definitely worth considering. You probably want a loadbalancer as well. So, at that point you are looking at ~50-100+$ per month anyway for a couple of instances, a LB and whatever else you need (e.g. RDS, S3, etc).
For anything running commercially, that's entirely defensible. Yes you can run cheaper on bare metal but people tend to forget all the hours doing devops stuff are also cost you. A day of a competent dev will easily run you kubernetes for quite some time. Unless your devs are super bored, make them spend their hours on more valuable stuff than reinventing wheels.
Re: Kubernetes for personal projects? No thanks
#129Earlier quoted context omitted.
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.
how does kubeadm take two days. I had to rebuild my cluster recently and it literally took me 20 minutes.
I didn't use it last time. It was marketed as beta iirc
Re: Kubernetes for personal projects? No thanks
#130I agree with the idea the post is trying to do but not with the justifications, I think it's wrong to compare Kubernetes vs rsync or ansible, it resolves a different problem, container cluster management, a more appropriate comparison would had been to compare with simpler solutions in the same domain, such as docker swarm or nomad.
I think the whole point of the article is that k8s solves a different problem: orchestrating large sets of images if your application uses a significant portion of a datacenter.
The problems one _actually_ has on a personal projects are indeed solved with simple tools like rsync.