KASLIN FIELDS: Hello, and welcome to the Kubernetes Podcast from Google. I'm your host, Kaslin Fields.

ABDEL SGHIOUAR: And I am Abdel Sghiouar.

[MUSIC PLAYING]

In this episode, we spoke to Pierre-Gilles Mialon and Glen Yu. Pierre-Gilles and Glen are Google Developer Experts. We had an opportunity to catch up with them at Google Cloud Next, and we spoke about platform engineering, GitOps, and AI.

KASLIN FIELDS: But first, let's get to the news.

[MUSIC PLAYING]

Docker Desktop version 4.43 was released, and it introduces a lot of improvements to the Docker model runner. New features include better model management from the interface in CLI, with the ability to inspect the model cards. The new version of the desktop also added expanded compatibility for the OpenAI API, like streaming outputs. The built-in MCP catalog also received improvements to its searching capabilities. You can learn more about these and many more features in the blog linked in our show notes.

ABDEL SGHIOUAR: Docker also announced at WeAreDevelopers in Berlin last week that they are expanding Docker Compose capabilities to support deploying apps to the cloud. The first implementation is done in partnership with Google Cloud. You can now use gcloud to deploy a Docker Compose file into Google Cloud Run, including support for GPUs and building containers without a Docker file.

KASLIN FIELDS: KubeCon CloudNativeCon is returning to Japan in 2026. The event will take place July 29 and 30 in the port city of Yokohama. The first edition of Kubecon in Japan took place this year in June and was very successful, with 700 speaking session submissions and a completely sold out event with around 1,500 attendees. I, Kaslin Fields from the Kubernetes Podcast, was there and recorded some behind the scenes interviews. Look forward to these coming out soon. And that's the news.

[MUSIC PLAYING]

ABDEL SGHIOUAR: Hello, everyone. Welcome back. This is Abdel from the Kubernetes Podcast. We are live from Google Cloud Next 2025. And I have with me Glen and Pierre-Gilles. Hi, folks.

GLEN YU: Hello. Hello.

PIERRE-GILLES MIALON: Hi.

ABDEL SGHIOUAR: How are you doing?

GLEN YU: I'm doing well. It's the last day. It's starting to get a little tired. Fatigue settling in, but no, it's been great.

ABDEL SGHIOUAR: Yeah, Next was insane. 33,000 people in Vegas in the middle of the desert. So--

GLEN YU: I certainly got my steps in.

ABDEL SGHIOUAR: Oh, yeah. I've been averaging, like, 25,000 steps every day. It's insane. All right, so let's start with some introductions. Gilles, who are you? What do you do?

PIERRE-GILLES MIALON: I'm a Cloud Champion, and I help companies in their journey to the cloud, mostly with Kubernetes.

ABDEL SGHIOUAR: Awesome. And you probably haven't figured it, Pierre-Gilles is French. And he has a very cute French accent. And Glen?

GLEN YU: Yeah, hi. I'm Glen Yu. I'm based out of Toronto. I work for PwC, which is a Google partner. Personally, I've been a Google Developer Expert for Google Cloud for five years now. I'm also a member of the Kubernetes Policy Working Group and the Kubernetes Infrastructure Life Cycle Working Group. So I'm quite involved with a lot of the Kubernetes aspects.

ABDEL SGHIOUAR: Awesome. So as you mentioned, you're both Google Developer Experts, GDEs, on our GDE program. So we'll start with you, Pierre-Gilles, because in the way you describe the work you do, you brought up a bunch of words that I am quite familiar with, GitOps. Where are we on GitOps these days?

PIERRE-GILLES MIALON: The main issue is infrastructure, is to be sure what is running on. And one way to ensure that is to put your definition in Git and ensure that you have something that reconcile what you exactly described and put it in your clusters. You have many ways to achieve that. GitOps is a practice that exists for nearly 7 or 8 years. The tools have changed during this period, and now, we have a great way to ensure that what is running is really what we want.

ABDEL SGHIOUAR: All right. Yeah. And in a way, GitOps just leverages the reconciliation concept in Kubernetes, right?

PIERRE-GILLES MIALON: Yeah. It also ensure you that what you want is what you get. Because GitOps ensure you all the Git principles. So you know that if something changes, someone has committed something, and so you have traceability. You have reversibility, too, because you can roll back through Git Revert.

And you have-- it's easy to read. You can see the change by reading your Git log. You have all the story of the evolution of your infrastructure.

ABDEL SGHIOUAR: All right. Cool. And so in this space of using GitOps practices to deploy apps, deploy infrastructure, deploy stuff, and even policy as code, which is the stuff that you then work on, there are basically two camps. There is the Terraform, Pulumi kind of bash script camp, which is write code that does stuff, and then there is the KRM camp, the Kubernetes Resource Model camp, which is using Kubernetes as a way to drive infrastructure management.

