Description
A GKE capture environment plus the capture that comes off it, tagged substrate: gke in the reality corpus.
GKE is the substrate most likely to break assumptions the corpus currently treats as universal: it ships its own managed collection, uses a distinct node label and taint vocabulary, has its own CNI and CSI drivers, and on Autopilot restricts what a workload can even observe. Whether the environment is Standard, Autopilot, or both is a decision this task should record with its reason rather than leave implicit.
Run k8s-monitoring against it exactly as the other captures do, so the difference in the corpus is the substrate and not the collector configuration. Capture at collector egress.
Do not correct synthkit inside this task; the deliverable is evidence.
Acceptance Criteria
- #1 A GKE environment stands up and tears down from terraform in the frozen module shape
- #2 Whether Standard, Autopilot or both are captured is decided and recorded with its reason
- #3 k8s-monitoring runs against it with the same configuration as the other captures
- #4 A capture lands in the reality corpus tagged substrate gke, with provenance
Definition of Done
- #1 terraform validate and fmt -check pass
- #2 The environment applies and destroys cleanly, verified post-destroy
- #3 A capture from the environment lands in the reality corpus with provenance and substrate tag
Implementation Notes
2026-08-30: the SOURCE CAPTURE now exists. Not ingested into the reality corpus yet, so no acceptance criterion is ticked here — this note records that the evidence-gathering half is done and where it is.
synthkit-terraform captures/rksy-20260830T190021Z.capture.json cluster rksy-gcp-gke, substrate gke, schema 2.0.0
All four signals are cleanly scoped to this one cluster and scope.not_applied is EMPTY, which was not true of any earlier capture: metrics and logs on the cloud/cluster labels, traces on resource.cluster, profiles on the cluster label. The trace and profile attributes were chosen by probing the live backend rather than assumed — an earlier version of the capture tool asserted, without ever measuring, that spans carried no cloud attribute and Pyroscope series carried neither cloud nor cluster. Both claims were false.
Proof the separation is real rather than nominal: the three per-cluster trace captures partition the estate EXACTLY. 508,276 + 605,430 + 542,419 = 1,656,125, and an unscoped capture over the identical window returns 1,656,125. Every span is in exactly one document.
READ THIS BEFORE INGESTING. A cluster-scoped metrics capture contains ZERO cloud-provider families — no aws_, azure_ or stackdriver_. That is correct behaviour, not a gap: those are ingested outside the cluster and carry a cloud label and no cluster label, so the cluster matcher excludes them. This document is per-SUBSTRATE evidence — the k8s, host and application surface — and is not a complete per-cloud capture. Do not record the absence of provider metrics as a coverage finding. Tracked as RKSY-0026.
Collector configuration, identical across all three substrates so the difference in the corpus is the substrate and not the collector: k8s-monitoring 4.5.0, default allow-lists DISABLED so the full exporter surface is present, otel-demo, and the modules/loadgen driver. Native and classic histograms both scraped and forwarded.
2026-08-31: SUPERSEDING CAPTURE. Use this one, not the 2026-08-30 file named in the previous note.
captures/rksy-20260831T102517Z.capture.json cluster rksy-gcp-gke, substrate gke, 1038 metric families, 576647 spans
Why it supersedes: yesterday’s was taken against a DESTROYED estate, reading retained data. This one is from a live estate after an ~11 hour soak, and the tool has been fixed twice since:
- the cluster-exclusion measurement now runs. It silently returned null on every cluster-scoped capture before today, so yesterday’s entries did not record that they exclude every cloud-provider family.
- the estate block now describes the SCOPE rather than the whole stack. Yesterday’s would have carried a false DECLARED_ESTATE_MISMATCH against all three clouds had the estate been live, which is precisely the provenance ambiguity that got the previous corpus input rejected.
The estate also gained real surface overnight: the chart PostgreSQL integration, and application metrics travelling BOTH the promrw and native-OTLP lanes distinguished by rksy_ingest, which is the first time a single capture holds the same instrument in both ingest shapes.
Still true, and still the thing to read before ingesting: this is cluster-scoped, so it contains ZERO aws_, azure_ or stackdriver_ families. That is correct — they are ingested outside the cluster and carry no cluster label. The document now says so itself in CLUSTER_SCOPE_EXCLUDED_FAMILIES, with the count and a per-prefix breakdown. Do not read their absence as a coverage gap.
scope.not_applied is empty and declared_observed_mismatch is null on all three of today’s per-substrate entries.
2026-09-06 per-AC evidence map: AC3 has the recorded identical collector configuration and RKSY-0025 receiver comparison. AC4 is capture-v2-a5ef809344ac23b907edd096d771ea7910b845ecbd9be68a4adcf07fb1c31967.json, source kind synthkit_terraform_capture, substrate gke, captured_on 2026-08-31. AC1 remains unproven because RKSY-0004 carries no destroy plus post-destroy sweep. AC2 remains unproven: the source has an explicit node pool, but no recorded Standard-versus-Autopilot decision with rationale was found. Remains To Do; no cloud experiment was performed.
Final reconciliation supersedes the earlier pending-validation note: synthkit-terraform just check passed at 04a228971deef87c11235ff3caddf38d64f1b86d, with hosted validate run 34028703857 successful. Validation DoD is now checked. The historical clean apply/destroy and post-destroy-sweep boundary remains open.
2026-09-06 managed lifecycle proof, via the environment repository recipes:
Scoped gcp result: standing=0 unknown=0
Apply complete! Resources: 77 added, 0 changed, 0 destroyed.
Scoped gcp result: standing=1 unknown=0
Destroy complete! Resources: 24 destroyed.
Scoped gcp result: standing=0 unknown=0Capture exit 0 after two-hour loaded soak. New capture remains a protected candidate pending exact producer/configuration routing review; existing corpus acceptance is historical and unchanged. First destroy failed role/database order and Helm timeout; recovered after dependency correction. Standard zonal GKE was selected for privileged/hostPath/hostNetwork collector parity and ephemeral cost, as documented in the environment source.