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

41–50 of 213 posts

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

#41

Post by kozikow »

ebikelaw wrote: post #28
kozikow wrote: post #11

Earlier quoted context omitted.

If someone thinks kubernetes is complicated, they would cry during their first month with the borg.

I would argue that borg has much less initial complexity than kubernetes. Because of Google's integrated systems you can take any local binary and run it in borg with a five-line config file and one command. You can't get started that quickly with kubernetes. If you understand the implications of running N replicas of a command on Also borg is easier to pronounce.

You can use "kubectl run" in k8s for one line run. Now if it runs it runs. Go figure why your borg job is getting preempted.

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

#42

Post by flor1s »

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 working on such (relatively simple) apps really consider using Kubernetes?

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

#43

Post by coding123 »

chrisweekly wrote: post #14
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.

Docker Swarm is a hot mess.

I've used it extensively and have been happy with it. I've never seen more fud in HN than in swarm vs kub threads.

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

#44

Post by hueving »

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.

Openstack is the same way. However, people want something simple by default. Do not underestimate how poisonous "too complex" can be as a label for a project.

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

#46

Post by hueving »

gtirloni wrote: post #21

TL;DR; Kubernetes needs to continue to focus on the developer experience but it's good enough for InfluxData's new cloud offering. The project has been listening: https://github.com/kubernetes/community/blob/master/sig-apps...

Forming a SIG is just paying lip service. It remains to be seen if anything will really change or if kubernetes will suffocate itself with its own bloat.

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

#47

Post by hueving »

atombender wrote: post #19
jrs95 wrote: post #16

The complexity of Kubernetes largely reflects the complexity of the problem. Nobody has delivered anything significantly simpler that hasn’t had a much smaller scope, and those tools approach the same level of complexity when composed with others to get the same level of functionality. But setting up Kubernetes is both well documented and automated on multiple cloud providers, whereas something like Nomad & Consul do…

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.

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

#48

Post by 49bc »

mwcampbell wrote: post #33

> 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…

How many “kicks” does it take to build a reasonably resilient distributed service? A lot!

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

#49

Post by jazoom »

Draiken wrote: post #38
nimish wrote: post #34

Earlier quoted context omitted.

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 tha…

I had heaps of issues with Kubernetes.

I moved to Swarm a year ago and have had a grand total of 0 issues. It can do everything I need.

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

#50

Post by ebikelaw »

kozikow wrote: post #41
ebikelaw wrote: post #28

Earlier quoted context omitted.

I would argue that borg has much less initial complexity than kubernetes. Because of Google's integrated systems you can take any local binary and run it in borg with a five-line config file and one command. You can't get started that quickly with kubernetes. If you understand the implications of running N replicas of a command on Also borg is easier to pronounce.

You can use "kubectl run" in k8s for one line run. Now if it runs it runs. Go figure why your borg job is getting preempted.

You can use kubectl run to make something run, only after you've got all your initial authentication/authorization squared away, and your nodes are deployed. Assuming you work at Google you can "borgcfg up" your job and it will run under your role, make authenticated RPCs under your own authority, using your personal freebie quota which is infinite. You can get preempted; that's the price of infinite free resources. Anybody who complains about that should be fired.
Post reply on HN