I'm certainly in the second camp, because I pretty much like Kubernetes. But what's your take on that, Pierre-Gilles? What's your-- which one do you like, first, and why?

PIERRE-GILLES MIALON: I'm an early adopter of Terraform and other infrastructure's code, but with time, it seems to me that KRM is definitely the best model, as you said. Because you can-- you can avoid the drift. This is one of the great features is that you can avoid the drift.

Another thing is that using a Kubernetes resource model, you use YAML. YAML is not the best thing in the world, but it's purely declarative. So there is no language. This is a description.

GLEN YU: Yeah. It's a config.

PIERRE-GILLES MIALON: When the API of the cloud provider change, you don't have to change your definition. What will be changed is the reconciliation behind the scene that will be upgraded, but your definition will stay the same.

Something you didn't have-- one of the most issues with Terraform, I think, is maintenance cost. I use a code that I wrote in a KRM model for. I wrote them four years ago. And I still continue to copy-paste, and use it. This is purely decorative. It's still working. I don't think that you can find a piece of Terraform code that worked four years ago and that still works today.

ABDEL SGHIOUAR: And this is because, what, the cloud provider changes their API and then you have to update your code?

PIERRE-GILLES MIALON: Yes. The way your company managed Terraform code, too, because you have style in Terraform.

ABDEL SGHIOUAR: Yes.

PIERRE-GILLES MIALON: The way the pipeline are really complex when you use KRM. When you use Terraform, you sometimes use orchestration. So you still need to apply this model first, and this one secondly, and this one after. In the KRM model, you don't have that. You put everything together and let reconcile.

It's a Kubernetes spirit. So even if it didn't work, your resource cannot be ready for one hour because it takes many times to reconcile the dependency of this resource, but it will work at the end. And you have only one operation. But with Terraform, you will have issued seven operations.

And we know that the most-- the incident came from operations. You follow the procedure, step 1, step 2, step 3, all. Oopsie daisy, there is a step 2 and 1/2 that broke, that was missing, and that was not mentioned in the procedure because the infrastructure that evolved between the days the documentation was written.

ABDEL SGHIOUAR: Yeah. Or it could be as simple as you run a Terraform script, and then one thing does not deploy because you don't have the right permissions.

PIERRE-GILLES MIALON: Yes.

ABDEL SGHIOUAR: And now you fall into this situation where you either have to rerun it one more time, but sometimes it doesn't work because some resources can only have a unique name. And then you have to go manually clean everything and then run it again. But I like that whole, the way you described, like the Kubernetes resource model, which is it's an eventually consistent system. So eventually, everything will reconcile.

PIERRE-GILLES MIALON: Exactly.

ABDEL SGHIOUAR: And everything will get created or updated or whatever, right?

PIERRE-GILLES MIALON: What you can show with a KRM model, is if it works in an environment, if your infrastructure converge, you are sure that it will converge in the other environment. So during qualification, you really have a full qualification of your code. You have your description. It's not really code.

ABDEL SGHIOUAR: It's declarative. And when you describe this thing of reconciling dependencies, like if you have to create this thing first, and then create this other things second, and then create this other thing third, yes, Terraform-- sorry-- KRM helps in the sense that object A will not be created if it depends on object B, and object B has to be created first, so it will wait until-- it will not wait. It will keep trying, basically.

PIERRE-GILLES MIALON: It depends on the implementation of your KRM model. Because sometimes, your KRM model is aware of the necessity of creating a dependency.

ABDEL SGHIOUAR: Yeah.

PIERRE-GILLES MIALON: It doesn't work for everyone, but in the end, it's just a matter of time.

ABDEL SGHIOUAR: Yeah. And so in that space, that's what KRO partially was trying to solve, right? The Kubernetes Resource Orchestrator.

PIERRE-GILLES MIALON: Yeah.

ABDEL SGHIOUAR: Which we did an episode about on the podcast with Nick and Jesse. But KRO has that capability. It basically has a DAG, a built in graph so it can resolve the dependencies. What's your take on KRO?

PIERRE-GILLES MIALON: I think this is amazing. Because, once again, we were talking about Terraform. Most of the executives are thinking that if they used Terraform, if their teams use Terraform, they will be able to deploy everything in every cloud, which is not true.

ABDEL SGHIOUAR: Yeah. It's not cloud agnostic.

PIERRE-GILLES MIALON: Yeah. You should rewrite your infrastructure with the appropriate provider for AWS, Azure, or GCP. The policies behind the KRO is that you can abstract concepts, you can abstract concepts at another level and hide the resources, the true resources of the cloud provider. And so you can create real agnostic declaration. This way, you have the world is offered to you.

