railiance-cluster/workplans/RAIL-BS-WP-0015-knative-declared-cpu-requests.md

id	type	title	domain	repo	status	flavor	owner	topic_slug	created	updated	related
RAIL-BS-WP-0015	workplan	Make the Knative installer apply rail-knative's declared CPU requests	financials	railiance-cluster	finished	implementation	codex	railiance	2026-09-21	2026-09-21	RAIL-BS-WP-0013 RAIL-KNATIVE-WP-0002

RAIL-BS-WP-0015 - Knative installer applies the declared CPU requests

On 2026-09-21 the CPU requests of six Knative Deployments were lowered live on railiance01 (ADMINISTER @ realm:kubernetes/railiance01, activation=APPROVED by the founder), to free CPU requests on a node where the identity and user-engine backups could not be scheduled. The record is the-custodian/docs/kubernetes-change-gate-decision.md. rail-knative declares the values in substrate/v1.22.0/cpu-requests.patch.yaml (RAIL-KNATIVE-WP-0002). install/knative/install.sh still applied the unpatched upstream manifests, so re-running it would have restored 300m/200m/100m and stalled the backups again.

Deployment	upstream	declared
knative-serving/activator	300m	50m
knative-serving/autoscaler	100m	30m
knative-serving/controller	100m	30m
knative-serving/webhook	100m	30m
knative-serving/net-kourier-controller	200m	30m
kourier-system/3scale-kourier-gateway	200m	50m

rail-knative's declaration, the change-gate record and the live cluster agree on all six values.

T01 - Render the upstream assets through overlays

id: RAIL-BS-WP-0015-T01
status: done
priority: high

install/knative/render.sh <dir> downloads the three upstream assets, keeps the SHA-256 check against release-lock.env, and renders with the local kubectl kustomize: crds.yaml verbatim (applied first and separately, since serving-core.yaml repeats a CRD), serving-core.rendered.yaml and kourier.rendered.yaml. The overlays in install/knative/overlays/ split rail-knative's patch file by asset (kustomize refuses a patch document with no matching resource) and keep each document as rail-knative wrote it. Only CPU requests change; memory requests and all limits stay upstream.

The kourier overlay also declares the Service as ClusterIP and pins the Envoy image from ENVOY_IMAGE. The old installer applied the upstream LoadBalancer Service and envoy:v1.37-latest, then patched both back; on a re-run that flipped the live Service and rolled the gateway twice.

T02 - install.sh and verify.sh

id: RAIL-BS-WP-0015-T02
status: done
priority: high

install.sh applies the three rendered files in the old order and keeps the two ConfigMap patches. It drops kubectl set image and the Service patch, because the render now carries both. verify.sh stays read-only and additionally checks the six CPU requests and the Envoy digest.

T03 - Offline proof and a test

id: RAIL-BS-WP-0015-T03
status: done
priority: high

tests/test_knative_render.py (in make test-unit) runs render.sh and compares every rendered object with upstream. The only differences are the six CPU requests, the Kourier Service type and the gateway image. The test also checks the CRD file's checksum, checks that verify.sh lists the same six values, and checks that the overlays match rail-knative/substrate/v1.22.0/cpu-requests.patch.yaml when rail-knative is checked out next to this repository. It skips when offline.

Read-only evidence, 2026-09-21: ssh railiance01 'kubectl diff -f -' against each rendered file.

• crds.yaml and kourier.rendered.yaml show no diff.
• serving-core.rendered.yaml shows no diff on any Deployment. It does show a diff on the webhook.serving.knative.dev and validation.webhook.serving.knative.dev webhook configurations. Their rules are filled at runtime by the Knative webhook, and the unpatched upstream file shows the same diff, so the change here did not cause it.
• For contrast, the unpatched upstream serving-core.yaml diffs the four serving Deployments back to 300m/100m.

T04 - Re-running the installer (not run)

id: RAIL-BS-WP-0015-T04
status: done
priority: medium

This session did not run the installer. The values are already live, so running the patched installer changes none of the six Deployments, the CRDs, Kourier, the Service type or the gateway image. The one exception is the two webhook configurations: apply resets them to the upstream skeleton and the Knative webhook fills them in again, exactly as any earlier re-run did. There is nothing to apply now. Any future run is ADMINISTER @ realm:kubernetes/railiance01 and needs the founder's go-ahead: install/knative/install.sh railiance01, then install/knative/verify.sh railiance01. Rollback of this change is a revert of its commit; the live values need no rollback.