railiance-cluster/workplans/RCLUSTER-WP-0020-node-budget-knative-caps-and-wave2-allocation.md

id	type	title	domain	repo	status	owner	topic_slug	created	updated	flavor	depends_on	related	state_hub_workstream_id
RCLUSTER-WP-0020	workplan	Receive the 2026-10-21 node budget: Knative HPA caps/requests and wave-2 allocation	financials	railiance-cluster	active	claude	railiance	2026-10-21	2026-10-21	implementation		CUST-WP-0071 RESOURCE-WP-0008 RAIL-KNATIVE-WP-0003	566eed01-9db4-5984-8e3d-3c8dec4ed7fb

RCLUSTER-WP-0020 - Receive the 2026-10-21 node budget

resource-control's node allocation review of 2026-10-21 (resource-control/docs/evidence/2026-10-21-node-allocation-review.md, per-workload table in .../2026-10-21-node-allocation-review/2026-10-21-node-budget.md) reconciles railiance01 only conditionally: lean decreases accepted, releases, builds and Knative scale-out serialized, and Knative HPA ceilings capped. This plan receives the railiance-cluster parts.

T01 - Installer renders rail-knative's RAIL-KNATIVE-WP-0003 declaration

id: RCLUSTER-WP-0020-T01
status: done
priority: high
state_hub_task_id: "33675677-b46b-5909-a190-11a02194a121"

rail-knative 76cb9c7 declares 10m CPU requests for the six substrate containers (was 50/30/30/30/30/50m) and HPA maxReplicas activator 20→3, webhook 5→2, 3scale-kourier-gateway 10→3. install/knative/overlays/ now carries both (cpu-requests.patch.yaml, new hpa-caps.patch.yaml, split by upstream asset), verify.sh checks the six requests and the three ceilings, and tests/test_knative_render.py asserts the overlays, verify.sh and the rail-knative checkout agree and that the render differs from upstream only in the declared fields. A read-only render-vs-live comparison showed exactly the 9 intended fields differing. Not applied.

T02 - Attended apply and verify on railiance01

id: RCLUSTER-WP-0020-T02
status: done
priority: high
depends_on: [RCLUSTER-WP-0020-T01]
state_hub_task_id: "c9a0edd8-c8a4-5a5e-b360-05e7ffda3010"

install/knative/install.sh railiance01, then install/knative/verify.sh railiance01.

T03 - Wave-2 allocation for railiance-cluster workloads (prepare only)

id: RCLUSTER-WP-0020-T03
status: todo
priority: medium
state_hub_task_id: "5ce03eaf-a279-59ba-96b4-3bd2ca13dbad"

Receiving task for the seven railiance-cluster rows of the node budget. Requests only; limits unchanged. Locate the source of each (k3s packaged manifests / HelmChartConfig under install/, cert-manager install) before changing anything; k3s-packaged components need a HelmChartConfig or --disable + owned manifest so the change survives k3s restarts.

Workload	CPU req→prop (m)	Mem req→prop (Mi)	p95/peak CPU 7d (m)	Action
cert-manager/cainjector	0→10	0→96	1.1/2.8	increase + memory up
cert-manager/cert-manager	0→10	0→80	1.4/3.5	increase + memory up
cert-manager/webhook	0→10	0→0	0.4/0.9	increase
kube-system/coredns	100→50	70→70	7.8/10.3	decrease (DNS floor 50m)
kube-system/local-path-provisioner	0→10	0→0	0.1/0.3	increase
kube-system/metrics-server	100→10	70→70	4.9/5.1	decrease
kube-system/traefik	0→10	0→80	3.8/16.0	increase + memory up

Measurement-only items in the same task, no manifest changes yet:

• Produce a 7-day host/control-plane series (non-pod cgroup CPU/memory); the 900m host figure is a 70-second kubelet sample. Coordinate with rapp-telemetry (node-exporter is disabled, Prometheus has no non-pod series).
• kube-reserved/system-reserved (~900m/2.5Gi) are set only after the wave-2 request decreases across owners have landed; applying them first makes the current requests unschedulable.

Done when the seven request changes are declared in this repo with a render or diff proof, applied attended, and the host series plus the reserved-resources decision are recorded.

Prepared 2026-10-22 (wave-2 worker W3; no apply, cluster read-only):

• cert-manager (Helm release cert-manager rev 1, chart v1.18.2, installed by hand 2026-03-25, no prior repo source): install/cert-manager/railiance01-resources.values.yaml. Render = chart v1.18.2 + crds.enabled=true (inferred: CRDs are Helm-owned)
  • this file. kubectl diff: only the three Deployments, keys containers[].resources.requests.{cpu,memory} and one arg reorder. Drift: live controller has --acme-http01-solver-nameservers=1.1.1.1:53 patched outside Helm (order the chart cannot produce); codified as extraArgs so an upgrade keeps it. Founder decides. Apply: helm upgrade cert-manager cert-manager --repo https://charts.jetstack.io --version v1.18.2 -n cert-manager --reuse-values -f install/cert-manager/railiance01-resources.values.yaml
• traefik (k3s HelmChart, existing HelmChartConfig practice): install/traefik/railiance01-helmchartconfig.yaml gains resources.requests. Render = k3s chart traefik-38.0.201+up38.0.2 + HelmChart values + this HelmChartConfig; kubectl diff changes only Deployment traefik resources.requests.{cpu,memory}. Apply per install/traefik/README.md. Rollout: 1 replica, maxSurge 1 / maxUnavailable 0 — no ingress gap expected.
• coredns, metrics-server, local-path-provisioner (k3s Addon objects from /var/lib/rancher/k3s/server/manifests, rewritten on k3s start): install/k3s-addons/wave2-requests.py (founder-run with sudo on railiance01; dry-run diff by default, --apply writes .skip markers + edited files). Diff of the patched objectset-applied Deployments vs live: only resources.requests.cpu on the three Deployments. coredns rollout has maxUnavailable 1 with 1 replica: expect a few seconds of DNS gap; run off-peak.
• kube-reserved/system-reserved: NOT ready. Set only after the wave-2 request decreases across all owners have been applied and measured; no kubelet change made.

Applied — 2026-10-21

The installer's ssh hop cannot read the k3s kubeconfig on railiance01, so the identical render.sh output was applied with the workstation kubeconfig. Results: RAIL-KNATIVE-WP-0003-T02. Follow-up: T04.

Make the Knative installer compatible with the annotation policy

id: RCLUSTER-WP-0020-T04
status: todo
priority: medium
state_hub_task_id: "a8501cb1-5d26-529c-a6d5-28476f0c6a29"

kubectl apply of serving-core.rendered.yaml is refused for the Knative webhook certificate object by the ValidatingAdmissionPolicy reject-secret-last-applied (no last-applied annotations on that kind). Knative generates its contents at runtime. Choose one: leave it out of the render after the first install, or apply it server-side. Also make install.sh reach the cluster without the failing ssh + k3s.yaml hop, since the remote user cannot read the k3s kubeconfig.