net-kingdom/workplans/NK-WP-0052-wave2-resource-right-sizing.md

id	type	title	domain	repo	status	flavor	owner	topic_slug	created	updated	related	state_hub_workstream_id
NK-WP-0052	workplan	Wave-2 resource right-sizing from the 2026-10-21 allocation review	infotech	net-kingdom	finished	implementation	claude	netkingdom	2026-10-21	2026-10-21	CUST-WP-0071 RESOURCE-WP-0008	7eaae0ab-19e6-533a-b3d1-11d11fa56210

NK-WP-0052 — Wave-2 resource right-sizing from the 2026-10-21 allocation review

Receiving workplan in net-kingdom for the wave-2 request changes below. Login path for the whole fleet; apply one Deployment at a time and test sign-in after each.

Origin: the 2026-10-21 node allocation review (RESOURCE-WP-0008-T03, feeding CUST-WP-0071-T03). Per the founder's 2026-10-21 delivery interview (the-custodian/docs/decisions/2026-10-21-cust-wp-0071-delivery-interview.md) the small adjustments form wave 2: one receiving task per owner repo, applied later in a batch. Applying wave 2 needs a separate founder approval, so every cluster-write task here is a human-gated wait. This file changes no manifest.

Apply the reviewed request changes

id: NK-WP-0052-T01
status: done
priority: medium
state_hub_task_id: "a69cd984-3c32-5087-9438-913c37e309f6"

Values are pod-aggregate figures from the budget file (7-day window ending 2026-10-21T06:08Z). Limits stay unchanged unless stated.

Workload (ns/name)	Pods	CPU request	CPU limit	CPU p95/peak 7d (m)	Memory request	Memory limit	Mem p95/peak (Mi)	Throttle	Action
mfa/net-kingdom-sso-mfa	1	110m → 20m	1000m	12.2/23.1	384Mi → 272Mi	896Mi	225.6/225.8	0.049	decrease + memory down
sso/net-kingdom-sso-mfa	4	150m → 40m	1150m	22.4/34.5	256Mi → 176Mi	640Mi	140.5/179.1	0.537	decrease + review CPU limit (throttled) + memory down

Source and container detail:

• mfa/net-kingdom-sso-mfa: namespace mfa: Deployment privacyidea, container privacyidea (sso-mfa/k8s/privacyidea/deployment.yaml, 100m/256Mi) plus the remaining 10m/128Mi in the same pod (confirm which container) — split the 20m/272Mi proposal across them. Also ~5% throttling at the 500m container limit.
• sso/net-kingdom-sso-mfa: namespace sso, four Deployments: keycape (25m/32Mi, limit 200m, sso-mfa/k8s/keycape/deployment.yaml), lldap (50m/64Mi, limit 200m), authelia (50m/128Mi, limit 500m), identity-provisioner (25m/32Mi, limit 250m). 53.7% of CFS periods throttled on the login path: find the throttled container(s) and review their CPU limit independently of the request decrease.

Evidence: resource-control docs/evidence/2026-10-21-node-allocation-review/2026-10-21-node-budget.md (+ .json, commit 3d9b1bd). Rule: CPU = max(floor, p95x1.5, peakx0.5) rounded up to 5m; memory request = 7d p95 working set x1.15 (only when the change is at least 64Mi).

Steps:

1. Map the pod-aggregate proposal onto the named container(s) in the source file; where a workload has several containers or pods, split by the per-pod figures in 2026-10-21-workload-usage.json and keep the sum at the proposed value.
2. Prepare the source change as a reviewed commit (no push, no sync) and record the before values here.
3. Apply only inside the batched wave-2 rollout, after founder approval, through the owner's normal deploy path (ArgoCD sync or documented helm/kubectl apply).

Verification: kubectl -n <ns> get pod -o jsonpath='{..resources}' shows the new requests; pods Ready with no new restarts or OOMKilled over 24h; for CPU decreases the throttle ratio and request latency stay at or below the 7d baseline; node request total drops by the expected delta.

Prepared 2026-10-22 (wave-2 worker W3; no apply, cluster read-only). Live objects are client-side-applied from sso-mfa/k8s/ (plus out-of-band kubectl patch/set history); each edited file was diffed against live with kubectl diff: only resources keys change, no other drift. The factor-recovery sidecar (added by privacyidea/deploy-factor-recovery.py, not in deployment.yaml) is kept by the client-side merge and left at 10m/128Mi.

The sso row (4 pods) splits per container; the throttled pod is lldap (53.7% of CFS periods at its 200m limit; authelia/keycape/provisioner ~0%):

Container	CPU req	CPU limit	Mem req	Basis
sso/lldap	50m -> 25m	200m -> 1000m	64Mi (keep)	p95/peak 20.4/27.0m; limit rule max(2x current, 1000m)
sso/authelia	50m -> 5m	500m	128Mi -> 64Mi	p95/peak 0.5/6.0m, mem p95 50Mi
sso/keycape	25m -> 5m	200m	32Mi	p95 ~1m
sso/identity-provisioner	25m -> 5m	250m	32Mi	p95 0.5m
mfa/privacyidea (main)	100m -> 10m	500m	256Mi -> 160Mi	pod p95/peak 12.2/23.1m; now 125Mi
databases/net-kingdom-pg	100m -> 50m	1000m	256Mi (keep)	DB floor 50m

Totals: sso 150m -> 40m (as proposed); sso memory 256Mi -> 192Mi (budget 176Mi; lldap kept at 64Mi over its 59Mi p95); mfa 110m -> 20m, 384Mi -> 288Mi (budget 272Mi; sidecar untouched). net-kingdom-pg: shared_buffers unset (default 128MB) — no conflict with the unchanged 256Mi request / 1Gi limit.

Apply (local kubectl, client-side as live, one at a time): kubectl apply -f sso-mfa/k8s/{lldap,authelia,keycape,identity-provisioner}/deployment.yaml, kubectl apply -f sso-mfa/k8s/privacyidea/deployment.yaml, kubectl apply -f sso-mfa/k8s/postgresql/cluster.yaml (DB window). Impact: every Deployment is 1 replica with strategy Recreate, so each apply is a short outage of that component: authelia/lldap/keycape = SSO login path, privacyidea = MFA; net-kingdom-pg restart (CNPG single instance) takes privacyIDEA/authelia storage down briefly. Run off-peak, health-check between.

Rollback: revert the source commit and re-sync/re-apply; the before values in the table above are the rollback target. Keep before/after kubectl get -o yaml captures as the receipt.

Applied — 2026-10-22 (NK-WP-0052-T01)

Applied under the founder's wave-2 authorization (the-custodian docs/decisions/2026-10-21-cust-wp-0071-delivery-interview.md), after a full-render diff against live that showed resources only. lldap CPU limit raised to 1 core (it had been throttled); authelia, keycape, identity-provisioner and privacyIDEA right-sized; net-kingdom-pg restarted at 22:40Z at 50m and is healthy. KeyCape discovery returns 200 and the forge sign-in redirect works. Evidence: the-custodian docs/evidence/2026-10-22-wave2-apply.md.