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

Kubernetes is hard

rcwz.pl

Post reply on HN
Print view View original

111–120 of 164 posts

Re: Kubernetes is hard

#111

Post by menacingly »

mirekrusin wrote: post #66
endisneigh wrote: post #17

Cost aside, I wonder how far you can get with something like a managed newsql database (Spanner, CockroachDB, Vitess, etc.) and serverless. Most providers at this point offer ephemeral containers or serverless functions. Does a product focused, non infra startup even need k8s? In my honest opinion people should be using Cloud Run. It’s by far Google’s best cloud product. Anyway, going back to the article - k8s is har…

Cloud services are shit unless I can run them locally when developing and testing.

why on earth do you need a functional implementation of a consumed service for testing?

Re: Kubernetes is hard

#112

Post by markus_zhang »

justinclift wrote: post #100
markus_zhang wrote: post #96

I feel with AI, maybe in a couple of years it's going to trivial to deploy things on current infra stacks. AI can probably create whole range of Terraform scripts, deploy k8s and dockers and scale them automatically, with maybe a few humans as supervisor.

The other side of that is debugging things when stuff goes wrong. From that perspective, it kind of sounds absolutely horrible unless matching "figure out what went wrong" pieces evolve to match.

Yeah. And there is not much chance to actually write new stuffs from scratch. I wonder how do we find more seniors when the grey hairs pass away.

Re: Kubernetes is hard

#114

Post by xyzzy_plugh »

preseinger wrote: post #104
xyzzy_plugh wrote: post #88

Earlier quoted context omitted.

Who said anything about a large-scale startup? Kubernetes is approachable all the way down to N=1 employees. I strongly disagree with your take on static vs dynamic scheduling. Static scheduling ties your hands early. In a mature organization, it is very much an optimization. Dynamic scheduling forces a cattle-not-pets mentality out of the gate, which is great. It also gives you all the knobs to figure out HA, right-…

deploying kubernetes in an org of O(1) or O(10) or even arguably O(100) engineers is professional negligence the benefits just don't outweigh the costs, until you get to org sizes where dunbar's number starts to matter "static scheduling" is the right choice for ~80% of technology orgs

You're likely looking at the problem from a different angle. Kubernetes is an ecosystem for managing software deployed on a fleet. There's value in that even if it's two or three hosts. What size of an org is too small for Terraform? Puppet? CI/CD? Docker? Some bash scripts?

All these tools should fundamentally solve some piece of the puzzle for you. Kubernetes on a managed platform just happens to cover many pieces that you still need to solve otherwise. It may be more novel than some other technology but it's not less proven or difficult, fundamentally.

Most of the criticism I see here is literally just FUD. I run Kubernetes at home. It's fine. It's less work than anything comparable I've ever encountered.

Re: Kubernetes is hard

#115

Post by nailer »

deathanatos wrote: post #53
988747 wrote: post #5

Earlier quoted context omitted.

Yes, they did, but did it really take less effort than running it on Kubernetes?

People think it took less effort. Right up until you needed to do one of the very many things k8s implements. For example, in multiple previous employers, we had cronjobs: you just set up a cronjob on the server, I mean, really, how hard is that to do? And that server was a single point of failure: we can't just spin up a second server running crond, obviously, as then the job runs twice. Something would need to prov…

I have 0 results for PDB SRE on multiple search engines. What does it mean?

Re: Kubernetes is hard

#116

Post by tptacek »

xyzzy_plugh wrote: post #114
preseinger wrote: post #104

Earlier quoted context omitted.

deploying kubernetes in an org of O(1) or O(10) or even arguably O(100) engineers is professional negligence the benefits just don't outweigh the costs, until you get to org sizes where dunbar's number starts to matter "static scheduling" is the right choice for ~80% of technology orgs

You're likely looking at the problem from a different angle. Kubernetes is an ecosystem for managing software deployed on a fleet. There's value in that even if it's two or three hosts. What size of an org is too small for Terraform? Puppet? CI/CD? Docker? Some bash scripts? All these tools should fundamentally solve some piece of the puzzle for you. Kubernetes on a managed platform just happens to cover many pieces…

This is the attitude I recoil from. Some of the technologies you listed --- CI is an example --- earn their keep so well that they're essentially universal best practices (at least for serverside software). But others don't, and you can't use a list that includes, like, "source control" as a way to launder in the idea that Kubernetes is a universal best practice. It is not. It earns its keep in some places and not in others.

Re: Kubernetes is hard

#117

