AI Agents

  • Fixed

    • The hook Jobs are policed by the chart (giantswarm/agent-platform#413): every hook of this chart — the kagent namespace hook, the two storage-version hooks, the self hooks, the ordered teardown — runs kubectl against the apiserver under the hook identity’s pod labels (app.kubernetes.io/instance: <release>, app.kubernetes.io/component: hooks), and the chart rendered no network policy for them; on a cluster that is default-deny for every endpoint (Cilium policyEnforcementMode: always) the pre-upgrade backup hook of 4.7.13+ looped on dial tcp <apiserver>:443: i/o timeout until its deadline and every meta-chart upgrade failed — the first 4.x installation sat on 4.7.12 from 2026-09-11 23:55Z for that reason. templates/hooks/netpol.yaml renders one policy for the hook identity as a hook object (a pre-install/pre-upgrade hook runs before the release’s manifests exist): weight -10 next to the identity’s ServiceAccount and ClusterRoleBinding, the same delete policy, at all five hook events with the bundled engine and at the storage-version hooks’ four without it; egress to the apiserver only — the kube-apiserver entity in the cilium flavour, networkPolicy.kubernetes.apiServerCIDR in the kubernetes one — gated on networkPolicy.enabled and networkPolicy.flavor like every policy the platform renders. make verify-hooks-netpol asserts both flavours, the events per engine shape, the off switches and that every hook Job’s pod carries the selected labels. An installation that hand-wrote such a policy (the connectivity hooks’ sibling, #367) can drop the meta release’s copy once this release is in. No fleet installation acts — the release stays inert behind the fleet’s <4.0.0 bound.
    • The storage-version backup hook no longer lists the cluster’s Helm release Secrets with their payloads in one call (giantswarm/agent-platform#414): the re-point step (#398) fetched every helm.sh/release.v1 Secret cluster-wide through a client-side jsonpath listing — kubectl get collects the whole objects before such a printer runs — so the pod’s memory grew with the cluster’s Helm history and was OOM-killed at its 128Mi limit on the first 4.x installation (351 release Secrets, 61 MB of payload), failing the hook right after no kagent CRD stores v1alpha2: nothing to migrate. The listing is now the apiserver’s Table (kubectl get … --no-headers, names only), each Secret is read and decoded on its own onto the emptyDir as before, and jq runs only on a manifest that names kagent.dev/v1alpha2 at all (grep first) — memory bounded by the largest single release, not their sum. make verify-kagent-storage-version asserts the Table listing, the absence of a client-side printer and the pre-filter ahead of jq.
  • Added

    • The chart provisions Agent Substrate’s snapshot store on CAPA (giantswarm/agent-platform#411, giantswarm/giantswarm#37705 wave 1e): kagent.harness.snapshotStore.crossplane renders the S3 Bucket (lifecycle expiration aws.lifecycleDays, 30 days by default; public-access block; TLS-only policy; never deleted by Crossplane, kept by Helm) and the IAM Role trusted by Substrate’s atelet and ate-api-server ServiceAccounts in ate-system through the installation’s IRSA OIDC provider, the way postgres.backup.crossplane renders the kagent-pg backup bucket (the Crossplane helpers and the bucket/trust/policy partials are shared: agent-platform.crossplane.*). The meta chart derives kagent.harness.snapshotLocation = s3://<aws.bucketName>/<prefix> for the kagent release (an explicit value that differs fails the render naming both keys), holds the block back from the kagent chart (components.kagent.omitKeys takes dotted paths), and forwards the role’s ARN as eks.amazonaws.com/role-arn on the substrate release’s atelet.serviceAccount.annotations and ateApiServer.serviceAccount.annotations (Substrate 0.0.27-gs.8; a differing explicit role fails the render, an installation’s other annotations stay). Off by default; make verify-substrate-store, ci/test-substrate-store-aws-values.yaml; UPGRADE.md.
  • Fixed

    • (deps) Update module github.com/giantswarm/selfupdate-cosign to v0.2.0 in #1208 by @renovate[bot]

    Full Changelog: https://github.com/giantswarm/muster/compare/v5.18.3...v5.18.4

  • Fixed

    • (deps) Update module github.com/giantswarm/selfupdate-cosign to v0.2.0 in #480 by @renovate[bot]

    Full Changelog: https://github.com/giantswarm/klaus/compare/v0.1.12...v0.1.13

  • Fixed

    • (deps) Update module github.com/giantswarm/selfupdate-cosign to v0.2.0 in #348 by @renovate[bot]

    Full Changelog: https://github.com/giantswarm/klausctl/compare/v0.4.5...v0.4.6

  • Fixed

    • A deleted platform Harness is recreated by the kagent release on its next reconcile (giantswarm/agent-platform#409): the kagent HelmRelease carries spec.driftDetection.mode: enabled — on every reconcile (gitops.interval) helm-controller compares the release manifest with the cluster and re-applies what differs or is missing, as a server-side apply without a Helm revision. Without it a plain reconcile of the unchanged release reported “in-sync”, and the Harness a consumer skipping 4.7.19 lost on the 4.8.0 upgrade stayed deleted — every template unadmitted, 600 s observed — until a forced reconcile. components.<name>.driftDetection is a passthrough for every component entry (HelmRelease v2 spec.driftDetection: mode, ignore), set for kagent only; tests/verify-kagent-wiring.py asserts it and that no other release carries one by default, and the ATS smoke deletes the Harness and sees it back on a requested (not forced) reconcile with both templates Ready and no revision written. UPGRADE.md’s 4.8.0 note names the forced-reconcile recovery for an installation on 4.8.0 exactly; the customer BOM example pins the connectivity chart to the release it is published with.
  • Added

    • (kagent) The kagent chart names its own images — drop kagent.tag, the workerImage and Harness pins; the platform Harness is the kagent release’s; atelet’s pinned set from the chart’s ConfigMap (#406 step 3) in #408 by @teemow

    Full Changelog: https://github.com/giantswarm/agent-platform/compare/v4.7.19...v4.8.0

  • Fixed

    • (kagent) Keep the platform Harness across the 4.8.0 hand-over to the kagent release (#406 step 2) in #407 by @teemow

    Full Changelog: https://github.com/giantswarm/agent-platform/compare/v4.7.18...v4.7.19

  • Fixed

    • The substrate release pins the platform Harness’s image in atelet’s image cache, and the Substrate line re-pins to v0.0.27-gs.6 (giantswarm/giantswarm#37764; giantswarm/giantswarm#37742 rows 34 and 35): atelet’s image GC evicted every image older than two minutes on every pass while the cache volume sat above the 85 % watermark — the Harness image included — so the first turn after a few idle minutes paid a cold pull and unpack that did not fit the resume’s restore budget and failed with context canceled. The line’s sixth release (giantswarm/substrate#21, #23, #24) makes the pinned set configurable (--image-cache-pinned-images; chart atelet.imageCache.{gcPeriod,highPercent,lowPercent,minAge,maxBytes,pinnedImages}, unset by default) and raises the router’s request-parking budget to 30 s. The meta chart derives atelet.imageCache.pinnedImages for the substrate release from kagent.harness.image (agent-platform.componentDerivedValues, next to the CNPG connection Secret): the platform Harness’s digest joins whatever substrate.atelet.imageCache.pinnedImages lists — the installation’s own pins first, once each — so atelet pulls it at every GC pass and never evicts it, and a Harness re-pin moves the pinned set with it; no second copy of the digest anywhere. The other imageCache knobs stay the chart’s defaults (an installation or a lab tunes them in substrate.atelet.imageCache). components.substrate/components.substrate-crds move to >=0.0.27-gs.6 <0.0.28-0 and kagent.substrateWorkerPool.workerImage to …:0.0.27-gs.6; examples/customer-bom.yaml and tests/verify-components.py move with the pin. make verify-components asserts the derived pin (the default render, a re-pinned Harness image, an installation’s own list). An installation on the 4.x line rolls the atelet DaemonSet once (--image-cache-pinned-images=<Harness digest>) on its next reconcile; the lab proof — no Image cache evicting image record for the Harness image, the first turn after ten idle minutes completing — is the audit’s next step. No installation acts — the release stays inert behind the fleet’s <4.0.0 bound.
  • Fixed

    • The kagent line re-pins to v0.11.0-gs.4 (giantswarm/giantswarm#37763, giantswarm/giantswarm#37010): the line’s fourth release (commit ca399a3a; the upstream pin stays kagent-dev/kagent main @ 6a6b54ff) carries one more patch, giantswarm/kagent-upstream#15 — the A2A gateway fails a task whose dispatch to the AgentInstance runtime fails (a failing dial, a failing ingester start, or a runtime stream that errors before its first event) instead of leaving it TASK_STATE_SUBMITTED for good, which kept it as the instance’s active task, refused every later message as a conflict and showed every client a turn that never ends; a submitted task the runtime does not know is failed by the reconciler after the one-minute dispatch grace period. kagent.tag moves to 0.11.0-gs.4 (the controller and UI image build) and kagent.harness.image to the gs.4 Go ADK index digest sha256:6e510b241e2d000b7d10879c9fde3dd34a37879854278f0a5d386426049a88bf (meta and connectivity charts); components.kagent/components.kagent-crds keep the range >=0.11.0-gs.1 <0.11.1-0. examples/customer-bom.yaml and tests/verify-kagent-crds.py (KAGENT_LINE_REF) move with the pin. An installation on the 4.x line rolls the kagent controller, UI and the platform Harness to the new build on its next reconcile; the lab proof of the released chart is the audit’s next step (giantswarm/giantswarm#37763). make verify-wiring’s whole-render comparison against origin/main leaves image references out, so a re-pin — which moves kagent.harness.image by design — no longer trips it.