---
id: RAIL-BS-WP-0015
type: workplan
title: "Make the Knative installer apply rail-knative's declared CPU requests"
domain: financials
repo: railiance-cluster
status: finished
flavor: implementation
owner: codex
topic_slug: railiance
created: "2026-09-21"
updated: "2026-09-21"
related:
  - 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

```task
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

```task
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

```task
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)

```task
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.