Exploring Kubernetes' future, multi-tenancy and community

Bart: Who are you? What's your role? And who do you work for?

Abdel: My name is Abdel. I am a cloud developer advocate at Google. I co-host the Kubernetes podcast by Google, and I've been at Google for 11 years. Living in Sweden, originally from Morocco.

Bart: What are three Kubernetes emerging tools that you are keeping an eye on?

Abdel: There is one very unknown. I don't know if it's unknown. It's called Actuated. It's a tool to run isolated GitHub action workers, specifically designed to run on ARM, but can also run on x86. It was written by a guy called Alex. I forgot his last name. He had a presentation at Cloud Native Rejekts last year in Amsterdam. It's a pretty cool tool. Actually, a lot of the top CNCF projects like etcd, FluentBit, that are built for ARM, use Actuated as a build isolation mechanism, and then they run on top of ARM servers. Second, Ray, the Kubernetes AI platform. That's going to be big. It was big last year and it's going to be big. And the third thing, I don't know much about it, but I keep hearing a lot about Argo. I'm assuming it's not going to go away anytime soon. And I think the sooner I learn it, the better I will sound next time I talk about it.

Bart: One of our guests, Artem, shared that between a single cluster with multiple environments and dedicated clusters per environment, the latter is easier to manage for a small team. When you share a cluster with multiple teams, should you share a single cluster or offer a dedicated cluster per team? What does your choice depend on?

Abdel: That is a very good question. I'm going to quickly put my consultant hat on and say it depends. But the thing with multi-tenancy is that a lot of times, people talk about it from the perspective of management. So, how easy or how difficult it is to manage. But there are actually some key things in Kubernetes that are not supported yet. Yet. That would make multi-tenancy true multi-tenancy. I can talk about two of them. It's quality of service in terms of networking and storage. On a Kubernetes cluster, you cannot ensure that if you have two workloads on the same node, one of them being noisy won't impact the other one. You can limit the amount of resources a pod consumes from a CPU and memory perspective, but you cannot limit the amount of network it will consume. And you cannot limit the amount of storage bandwidth to consume. So, since these two things don't exist technically, it's very difficult to do multi-tenancy effectively and have guaranteed quality of service for workloads. So let's just start there. Following your question, single cluster versus multi-cluster. I mean, if you're going to go down the single cluster with multiple tenants path, you are technically building a platform. You really need a team for it. A single cluster per team seems to be easier, especially if you're using a managed cloud provider. You click and forget. So, if you are using something fully managed like AWS Fargate, GKE Autopilot, where the cluster is managed for you by the cloud provider, then the ease of management is already built into the platform, and you don't really have to go the multi-tenant path. However, multi-tenancy comes with advantages like cost, for example, is usually easier to manage with multi-tenancy. It's more difficult to do because you need to label everything. So, I think that there are considerations for both. It really depends on what you are trying to achieve.

Bart: Once you slice your Kubernetes clusters into a multi-tenant environment. Our guest Artem said you should consider multi-tenancy for every tool you install, such as logging, monitoring, scaling, etc. What's your advice on building Kubernetes platforms that are shared in the organization?

Abdel: Yes, you should consider multi-tenancy for every single tool. And that's part of the problem because not all these tools are actually built with multi-tenancy in mind. One easier path you can go down is shared control plane and then single node pools per tenant. Then you can deploy the node pools with all the tools that a specific tenant needs. So that would work. In my opinion, it kind of defeats the purpose of Kubernetes, but there are good arguments for it. I mean, I don't have very specific advice. I think you really have to consider if you have a team dedicated to running this stuff, running the cluster itself, running the tools that need to run on it, making sure tenants don't impact each other.

Bart: If you don't just go down the single-tenant spots, it's easier. One of our guests said that CRDs are his favorite feature in Kubernetes. Do you agree? And if not, What's your favorite feature?

Abdel: It is one of my favorite features, but managing CRDs is a pain. Too many CRDs can actually kill your cluster. Too many webhooks can kill your cluster. My favorite feature, coming from the old school Linux administration time. Just having something that can restart your workloads without you even thinking about it, I think, is an underrated feature.

Bart: Kubernetes is turning 10 years old this year. What should we expect in the next 10 years to come?

Abdel: It's turning 10 years on June 6th. Don't forget the date. What should they expect? I'm going to borrow from Tim Hockin's last year's keynote, the next one billion core. AI is getting big. A lot of AI stuff is built on Kubernetes, so it's going to continue being big. The second thing is a lot of things that are today, components that people install on top of Kubernetes just to make it easier, are going to be pushed down the stack and become just something that is available for everyone to use. Things like service mesh, networking observability tools, or observability in general are going to eventually become just a component that you don't even think is there and you just use it. And the next generation of community leads that are going to take this and continue running this great community into the future.

Bart: If you had to give a shout out to someone in 2024 who's been instrumental for the things that you're doing, who would it be and why?

Abdel: Well, he left the community a while ago, but Kelsey Hightower, big inspiration, great person. I had the opportunity to have dinner with him last year after KubeCon. Learned a lot. So yeah, shout out to Kelsey Hightower.

Bart: What's next for you?

Abdel: I'm going to do my talk in a few hours at Cloud Native Rejekts. Tomorrow, we have a session in our office. And then just KubeCon. It's going to be beautiful and chaotic. And we are in Paris. I love Paris and also hate Paris. So we'll see how it goes.

Bart: How can people get in touch with you?

Abdel: LinkedIn or Twitter. boredabdel on Twitter and just find me with my last name on LinkedIn.