AKS capture environment and its first corpus capture

Description

An AKS capture environment plus the capture that comes off it, tagged substrate: aks in the reality corpus.

AKS is expected to diverge from EKS in the places synthkit already models: node resource-group naming and the kubernetes.azure.com/* node label set, Azure CNI or overlay networking metrics, the Azure Disk and File CSI drivers, and a control plane whose scrapeable surface differs from EKS. None of that is currently evidence in the corpus, so synthkit’s k8s shapes are only verified against one cloud.

Run k8s-monitoring against it exactly as the EKS and k3d captures do, so the difference in the resulting corpus is the substrate and not the collector configuration. Capture at collector egress, per the standing rule.

Do not correct synthkit inside this task. The deliverable is evidence; what the evidence proves about synthkit’s emissions is reconciliation work.

Acceptance Criteria

• #1 An AKS environment stands up and tears down from terraform in the frozen module shape
• #2 k8s-monitoring runs against it with the same configuration as the EKS and k3d captures
• #3 A capture lands in the reality corpus tagged substrate aks, with provenance
• #4 Where AKS diverges from EKS is recorded as findings, not silently reconciled in this task

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-20260830T182838Z.capture.json cluster rksy-azure-aks, substrate aks, 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-20260831T102333Z.capture.json cluster rksy-azure-aks, substrate aks, 1433 metric families, 651296 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: AC2 has the recorded identical collector configuration and byte-identical receiver evidence in RKSY-0025. AC3 is capture-v2-173dc9fdcf828762cecb8d089e0745c7a20416f42ffbea317ce41641be5c81db.json, source kind synthkit_terraform_capture, substrate aks, captured_on 2026-08-31. AC4 is RKSY-0025 (cloud detector asymmetry), RKSY-0026 (scope exclusions), and RKSY-0027 (ingest-path metadata). AC1 remains unchecked: RKSY-0003 Done contains no pasted destroy plus post-destroy sweep. Captures prove observations, not teardown. Remains To Do.

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 azure result: standing=0 unknown=0
Apply complete! Resources: 60 added, 0 changed, 0 destroyed.
Scoped azure result: standing=0 unknown=0
azure directory: owned application deleted; application=0 service_principal=0
Destroy complete! Resources: 0 destroyed.
Scoped azure result: standing=0 unknown=0

Capture 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 with directory 403; the guarded owned-application cascade recovered it, with both active directory objects absent.