v1.6.0-rc.1 on GKE: two-chart install, DisaggregatedSet roll-up, steady-state cost

Date: 2026-10-16, 17:42–18:09 UTC. Cluster: GKE gke-agent-authority-test (project scc-manual-testing-7, zone us-central1-a), two e2-medium nodes, no GPUs, found with no Helm releases and only a KServe CRD installed. Artifacts: the published v1.6.0-rc.1 prerelease — image sha256:79c160eb04785ef2ec6aa12e64c13e16c9d0c1c95f080ec33f3e0447cd81686f, charts k8s-aibom and k8s-aibom-crds at 1.6.0-rc.1 from oci://ghcr.io/googlecloudplatform/charts. Method as in v1.5.1: client-side attribution from the controller’s own counters over kubectl port-forward; the cluster was restored to as-found at the end.

Release artifacts (verified before touching the cluster)

Check	Result
GitHub prerelease assets	14, including five *.intoto.jsonl bundles: image provenance, image SBOM attestation, chart provenance, CRDs-chart provenance, plugin provenance
gh attestation verify kubectl-aibom_v1.6.0-rc.1_darwin_arm64.tar.gz --owner GoogleCloudPlatform --bundle kubectl-aibom_v1.6.0-rc.1.provenance.intoto.jsonl	succeeded (offline, from release assets alone)
gh attestation verify oci://…k8s-aibom@sha256:79c160eb… --owner GoogleCloudPlatform	succeeded
Plugin archive checksum vs kubectl-aibom_checksums.txt; binary runs	match; prints usage
Anonymous pull of charts/k8s-aibom, charts/k8s-aibom-crds, image	all HTTP 200: the new CRDs-chart package was public without a manual step
install.yaml	two CRDs, image digest-pinned

Timeline

UTC	Step	Result
17:42	helm install k8s-aibom-crds then helm install k8s-aibom (metrics.enabled=true), both --version 1.6.0-rc.1	CRDs carry app.kubernetes.io/managed-by=Helm and helm.sh/resource-policy=keep; main chart installed over them without conflict; Deployment Available; AIBOMControllerConfig/default Ready=True, Degraded=False
17:44	Opt in namespace rc-walk; apply a vLLM Deployment (vllm/vllm-openai:v0.6.3, --model Qwen/Qwen3-0.6B) and an nginx control, both pinned to a non-existent node so no image is pulled	one AIBOM: runtime vllm v0.6.3 inferred, model Qwen/Qwen3-0.6B declared from container_arg; none for the control
17:45	Install kubernetes-sigs/lws v0.11.1 from its official release manifest (real CRDs and controller)	three CRDs served; controller needed replicas: 1 and cpu: 50m to schedule on e2-medium (test-only sizing)
17:47	kubectl rollout restart of the controller (a CRD installed after start needs a restart, as documented)	supervisor logs watch healthy for DisaggregatedSet, LeaderWorkerSet, InferenceService; Dynamo and NIMService logged CRD not found; skipping watch; the existing AIBOM survived the restart; config green
17:49	Apply a wide-EP-shaped DisaggregatedSet (prefill and decode roles, size 1, replicas 1, vllm/vllm-openai:v0.11.0, --model deepseek-ai/DeepSeek-R1-0528)	lws created two LeaderWorkerSets (controller-owned by the set) and two StatefulSets (owned by the LWS). One AIBOM for the set; none for the LWS or StatefulSets
17:51–18:06	Steady-state window, 940 s	see below
18:07	Delete the DisaggregatedSet	its AIBOM removed with it (owner reference); the lws objects garbage-collected
18:08	helm uninstall both releases	no Deployment, RBAC, ServiceAccount or AIBOMControllerConfig left; CRDs retained by the keep policy (by design); the namespace’s default ServiceAccount is the only object remaining
18:09	Delete the two CRDs, the lws manifest, the walk namespaces	as-found: only the pre-existing KServe CRD; no Helm releases

The DisaggregatedSet document, as served

Root component wide-ep-walk with aibom.rollup.owned.0..3 = LeaderWorkerSet/wide-ep-walk-0-…-decode, LeaderWorkerSet/…-prefill, StatefulSet/…-decode, StatefulSet/…-prefill. Six components: per role, one application vllm v0.11.0 (inferred, locator spec.roles[i].spec.leaderWorkerTemplate.workerTemplate.spec.containers[0].image with the matching pattern recorded), one container carrying disaggregatedset.role, lws.role: worker, lws.size: 1, lws.replicas: 1, disaggregatedset.slices: 1 (defaulted by lws), and one machine-learning-model deepseek-ai/DeepSeek-R1-0528 (declared, locator …containers[0].args[0 1](--model)). Pods never ran, so no digests, as expected on a GPU-less cluster.

Steady state, v1.6.0-rc.1

Controller with default values plus metrics.enabled=true, three supervised third-party kinds present (KServe, LeaderWorkerSet, DisaggregatedSet), two tracked workloads with documents, four rolled-up workloads. Attributed client-side over 940 s:

Counter	Delta	Rate
rest_client_requests_total GET 200	51	3.26 requests/minute
rest_client_requests_total PUT 200	1	one status refresh
controller_runtime_reconcile_total	2 (Deployment controller)	a pod-status event on the Pending fixture
process_cpu_seconds_total	2.55 cpu-s	2.7 mCPU average
memory	—	24 Mi working set (kubectl top) / 70 Mi RSS

Against v1.5.1’s 0.96 requests/minute with apps/v1 kinds only: the difference is the Design 004 supervisor’s liveness probe, one Limit: 1 list per present third-party kind every two minutes (three kinds here: about 1.5 requests/minute), plus the watch re-establishments of the additional informers (per-kind caches for the three kinds, CronJob, Grove-style intermediates). This matches the CHANGELOG’s stated cost (“about one request per minute on top” for AICR’s two kinds) and is independent of workload count. No writes at steady state beyond the single status refresh.

Not exercised here

Dynamo and NIMService (CRDs absent; covered by envtest and by NVIDIA’s requalification run), GPU pods and therefore digest resolution for the set, and the upgrade path from a pre-1.6 install (the cluster was clean; the CRDs-chart adoption step in charts/k8s-aibom-crds/README.md is covered by the chart’s documentation and the kind job’s two-chart order, not by this walk).