Follow[Cloud Native Treasure Box]Official account to get more cloud native news
Kubernetes has become too complex, and it needs to learn restraint, otherwise it will stop innovating until it loses its base.
Kubernetes co-founder Tim Hockin rarely spoke out. At this year's KubeCon, he suggested that Kubernetes core maintainers should weigh the benefits of proposed new features against the additional complexity they bring.
Kubernetes isn’t as shiny anymore!
The original container orchestration platform is becoming less and less like itself. K8s itself is becoming more and more complex. Not only development and operation and maintenance personnel are overwhelmed, but even K8s insiders are beginning to speak out.
Tim Hockin, co-founder of Kubernetes and distinguished software engineer at Google, began to worry about the future of K8s.
Kubernetes was originally created by Google engineers in 2014. Two years later, it became the first managed project of the Cloud Native Computing Foundation and the second largest open source project in the world after Linux.
Efficiency and scalability have always been the highlights of K8s, especially scalability, which not only enables deployment and management of application scalability, but also allows development teams to focus on innovative software and prepares enterprises for emerging technologies.
9 years (and a half) later, the penny of K8s may not be so shiny. "Whereas it used to power highly scalable applications, it's slowly becoming the platform of choice for more complex work, such as machine learning inference." A typical example is that two years ago, Kubeflow was used for the deployment and inference of Tensorflow models, and the recent LLMOps also saw the use of Kubernetes.
most pressing challenge
"What do you think is the most pressing challenge of K8s?" Hockin asked the cloud native community without any secret.
Yes, the expected answer was mentioned repeatedly at the venue:The complexity of deploying and maintaining container orchestration engines is terrifying ! Pushing all this complexity onto DevOps is a nightmare! Some even say this is the “biggest existential threat” to K8s.
“There has to be a price to pay,” Hockin said, pointing out that this is the price K8s has paid for absorbing many complex projects over the years. Not only end users, but core maintainers are also affected by complexity.
The higher the complexity, the less agile the K8s core maintainers will be to easily make changes in the future. At the same time, the more complex the software, the greater the user resistance.
Kubernetes is overwhelming developers. Before using K8s, what development engineers have to do is: develop applications, write, test, package and deploy. But with K8s, the development process has been completely overturned:
For developers, operations tasks become onerous. Especially when the platform engineering team intervenes, it often means that a battle is coming. While they throw artifacts into the cluster, they also have high expectations for quality requirements. However, persuading developers to follow the requirements of platform engineering often fails. It requires many rounds of battle.
Two fatigue gaps
Kubernetes' transformation from a container orchestration platform to today's huge ecosystem has created two "fatigue gaps" that need to be crossed for development and operation in the cloud native era. DevOps teams must expand their areas of expertise when moving to cloud-native architectures, and yes, it's significantly outside of their comfort zone.
Both parties must learn more skills than their comfort zones allow:Infrastructure team members must become more attuned to the needs of developers as their workloads increase Increasingly, infrastructure-related tasks are covered.
Specifically, developers need to be more aware of infrastructure issues. On the other hand, operations, infrastructure or systems engineering people are getting closer to the development side, because the way to write Kubernetes resources or Kubernetes YAML inevitably requires learning from their software development colleagues. , because iteration is involved.
What is even more frightening is that up to now there is still a misunderstanding about being obsessed with new technologies:Go to K8s for the sake of K8s, go to microservices for the sake of microservices, even if it is not possible at all. No need for it.
Complexity 'like a budget' will eventually run out
Kubernetes software is community-driven: to date, the community has more than 74,680 contributors and 7,812 contributing companies. This is inseparable from the efforts of the first generation of K8s users, but as new users continue to join, their interest in how Kubernetes works inevitably wanes, and more complex things are added.
“The more complex things we add, the more of our budget we consume.When the budget runs out, bad things happen happens, K8s innovation will stop and users will turn to other solutions."
Therefore, Kubernetes project managers need to treat complexity as a limited resource, such as calling it a "complexity budget", that cannot continue indefinitely.
Top Kubernetes engineers agree: K8s has become too complex for end users and even the core maintainers themselves. It’s time to build complexity into your budget.
K8s insiders need to say "no" more often
Hockin admits that he doesn't know how to measure a piece of software's complexity, let alone how patiently end users have to deal with complex software. But he cleverly transformed the complexity issue into a budget issue: "Engineers usually know when they're over budget."
So when considering adding new functionality, they must ask questions like:Do we have enough complexity budget to take on this task? Should we waste our limited budget on this?
Part of an engineer's job is to weigh the trade-offs of any decision, and the additional complexity that new features may bring should be one of the factors that needs to be evaluated.
Some extensions to the code base may result in a 5% performance improvement in certain aspects of the software,butif this Giving maintainers more internal complexity to deal with, is it still worth it? If the API is changed to meet a specific use case, is it worth the burden of this change on all other users?
All K8s staff need to raise the bar whilebe willing to say "no" and "be willing to say no to things we really want. , willing to say no to things that don’t seem like a bad idea, willing to say no to things that seem obvious and easy in themselves, willing to say no to things that contribute to what we seem to really want!”
By saying "no" to certain proposals, you can leave some room in your complexity budget to tackle more relevant projects in the future.
Hockin believes thatK8s must say "no" to things today so that we can be able to do interesting things tomorrow.
Hockin says we're all used to thinking that more is better, but Kubernetes may now have more to consider"Less is more". And, there is still a lot of work to be done with Kubernetes, but that doesn’t mean it all needs to be done right away.
Signs of K8s being replaced
K8s was created by Google, but it is not suitable for all enterprises. If in the past few years everyone was chasing new technologies and adopting K8s for the sake of K8s, then K8s, which has been nearly ten years old, is showing signs of being slowly replaced. “If you don’t need Kubernetes, don’t adopt it.”
Even in the field of container orchestration, enterprises have to spend a lot of time managing Kubernetes because it is not developer-friendly and requires a lot of time and understanding to deploy, operate, and troubleshoot. In the past two years, companies have been looking for other options.
-
• Some choose to host Kubernetes and use a cloud provider’s managed Kubernetes service;
-
• Some use distributions that can reduce K8s operations, such as Red Hat’s OpenShift;
-
• Some use alternatives such as HashiCorp’s Nomad;
-
• Or take what Adrian Cockcroft, Amazon's vice president of sustainable architecture, calls a "serverless-first approach," jumping directly to FaaS offerings like Azure Functions, Amazon Web Services Lambda, or Google Cloud Functions and bypassing Kubernetes entirely.
In addition, new products such as cycle.io, which are dedicated to replacing K8s as the king of container orchestration, have also appeared on the market, allowing even People with limited DevOps experience can describe what they want and the platform is responsible for implementing it.
write at the end
Of course, continuous absorption and expansion have allowed Kubernetes to rapidly grow in the cloud native era, but the "star-attracting method" of quickly absorbing new functions has also begun to have backlash. Currently, Kubernetes is being slowed down in the field of container orchestration, and new rivals are eagerly trying to surpass it.
As one industry insider advised Hockin to “delay gratification”: To stay viable, Kubernetes should remain unfinished!
Reference links:
-
1. https://thenewstack.io/how-to-fight-kubernetes-complexity-fatigue/
-
2. https://thenewstack.io/tim-hockin-kubernetes-needs-a-complexity-budget/
-
3. https://blog.container-solutions.com/adrian-cockcroft-on-serverless-continuous-resilience