agent-platform release v4.23.0

Added

• components.gpu-operator: NVIDIA’s GPU operator as a chart component, off by default and independent of model serving (giantswarm/agent-platform#327; bumblebee-plans#46, the plan’s D3; epic giantswarm/giantswarm#37639). One OCIRepository + HelmRelease of Giant Swarm’s gpu-operator-app — the catalog’s gpu-operator wrapper chart on 1.x — into kube-system (the release history there too, so the GPU guide’s hand-installed release upgrades in place) with crds: CreateReplace, no dependsOn, gitops.target.kubeConfig.secretRef honoured. The operator’s configuration is the new gpu-operator: block, forwarded under the wrapper’s subchart key — a table of two rows and no third: Flatcar, driver and toolkit off (the default); nodes with a pre-installed driver, gpu-operator.toolkit.enabled: true. In every configuration the operator creates the nvidia RuntimeClass GPU pods use (modelServing.serving.runtimeClassName: nvidia where the platform’s own release serves), so the chart adds none. One owner per cluster: with the component on, a ClusterPolicy, HelmRelease or App of the operator that is not this release’s fails the render naming what was seen and the handover — delete cluster-manager’s <cluster>-gpu-operator (its detection then sees the component and never re-creates it) or the hand-installed release, then switch the toggle on, or leave it off; the ClusterPolicy CRD is under ownedCrds as the backstop. The default render is unchanged but for the roster entry forwarded to connectivity (components.gpu-operator.enabled: false), which make verify-target’s golden now drops as the one difference a new component is allowed. make verify-gpu-operator asserts the offline half; tests/fixtures/gpu-operator-foreign-owner.yaml shows the refusal on a cluster; examples/customer-bom.yaml pins 1.3.0. README “The GPU operator”.