Added
- The three upstream lines at their decoupled releases: kagent
1.0.0, Substrate1.0.0, agentgateway2.0.0under its nested names (giantswarm/agent-platform#608; epic giantswarm/giantswarm#37705). The lines release stable semver of their own, decoupled from the upstream versions theirFORK.mds record, and publish nothing more under the formervX.Y.Z-gs.Nscheme.components.kagent*.versionRangeandcomponents.substrate*.versionRangeare>=1.0.0 <1.1.0; both charts name the agentgateway line’s2.0.0in full —agentgateway.controller.imagegiantswarm/agentgateway-upstream/controller:2.0.0,agentgateway.proxy.imagegiantswarm/agentgateway-upstream/agentgateway:2.0.0,substrate.images.agentgatewaythe same data plane for Substrate’s egress gateway — so the packaging chart’s defaults cannot move the images (a value wins over a chart default, and a default that moved alone to the nested names rendered a tag that existed only there);components.agentgateway.versionRangeis>=2.2.2 <3.0.0, the packaging release that renders a bare tag as written. The range shape follows the scheme — a patch of a line never changes a runtime contract, a re-pin onto another upstream release is at least a minor — soagent-platform.substrate.validateRangeadmits an exact version or>=X.Y.Z <X.(Y+1).0and refuses a-0bound (Flux’s Masterminds semver skips prereleases while no bound of a range carries one and evaluates them all once one does, so<1.1.0-0would have put every installation on the line’s newest dev build) and the former>=X.Y.Z-gs.N <X.Y.(Z+1)-0,agent-platform.substrate.workerPoolSpreadFlooris1.0.0,examples/customer-bom.yamlpins1.0.0and2.2.2, and the verify scripts’ fixtures move to the stable shapes. UPGRADE.md names the operator’s part.\n\n- The kagent line’s and the Substrate line’s charts come from gsoci; the lines move tov0.11.0-gs.22andv0.0.30-gs.5(giantswarm/agent-platform#580; epic giantswarm/giantswarm#37853). The two lines publish natively to the org’s registry from CircleCI — the multi-arch images and the charts, signed with the Giant Swarm identity, releases and dev builds alike — socomponents.kagent.repositoryandcomponents.kagent-crds.repositoryareoci://gsoci.azurecr.io/giantswarm/kagent/helm,components.substrate.repositoryandcomponents.substrate-crds.repositoryareoci://gsoci.azurecr.io/giantswarm/substrate/helm. The Substrate floor moves to0.0.30-gs.5— the line’s first release published there, the patches of gs.4 — incomponents.substrate*.versionRange(>=0.0.30-gs.5 <0.0.31-0), the BOM pin and, derived from it, the kagent WorkerPool’s worker image, so the atelet and the worker are one native, signed release and nothing of the line depends on a copy. The kagent floor moves to0.11.0-gs.22the same way (components.kagent*.versionRange>=0.11.0-gs.22 <0.11.1-0, the BOM pin): the chart paths on gsoci begin with each line’s first native release — the older releases exist there as retagger’s image copies only, no charts — and the kagent chart’s stamped digests of its Go ADK and Claude harness images resolve on gsoci from that release on. With the charts the last ghcr.io reference of the two lines goes: a default installation pulls everything of kagent and Substrate from gsoci, and the dev channel (acomponents.<name>.semverFilteron the lines’-dev.giantswarm.builds) needs no registry override any more —kagent.registryandsubstrate.image.registrystay on their defaults (README “Dev channel”).make verify-imagestolerates the two lines by name no longer; the upstream CloudNativePG chart is the one pending entry left, behind a Giant Swarm wrapper release on the same operator line.verify-componentsandverify-kagent-wiringassert the new sources;verify-targetholds them on both sides of the golden comparison untilorigin/maincarries them. UPGRADE.md. - An Overview board, the entry point of the platform’s Grafana folder (giantswarm/giantswarm#36711).
dashboardsin both charts renders one ConfigMap per JSON under the connectivity chart’sdashboards/directory, discovered by observability-operator throughapp.giantswarm.io/kind: dashboardand placed by the organization and folder annotations (both values carry a space, so neither can be a label). It shipsoverview.json, uidagent-platform-overview, inShared Org / Agent Platform: what the platform is and which board covers what; component health; what it is doing; and the Postgres and Valkey rows, which have no board of their own. Every health panel reads the same series as the alert that pages for it —gotk_resource_info,kube_deployment_status_replicas_available,muster_mcpserver_state,kube_cnpg_cluster_info,kube_pod_container_status_restarts_total,muster_session_store_backend,redis_memory_used_bytes— so a panel and a page cannot disagree. Today the six alerts ofagent-platform.rules.ymlhand on-call a runbook and no graph. The ConfigMaps render under the resolvedglobal.observability.metrics.serviceMonitor.enabled: the operator that picks them up is part of the observability platform the monitors write to. A component’s own board still comes from its own chart. The Postgres and the Valkey row, and the six agentgateway panels of the “what it is doing” row, are gated on the series they read: each one repeats over a hiddenlabel_values(<metric>, __name__)variable, which yields one value while the metric exists and none while it does not, so an installation that runs neither CloudNativePG nor Valkey nor the agentgateway data plane opens the board without a row of “No data”. A component that is on but not yet scraped is hidden the same way, which a Helm conditional oncomponents.<name>.enabledcould not do.
Changed
- The mcp-kubernetes chart’s own ServiceMonitor and its three Grafana boards are on (giantswarm/giantswarm#36711). The chart ships a ServiceMonitor over the dedicated metrics port and the boards
administrator,securityandcluster-operator, and this chart turned none of them on, so an installation that runs the Kubernetes MCP server collected nothing from it.mcp-kubernetes.mcpKubernetes.instrumentation.serviceMonitor.enabledandmcp-kubernetes.grafanaDashboards.enabledfollow the resolvedglobal.observability.metrics.serviceMonitor.enabled(auto | true | false), the monitor carriesobservability.giantswarm.io/tenant, and the boards land inShared Org / Agent Platformbeside the platform’s own. The chart’sprometheusRulesstay off: its three alerts link to runbook pages that do not exist yet. The floor1.1.1already carries every key, so no range moves. - Every agent platform dashboard lands in one folder customers can reach:
Shared Org / Agent Platform(giantswarm/giantswarm#36711). The muster board (Muster / MCP Gateway) was loaded into the staff-onlyGiant Swarmorganization, in a folder named after the component, so the people who run agents on the platform could not see it:muster.observability.grafanaDashboard.folderisAgent Platformand.giantswarm.organizationisShared Org.Shared Orgis the organization every logged-in customer reaches as a Viewer and it carries the observability data of Giant Swarm managed components, which is where these boards belong; theGiant Swarmorganization is staff-only. The boards that follow — the agentgateway gateway board, the platform’s own overview — land in the same folder.