Post by master_crab »

dekhn wrote: post #78
0xbadcafebee wrote: post #55

> Kubernetes is complex and I think they are partially right Kubernetes is a distributed centralized operating system which itself depends on a distributed decentralized database, and has a varying network topology, permissions system, plugins, scheduler, storage, and much more, depending on how & where it was built, and runs applications as independent containerized environments (often deeply dependent on Linux kern…

if you think k8s is the most complex system anyone in the world will ever use: 50K googler using borg beg to disagree.

This is a bad argument.

You are basically admitting that companies need google-level resources to hire dozens (hundreds?) of infra engineers to maintain a K8s-type infra.

Re: Kubernetes is hard

#118

Post by Spivak »

dgroshev wrote: post #90
lcw wrote: post #60

Earlier quoted context omitted.

> 1. Make it work 2. Make it good 3. Make it fast Anecdotally, everytime someone tells me Kubernetes is overkill and then follows your approach. In a year they end up building the capabilities that come out of the box with Kubernetes, and of course they aren't as well thought out. Because they were done adhoc and as needed.

Why is that bad? If the business survived for long enough to have that problem, that's a win, not a failure. Being killed or at least hobbled by unnecessary complexity, on the other hand, is a thing in way more businesses than we like to admit.

Yep, you can grow to be a huge company with just autoscaling groups and some terraform.

Absolutely painfully boring stack. I’m working at a place now with that stack and we haven’t had a single page in over a year now and we do 5 deploys a day ish.

Re: Kubernetes is hard

#119

Post by YetAnotherNick »

nerdix wrote: post #72
YetAnotherNick wrote: post #63

Earlier quoted context omitted.

> 1. Make it work 2. Make it good 3. Make it fast Disagree. The first two objective clashes very much with each other. I have worked in teams that did that. And generally if anything non trivial is done without planning to just "make it work", it would be more often than not, ridden with many design issues which doesn't allow it to be good.

I've never seen anything that couldn't be incrementally improved. There are definitely tons of situations where the additional effort to "make it good" is worth incurring upfront. But you can definitely make something work then make it better. And a lot of times, you'll find that your carefully planned out "good" solution ends up not being all that good and needs incremental improvement. It can be hard to get somethi…

I have rarely seen bad but barely workable website become good with incremental improvement. After the product reaches some threshold of users, it is hard to change the code structure in a safe testable way if there is no good way to test it in production like environment, and so developers are rightfully afraid to make any big changes in one go. I have seen many examples both internally and externally.

- My bank's website which is a decade old and has millions of users, has tons of issues. I am not even talking about UI or look. It randomly hangs, session disconnects etc.

- ERP tool of one of my previous org sucked, even though used by 10s of 1000s of people and having dedicated team in maintaining.

- One team that I worked with has no proper staging environment, and it would have required synced deployment of dozens of services with many teams working with different language and config. And just this simple task couldn't be completed even with push from upper management, just because of complexity.

Lot of companies doesn't even have these: Have a way to properly test product, have actionable alerting/logging, have reproducible environment, and distribute ownership clearly among code components. Kubernetes more or less forces a reproducible environment.

Re: Kubernetes is hard

#120

Post by preseinger »

xyzzy_plugh wrote: post #114
preseinger wrote: post #104

Earlier quoted context omitted.

deploying kubernetes in an org of O(1) or O(10) or even arguably O(100) engineers is professional negligence the benefits just don't outweigh the costs, until you get to org sizes where dunbar's number starts to matter "static scheduling" is the right choice for ~80% of technology orgs

You're likely looking at the problem from a different angle. Kubernetes is an ecosystem for managing software deployed on a fleet. There's value in that even if it's two or three hosts. What size of an org is too small for Terraform? Puppet? CI/CD? Docker? Some bash scripts? All these tools should fundamentally solve some piece of the puzzle for you. Kubernetes on a managed platform just happens to cover many pieces…

> Kubernetes is an ecosystem for managing software deployed on a fleet. There's value in that even if it's two or three hosts.

there's value yes, but there's also cost, and that cost is huge

> Kubernetes on a managed platform just happens to cover many pieces that you still need to solve otherwise

i do not need to solve the vast majority of things that kubernetes solves

certainly not in 2-3 node deployments, very likely not in 10-50 node deployments

> I run Kubernetes at home. It's fine. It's less work than anything comparable I've ever encountered.

your "fine" rests on a base level of knowledge which is enormous, certainly incompatible with p99 of users

Post reply on HN