Create DigitalOcean Kubernetes (DOKS) cluster in l5_compute

[chicks-net]

Summary

Provision a DOKS cluster in the l5_compute layer to host containerized workloads, starting with the fini-domains CoreDNS container pushed to registry.digitalocean.com/fini-domains-prod.

Specifications

Parameter	Value
Layer	l5_compute/doks-cluster/ (new Terraform module)
Region	ric1
Kubernetes version	Auto (latest stable)
HA control plane	Yes (3 nodes)
Node pool	s-2vcpu-4gb, autoscale min 2 / max 5, default 2 nodes
Container registry	Integrate existing DOC registry (fini-domains-prod) via digitalocean_container_registry data source
Maintenance window	Sunday 04:00–06:00 UTC

Resources to create

1. digitalocean_kubernetes_cluster — primary cluster resource with HA control plane, autoscaling node pool, and maintenance window policy
2. digitalocean_container_registry data source — to reference the existing fini-domains-prod registry and enable authenticated pulls from DOKS
3. Standard module files: providers.tf, main.tf, variables.tf, outputs.tf, README.md (following existing repo patterns)
4. Backend key: l5_compute/doks-cluster in the existing S3/Spaces state bucket

Cross-layer dependencies

• l1_privilege/do-spaces-keys — may need registry credentials for container pulls
• l4_data — state bucket for remote state reads

Follow-up work (separate issues)

• Kubernetes manifests / Helm chart for deploying the fini-domains CoreDNS container
• DNS records pointing to the cluster (in l6_ingress or fini-domains DNS configs)
• Monitoring / observability integration
• VPC networking integration from l2_network (if needed)

[chicks-net]

@claude if we want to test the monitoring of the DNS container with prometheus and grafana, should we create the VPC for the k8s cluster first?

[claude]

Claude finished @chicks-net's task in 55s —— View job

---

Analysis: VPC-first vs. DOKS-first for Prometheus/Grafana monitoring

• Gather context (existing networking state, compute config)
• Analyze architectural dependencies for the monitoring use case
• Provide recommendation

---

Short answer: For getting Prometheus/Grafana monitoring of the DNS container working, you do not need the VPC first. But there's a strong reason to create it first anyway.

Why VPC doesn't matter for the monitoring stack itself

Prometheus scrapes metrics from pods/services using Kubernetes-native service discovery — it talks to the API server and scrapes pods on their internal cluster network. Grafana queries Prometheus over the same cluster-internal network. None of this crosses VPC boundaries; it's all intra-cluster traffic. A custom VPC has zero effect on whether this works.

The real reason to create the VPC first anyway

DigitalOcean does not allow changing a DOKS cluster's VPC after creation. The vpc_uuid field is immutable — if you create the cluster on the default VPC and later want to put it in a custom VPC (to network it with a managed database, or to connect it to other Droplets like the existing Nagios host), you'd have to destroy and recreate the cluster.

The issue already flags VPC networking integration as a follow-up:

• VPC networking integration from l2_network (if needed)

That "if needed" will almost certainly become "needed" once you add a managed database for Prometheus's long-term storage (Thanos, Mimir, etc.) or want private connectivity to other infrastructure.

Recommendation

Create l2_network/vpc-ric1/ first — it's a 10-line resource:

resource "digitalocean_vpc" "ric1" {
  name     = "fini-ric1"
  region   = "ric1"
  ip_range = "10.10.0.0/16"
}

Then reference digitalocean_vpc.ric1.id as vpc_uuid in the DOKS cluster. This aligns with the 7-layer architecture (l2 before l5), avoids a future cluster recreation, and costs nothing extra on DigitalOcean.

The sequencing would be:

1. l2_network/vpc-ric1 — VPC (5 min)
2. l5_compute/doks-cluster — DOKS cluster referencing the VPC
3. Helm charts / manifests for CoreDNS, Prometheus, Grafana

---