How I think about Kubernetes • Hacker News Board

Re: How I think about Kubernetes

#61

Post by hbogert » Sat, Dec 27, 2025, 11:22 AM UTC

themgt wrote: post #30

anymouse123456 wrote: post #22

The allure of declarative approaches to complex problem solving has finally been worn down to nothing for me and Kubernetes was the last straw, nearly 10 years ago. The mental gymnastics required to express oneself in yaml, rather than, say, literally anything else, invariably generates a horror show of extremely verbose boilerplate, duplication, bloat, delays and pain. If you're not Google, please for the love of go…

If you're not Google, please for the love of god, please consider just launching a monolith and database on a Linux box (or two) in the corner and see how beautifully simple life can be. You can literally get a Linux box (or two) in the corner and run: curl -sfL https://get.k3s.io | sh - cat How am I installing a monolith and a database on this Linux box without Kubernetes? Be specific, just show the commands for me…

I'm saying this as Kubernetes certified service provider:

Just because you can install it with 1 command doesn't mean it's not complex, it's just made easier, not simpler.

Re: How I think about Kubernetes

#62

Post by NewJazz » Sat, Dec 27, 2025, 5:38 PM UTC

vbezhenar wrote: post #58

NewJazz wrote: post #19

Earlier quoted context omitted.

Some people want their k8s logs to be centralized with non k8s logs. Standardizing log storage seems like a challenging problem. Perhaps they could add built in log shipping . But even then, the transfer format needs to be specified. Adding an idp is pretty standard in k8s... What do you want to actually do different?

I want to add users via manifests, so these users could use logins/passwords/pubkeys, and that's out of the box, without installing dex, keycloak or delegating to other systems. Think about Linux installation. I don't need to add IDP to create unix users for various people. Right now it's super complicated in Kubernetes and even requires third-party extensions for kubectl.

You can create service accounts and tokens... Although long lived tokens are discouraged, that's as simple as it gets.

Sorry I think you're in the minority here. Most people don't want what you are talking about, they want to use SSO. Even with plain Linux machines, they want SSO.

Re: How I think about Kubernetes

#63

Post by welliebobs » Sat, Dec 27, 2025, 6:09 PM UTC

hbogert wrote: post #60

welliebobs wrote: post #41

Earlier quoted context omitted.

You can find even more simplicity in Talos Linux[1]. Drop an ISO onto a USB, run a handful of commands[2] to generate and apply a configuration, and you've got a cluster up and running. [1] https://www.talos.dev/ [2] https://docs.siderolabs.com/talos/v1.12/getting-started/gett...

That's just making it easier, not simpler. I think the parent means, really a drop-in but simpler k8s

Sure, but I was mostly concerning myself with the comment I replied to, having used K3s often enough myself.

Re: How I think about Kubernetes

#64

Post by anymouse123456 » Sat, Dec 27, 2025, 7:51 PM UTC

hbogert wrote: post #61

themgt wrote: post #30

Earlier quoted context omitted.

If you're not Google, please for the love of god, please consider just launching a monolith and database on a Linux box (or two) in the corner and see how beautifully simple life can be. You can literally get a Linux box (or two) in the corner and run: curl -sfL https://get.k3s.io | sh - cat How am I installing a monolith and a database on this Linux box without Kubernetes? Be specific, just show the commands for me…

I'm saying this as Kubernetes certified service provider: Just because you can install it with 1 command doesn't mean it's not complex, it's just made easier, not simpler.

Yah, also there is a huge difference between a minimal demo and actual, recommended, canonical deployments.

I’ve seen teams waste many months refining k8s deployments only to find that local development isn’t even possible anymore.

This massive investment often happens before any business value has been uncovered.

My assertion, having spent 3 decades building startups, is that these big co infra tools are functionally a psyop to squash potential competitors before they can find PMF.

Re: How I think about Kubernetes

#65

Post by themgt » Sat, Dec 27, 2025, 10:37 PM UTC

anymouse123456 wrote: post #64

hbogert wrote: post #61

Earlier quoted context omitted.

I'm saying this as Kubernetes certified service provider: Just because you can install it with 1 command doesn't mean it's not complex, it's just made easier, not simpler.

Yah, also there is a huge difference between a minimal demo and actual, recommended, canonical deployments. I’ve seen teams waste many months refining k8s deployments only to find that local development isn’t even possible anymore. This massive investment often happens before any business value has been uncovered. My assertion, having spent 3 decades building startups, is that these big co infra tools are functionall…

When you're comparing Kubernetes "recommended, canonical deployments" to "just launching a monolith and database on a Linux box (or two) in the corner" the latter is obviously going to seem simpler. The point is the k8s analogue of that isn't actually complicated. If you've seen teams waste months making it complicated, that was their choice.

Re: How I think about Kubernetes

#66

Post by wlonkly » Sun, Dec 28, 2025, 1:19 AM UTC

The author repeats:

> that runtime continuously works to make the infrastructure match your intent.

The flipside of that is that the infrastructure, at any given time, might not match your intent, or might be continuously working to try to match your intent, which means the state of the infrastructure often does not match the state of its configuration, which is hell during an incident.

It makes me wonder if declarative, converging systems are actually what we want, or if they're what we ended up with, or if all the alternatives are just worse.

Re: How I think about Kubernetes

#67

Post by anymouse123456 » Sun, Dec 28, 2025, 4:16 AM UTC

themgt wrote: post #65

anymouse123456 wrote: post #64

Earlier quoted context omitted.

Yah, also there is a huge difference between a minimal demo and actual, recommended, canonical deployments. I’ve seen teams waste many months refining k8s deployments only to find that local development isn’t even possible anymore. This massive investment often happens before any business value has been uncovered. My assertion, having spent 3 decades building startups, is that these big co infra tools are functionall…

When you're comparing Kubernetes "recommended, canonical deployments" to "just launching a monolith and database on a Linux box (or two) in the corner" the latter is obviously going to seem simpler. The point is the k8s analogue of that isn't actually complicated. If you've seen teams waste months making it complicated, that was their choice.

No argument here.

If you’re running things differently and getting tons of value with little investment, kudos! Keep on keeping on!

What I’ve seen is that the vast majority of teams that pick up k8s also drink the micro service kool-aid and build a mountain of bullshit that costs far more than it creates.

Re: How I think about Kubernetes

#68

Post by vbezhenar » Sun, Dec 28, 2025, 12:38 PM UTC

NewJazz wrote: post #62

vbezhenar wrote: post #58

Earlier quoted context omitted.

I want to add users via manifests, so these users could use logins/passwords/pubkeys, and that's out of the box, without installing dex, keycloak or delegating to other systems. Think about Linux installation. I don't need to add IDP to create unix users for various people. Right now it's super complicated in Kubernetes and even requires third-party extensions for kubectl.

You can create service accounts and tokens... Although long lived tokens are discouraged, that's as simple as it gets. Sorry I think you're in the minority here. Most people don't want what you are talking about, they want to use SSO. Even with plain Linux machines, they want SSO.

Service accounts can't belong to groups, so they are super not convenient for human operators. You can't just create group "developers", assign roles for this group and add service accounts to this group. You must assign role for every user in every namespace, etc.

Having SSO is fine as long as it's built-in. Installing and configuring separate SSO software is not fine.