Kubernetes at 10: From stateless also-ran to ‘platform to build platforms’

What was the market like when Kubernetes first launched?

Sergey Pronin: Because organisations had increasingly adopted microservices architecture there was a need to manage and scale large numbers of containers efficiently. Container deployments and scaling had been carried out manually, which was error-prone and time consuming, so there was demand for automated orchestration tools.

In 2014, Kubernetes entered a container orchestration market that was buzzing with potential but lacked a clear leader. Docker had ignited the container revolution, but managing containers at scale remained a complex puzzle. Options like Apache Mesos existed, but they were often unwieldy and required specialised knowledge.

How did you get involved in work on the data infrastructure around Kubernetes?

Pronin: Back then, I led multiple engineering teams building various platform-as-a-service solutions. Developers always want to remove toil through automation, and simplifying orchestration was something that everyone wanted. Kubernetes was not as sophisticated as it is today, but it was slowly gaining traction in the community.

Curiosity opens a lot of doors and I saw Kubernetes behind one of them. Once I looked at what was involved, I thought it was a project I should keep track of. Little did I know how much it would be part of my future career.

How did you realise Kubernetes was in the leading position in the market?

Pronin: It was not a sudden realisation for me. It happened slowly. Solutions like Apache Mesos, Docker Swarm and even AWS ECS (Elastic Container Service) were widely used. The reason Kubernetes won is the community. Its pluggable architecture and rapid development drove its adoption and slowly ate the market share of other solutions.

When you looked at Kubernetes, how did you approach data?

Pronin: For a long time for me, Kubernetes was only for stateless applications. We even had quite strict quality bars on our platforms where we did not allow stateful apps in Kubernetes. This was 12 factor app thinking at its best around how to design and build scalable and resilient cloud-native applications. One of the core tenets is to treat back-end services, including databases, as attached resources, to promote stateless application design.

What issues first came up around data and storage with Kubernetes for you?

Pronin: The biggest issue was immaturity. Provisioning Persistent Volumes was like sacred knowledge, only known to a few, not fully automated and available through some core hacking. Integration with storage providers was non-existent, which meant the user experience was quite clunky.

Then in 2019 AWS EKS (Elastic Kubernetes Service) officially started to support AWS EBS (Elastic Block Storage). This might be the milestone that started to change perceptions.

What had to change?

Pronin: The release of Stateful Sets and Operators was three years after the first release, so it did take some time to make Kubernetes ready. Once they were released it still took time to overcome reticence to deploy them. A lot of testing was needed to get over that hurdle before we were ready to change our policies.

How did you get involved around Kubernetes operators?

Pronin: I joined Percona 3.5 years ago to lead the product management team responsible for Operators and cloud native application deployments. It was a complete greenfield back then, with a lot of uncertainty and a relatively small community. I was a strong believer in “Kubernetes for stateless” so it was quite a challenge to grasp the idea. Percona’s leadership team saw an opportunity and sensed the market trend long before it became mainstream.

What happened around operators that made them a success for data and storage?

Pronin: It is a combination of events.

In the microservices era, users tried to run databases in Docker containers, outside of Kubernetes. This is a complex task, especially if there is clustering in the deployments, which you might need for databases.

Kubernetes was becoming a de facto standard to run microservices and build platforms. It was described as “a platform to build platforms” and I think that definition is accurate now.

Kubernetes promised to solve some of the complexity problems, but managing databases is hard. Learning all the Kubernetes primitives and grasping the concepts is for the brave. Operators abstracted all this complexity and lowered the entry barrier significantly.

Not only that, Operators solved the problem of day-two operations. This is where most database complexity comes from – tasks like ongoing maintenance, upgrades, backup and restores, security and so on. Kubernetes can help improve how fast you can implement infrastructure, but it can’t take on a database query for you.

How did this support more cloud-native approaches? What were the consequences?

Pronin: Operators – especially for databases – gave an additional boost for Kubernetes and the CNCF ecosystem and made it easier to adopt those open source options.

Supplier lock-in was an issue in public cloud, while Kubernetes provided a way to run applications anywhere using a uniform API. Kubernetes had demonstrated it could work perfectly for stateless apps and with Operators, and so databases also got a chance to run in the same way.

Kubernetes is now 10. How do you think about it today?

Pronin: Over the past 10 years, Kubernetes has become the industry standard and fundamentally changed how applications are developed and deployed. Its impact is undeniable. It has fostered innovation and driven the rise of microservices architecture.

While challenges like complexity and security persist, the future of Kubernetes is bright. The growing community and all the innovation taking place will ensure it remains adaptable to new trends.

What problems still exist around Kubernetes when it comes to data and storage?

Pronin: Complexity is still an issue, even while Operators are making it easier to manage data and storage resources. Mostly, it comes from a lack of standardisation across various Container Storage Interfaces (CSIs) and the intricacies of integrations with different storage providers.

Managing data and storage across multiple clouds or hybrid environments can be challenging due to differences in storage APIs and configurations. There are various attempts to simplify that through federation or multi-cluster control planes.

Database engines like MySQL or PostgreSQL were designed long before microservices. Engineers have adapted them to run on Kubernetes, but it sometimes requires hack-ish workarounds to make them work.

Any other anecdotes or information to share?

Pronin: Operators and databases on Kubernetes moved quickly from greenfield hacks to get things working to being enterprise-grade. Now it is more about “how” rather than “why” from organisations of different levels. Data on Kubernetes is now not “only for the brave”. It is mainstream.