Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Dear friend, you have built a Kubernetes (2024)

macchaffee.com

Post reply on HN
Print view View original

71–80 of 183 posts

Re: Dear friend, you have built a Kubernetes (2024)

#71

Post by cortesoft »

ablob wrote: post #37
cortesoft wrote: post #11

This is obviously slightly exaggerated, but I do feel like this whenever people dismiss Kubernetes as either too complicated or not needed. The response I always got when suggesting Kubernetes is "you can do all those things without Kubernetes" Sure, of course. There are a million different ways to do everything Kubernetes does, and some of them might be simpler or fit your use case more perfectly. You can make diffe…

I just feel like "you can do this with Kubernetes" is a slippery slope. "You can do X with Y, so use Y" is a great way to add a dependency, especially if it is "community vetted" already. Sometimes simple is better - you don't need to add anything that implements some of you logic as a dependency to stay DRY or whatever you want to call it. It really feels like we are drowning in self-imposed tech debt and keep addin…

Kubernetes handles so many layers you are going to need for every app, though… deployments, networking, cert management, monitoring, logging, server maintenance, horizontal scaling… this isn’t a slippery slope, it is just what you need.

Re: Dear friend, you have built a Kubernetes (2024)

#72

Post by cortesoft »

subhobroto wrote: post #49
cortesoft wrote: post #11

This is obviously slightly exaggerated, but I do feel like this whenever people dismiss Kubernetes as either too complicated or not needed. The response I always got when suggesting Kubernetes is "you can do all those things without Kubernetes" Sure, of course. There are a million different ways to do everything Kubernetes does, and some of them might be simpler or fit your use case more perfectly. You can make diffe…

> This is VERY powerful No argument there. The Toyota 5S-FE non-interference engine is a near indestructible 4 cylinder engine that's well documented, popular and you can purchase parts for pennies. It has powered 10 models of Camrys and Lexus and battle proven. You can expect any mechanic who has been a professional mechanic for the last 3 years know exactly what to do when it starts acting up. 1 out of 4 cars on th…

Sure, but to extend your metaphor, Kubernetes HAS smaller engine models that you can use in those situations, and still gain all the benefits of being in the same ecosystem. You can use K3s, for example, and get all the benefits without having a giant engine in your weedwhacker.

Re: Dear friend, you have built a Kubernetes (2024)

#73

Post by Kinrany »

cortesoft wrote: post #11

This is obviously slightly exaggerated, but I do feel like this whenever people dismiss Kubernetes as either too complicated or not needed. The response I always got when suggesting Kubernetes is "you can do all those things without Kubernetes" Sure, of course. There are a million different ways to do everything Kubernetes does, and some of them might be simpler or fit your use case more perfectly. You can make diffe…

If you can solve the same problem in a simpler way without using k8s, that means k8s is not a zero cost abstraction.

It's not obligated to be, but it's also obvious why people would want it to be.

Re: Dear friend, you have built a Kubernetes (2024)

#74

Post by cortesoft »

tarkin2 wrote: post #48
nazcan wrote: post #41

Earlier quoted context omitted.

But if you want some redundancy, k8s let's you just say run 4 of this, 6 of this on these 3 machines. At least I find it quite straight forward. The database is more complex since there is storage affinity (I use cockroachDB with local persistent volumes for it) - but stateful is always complicated.

Most of the time you don't need redundancy. You need regular backups for exceptional circumstances. And k8s gives you more complexity, and more problems through more moving parts, to give you the possibility of using a feature you'll never need, and if you do start to use it it'll probably be instead of fixing performance problems downstream

Are we talking for personal projects where there are no expectations, or small startups where you don’t have much scale but you still care about down time and data loss?

Personal projects are one thing, but even the smallest startup wants to be able to avoid data loss and downtime. If you are running everything on one server, how do you do kernel patches? You need to be able to move your workload to another server to reboot for that, even if you don’t want redundancy. Kubernetes does this for you. Bring in another node, drain one (which will start up new instances on the new node and shift traffic before bringing down the other instance, all automatically for you out of the box), and then reboot the old one.

Again, you could do all of this with other tech, but it is just standard with Kubernetes.

Re: Dear friend, you have built a Kubernetes (2024)

#75

Post by andai »

jmalicki wrote: post #39
PunchyHamster wrote: post #26

Earlier quoted context omitted.

Honestly the main problem is people using k8s for something that's like... a database, and an app, and maybe a second app, that all could be containers or just a systemd service. And then they hit all the things that make sense in big company with like 40 services but very little in their context and complain that complex thing designed for complex interactions isn't simple

Luckily since I met this guy named Claude most of that complexity has gone away.

A while back when the agents got hyped I was looking into the whole "give it a VM / docker container" I realized the safest and simplest option was just to give it its own machine.

Then I realized giving it root on a $3 VPS is functionally equivalent. If it blows it up, you just reset the VM.

It sounds bad but I can't see an actual difference.

Re: Dear friend, you have built a Kubernetes (2024)

#76

Post by cortesoft »

