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

Will Kubernetes Collapse Under the Weight of Its Complexity?

influxdata.com

Post reply on HN
Print view View original

51–60 of 213 posts

Re: Will Kubernetes Collapse Under the Weight of Its Complexity?

#51

Post by manigandham »

Microsoft Word is also incredibly complex software with decades of development and features, and yet it's just a word processor. Everyone uses a small subset of the actual functionality which is why the entire system can be complex and simple at the same time, depending on your needs.

It's exactly the same with Kubernetes. It's just clustering software that ties multiple servers together to give you an PaaS-like workspace to run containers, but there are 1000s of details you can use if you need them to build much more intelligence into operations. If you don't need them, you can just run a single container and still benefit from simple declarative deployments and automated oversight.

Re: Will Kubernetes Collapse Under the Weight of Its Complexity?

#52

Post by manigandham »

GiorgioG wrote: post #15
outside1234 wrote: post #3

> kubectl scaffold mysql --generate This exists, its called helm, which in fact delivers the productivity gains the author is looking for.

I have Kubernetes in Action on my desk and I haven’t cracked it open yet because Kubernetes seems monstrously complex. Sure helm gets you up and running. When something goes wrong in prod at 3am, what do you do?

What do you do now, without Helm or Kubernetes?

Re: Will Kubernetes Collapse Under the Weight of Its Complexity?

#53

Post by manigandham »

Pyxl101 wrote: post #25

Is Kubernetes really scalable to a meaningful extent? I feel like if I was going to set up a Kubernetes system, I'd need to plan from the beginning to have multiple clusters anyway, and then the utility of all the scheduling features would be considerably diminished since I'd have to plan to load balance applications across the clusters in some custom way. Yuck. The Kubernetes website (1) currently claims that it sup…

5000 nodes has proven to be a high enough ceiling for basically all workloads, especially given the size of individual servers available now in clouds. Easier to run smaller numbers of bigger servers, as always.

Also Kubernetes does support federation for cross-cluster deployments (now named multi-cluster). Some cloud services even support ingress load balancing across these, or you can do that part yourself by simple sticking with the same ports, but it all works fine today. Nothing custom needed.

Re: Will Kubernetes Collapse Under the Weight of Its Complexity?

#54

Post by sidlls »

flor1s wrote: post #42
hharnisch wrote: post #39

I've gone to the last few KubeCons and given talks at two of them and I'd also consider myself to be more of an app developer than ops. The tone has been very much that Kubernetes is deeper in the stack than most developers want or need to be thinking about. Mantras like "kubectl is the new ssh" have become super popular. So Kubernetes ends up being the platform you build your tools developers deploy their applicatio…

The problem with saying "kubectl is the new ssh" is that it is simply not true in my opinion. Something more akin to "kubectl is to controlling a cluster as ssh is to controlling a server" would be more accurate I think. The point the OP makes about "Most Developers Don’t Have Google-Scale Problems" is true, I don't think you should use Kubernetes if your app consists of just a website and a database. But do people w…

Yes, as part of a terrible feedback loop and resume driven development.

Re: Will Kubernetes Collapse Under the Weight of Its Complexity?

#55

Post by geerlingguy »

flor1s wrote: post #42
hharnisch wrote: post #39

I've gone to the last few KubeCons and given talks at two of them and I'd also consider myself to be more of an app developer than ops. The tone has been very much that Kubernetes is deeper in the stack than most developers want or need to be thinking about. Mantras like "kubectl is the new ssh" have become super popular. So Kubernetes ends up being the platform you build your tools developers deploy their applicatio…

The problem with saying "kubectl is the new ssh" is that it is simply not true in my opinion. Something more akin to "kubectl is to controlling a cluster as ssh is to controlling a server" would be more accurate I think. The point the OP makes about "Most Developers Don’t Have Google-Scale Problems" is true, I don't think you should use Kubernetes if your app consists of just a website and a database. But do people w…

IMO, only if you're working on like 100+ of them. If you just maintain a website using a traditional LAMP/LEMP stack, Rails, Node.js, or something like that it still makes more sense (unless you want to be 'trendy') to stick to primitives or use more managed hosting.

