122 lines
4.7 KiB
Markdown
122 lines
4.7 KiB
Markdown
|
---
|
||
|
|
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.
|