Platform Engineering, GitOps and AI with Pierre-Gilles Mialon and Glen Yu

Summary

Kubernetes Podcast from Google – Episode: Platform Engineering, GitOps and AI with Pierre-Gilles Mialon and Glenn Yu

Release Date: July 25, 2025

In this enlightening episode of the Kubernetes Podcast from Google, hosts Abdel Sighiwar and Kaslin Fields engage in a comprehensive discussion with Google Developer Experts Pierre-Gilles Mialon and Glenn Yu. The conversation delves deep into the realms of platform engineering, GitOps, and AI, offering valuable insights for Kubernetes enthusiasts and professionals alike.

---

1. Exploring GitOps: Principles and Practices

The episode kicks off with an in-depth exploration of GitOps, a methodology centered around using Git as the single source of truth for infrastructure and application deployments.

Pierre-Gilles Mialon explains, “GitOps is a practice that exists for nearly seven or eight 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.” [03:26]

Abdel Sighiwar connects GitOps to Kubernetes, noting its reliance on reconciliation: “GitOps just leverages the reconciliation concept in Kubernetes, right?”

Pierre-Gilles elaborates on GitOps’ advantages, emphasizing traceability and consistency. “GitHub ensures you all the git principles so you know that if something changes, someone has committed something. And so you have traceability, you have reversibility because you can roll back.” [04:00]

---

2. GitOps Tools: KRM vs. Terraform/Pulumi

A significant portion of the discussion contrasts Kubernetes Resource Model (KRM) with traditional infrastructure-as-code tools like Terraform and Pulumi.

Pierre-Gilles advocates for KRM, highlighting its ability to avoid configuration drift and its purely declarative nature: “YAML is not the best thing in the world, but it's purely declarative. So there is no language. This is a description.” [05:45]

He further critiques Terraform’s maintenance overhead: “One of the most issue with Terraform... you have to update your code when the cloud provider changes their API.” [06:28]

In contrast, KRM offers seamless reconciliation aligned with Kubernetes’ principles. “It's a Kubernetes spirit. So even if it doesn't work, your resource cannot be ready for one hour because it took many times to reconcile the dependency of this resource.” [06:59]

---

3. Kubernetes Resource Orchestrator (Kero)

The conversation transitions to Kero, the Kubernetes Resource Orchestrator, which addresses dependency management within Kubernetes.

Pierre-Gilles praises Kero’s abstraction capabilities: “You can abstract the provider and through YAML and the second one is collection of YAML you need is abstracted too.” [10:49]

He underscores Kero’s role in enforcing security and best practices by restricting developers from creating unauthorized resources: “There is a security issue behind this because you can offer the opportunity to your developers to deploy my database type CRD but ensure that they won't be able to create cloud SQL instances.” [10:49]

Abdel concurs, appreciating Kero’s ability to hide certain security configurations: “That's actually one of the features I like about Kero, which is simplifying or hiding certain security things that I don't want developers to create.” [09:34]

---

4. Security Challenges in Platform Engineering

Shifting focus to security, the guests discuss the concept of Shift Down Security and the limitations of Shift Left approaches.

Glenn Yu introduces the topic: “Policy as code takes that principle, that infrastructure as code solved for infrastructure. And I was applying it to securing and hardening the resources that you've already deployed.” [11:15]

He emphasizes that security is a collective responsibility: “Security is everybody's responsibility. It's not just developers, but also platform teams, the security teams, they need to do their part to make sure everything's secure.” [14:06]

Pierre-Gilles adds, “One of the issues with Kubernetes is when it was created to ensure that you can run everything. Running everything is not a good idea... the default policy on a Kubernetes server are far too permissive.” [16:12]

---

5. Policy as Code and Tools like Caverno

The discussion delves into Policy as Code, with Glenn Yu highlighting tools like Caverno that enforce policies within Kubernetes clusters.

Glenn explains, “You can use policies in your Kubernetes clusters. 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...” [12:25]

These policies act as automated guards, ensuring that deployments adhere to predefined standards without constant manual oversight.

---

6. Alternative Orchestrators: Nomad

Abdel introduces the topic of HashiCorp Nomad, questioning its relevance in the Kubernetes-dominated landscape.

Pierre-Gilles provides context on Nomad’s niche usage: “It's got a really small market share... some niche industries do use it.” [17:04]

Glenn Yu adds, “Nomad was a good, easier alternative, especially for smaller companies back then. Who didn't have the knowledge to handle or the people to handle the complexity of Kubernetes.” [17:09]

