Bleeding Runway on Kubernetes or Pulumi? | Comparison

Kubernetes is fundamentally a distributed system control plane and state-reconciliation engine. It operates continuously via an API server backed by etcd, utilizing asynchronous control loops to drive the actual infrastructure state toward a declared desired state in real-time. In contrast, Pulumi is a transactional Infrastructure as Code (IaC) deployment engine. It evaluates general-purpose programming languages (TypeScript, Python, Go) at compile-time to construct a static dependency graph of cloud resources, mutates provider APIs via gRPC plugins, and records the resulting resource IDs in a static state file. The architectural friction emerges when integrating the two paradigms. While Pulumi can provision Kubernetes clusters and inject workloads into them, doing so often subverts Kubernetes' native GitOps model. Relying on Pulumi to manage in-cluster resources introduces an external, pipeline-bound state dependency that cannot react to out-of-band drift. High-performing enterprise engineering teams should isolate Pulumi strictly to Day 0 infrastructure provisioning (VPCs, IAM, cluster creation) while delegating Day 2 workload orchestration and continuous state reconciliation natively to Kubernetes operators and in-cluster controllers.