Because you have the first abstraction of the KRM model that ensures that it will reconcile. And secondly, you have the abstraction of the-- you abstract the provider through a YAML, and the second one is collection of YAML you need is abstracted to. There is security issue behind this.

Because you can offer the opportunity to your developers to deploy my database type, a CRD, but I'm sure that they won't be able to create Cloud SQL instances. And this way, you can ensure that the way they deploy Cloud SQL are defined by your platform team and ensure the best practices and the best security practice around this. So it achieves the promises that Terraform didn't have.

ABDEL SGHIOUAR: Yeah. And that's actually one of the features I like about KRO, which is simplifying or hiding certain security things that I don't want developers to create a database that has a public IP, for example. You can just hide that away.

So that's actually a good segue to you, Glen. You worked on this paper for Kubernetes called Shift Down Security for Kubernetes, Security Shift Down, right?

GLEN YU: Yes.

ABDEL SGHIOUAR: And we've been hearing this thing of Shift Down quite a lot. That's what Terraform also was trying to achieve in a way. So what's that paper about?

GLEN YU: It's about policy as code. I like how we talked about infrastructure as code first, because think back about what infrastructure as code solved is like, people used to build their servers manually. It's very error-prone. And so something like infrastructure as code makes things more declarative. You can do things more repeatable. And it's also, in of itself, a live documentation.

And after your resource gets deployed, it doesn't stop there. It's, yeah, I have my server. I have certain things configured, certain things enabled, network, whatnot, but what happens inside? A lot of the configurations of the applications or the IAM or other settings in there, people still do manually. Policy as code takes that principle, that infrastructure as code solved for infrastructure and is applying it to securing and hardening the resources that you've already deployed.

ABDEL SGHIOUAR: Can you, just for the sake of clarity, can you give us some concrete example of what would you do with security as code? Because I've been hearing about tools like Kyverno, which is one popular one. But, yeah, just an example.

GLEN YU: So Kyverno is a tool that I quite like. So you can set-- you set policies in your Kubernetes cluster. Let's say you have to have a certain tag. It needs to have a service account, or it cannot be in the default namespace, and other things like that. Or when you deploy a container, it can't have a "latest" tag, little things like that that you can't-- after you you've deployed Kubernetes, you can't always be there watching what everybody does, make sure that everybody does the right thing.

So something like policy as code puts in these admissions controllers that will say, hey, you're trying to deploy something with the "latest" tag. You should have an explicit version. Or you don't have a-- you don't have the appropriate tags, or you're trying to deploy in the default namespace. These are some things that you need to fix.

ABDEL SGHIOUAR: All right. Yeah. And that's actually-- these are stuff that you could also effectively orchestrate through Kubernetes Resource Orchestrator, right? Or abstract away the high-level implementation details? So in this day and age, there is this thing called platform engineering, and everybody seems to be a big fan about it.

And to me, it's funny, because it seems like what DevOps have been trying to solve for a very long time is the separation of concerns between development and operations, so to blend these two things together. And now, the way platform engineering feels is going back to that age where we have the platform at the bottom and the applications at the top, and just give me a platform where I run my apps and don't talk to me. So my follow-up question to that is-- or my question to this is, where do you see security challenges within this platform space?

GLEN YU: The main principle about Shift Down is you want your platform to be secure by design, which is a little bit different from the Shift Left that was very popular a few years back. But I think Shift Left is a little bit lazy, in a way. It's good that developers take security into account earlier, but at the same time, that's not their bread and butter. That's not what they specialize in.

And you're trying to put a lot of the onus on securing your app and the platform that it runs on onto developers. And that's I think that's not a full, secure solution. Security is everybody's responsibility. It's not just developers, but also platform teams, the security teams. They need to do their part to be sure everything's secure.

Now, some of the challenges that I think platform teams will face is that there's going to-- there's usually that disconnect in communications between them and the application team. So there are things that they might not talk about or they don't know what to ask, and there might be things that get left out. So that's where things like policy as code and things help. That's where they come in to really help create a good baseline for what-- a guardrail for what should and shouldn't be. It's everybody's job, everybody's responsibility. You need everybody to do their part and work together to make something safe.

ABDEL SGHIOUAR: Yeah. And I'll go back to Pierre-Gilles, do you have to-- since you work on automation and Flux CD and KRM, KCC, and all that stuff, is security something that you touch and be concerned with?

PIERRE-GILLES MIALON: It's at every step.

ABDEL SGHIOUAR: OK.

PIERRE-GILLES MIALON: I share exactly-- I share what you said. One of the issues with Kubernetes is that it was created to ensure that you can run everything. And running everything is not a good idea in a world where people create [? porn ?] applications.