They acknowledge Nomad’s position between Docker Swarm and Kubernetes in terms of complexity and functionality.

---

7. GitOps Tools Showdown: FluxCD vs. Argo CD

The final major topic compares two leading GitOps tools: FluxCD and Argo CD.

Pierre-Gilles champions FluxCD for its adherence to Kubernetes principles: “It's in the spirit of Kubernetes. It respects everything. The role-based access control of Kubernetes is that we wrote something above it.” [18:32]

Glenn Yu shares his preference, appreciating FluxCD’s command-line interface: “I really like the command line aspect of FluxCD a lot more. Argo CD is a little bit more visual...” [18:45]

Pierre-Gilles emphasizes FluxCD’s seamless integration with CI/CD pipelines: “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... if it succeeds you have a notification that tell you the development is okay.” [19:11]

---

8. Conclusion

The episode wraps up with the hosts expressing gratitude to Pierre-Gilles and Glenn for their valuable insights. They highlight the importance of adopting robust GitOps practices, leveraging the right tools, and prioritizing security within platform engineering.

---

Key Takeaways:

• GitOps offers a declarative, version-controlled approach to infrastructure and application management, ensuring consistency and traceability.

• KRM is favored over tools like Terraform for its seamless reconciliation with Kubernetes and reduced maintenance overhead.

• Kero enhances Kubernetes’ capability by managing dependencies and enforcing security policies through abstraction.

• Shift Down Security advocates for security-by-design within platforms, distributing responsibility across teams rather than solely relying on developers.

• Policy as Code tools like Caverno are essential for automating and enforcing security standards within Kubernetes environments.

• FluxCD and Argo CD represent two robust GitOps tools, each with its own strengths catering to different use cases and preferences.

This episode provides a wealth of knowledge for those looking to optimize their Kubernetes deployments, implement effective GitOps strategies, and ensure robust security within their platform engineering practices.

Transcript

[Kaslin Fields]

Hello and welcome to the Kubernetes podcast from Google. I'm your host Kaslin Fields.

[Abdel Sighiwar]

And I am Abdel Sighiwar. In this episode we spoke to Pierre gillesmillon and Glenn New. Pierre, Gilles and Glenn 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. 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 Sighiwar]

Docker also announced that we are developers 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 Dockerfile.

[Kaslin Fields]

Kubecon Cloud Native Con is returning to Japan in 2026. The event will take place July 29th and 30th 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, Kazem 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.

[Abdel Sighiwar]

Hello everyone. Welcome back. This is Abdel from the Kubernetes podcast. We are live from go Cloud next 2025 and I have with me Glenn and Pierre Gilles. Hi folks.

[Pierre Gilles]

Hi.

[Abdel Sighiwar]

How are you doing?

[Glenn Yu]

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 Sighiwar]

Yeah, Dex was insane. 33,000 people in Vegas in the middle of the desert.

[Glenn Yu]

So I certainly got my steps in.

[Abdel Sighiwar]

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]

I'm a cloud champion and I help companies in their journey to the cloud, mostly with Kubernetes.

[Abdel Sighiwar]

Awesome. And you probably haven't figured it gargill is French and he has a very cute French accent and. Glenn?

[Glenn Yu]

Yeah, Hi, I'm Glenn Yu. I'm based out of Toronto. I work for B2C, 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 Lifecycle Working Group. So I'm quite involved with a lot of the kubernetes aspects.

[Abdel Sighiwar]

Awesome. And yeah, so as you mentioned, you're both Google Developer fed 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 like a bunch of words that I am quite familiar with. GetOps. Where are we on GetOps these days?

[Pierre Gilles]

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 reconciles 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 seven or eight 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 Sighiwar]

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

[Pierre Gilles]

Yeah. It also ensures you that what you want is what you get, because GitHub ensures you all the git principles so you know that if something changes, someone has committed something. And so you have traceability, you have reversibility because you can roll back. It's a git revote and 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 Sighiwar]

All right, cool. And so in this space of using GitOps practices to deploy apps, deploy infrastructure, deploy stuff, and even like 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 Krem 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. So what's your take on that, Pierre Gilles? Which one do you like first and why?

[Pierre Gilles]

I'm an early adopter of Terraform and other two infrastructure as code. But with time it seems to me that KRM is definitely the best model, as you said, because 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.

[Abdel Sighiwar]

Yeah, it's a config.

