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...
Will Kubernetes Collapse Under the Weight of Its Complexity?
21–30 of 213 posts
Re: Will Kubernetes Collapse Under the Weight of Its Complexity?
#22Kubernetes 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.
Re: Will Kubernetes Collapse Under the Weight of Its Complexity?
#23The funny thing about Kubernetes is that I read somewhere that it's not actually widely used within Google (please correct me if I'm wrong). Given that's it's a complicated piece of software and that Google has extremely complicated requirements, that's pretty concerning. To me, we've barely starting to solve deployments, the idea of Kubernetes seems a little ahead of it's time. If you're using GPC I do hear it's rea…
Google uses Borg internally, and Kubernetes is really their third container orchestration system. After Borg came Omega, which was never deployed, but ended up being a test bed for a lot of innovations that were folded back into Borg. But Borg is a decade old and has a lot of warts (according to its designers), and with Kubernetes they aimed to learn from their mistakes and improve on the design.
As far as I can tell, the aim with Kubernetes was never to replace Borg at Google -- Google is far too invested in Borg, and it would take a considerable engineering effort to migrate away from it. Rather, developers at Google saw an opportunity to create an open source version based on what they had learned and help the world along in adopting the same engineering principles as Google has long practiced. Not all altruistic notions, of course -- Google benefits from the commoditization of containers indirectly, by undermining competitors such as AWS (where containers are still not well-supported) and making their own cloud the best fit for Kubernetes.
Google does run stuff on Kubernetes, via GKE. As I understand it, new products are encouraged to run on GCP. I don't know how many applications they run, however. Maybe someone from Google can comment.
Re: Will Kubernetes Collapse Under the Weight of Its Complexity?
#24The 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":…
It's certainly a lot easier to do "kubernetes the hard way" than it is to do "Linux from scratch", and I don't see a lot of FUD about how we should stop using Linux because it's too complex. That might seem like an extreme comparison, but I think the number & quality of comparable alternatives is similar between the two.
Re: Will Kubernetes Collapse Under the Weight of Its Complexity?
#25Is 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 supports clusters of up to 5000 nodes, which is a decent amount but not enough to avoid having multiple clusters. Does anyone have experience operating multiple production clusters in a single territory as partitions for scaling reasons? What's the experience like?
Re: Will Kubernetes Collapse Under the Weight of Its Complexity?
#26> kubectl scaffold mysql --generate This exists, its called helm, which in fact delivers the productivity gains the author is looking for.
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 want it to?
Re: Will Kubernetes Collapse Under the Weight of Its Complexity?
#27This is exactly one of the reason we picked kontena.io in our startup, and never regretted it. Also super excited about their approach to run on top of k8 with pharos.sh.
Re: Will Kubernetes Collapse Under the Weight of Its Complexity?
#28The funny thing about Kubernetes is that I read somewhere that it's not actually widely used within Google (please correct me if I'm wrong). Given that's it's a complicated piece of software and that Google has extremely complicated requirements, that's pretty concerning. To me, we've barely starting to solve deployments, the idea of Kubernetes seems a little ahead of it's time. If you're using GPC I do hear it's rea…
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.
Re: Will Kubernetes Collapse Under the Weight of Its Complexity?
#29Is 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…
If you have a need for more than 5000 nodes in a cluster, it should take a trivial amount of your resources to solve that problem IMO.
The vast majority of Kuberentes users probably won’t even need a 500 node cluster, let alone a 5000 node cluster. It makes sense for them to prioritize optimizing for other things like developer experience to help address some of the concerns mentioned in this article over supporting even larger clusters right now.
Re: Will Kubernetes Collapse Under the Weight of Its Complexity?
#30Kubernetes 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