We don't need to see Postfix running in a Kubernetes server. But when Kubernetes was created, it was created to allow that. So the default policy on a command Kuberbnetes server are far too permissive. And for this reason, I am sure that, for example, I use a permission controller for every namespace, for every namespace of my customer, and I add policies, as you said. Because I don't want that developers is able to create a service type load balancer, for example.

ABDEL SGHIOUAR: Of course. Yeah. And so I do have a follow-up question. It's actually not a follow-up question, because preparing for this episode, I was looking at your blog on Medium and you wrote something about Nomad. And it's funny, because we are all kind of way too deep-- I'm talking about myself. I'm way too deep into the Kubernetes space that I just assumed that Kubernetes is the only orchestrators that exist.

And the even funnier thing is, yesterday, I was talking to a software engineer from this company called Fermyon. They do WASM. And they use Nomad for their cloud serverless functions, the WASM serverless functions. So what's up with Nomad? Is it, like, big?

GLEN YU: No, it's not. It's got a really small market share. I think there's some niche industries that do use it. But I think it was out around the same time as Kubernetes. It's from HashiCorp. It's their workload orchestrator, because they do more than just containers. You can run-- you can orchestrate Java apps.

ABDEL SGHIOUAR: It does more than just-- it doesn't only do container.

GLEN YU: Containers is a huge part, but that's one of the things that it can do. Early in my career, I did I did quite a bit of work with Nomad, and I find that it is-- and this was probably like 6 or 7 years ago. Kubernetes was still early. We still didn't have a lot of the tools that we have today. And even from a managed service standpoint, it wasn't available everywhere.

Nomad was a good, easier alternative, especially for smaller companies back then who didn't have the knowledge or the people to handle the complexity of Kubernetes. I would say it would be somewhere that falls between, say, like Docker Swarm and Kubernetes. It falls somewhere in between in terms of comfort.

ABDEL SGHIOUAR: Yeah. And so one more tool I want to talk about-- this is going to be my last question. Do you work with Flux CD?

GLEN YU: No. I use-- I like Flux CD. I've tried it a bit. But I've been using Argo, mostly.

ABDEL SGHIOUAR: Yeah. And so it seems like we're in this space now where there is, again, two camps. There is the Argo CD camp and the Flux CD camp. Can you, Pierre-Gilles, briefly what's-- because you work with Flux CD. What do you like about it? What's up with Flux CD?

PIERRE-GILLES MIALON: It's in the spirit of Kubernetes. It respects everything. It's a role-based access control of Kubernetes. It rewrote something above it. So, yes, it's really Kubernetes' spirit.

GLEN YU: I will tend to agree. And I really like the command line aspect of Flux CD. It's a lot more-- it's a lot more command line. Argo CD is a little bit more visual. But at the same time, if I was working on a personal project, I might use Flux CD.

I work as a consultant, and a lot of clients, they like Argo, so that's very understandable. So I see a lot more Argo. I'm coming from a consultant background, right? So it's very different.

PIERRE-GILLES MIALON: There is one more thing about the Flux. I think that for developers, they don't use-- they shouldn't use the CLI. The idea behind Flux CD is that you rely on notification. And in your real githubs, what you want to do is to-- the developer should work as fast as it can.

So he put his code. The code is compiled by the CI. It's deployed by Flux, and if it succeeds, you have a notification that tells you the development is OK. Then you can go to the next step. And the idea is that you don't want to lose your time opening a web UI.

Because normally, if everything is good, continue to work on your stuff and you don't have to-- you don't have to check what's happened. Because if the way you deploy your application is great, then you don't have to focus on that. Concentrate on your work.

ABDEL SGHIOUAR: Yeah. Tell me only when things broke. But when things are working, I don't want to know.

PIERRE-GILLES MIALON: Exactly.

ABDEL SGHIOUAR: Yeah. Awesome. Awesome.

PIERRE-GILLES MIALON: Tell me when it fails.

ABDEL SGHIOUAR: Yes. All right, well, awesome. Thank you so much, guys, for being on the show. This was really good conversation. And we'll make sure to link your socials on the episode when it's out. Thank you.

GLEN YU: Absolutely.

PIERRE-GILLES MIALON: Thank you. Thanks for having me. Thanks for having us.

KASLIN FIELDS: That brings us to the end of another episode. If you enjoyed the show, please help us spread the word and tell a friend. If you have any feedback for us, you can find us on social media at Kubernetes Pod or reach us by email <kubernetespodcast@google.com>.

You can also check out the website at kubernetespodcast.com, where you'll find transcripts, show notes, and links to subscribe. Please consider rating us in your podcast player so we can help more people find and enjoy the show. Thanks for listening, and we'll see you next time.

[MUSIC PLAYING]