agent-platform release v4.58.2

Changed

• The kagent controller’s memory limit is 1536Mi, and its VPA can recommend up to 1280Mi: kagent.controller.resources, kagent.controller.vpa.maxAllowed.memory (giantswarm/agent-platform#455 follow-up). The meta chart sets the controller’s resources to the kagent chart’s defaults with the memory limit raised from 512Mi, and the VPA’s memory cap moves from 480Mi to 1280Mi in both charts. make verify-kagent-vpa asserts the limits on the kagent release and the new cap. UPGRADE.md.

Fixed

• The agentgateway data plane declares cpu and memory on both sides of its budget, so CPU_LIMIT is the pod’s and not the node’s (giantswarm/agent-platform#629, mechanism corrected in #631). gateway.parameters.dataPlaneResources carried an ephemeral-storage request and limit only — the pair the require-emptydir-requests-and-limits Kyverno policy needs for the writable /tmp emptyDir the controller injects. The container’s cpu and memory requests came from the agentgateway controller’s own defaults (100m / 128Mi, merged in under the container’s name), and it had no cpu or memory limit at all. The cpu limit is load-bearing beyond capping the container: the generated pod carries CPU_LIMIT as a resourceFieldRef on this container’s own limits.cpu (divisor: 1), and a resourceFieldRef against an unset limit resolves to the node’s allocatable capacity, not the pod’s budget — so the data plane sized its worker threads for whatever node it landed on. On gazelle, a 3.4 CPU node gave CPU_LIMIT 4; it is now 2. The block declares requests cpu 100m / memory 128Mi (what the controller already injected, so the render of the requests is unchanged — stated here so the whole budget is in one place and a controller default change on an agentgateway bump cannot move it) and limits cpu 2000m / memory 512Mi, the ephemeral-storage pair unchanged. limits.cpu is read as whole cores rounded up, so the value IS what the proxy sees. The memory limit feeds no env var — the data plane is Rust, and the pod carries no GOMEMLIMIT/GOMAXPROCS — so it is a plain cgroup ceiling; 512Mi is roughly 15x the working set measured on gazelle (12-33 MiB across both replicas). Both charts carry the block: the meta chart forwards its whole values tree to the connectivity release and a forwarded copy of a default shadows the child’s, so a connectivity-only default would never have reached an installation (the #303 shape, and #522 again). make verify-dataplane-ha asserts cpu, memory and ephemeral-storage on each side of the rendered container’s budget — each side cut out on its own, because a grep window over limits: runs on into requests: and passes a container that has no limit at all — that an installation’s own limits reach the container in millicores, and that the meta chart forwards the two limits; tests/verify-mirrored-values.py holds all six leaves equal between the two charts, so the budget cannot drift the way the egress lists did. Every installation gets a data-plane pod roll. The PodDisruptionBudget does not cover it — a budget governs evictions, not a Deployment’s own rolling update — and the AgentgatewayParameters sets no strategy, so the roll runs at whatever the agentgateway controller defaults to across the two replicas.