But if you're maintaining a fleet of independent sites, Kubernetes' scheduling can make sense, despite the inherent complexity (TBH, you're going to have a similar level of complexity managing the same kind of scale with any other tool).

Re: Will Kubernetes Collapse Under the Weight of Its Complexity?

#56

Post by bdcravens »

flor1s wrote: post #37

Isn't one of the appeals of Kubernetes to have a portable cloud environment, which means I can easily switch between Windows Azure, Google Cloud, Amazon Web Services, on premise, and even Minikube (localhost). Is there any simpler alternative for that?

For many use cases, I'd imagine an abstraction atop of Kubernetes (like OpenShift or Rancher) is a good fit.

Re: Will Kubernetes Collapse Under the Weight of Its Complexity?

#57

Post by geerlingguy »

outside1234 wrote: post #3

> kubectl scaffold mysql --generate This exists, its called helm, which in fact delivers the productivity gains the author is looking for.

As someone new to Kubernetes, Helm is _really_ not appealing; it masks a _ton_ of complexity, and is akin to telling someone new to Docker to run all their applications off the 'Docker Library' official images on Docker Hub.

With few exceptions, those cookie cutter examples are not ideal for running production applications; they're decent starting points for learning how they could be built, just like Helm could be (if it were a little less "here's a 1,000 line Kubernetes configuration file in a box, good luck!"-ish).

Re: Will Kubernetes Collapse Under the Weight of Its Complexity?

#58

Post by geerlingguy »

rorykoehler wrote: post #30
bigdubs wrote: post #22

Kubernetes isn't supposed to be simple; it's supposed to be a box of tools that you pull from to represent literally any workload. Once you know what tools to ignore, and build scripts around the ones you need, it's very powerful. This line of thinking is like faulting the golang stdlib for having a lot of useful stuff in it.

Everything should be as simple as possible. It's the mark of good design

Minikube—and by extension, basing all the starting tutorials off minikube—is approaching this ideal, IMHO. A year ago, the first time I tried it, it was frustrating to even get up and running. This year I was actually able to get some examples running locally... and that's progress :)

Re: Will Kubernetes Collapse Under the Weight of Its Complexity?

#59

Post by geerlingguy »

Pyxl101 wrote: post #25

Is Kubernetes really scalable to a meaningful extent? I feel like if I was going to set up a Kubernetes system, I'd need to plan from the beginning to have multiple clusters anyway, and then the utility of all the scheduling features would be considerably diminished since I'd have to plan to load balance applications across the clusters in some custom way. Yuck. The Kubernetes website (1) currently claims that it sup…

The other important distinction there is the current (soft-ish) limit of 110 pods per node; if you want to run hundreds or thousands of pods on a few giant (beefy CPU/RAM) nodes, you need to rethink that strategy and go with many smaller nodes, with the pods evenly spread across them.

Re: Will Kubernetes Collapse Under the Weight of Its Complexity?

#60

Post by lobster_johnson »

hueving wrote: post #47
atombender wrote: post #19

Earlier quoted context omitted.

I would also argue that Kubernetes is less complex than it seems at first glance. Yes, if you look at all the possible parts, and at the current monolithic codebase, there's a lot of complexity. It also supports umpteen cloud providers, volume providers, networking stacks, etc., and comes with a whole swathe of bootstrapping tools for various environments (e.g. AWS). But if you strip it down, Kubernetes is "simple":…

>Everything is, in principle, controllers mediating between the data model and the real world. Very elegant and orthogonal. If you distill k8s down to this model alone, k8s becomes nothing but a pattern that has existed for decades. Maintaining "desired state" and "operational state" as separate things is not new.

You missed my point; I didn't say it's new, I said it was simpler than it might seem, and that thinking of it as a state machine makes it easier to understand what the core of Kubernetes really is.

And of course "nothing but a pattern" is nonsense. Pre-container systems like Puppet and Chef -- which are also, vaguely, based on converging real state towards desired state -- are firmly rooted in the traditional Unix model of mutable boxes. You can't implement a consistent reconciliation loop if your state can't be cleanly encapsulated (as with containers).

Post reply on HN