[Pierre Gilles]

When the API of the cloud provider change, you don't have to change your definition. What will be changed is the reconciliation, the reconciler behind the scene that will be upgraded, but your definition will stay the same. Something you didn't have. One of the most issue with Terraform, I think is maintenance cost. I use a code that I wrote in the KREM 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. Don't think that you can find a piece of Terraform code that worked four years ago and that still work today.

[Abdel Sighiwar]

And this is because cloud provider changes their API and then you have to update your code.

[Pierre Gilles]

Yes, the way your company manages the Terraform code too. Because you have styling Terraform. Yes, 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 module first and this one secondly and this one after. In a Krem model you don't have that. You put everything together and let's reconcile. It's a Kubernetes spirit. So even if it doesn't work, your resource cannot be ready for one hour because it took many times to reconciliate 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. Yes, you follow the procedure. Step one, step two, step three or oxidizey. There is a step two and half 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 Sighiwar]

Yeah. Or it could be as simple as your relative form scripts and then one thing does not deploy because you don't have the right permissions.

[Pierre Gilles]

Yes.

[Abdel Sighiwar]

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 the Kubernetes resource model, which is it's an eventually consistent system. So eventually everything will reconcile.

[Pierre Gilles]

Exactly.

[Abdel Sighiwar]

And everything will get created or updated or whatever. Right.

[Pierre Gilles]

What you're unsure with, okay, our 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 fully calification of your code of your description.

[Abdel Sighiwar]

It's not really code, it's declarative. When you describe this thing of the reconciling dependencies like things. If you have to create this thing first and then create this other thing 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 one not wait, it will keep trying.

[Pierre Gilles]

Basically it depends on the implementation of your KR model because sometimes your KR model is aware of the necessity of creating a dependency. It doesn't work for everyone, but in the end it's just a matter of time.

[Abdel Sighiwar]

Yeah. And so in that space that's what keyroll partially was trying to solve. Right. Like the Kubernetes Resource Orchestrator which we did an episode about on the podcast with Nick and Jesse. But Kero has this capability. It basically has a dag, a built in graph so it can resolve the dependencies. What's your take on Kiero?

[Pierre Gilles]

I think this is amazing because once again we were talking about Terraform. Most of us, the executive are thinking that if they use Terraform, if their teams use Terraform, they will be able to deploy everything in every cloud. Which is not true.

[Abdel Sighiwar]

Yeah, it's not cloud agnostic.

[Pierre Gilles]

Yeah, you should rewrite your infrastructure with the appropriate provider for AWS Azure, off gcp. The promises with the CROW 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 the world is offered to you because you have the first abstraction of the KI model that ensures that it will reconcile and secondly you have the abstraction of the so you abstract the provider and through YAML and the second one is collection of YAML you need is abstracted too. There is security issue behind this because you can offer the opportunity to your developers to deploy my database type CRD but ensure 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 Sighiwar]

Yeah. And that's actually one of the features I like about Kera, 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 way. So that's actually a good segue to you. Glenn, you worked on this paper for Kubernetes called Shift down security for Kubernetes security. Shift down, right. Yes. And we've been hearing this thing of shift down quite a lot. That's what Terraform also is trying to achieve in a way. So what's this paper about?

