# Knative Serving installation

`install.sh` verifies repository-pinned SHA-256 checksums for the upstream
Serving and Kourier v1.22.0 assets before applying them over SSH. It is
idempotent.

It does not apply the upstream manifests as published. `render.sh` (also
usable on its own, with no cluster contact) renders them through the kustomize
overlays in `overlays/`: CRDs verbatim and first, because `serving-core.yaml`
repeats one of them; then serving-core and kourier with the CPU requests that
rail-knative declares in `substrate/v1.22.0/cpu-requests.patch.yaml`
(activator 50m, autoscaler/controller/webhook/net-kourier-controller 30m,
3scale-kourier-gateway 50m), the Kourier Service as `ClusterIP` and the Envoy
gateway image pinned to `ENVOY_IMAGE`. Memory requests and all limits stay
upstream. Applying the unpatched upstream files restores 300m/200m/100m and
exhausts railiance01's CPU requests again. `tests/test_knative_render.py`
proves the render offline and fails if these overlays drift from rail-knative's
declaration. `install.sh` needs a local `kubectl` for `kubectl kustomize`. Kourier is kept `ClusterIP`; public entry through Traefik, DNS, and
TLS requires separate reef admission evidence.

The installer enables only Knative's
`kubernetes.podspec-init-containers` feature. Production workloads use init
containers for fail-closed admission checks such as verifying that egress
policy has reconciled before application code starts.

Run `install.sh railiance01`, then `verify.sh railiance01`; `verify.sh` is
read-only and also checks the six CPU requests and the Envoy pin.

Before workload admission, rollback deletes Kourier, Serving core, then CRDs
using the same verified assets. After Knative Services exist, removal requires
a workload migration and backup review and is not unattended.