# Create cluster
resource "aws_eks_cluster" "main" {
...

The problem: You can’t create a Kubernetes cluster and then add resources to it in the same apply. Providers are configured at the root before resources exist, so you can’t use dynamic outputs (like a cluster endpoint) as provider config.

The workarounds all suck:

Two separate Terraform stacks (pain passing values across the boundary)

null_resource with local-exec kubectl hacks (no state tracking, no drift detection)

Manual two-phase applies (wait for cluster, then apply workloads)

After years of fighting this, I realized what we needed was inline per-resource connections that sidestep Terraform’s provider model entirely.

So I built a Terraform provider (k8sconnect) that does exactly that:

# Create cluster
resource "aws_eks_cluster" "main" {
name = "my-cluster"
# ...
}

resource "aws_eks_node_group" "main" {
cluster_name = aws_eks_cluster.main.name
# ...
}

# Connection can be reused across resources
locals {
cluster = {
host                   = aws_eks_cluster.main.endpoint
cluster_ca_certificate = aws_eks_cluster.main.certificate_authority[0].data
exec = {
api_version = "client.authentication.k8s.io/v1"
command     = "aws"
args        = ["eks", "get-token", "--cluster-name", aws_eks_cluster.main.name]
}
}
}

# Deploy immediately - no provider configuration needed
resource "k8sconnect_object" "app" {
yaml_body = file("app.yaml")
cluster   = local.cluster

# Ensure nodes are ready before deploying workloads
depends_on = [aws_eks_node_group.main]
}

Single apply. No provider dependency issues. Works in modules. Multi-cluster support.

Building with SSA from the ground up unlocked other fixes

Once I committed to Server-Side Apply and field ownership tracking as foundational (not bolted-on), it opened doors to solve other long-standing community pain points:

Accurate diffs - Server-side dry-run during plan shows what K8s will actually do. Field ownership tracking filters to only managed fields, eliminating false drift from HPA changing replicas, K8s adding nodePort, quantity normalization (“1Gi” vs “1073741824”), etc.

CRD + CR in same apply - Auto-retry with exponential backoff handles eventual consistency. No more time_sleep hacks. (Addresses HashiCorp #1367 - 362+ reactions)

Surgical patches - Modify EKS/GKE defaults, Helm deployments, operator-managed resources without taking full ownership. Field-level ownership transfer on destroy. (Addresses HashiCorp #723 - 675+ reactions)

Non-destructive waits - Separate wait resource means timeouts don’t taint and force recreation. Your StatefulSet/PVC won’t get destroyed just because you needed to wait longer.

YAML + validation - Strict K8s schema validation at plan time catches typos before apply (replica vs replicas, imagePullPolice vs imagePullPolicy).

Universal CRD support - Dry-run validation and field ownership work with any CRD. No waiting for provider schema updates.

What this is for

I use Flux/ArgoCD for application manifests and GitOps is the right approach for most workloads. But there’s a foundation layer that needs to exist before GitOps can take over:

The cluster itself

GitOps operators (Flux, ArgoCD)

Foundation services (external-secrets, cert-manager, reloader, reflector)

RBAC and initial namespaces

Cluster-wide policies and network configuration

These need to be deployed in the same apply that creates the cluster. That’s what this provider solves. Bootstrap your cluster with the foundation, then let GitOps handle the applications.

Links

GitHub: https://github.com/jmorris0x0/terraform-provider-k8sconnect

Registry: https://registry.terraform.io/providers/jmorris0x0/k8sconnect/latest

Examples: https://github.com/jmorris0x0/terraform-provider-k8sconnect/tree/main/examples

Looking for feedback from people who’ve hit these pain points. If the bootstrap problem, false drift, or controller coexistence has been frustrating you, I’d appreciate you giving it a try.

What pain points am I missing? What would make this more useful?