[Glenn 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 kind of solved is. Like people used to kind of 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 a. It's also in of itself a live documentation.

[Abdel Sighiwar]

Yeah.

[Glenn Yu]

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? Right. A lot of the configurations of the applications or the IAM or other settings in there, people still do manually.

[Abdel Sighiwar]

Yeah.

[Glenn Yu]

Policy as code takes that principle, that infrastructure as code solved for infrastructure. And I was applying it to securing and hardening the resources that you've already deployed.

[Abdel Sighiwar]

All right, can you, just for the sake of clarity, can you give us some concrete example of what would you do with security as code? Maybe because I've been hearing about tools like Caverno, which is one popular one, but yeah, just an example.

[Glenn Yu]

So Caverno is a tool that I quite like. So you can use policies in your, say, your Kubernetes clusters. 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'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 emissions controllers that will say, hey, you, you're trying to deploy something with the latest tag, you should have an explicit version.

[Abdel Sighiwar]

Right.

[Glenn Yu]

Or you're. You don't have. You don't have the appropriate tags or you're trying to deploy in the default namespace. Like these are some things that you need to fix.

[Abdel Sighiwar]

All right. Yeah. And that's actually, these are stuff that you could also effectively orchestrate through the Kubernetes resource Orchestrator. Right. Or abstract away the high level implementation details like. 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 developments and operations. And 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 then 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?

[Glenn 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 a. I think that's a. That's not a full secure solution. Security is everybody's responsibility. It's not just, not just developers, but also platform teams, the security teams, they need to do their part to make sure everything's secure. Now some of the challenges that I think platform teams will face is that 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 the commands really help create a good baseline for what should be a guardrail for what should and shouldn't be.

[Abdel Sighiwar]

Yeah.

[Glenn Yu]

Right now looks like it's everybody's job, everybody's responsibility. You need everybody to do their part and work together to make something safe.

[Abdel Sighiwar]

Yeah. And I'll go back to you. Do you have to? Since you work on Automation and FluxCity and KRM KCC and all that stuff. Is security something that you like, touch and be concerned with?

[Pierre Gilles]

It's at every step. Okay, I share.

[Abdel Sighiwar]

Exactly.

[Pierre Gilles]

I share what you said. One of the issues with Kubernetes is when it was created to ensure that you can run everything. Running everything is not a good idea in a world where people create own applications. Yes, we don't need to see part fix running in a Kubernetes server, but when Kubernetes was created, it was created to allow that. So the default policy on a Kubernetes server are far too permissive. And for this reason I ensure that, for example, I use a padded mission controller. Controller for every. For every namespace. For every namespace of my customer. And I add policies as you said, because I don't want that developers is about to create a service type load balancer.

[Abdel Sighiwar]

Yeah.

[Pierre Gilles]

For example.

[Abdel Sighiwar]

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 assume 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 Fermion. They do wasm and they use Nomad for their cloud serverless functions. Wasm service functions. So what's up with Nomad? Is it like big?

[Glenn Yu]

No, it's not. It's got a really small market share.

[Pierre Gilles]

It's.

[Glenn Yu]

I think there's some niche industries that do use it.

[Abdel Sighiwar]

Yeah.

[Glenn Yu]

But I think it was out around the same time as Kubernetes. It's from Hashicorp.

[Abdel Sighiwar]

Yep.

[Glenn Yu]

It's their workload Orchestrator. Because they do more than just containers. They do. You can run. You can orchestrate Java apps like.

[Abdel Sighiwar]

Yeah, it does more than just. It doesn't need the container.

[Glenn Yu]

Containers is a huge part, but that's one of the things that it can do. Early in my career I did a. I did quite a bit of work with Nomad and I find that it is when this was probably like six, seven years ago, Kubernetes was still fairly early. We still don't have a lot of the tools that we have today. And even like from a managed service standpoint, it wasn't available. Nomad was a good, easier alternative, especially for like smaller companies back then. Who didn't have the knowledge to handle 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 complexity.

[Abdel Sighiwar]

Yeah. And so one more tool I want to talk about, this is going to be my last question and do you work with FluxCD?

[Glenn Yu]

No, I use. I like FluxCD. I've tried it a bit but I've been using Argo mostly.

[Abdel Sighiwar]

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 cdc. Can you brg just briefly what's. Because you work with FluxCD, what do you like about it? What's up with FluxCD?

[Pierre Gilles]

It's in the spirit of Kubernetes.

[Abdel Sighiwar]

Okay.

[Pierre Gilles]

It respects everything. The role based access control of Kubernetes is that we wrote something above it. So yes, it's really Kubernetes spirit.

[Glenn Yu]

I will tend to agree. And I really like the command line aspect of FluxCD 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 fluxd. 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 buggeron background. Right. So it's very different.

[Pierre Gilles]

There is one more thing about Flux. I think that for developers they don't use, they just shouldn't use cli. The idea behind fluxity is that you rely on notification and in your real githubs what would you want to do is to. The developer should work as fast as this can so you put his card. The code is compiled by the CI, it's deployed by Flux and if it succeeds you have a notification that tell you the development is okay. 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 stops interruption and 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 it. Concentrate on your work.

[Abdel Sighiwar]

Tell me only when things broke, but when things are working I don't want to know exactly. Yeah. Awesome, awesome.

[Pierre Gilles]

I'll help me when it fails.

[Abdel Sighiwar]

Yes. All right, well, awesome. Thank you very 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.

[Glenn Yu]

Absolutely.

[Pierre Gilles]

Thank you.

[Glenn Yu]

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 Kubernetespod or reach us by email at kubernetespodcastgoogle.com youm 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.