'Boringly reliable': Red Hat architect thinks Kubernetes is 'mostly done' – but there are still plenty of bugs

Interview Red Hat architect and Kubernetes contributor Clayton Coleman, who leads development of OpenShift, reckons Kubernetes is "mostly done" – it needs tidying up and bugs fixed but not major new features.

Coleman has worked on Kubernetes since it first went open source in mid-2014. OpenShift is older than Kubernetes and originally used its own container technology.

"I was involved in early discussions with Google about open-sourcing Kubernetes, they were shopping around the idea of starting an open-source project," said Coleman. "It was: will they or won't they? We were on the point of deciding to go with Mesosphere, when Google said, 'OK we're going to open-source this next week. Are you guys in or out?.' Sure, we're in, we said."

If we are not doing it in the Kubernetes community, if Red Hat is not doing it, if the big companies playing with Kubernetes are not truly trying to bring the ecosystem together … I feel we're a little balkanized today, I think we can do better.

During our discussion the word "complexity" comes up constantly. The reason is that despite its popularity, Kubernetes is notorious for being tricky to use.

Is it a deserved reputation? "Kubernetes definitely has some accidental complexity, it's an open-source project with thousands of contributors," said Coleman. "But if Kubernetes were simpler it would be less successful. If it was more complex, it would probably be an overly complex solution. There's plenty of complex things that Kubernetes tries to accomplish.

"Maybe we need more warning labels on the project. We wanted to leave the door open to say, well this can be used as a tool that allows you to access the complexity if you need it.

"I want to see Kubernetes grow to have tools that are simpler, that hide complexity, and I think it's a crazy good tool for different kinds of people building applications at scale. Building applications at scale is not something everybody needs to do."

At what level does Kubernetes become a sensible option for deploying an application? "If you assume Kubernetes is there to simplify the act of building and developing applications, that's where a lot of people get hung up. Kubernetes is a really powerful tool for deploying and keeping applications running and letting you change them later," said Coleman.

"It's less about the size of the project than the individual." The technology is for people "tired of reinventing the wheel," he said. "It's not going to be perfect, no software is, but I'm going to let Kubernetes deal with deployments, routes, splitting traffic across applications, put quota on my applications, and so on. That is the Kubernetes sweet spot, has always been."

Does Kubernetes run better on Google's cloud?

A common opinion is that Kubernetes runs better on Google Cloud Platform then elsewhere. Is there any truth to it? Back comes the complexity word. "I am far too close to Kubernetes to see it as anything other than my lovable, adorable totally ugly child," said Coleman. "Kubernetes has tons of bugs, tons of challenges, and distributed systems are invariably very hard. Kubernetes is trying to help simplify some of that, but there's still some areas of complexity there.

"I would say Google did everything right to get the benefit of that statement, even if that statement may not be true. There's plenty of places Kubernetes runs well. Google has done a great job of integrating Kubernetes with their cloud and that's something that others came around to after Google. And the head start gave Google an advantage.

"At Red Hat we were very focused on how enterprises can deploy something that's standard but also fits in their environments, tolerates enterprise LDAP, or tolerates security requirements which are much higher than someone standing up their own cluster and just putting all the stuff in it.

"Red Hat have said we want to give you the choices that matter in an enterprise environment, and similarly Google says here are the choices that matter in a cloud environment. There are advantages in each. I hesitate to say which is better."

Every Kubernetes environment is different, Coleman said, which suggests that the notion of seamlessly managing Kubernetes across different clouds and on-premises, the promise of Google Anthos and Azure Arc, may be optimistic. Is portability of applications across different Kubernetes environments realistic?

I think that the real innovation in Kubernetes should come from layers on top. And layers underneath, cleaning up areas of Linux that are painful for admin.

"Kubernetes is complex because it's managing machines, networking, storage, those are all hard challenges," said Coleman. "If you're not controlling all the variables, top to bottom, then you are going to hit compatibility issues. Will you hit them every day? No. Will you hit them at the worst possible time? Absolutely, yes.

"I know of people running in multiple environments who have to retest in multiple environments. You might be running different versions of Istio or Knative, or monitoring, every one of these pieces is there. One of the focuses for Red Hat is can we help people standardise that no matter where it is, can we reduce the known qualities that definitely will break you? That's what a lot of folk are starting to realise."

Forget new features: Kubernetes is 'mostly done'

What is coming up in Kubernetes? Coleman is not keen on new features. "I do not wish to diminish the accomplishments of anyone who has a feature coming in Kubernetes. But I like to think of Kubernetes as mostly done. What we're doing today is refining it and cleaning it up. I don't think there's much benefit in growing Kubernetes itself extensively," he said.

"We have a lot of beta features, enthusiastic contributions from the community that might have gotten to alpha status or beta status, but have languished. A huge effort for the next year is pushing those either to completion or removing them. Closing off the areas where our ambition exceeded our grasp.

"I think that the real innovation in Kubernetes should come from layers on top. And layers underneath, cleaning up areas of Linux that are painful for admin. Kubernetes itself as a project is best served by being boringly reliable. If you don't need to read the release notes, that would be the best outcome for people running it. I'd love that changelog to get smaller and smaller, just a long list of bugs fixed and frustrations removed."

Kubernetes itself should not be the centre of attention, but rather the ecosystem around it, according to Coleman. "I'd love to see more focus on the ecosystems and how they come together. That's hard because there's lots of places where the ecosystems haven't come together," he said. "OpenShift is a way of trying to bring some sanity, trying to offer a reasonable set of choices. We are nowhere near done. As an engineer and architect, I'd love to see the focus shift to a more critical view of how the ecosystem is coming together.

"If we are not doing it in the Kubernetes community, if Red Hat is not doing it, if the big companies playing with Kubernetes are not truly trying to bring the ecosystem together … I feel we're a little balkanized today, I think we can do better."

What then of the debate about whether Google should hand over Istio and Knative to an open-source foundation, about which the company gives mixed messages? Coleman is nuanced in his response. "Google was very open about this in the early days, were looking to build an ecosystem that people believe in, wanted to do open source right.

"We were recognising that a lot of open-source projects don't succeed, there's a lot of things you have to do right. Google is clearly wanting to create an ecosystem that they also offer as a service, not just taking open-source software and running that as a service, but building open-source software.

"They did the right things and they got lucky. For Red Hat, it was fortuitous for us: right place right time.

"Microsoft eventually got involved, Amazon eventually got involved, but the folks at Google did a really good job of trying to stick the landing and it has benefited them. Every layer of the project is different, it would be unfair to call out Google specifically for open-source projects that are controlled by one entity. The vast majority of open-source projects have one major company contributing to them. A smaller percentage have two. Projects like Kubernetes are very rare."

The actual people working on projects like Istio and Knative are great to collaborate with, said Coleman, but he added that "the people in the community can't be responsible for the choices that a business makes. Because the business ultimately do need to make choices about funding and how they use strategy advantages and I don't hold that against people."

Is Kubernetes boring? "It's not the sexiest thing in the world, but changing the future of computing is." ®