The open source container orchestration technology Kubernetes is 10 years old this month. Kubernetes automates the deployment, management and scaling of containerised software applications and services. Given the passing of this perhaps seminal moment in cloud computing space and time, now is a good moment to question quite how we got here, why this technology has been so widely embraced and adopted… and what impact Kubernetes has had at a broader level for platform engineering the wider move to essentially virtualised, typically abstracted and increasingly serverless technologies.
Most of us don’t need a brief history of Kubernetes, so let’s keep the back story short for those who might appreciate it. The technology takes its name from the Ancient Greek for pilot or helmsman (as in nautical navigation) and was chosen to perhaps convey the ‘vast expanse’ of cloud being somewhat similar to our planet’s seven seas.
Tracing its roots back to Google’s Borg cluster management system in 2003 (which later became Omega in 2013), Google software engineers Craig McLuckie, Joe Beda and Brendan Burns proposed this concept of an open source container management system to their employers in 2014. The project got underway and was immediately open sourced to draw in maximum community involvement. Today, according to a Cloud Native Computing Foundation (CNCF) report, Kubernetes is the second largest open source project in the world. Linux is the largest, just in case you had to ask.
Given all this history, what does the industry think of Kubernetes?
“A decade in, Kubernetes has evolved from a powerful idea into an indispensable tool for modern application development. It was initially designed to manage containerised applications at scale, providing a robust framework for deployment, scaling and operations. Today, it is a cornerstone of cloud-native computing, with an ecosystem that continues to grow and innovate,” said Matt Barker, VP & global head for workload identity architecture at Venafi.
As we know, Kubernetes is now the de facto standard across the industry for ensuring container workloads run to specification and can scale effectively – and according to 84% of IT and security leaders, it’s fast becoming the primary platform for developing all applications.
Scaling & security scares
“As Kubernetes has grown in maturity, we’re seeing the community start to innovate around the pressing challenges of developer experience, scaling and security,” notes Barker. “The complexity of cloud-native environments continues to increase, and we are seeing increased blind spots and challenges for developers. Not only is the growth in multi-cloud and multi-cluster increasing operational overhead it’s also widening the attack surface. One particular challenge is how this explosion of machines makes it harder for developers to know if workloads and services are allowed to communicate with each other. Meanwhile, traditional security protocols are not geared to protect environments that no longer operate within a perimeter.”
Looking ahead, Venafi’s Barker says he’s excited to see the continued maturing of service meshes and a renewed focus on identities to secure workloads. SPIFFE, for example is a framework developed by the above-noted joint founder of Kubernetes Joe Beda. Around the time he released Kubernetes, he also envisaged the need to authenticate workloads across dynamic multi-cloud environments at speed and created SPIFFE.
“I was recently speaking to Joe – and he believes we’ve reached a point where people now ‘understand’ cloud and as they commit more resources to it, are starting to realise the challenges of having shared services across multiple environments. In his words, Kubernetes has now ‘taken on a life on its own’, so growth in Kubernetes is only set to increase this pain, meaning the question of securing workloads in these increasingly dynamic environments means workload identity is set to have a huge future focus,” he said.
Voice of Kubernetes experts
Pure Storage partnered with Dimensional Research to release a data report in line with the Kubernetes anniversary to analyse the adoption of cloud-native platforms. The Voice of Kubernetes Experts Report 2024: The Data Trends Driving the Future of the Enterprise, explores the priorities and trends in the cloud-native landscape, including modern virtualisation, cloud-native databases and AI/ML adoption using Kubernetes, plus of course the rise of platform engineering.
Over the next five years, 80% of respondents confirmed that all or most of their new applications will be built in cloud-native platforms. For their cloud-native technology, they prefer the flexibility of deploying in hybrid cloud environments, with 86% confirming they run cloud-native technology across both public and private clouds. More than half (58%) of organisations plan to migrate some of their VM workloads to Kubernetes, with 65% planning to migrate virtual machine (VM) workloads within the next two years. Nearly all (98%) of respondents run data-intensive workloads on cloud-native platforms, with critical apps like databases (72%), analytics (67%) and AI/ML workloads (54%) being built on Kubernetes.
“Experienced platform leaders are running mission-critical applications like databases, analytics and AI/ML on Kubernetes at massive scale in hybrid and multi-cloud environments. It’s no surprise that these platform leaders are also paving the way for VMs to be managed by Kubernetes without compromising enterprise requirements, supported by solutions like Red Hat OpenShift. The latest findings underscore the urgency of elevating the platform engineering role to manage infrastructure alongside the application stack for seamless innovation,” suggested Murli Thirumale, VP & GM for Portworx by Pure Storage. Thirumale also (unsuprisingly) suggests that Portworx also plays a solid role in K8S management alongside OpenShift.
Lessons from Linux
Yechezkel Rabinovich, groundcover’s CTO and co-founder thinks that Kubernetes has proven its capability to handle a wide range of tasks, but its complexity demands significant setup and constant adjustments.
“Much like how Linux evolved to become a robust operating system, I anticipate Kubernetes will evolve into a more user-friendly abstraction layer. In the coming years, we’ll see more abstractions on top of Kubernetes that will simplify its use and reduce friction, making it more accessible and efficient for everyone,” said Rabinovich.
When it started, it was not certain that Kubernetes would be the platform that won out for all container management. The application developer space picked it up quickly which led to more development around how to support other components of the application stack. As those components were added, it made it easier to support other workloads like databases. This is the opinion of Patrick McFadin, vice president for developer relations at DataStax.
“The two biggest catalysts that solidified Kubernetes for the entire stack were the launch of Kubernetes Operators and improved storage management,” said McFadin. “Both were important, but operators made it easier to add support for other IT assets and workloads. Maybe too easy. When Operators first launched, it seemed like everyone would build their own over a weekend. There was such a glut of them. It was easy to meet the minimum operator standards and assemble what you needed quickly. That made it a bit more difficult as everyone had their own way of doing things. Still, the community did start to come together and focus on collaborating rather than trying to do everything themselves. That is probably a big reason why Kubernetes won out in the first place.”
As Kubernetes celebrates its tenth anniversary, McFadin says it’s clear that it’s entering its teenage years. He proposes that the technology may still have some rough edges and challenges to overcome, but its rapid maturation is undeniable.
An opposite view
Kubernetes was built to manage software containers and make applications more portable in cloud environments. It was designed for running microservices application components in clusters that could be set up, started when needed, and switched off again when no longer needed. These were stateless systems that would run on demand.
“This is the complete opposite of what you need for data workloads, where persistence and storage over time are needed. Kubernetes did not start off supporting data workloads like databases, as they are stateful workloads that can exist for years,” said Sergey Pronin, group products manager, Percona.
Pronin reminds that developers liked Kubernetes and containers, but the community had a lot of work to do if databases and storage were going to run alongside those application workloads. He notes that this work was needed if we were going to move applications to the cloud, so the release of Kubernetes Operators was really important to the adoption of containers outside that initial batch of stateless applications. Alongside this, the release of Stateful Sets enabled containers to run stateful workloads that could exist for months, even years as needed.
“There was a lot of push-back at the beginning around running databases on Kubernetes,” explained Pronin. “For the first couple of years, it was strictly the preserve of those at the cutting edge of cloud native. But community development and more work on operators for databases made it easier to run database instances on Kubernetes, and that broadened the community. Now, the majority of those who run Kubernetes for their applications will run their database instances alongside. It’s taken us ten years to get to this point, and there are still problems that have to be solved around auto-scaling stateful workloads, but Kubernetes is here to stay when it comes to hosting databases and storing data.”
20 years of Kubernetes?
Will we be talking about 20 years of Kubernetes a decade on from now? It seems highly likely that we will. Whether the ‘issues of the day’ will be security, developer experience, scalability and the eradication of brittle systems is yet to be seen. Perhaps the most telling bellwether will be just how far cloud computing itself has become a subsumed ‘utility-like’ component of our IT stacks and is considered eminently controllable (much like electricity or a water supply) to a more established degree than today. Either way, despite its nautical naming, there could still be some rough seas ahead.