Kubernetes for infrastructure engineers: what Terraform users need to understand
Published on 31 May 2026 by Adam Lloyd-Jones
1. The conceptual alignment: from resources to objects
The foundational principle of both Terraform and Kubernetes is declarative configuration. In Terraform, you describe the desired end state of your infrastructure—what you want to have in place—and the engine determines the step-by-step process for achieving it. Kubernetes operates under the same “desired state” model; you define objects like Pods and Deployments in YAML, and the Kubernetes control plane works tirelessly to ensure the actual state of the cluster matches that definition.
In the Terraform world, blocks are the nouns of the language, representing concrete items like virtual machines, subnets, or DNS records. In Kubernetes, these nouns are referred to as Objects. Just as a Terraform resource has a type (e.g., aws_instance), a Kubernetes object has a kind (e.g., Pod or Service). For an infrastructure engineer, the “unit of work” shifts from the EC2 Instance or Virtual Machine to the Pod, which is a collocated group of containers and the basic building block in Kubernetes.
2. Infrastructure provisioning vs. application orchestration
One of the most critical distinctions for Terraform users to understand is the “line of demarcation” between provisioning and orchestration. Provisioning tools like Terraform are responsible for creating the servers, databases, load balancers, and network topologies themselves. Orchestration tools like Kubernetes are responsible for managing the software that runs on top of those servers.
A common pattern in production-grade infrastructure is to use Terraform to build the cluster and Kubernetes to manage the workloads. For example, you might use Terraform to provision an Amazon EKS cluster, which includes the control plane, worker nodes, and the necessary IAM roles and VPC subnets. Once that “backbone” is built, you transition to using Kubernetes-native tools like kubectl or Helm to deploy applications onto that backbone.
The sources advise against using Terraform to manage individual applications inside a Kubernetes cluster. While a Kubernetes provider for Terraform exists, doing so places an abstraction layer on top of another abstraction layer, which can make debugging significantly more difficult. Instead, engineers should use Kubernetes manifests or Helm charts to manage application-level concerns like environment variables, secrets, and container image versions.
3. State management: the source of truth
Terraform users are intimately familiar with the State File (.tfstate), which acts as a “memory” mapping your code to real-world resource IDs. This state is often stored in remote backends like Amazon S3 or Google Cloud Storage to allow for team collaboration and state locking.
Kubernetes handles state differently. Instead of a single JSON file managed by a client, Kubernetes stores the entire cluster configuration and its current status in a distributed key-value store called etcd, which lives within the master node’s control plane. For a Terraform user, you can think of etcd as the “permanent, server-side state” of the cluster. While Terraform state is refreshed only when you run a command like plan or apply, the Kubernetes control plane continuously observes the actual state and automatically reconciles differences without human intervention.
4. Networking: VPCs vs. services and ingress
In Terraform, networking involves defining Virtual Private Clouds (VPCs), subnets, routing rules, and security groups. This is “low-level” networking that manages how machines talk to each other over a physical or software-defined network.
Kubernetes networking operates at a higher level of abstraction. When you deploy a microservice as a Pod, it is assigned an ephemeral IP address that changes every time the Pod is replaced. To provide a stable endpoint, Kubernetes users create a Service. A Service acts as a traffic director and provides a stable DNS record, which is conceptually similar to an AWS Application Load Balancer (ALB) or an Azure Load Balancer managed by Terraform.
For external access, Kubernetes uses Ingress. An Ingress resource manages external access to the services in a cluster, typically via HTTP, and can handle advanced routing and SSL termination. For a Terraform engineer, an Ingress controller is the software equivalent of a managed load balancer that you would typically provision as an independent cloud resource.
5. Scaling: vertical vs. horizontal
Terraform users often think about scaling in terms of “Vertical Scaling” (changing an instance_type to a larger VM) or “Horizontal Scaling” (increasing a count or for_each loop to launch more identical instances). Renaming or resizing resources in Terraform often triggers a replacement (destroy then create), which requires careful use of the create_before_destroy lifecycle setting to avoid downtime.
Kubernetes is built for Horizontal Scaling and high availability from the ground up. By using a Deployment object, you specify the number of replicas you want, and Kubernetes ensures that many Pods are always running across your fleet of worker nodes. Updates in Kubernetes are typically handled via Rolling Updates, where the orchestrator replaces one replica at a time, only proceeding once the new instance passes its readiness probe. This is more fluid than Terraform’s resource-level replacements and is designed specifically for application-tier zero-downtime deployments.
6. Reusability: modules vs. helm charts
To avoid “DRY” (Don’t Repeat Yourself) violations, Terraform users package infrastructure into Modules. Modules are reusable blueprints that take input variables and return outputs, allowing you to deploy the same pattern across staging and production environments.
The Kubernetes equivalent of a Terraform module is a Helm Chart. Helm is a package manager that allows you to template your Kubernetes YAML manifests. Just as a Terraform module uses a variables.tf file to define inputs, a Helm chart uses a values.yaml file to parameterize configurations like image tags, resource limits, and replica counts. This allows for environment-specific overrides, ensuring that your production environment can have ten replicas while your staging environment has only one, all using the same underlying chart.
7. Managing complexity with “cattle, not pets”
A core philosophy for any infrastructure engineer is treating servers like “cattle, not pets”. Terraform enables this by making it easy to destroy and recreate environments from scratch at will. Kubernetes embodies this philosophy even more aggressively; Pods are designed to be entirely disposable and ephemeral.
If a Pod crashes or a node fails, the Kubernetes Scheduler automatically moves the workload to a healthy node, maintaining the desired state without manual intervention. For Terraform users, this is similar to an AWS Auto Scaling Group (ASG), but it operates at the container level rather than the VM level, providing much faster recovery times and better resource utilization.
8. The emergence of GitOps and reconciliation loops
Terraform is traditionally a “Push” model of delivery: a developer or a CI server runs terraform apply, and the CLI pushes changes to the cloud provider. While this can be automated, it is still a point-in-time execution.
Kubernetes has popularized the GitOps model, which centers on Continuous Reconciliation. In a GitOps workflow, a software agent (like Flux or ArgoCD) runs inside the cluster and pulls the desired state from your Git repository. If someone manually deletes a resource in the cluster, the agent will detect the drift and automatically recreate it to match the code in Git.
Terraform users can now adopt this pattern through tools like the Flux tf-controller, which allows you to treat Terraform resources as a reconciliation loop inside Kubernetes. This turns your infrastructure into a self-healing system, where Terraform runs on a schedule to correct any configuration drift detected in your cloud environment.
9. Advanced refactoring: moved blocks and refactoring state
As Terraform projects grow, engineers often need to refactor their code—renaming resources or moving them into modules to improve maintainability. Historically, this was a manual process using terraform state mv, which was risky and difficult to automate. Modern Terraform and OpenTofu now provide the moved block, allowing you to codify these renames in HCL.
In Kubernetes, refactoring is generally less state-heavy for stateless applications because you can simply update a Deployment manifest and let the rolling update handle the transition. However, for stateful systems, Kubernetes uses StatefulSets, which provide stable identifiers and persistent storage mappings. For the Terraform user, managing a StatefulSet is more akin to managing a database resource where the identity and order of the instances must be preserved across updates.
10. Testing infrastructure and workloads
The sources emphasize that infrastructure code without tests is broken. Terraform users build confidence using the “Testing Pyramid”, which includes:
- Static Analysis: Using tools like
terraform validate,TFLint, and security scanners likeCheckovto catch syntax and policy errors. - Unit/Integration Testing: Using Terratest (Go) or the Terraform Testing Framework (HCL) to provision real resources in a sandbox and validate their behavior.
In the Kubernetes world, testing is equally vital. You must not only test the manifests themselves using linters but also validate the workflow of the application inside the cluster. This involves verifying that Pods scale correctly, load balancers direct traffic accurately, and security policies are enforced. Tools like Terratest are “Swiss Army knives” here, as they can test not only Terraform and Packer but also Kubernetes and Helm configurations, providing a unified testing interface for the entire stack.
11. Tool synergy: the “trio” of automation
Successful infrastructure engineers don’t rely on a single tool but rather a “trio” of specialized technologies:
- Terraform: For provisioning the cloud resources (VPC, EKS, Databases) [2.5, 4214].
- Kubernetes: For orchestration of the containers and managing the application lifecycle.
- Ansible/SaltStack: For configuration management of the underlying nodes or performing ad-hoc tasks that Terraform and Kubernetes aren’t designed for [20, 5, 2.5].
By combining these, you move from “artisan crafting” to an industrialized, automated factory where infrastructure is “routine and boring”—which is a very good thing in production.
Conclusion: embracing the abstraction
For a Terraform user, Kubernetes might initially feel like it is taking control away from the infrastructure layer. However, the true power of Kubernetes lies in its ability to standardize the application platform across any cloud provider, effectively preventing vendor lock-in. While Terraform allows you to script the creation of cloud infrastructure with ease, Kubernetes provides the production backbone that manages the daily “housekeeping” of running those applications at scale.
By understanding the alignment between Terraform’s resource-centric declarative model and Kubernetes’ object-oriented reconciliation model, infrastructure engineers can build systems that are not only repeatable and consistent but also resilient and self-healing. The journey from Terraform to Kubernetes is not about replacing one tool with another, but about expanding your toolkit to manage higher levels of complexity with the same rigor and automation that defined your success in the cloud.
Related Posts
- Terraform drift detection: Why terraform plan is too late
- Module 5: Terraform CI/CD Environments and Production Workflows on Azure
- How to Manage Terraform State in a Large Team
- Drawbacks and Challenges of Microservices Architecture
- How Does Terraform Differ From Puppet and Ansible
