Kubernetes AI Tools and Platform Engineering Insights

Bart Farrell: First things first, who are you, what's your role, and where do you work?

Gari Singh: My name's Gari Singh. I'm a product manager, GKE, at Google.

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

Gari Singh: So, kubectl-ai, which is obviously, you know, built for us for AI. I guess I would say, hmm, I don't think. A lot of them, I guess, you know, are sort of out there. But, yeah, mostly stuff in the AI automation space.

Bart Farrell: Now, one of our guests, Ben Poland, thinks, for a platform team, you want to empower anyone to make the changes they need rather than centralizing everything. How do you balance self-service capabilities peace with governance and platform engineering?

Gari Singh: Ah, that's a great question. Yeah, I think to a degree, you have to have some level of like centralization, guardrails, people may call them, right? But you do want to allow, you don't want to inhibit like developers or people from being able to get things actually done, right? So you don't necessarily want to limit deployments, but maybe you want to put policies in place in terms of what things they're not like allowed to do. Maybe not allowed to use host port, other things that may violate things. So I think there is this sort of fine line of, you know, building a set of all overloaded term guardrails, but kind of that core underlying platform, maybe some base principles, some base primitives in there, and then allowing users to have access to that.

Bart Farrell: One of our guests, Michael, defined platform engineering as 100% customer service role and 100% product engineering. What's your advice for building internal development platforms on Kubernetes?

Gari Singh: So the first thing I'll just point out is the point of advice is that you should always remember that internal developer platforms or even any platform engineering are products and should be treated as such. meaning that they should actually have an overall lifecycle and you need to keep updating them, adjusting them as sort of things change. I think a couple of key things to take in mind when you're using Kubernetes, obviously leverage as much of Kubernetes as you can. Don't try to rebuild the plumbing of Kubernetes when you're building a platform. Build on top of things that are specific to how you want to necessarily run your business and build your applications. And then do decide whether you want to have a totally essentially controlled platform. This is a big choice. Namespace is a service type thing for a single cluster or whether or not you're going to allow some level of, you know, sort of self-service. We found that you start on either end of the spectrum. You always see in the end, you know, end up in the middle. So I think you should always build kind of a flexible model that will have like a big, large Uber central cluster, but also be able to support bespoke self-service clusters.

Bart Farrell: What's next for you, Gari? My big focus, I think, for the rest of the year, I'm going to figure out whatever buzzword AI ops, agentic operations. I know everyone's excited about running AI on Kubernetes. I am too. I am super excited about running Kubernetes with AI. Total tangent. Do you play sports in college?

Gari Singh: I did. What'd you play? I played lacrosse. Good.

Bart Farrell: What can the Kubernetes world learn from lacrosse?

Gari Singh: Ah, you know, what can we learn from lacrosse? I think lacrosse is a team sport. Um, right. You know, play hard, play fast, you know, slow down when you need to. box lacrosse is a great sport like hockey, right? Great teamwork. Sometimes you got to go fast on the fast break. Sometimes you got to pull it back and go slow, run a settled offense and you got to be able to handle anything in between.