Kubernetes and Infrastructure as Code in the Age of Agentic Development

Infrastructure-as-code is often understood as a solution for provisioning cloud resources. This is true – and in the world of agentic AI, creating cloud infrastructure seems easier than ever.

But the reality is that provisioning is only the first step. IaC at its base addresses one specific issue, and that is the dirty secret that your infrastructure – your instances, your clusters, your networking, your databases – is not static and set in stone.

For end users, Kubernetes clusters are a prerequisite to shipping containerized applications. But just like applications running in pods, Kubernetes clusters are not immutable, even though updates to them happen much less frequently. When a Kubernetes minor version rolls out of support, your cloud bill shoots up unless you upgrade.

With IaC, you define all your infrastructure in a single place, whether or not it is managed inside of a Kubernetes cluster. Updates are clear to reason about, safe to trigger, and, most importantly, give agents a safeguard to run infrastructure changes without handing them the keys to your cloud accounts directly.

The Infrastructure-Native Approach

Infrastructure management tools such as Crossplane, AWS Controllers for Kubernetes, Config Connector, and Azure Service Operator follow the Kubernetes Resource Model, applied to cloud infrastructure. But these tools need an existing cluster to work.

In contrast, external infrastructure management solutions like Pulumi, Terraform, and OpenTofu treat a Kubernetes cluster as just one more part of your system. Clusters are defined and provisioned alongside the applications that run on them, in one go. This also makes cluster upgrades safe and reviewable. Your Kubernetes version becomes a one-line code change with a preview gating the deploy, showing you any resources that would be replaced rather than updated, so you can ship quickly and with confidence.

In addition, rather than requiring YAML configuration, with IaC, a platform team can package scoped infrastructure components as a typed library that application teams can consume.

When detecting drift, an in-cluster control plane corrects it immediately via auto-reconcile without asking. IaC by default asks first, and only applies what someone explicitly approved. Correcting drift automatically is a second configurable switch.

IaC also allows for much greater flexibility with regards to cloud provider. Standing up the same cluster or platform tooling somewhere else (a new region, a new deploy stage, a different cloud provider) means merely editing the configuration part of your program that provisions the cluster. Your non-cloud-specific Kubernetes objects follow without a rewrite.

Additionally, almost every Kubernetes shop has pieces of infrastructure that must live outside of a Kubernetes cluster. IaC allows you to manage hybrid infrastructure alongside everything else as well. An external database is just another IaC resource, and your workloads can depend on it directly. In contrast, Helm orders a chart’s manifests by kind, not by dependency, and it cannot wait on a resource that is not a Kubernetes object at all.

Add Agents as a Force Multiplier

Agents, today, can speak directly to cloud providers to create and modify infrastructure. But agents are not deterministic by default, and handing them the keys to your cloud account may not bring the results you want. You’d have little insight into what is happening in your cloud stack, or why, an unacceptable premise when running large systems at scale.

But hand the agent an IaC program, or a stack configuration, and the interaction changes. The agent proposes a change to code. A preview shows exactly what that change would do before anything goes live, using a process you already trust. The diff is reviewable, and the approval stays human, while the agent does all of the heavy lifting.

IaC Meets You on Your Own Terms

Running all infrastructure in one place gives you the most advantage, but almost nobody starts from a clean slate. But IaC is composable. You can gradually migrate to provisioning and maintaining your infrastructure with an IaC program, one piece at a time, without losing track of the state of your existing system. You can even use IaC to begin your Kubernetes journey itself, migrating off older systems.

Because IaC creates a declarative wrapper around your cloud resources, you can import current cloud state into a program. A zero-diff preview serves as proof that your new code matches reality exactly. This desired state paradigm also allows AI agents to reason about your infrastructure deterministically, assisting you with any manual migration tasks.

Finally, if your team is already very Kubernetes-native, or has standardized on an existing GitOps approach, you don’t have to leave that model. An operator can run your IaC programs from inside the cluster, driven by a Kubernetes object that points at a git branch. Your Kubernetes objects are managed as before, and the operator runs what they describe.

In Conclusion

Your infrastructure is already hybrid. If you would rather not manage everything as a Kubernetes object, if you want a review cycle with a human in the loop, or if you want to easily manage your cluster upgrades, then IaC is the solution for you.

KubeCon + CloudNativeCon is taking place in Salt Lake City, Utah, from November 9 to 12. Register Now!