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

31–40 of 213 posts

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

#31

Post by dominotw »

justinjlynn wrote: post #26
hyperrail wrote: post #13

Earlier quoted context omitted.

In the following paragraph, the author considers and appears to reject that solution: >Maybe the combination of operators and Helm charts covers this, but I don’t think that will cut it. Then we’re forcing developers to learn about two other things in addition to Kubernetes. Even if it’s just increasing the vocabulary and installing a new command line tool, it’s extra effort and thought. These things need to be first…

So, instead of keeping cross-cutting concerns separate and permitting them to evolve separately, the author wants K8S to become more complex, because they'd rather learn one more complex thing than multiple simpler things? Seems legit. I mean, why should I install multiple libraries? Why can't glibc wash my car? Will glibc collapse under the weight of it's own complexity -- even though it can't wash my car like I wan…

I think more charitable interpretation is that kuberbetes should be designed in such a way that these tools are a natural part of it. Think of active record being part of rails. Sure you can use rails without ar but that doesn't make sense.

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

#32

Post by davidp »

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

As simple as possible, but no simpler.

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

#33

Post by mwcampbell »

> available 99.5% of the time with decent alerting for operators to kick it

An operator should never have to "kick" a service. It should repair itself, except for the occasional hardware replacement if one is working with bare metal. And for anything that's being sold as a product, as opposed to an internal tool, I think 99.9% availability should be the minimum.

But I don't know enough about Kubernetes to say whether it's overkill at the scale of just a few servers.

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

#34

Post by nimish »

lobster_johnson wrote: post #18
nimish wrote: post #9

kubernetes is a classic case of a tool designed for consultants and companies to sell consulting services (Including cloud services, which is why every cloud provider leapt onto it). In like 90% of the cases when someone used Kubernetes, Docker Swarm would have easily sufficed.

Disagree. OpenShift and CNCF are arguably exactly that, but Kubernetes itself isn't. It came out of the engineering team at Google, and its technical merit shouldn't be confused with the considerable marketing effort being put behind it. Docker Swarm is much more deserving of this kind of cynicism -- a weak, badly designed solution forced on users by a company that's realizing their invention has been commoditized an…

I disagree. Kubernetes came out of Google, but has exploded in popularity due to its capability (which comes with extreme complexity): it can scale to extreme levels, but wrapping your head around it requires far more time and trouble for your most basic apps. Thus, you see the software consultants race to become the next Kubernetes experts, since choosing to deploy it essentially requires that you have dedicated professionals managing it (as Google does).

Docker Swarm might be incomplete and missing quite a few features, and it won't scale to thousands of nodes with dozens of independent apps, but the use-cases I've seen are far from that. A single engineer can basically get a "good-enough" moderately scaled system going.

If you have Google-scale problems with Google-caliber engineers and SREs backing you, use Kubernetes. Otherwise, using something else (Docker Swarm "just worked" for the cases I've seen) is easier.

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

#35

Post by nine_k »

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

There's no single design that suits everyone.

It's a toolbox. The job of choosing the right tool is on you.

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

#38

Post by Draiken »

nimish wrote: post #34
lobster_johnson wrote: post #18

Earlier quoted context omitted.

Disagree. OpenShift and CNCF are arguably exactly that, but Kubernetes itself isn't. It came out of the engineering team at Google, and its technical merit shouldn't be confused with the considerable marketing effort being put behind it. Docker Swarm is much more deserving of this kind of cynicism -- a weak, badly designed solution forced on users by a company that's realizing their invention has been commoditized an…

I disagree. Kubernetes came out of Google, but has exploded in popularity due to its capability (which comes with extreme complexity): it can scale to extreme levels, but wrapping your head around it requires far more time and trouble for your most basic apps. Thus, you see the software consultants race to become the next Kubernetes experts, since choosing to deploy it essentially requires that you have dedicated pro…

If you can use docker swarm you can use Kubernetes. At that point k8s is just plain better.

The core of Kubernetes is super simple and all the hard parts are hidden away on actually setting up and maintaining kubernetes the hard way on bare metal machines. Odds are, if you're doing that, you have the resources to take some time to dive deeper into how it works.

I've done multiple single engineer Kubernetes setups that are working on production today. So far I've had only a few problems with it. I know it's not a huge data range, but I'm not the smartest person in the world (or a true infrastructure guy) and still found it easy to work with.

Swarm has always been a rushed afterthought IMO. Although I have way less experience with it than k8s, so I'm biased on this.

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

#39

Post by hharnisch »

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 applications with -- if you work on ops. The problem seems to be that there's not a lot of agreement on what those tools actually look like. What Kubernetes does end up doing is providing a consistent API to deploy workloads across (many, but not all) cloud providers. Over time we'll see better and better developer facing solutions built on top of Kubernetes, rather than part of Kubernetes.

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

#40

Post by rickycook »

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…

nodes meaning compute nodes; not containers

in case there was confusion

Post reply on HN