Chart defaults set requests == limits == 500m for both. The node is at 95% of
allocatable CPU in requests while actually using about 10%, so lapi sat Pending
with Insufficient cpu. Requests dropped to 50m/100m with the limits left
generous, since appsec runs inline on every public request.
Detection is CAPI community blocklists plus AppSec inline WAF, not Envoy
access-log parsing. Enforcement is gRPC ext_authz from Envoy Gateway.
Changes from the draft that was held:
Agent disabled rather than given an empty acquisition list. Chart 0.24.0
refuses to render the DaemonSet with acquisition: [] ("No acquisition or
additionalAcquisition configured"), and with no log tailing the agent has
nothing to do. The WAF collections moved to appsec.env, where they belong,
and base-http-scenarios was dropped since it only feeds log parsing. AppSec
registers with LAPI on its own, so it works without the agent.
Bouncer values updated for chart 0.8.0 (the app already pinned 0.8.0 while the
values were written against 0.6.3). Added waf.failOpen: true, whose chart
default is false and would deny every request if AppSec were unreachable.
SecurityPolicy now targets the whole gateway-public rather than the it-tools
listener. EG v1.3.2 rejects targetRefs.sectionName on SecurityPolicy, and
targeting the HTTPRoute instead would gate LAN traffic too since public routes
also parent gateway-internal. Blanket coverage of the public gateway is what we
want anyway, and failOpen keeps a bouncer outage from taking public apps down.
envoyproxy-public.yaml is kept as documentation but not applied. EG v1.3.2
already defaults envoyService.externalTrafficPolicy to Local, verified live on
all three gateway LB services, so the real client IP already reaches Envoy.
Not wired into the envoy-gateway kustomization yet. That lands once the
bouncer is up and healthy.
Bumps every outdated image and chart except databases, which are
deliberately left on their current versions.
Applications:
authentik 2026.5.2 -> 2026.8.0 (server and worker)
immich v2.7.5 -> v3.1.0
gitea 1.25 -> 1.27.2
gotify 2.9.1 -> 3.0.0
uptime-kuma 2.2.1 -> 2.5.3
zipline 4.5.3 -> 4.7.0
outline 1.8.1 -> 1.9.2
reactive-resume v5.0 -> v5.2.8
netbootxyz nbxyz18 -> nbxyz24
bentopdf v2.8.2 -> v2.8.7
jellyfin 10.11.9 -> 10.11.11
gitea runner init busybox 1.37.0 -> 1.38.0
Infra:
kube-vip v0.9.1 -> v1.2.3
victoria-metrics-k8s-stack 0.77.0 -> 0.91.2
intel-device-plugins v0.35.0 -> v0.36.0
crowdsec-envoy-bouncer 0.6.3 -> 0.8.0
Immich v3 drops pgvecto.rs support. Verified the live database already
runs vchord 0.4.3 and pgvector 0.8.1 with no pgvecto.rs extension, both
inside the ranges v3 accepts, so no database change is required.
The victoria-metrics chart renamed defaultRules.create to
defaultRules.enabled at both the top level and per group. Migrated those
keys so the etcd, kubeScheduler, kubernetesSystemControllerManager and
kubernetesSystemScheduler exclusions keep applying. Without the rename
those groups revert to enabled and alert on control-plane components
that k3s runs embedded.
That chart also moved default rules and dashboards to a runtime sync job
instead of templating them, so ArgoCD will prune the VMRules and
dashboard ConfigMaps it currently owns and the job will recreate them.
kube-vip is not managed by ArgoCD. The manifest change is inert until
applied by hand.
Longhorn auto-creates this class when missing and it is not backed by the longhorn-storageclass ConfigMap, so it had no source of truth. Set to Retain.
Jeffrey