throwawaypath wrote: post #53
echelon wrote: post #40

Earlier quoted context omitted.

You can use k8s on $2/mo digital ocean projects. It probably even works on the free tier of a lot of providers. And there's zero setup. Just a deployment yaml that specifies exactly what you want deployed, which has the benefit of easy version control. I don't get why people are so bent on hating Kubernetes. The mental cost to deploy a 6-line deployment yaml is less than futzing around with FTP and nginx. Kube is the…

>And portable. This made me audibly guffaw. Kubernetes is a lot of things, but "portable" is not one of them. GKE, EKS, AKS, OCP, etc., portability between them is nowhere near guaranteed.

It is if you stick to standard Kubernetes resources, and it has gotten even easier with better storage class and load balancer support. All of the cloud providers now give you default storage classes and ingresses when you provision a cluster on them, so you can use the exact same deployment on any of them an automatically get those things provisioned in the right way out of the box.

Re: Dear friend, you have built a Kubernetes (2024)

#77

Post by blindlobstar »

PufPufPuf wrote: post #69
blindlobstar wrote: post #43

Why both posts mention docker compose and not mentioning docker swarm. Being using it for my projects for long time. And it's so nice. Similar syntax, easy networking, rollout strategy, easy to add nodes to cluster. You can have one template docker-compose.yaml file and separate deployment files for different envs, like: docker-compose.dev.yaml, docker-compose.prod.yaml I think swarm is really underrated

I've been there. We still ended up with messy deploy scripts written in Ruby and the only debugging solution was "just comment out everything then run line by line".

'docker stack deploy' covers most of the cases. But yeah, there is still some problems like: "update a config or a secret", that require manually invoking additional commands (or via scripts)

Re: Dear friend, you have built a Kubernetes (2024)

#78

Post by cortesoft »

Kinrany wrote: post #73
cortesoft wrote: post #11

This is obviously slightly exaggerated, but I do feel like this whenever people dismiss Kubernetes as either too complicated or not needed. The response I always got when suggesting Kubernetes is "you can do all those things without Kubernetes" Sure, of course. There are a million different ways to do everything Kubernetes does, and some of them might be simpler or fit your use case more perfectly. You can make diffe…

If you can solve the same problem in a simpler way without using k8s, that means k8s is not a zero cost abstraction. It's not obligated to be, but it's also obvious why people would want it to be.

> If you can solve the same problem in a simpler way without using k8s

I think I disagree with this, or at least the implication. I think it is true you can solve EACH OF THISE PROBLEMS INDIVIDUALLY in a simpler way than Kubernetes, the fact that you are going to have to solve at least 5-10 of those problems individually makes the sum total more complicated than Kubernetes, not to mention bespoke. The Kubernetes solutions are all designed to work together, and when they fail to work together, you are more likely to find answers when you search for it because everyone is using the same thing.

I think it is fair to say k8s is not a zero cost abstraction, but nothing you use instead is going to be, either, and when you do run into a situation where that abstraction breaks, it will be easier to find a solution for kubernetes than it will for the random 5 solutions you pieced together yourself.

Re: Dear friend, you have built a Kubernetes (2024)

#79

Post by throwawaypath »

cortesoft wrote: post #76
throwawaypath wrote: post #53

Earlier quoted context omitted.

>And portable. This made me audibly guffaw. Kubernetes is a lot of things, but "portable" is not one of them. GKE, EKS, AKS, OCP, etc., portability between them is nowhere near guaranteed.

It is if you stick to standard Kubernetes resources, and it has gotten even easier with better storage class and load balancer support. All of the cloud providers now give you default storage classes and ingresses when you provision a cluster on them, so you can use the exact same deployment on any of them an automatically get those things provisioned in the right way out of the box.

>It is if you stick to standard Kubernetes resources

"If you stick to standard C..."

No one does, that's the issue. Helm charts that only support certain cloud providers, operators and annotations that end up being platform specific, etc.

>now give you default storage classes and ingresses

Ingress is being deprecated, it's Gateway now! Welcome to hell, er, Kubernetes.

Re: Dear friend, you have built a Kubernetes (2024)

#80

Post by cassianoleal »

supriyo-biswas wrote: post #24
srcreigh wrote: post #17

Earlier quoted context omitted.

Seems to be a case of the XY problem. What do you need cleanups and hooks for?

Cleanups: I want to do a `helm uninstall` and have all the manifests go away at once instead of looking around for N different resources. Hooks: I want to apply my database migrations and populate the database with static datasets before I deploy my application, without having my CI connect to the database cluster (at places I've worked, the CI cluster and K8s cluster were completely separate).

> Cleanups: I want to do a `helm uninstall` and have all the manifests go away at once instead of looking around for N different resources.

    kubectl delete -f 

    kubectl delete -k
> I want to apply my database migrations and populate the database with static datasets before I deploy my application, without having my CI connect to the database cluster

A Job feels like a good fit for this. CI deployes the Job without connecting to DB, Job runs migrations using the same connectivity as the application.

Post reply on HN