Files
home-network-k3s-impl/platform/external-snapshotter
jakman85andClaude Opus 4.8 7a79cea94a fix(flux): vendor external-snapshotter manifests locally (stop remote-base build flake)
The kustomization pulled two REMOTE github bases (?ref=v8.2.0) that Flux's kustomize-controller
git-fetched on every reconcile; those fetches intermittently exceeded the 27s timeout ->
'kustomize build failed' BuildFailed events -> the whole platform tier stalled whenever GitHub was
slow. Vendored the exact v8.2.0 output to local crds.yaml + snapshot-controller.yaml (built with
kubectl kustomize; images transformer still re-pins the controller to v8.2.0), so the build is now
offline + deterministic. No change to what's deployed. platform/kubevirt has the same latent pattern.

Co-Authored-By: Claude Opus 4.8 <[email protected]>
2026-08-31 10:54:43 -05:00
..

external-snapshotter (CSI snapshot control plane)

Installs the cluster-singleton kubernetes-csi/external-snapshotter:

  • the snapshot.storage.k8s.io CRDs — VolumeSnapshot, VolumeSnapshotContent, VolumeSnapshotClass (v1, GA);
  • the snapshot-controller Deployment (into kube-system, the upstream default) that reconciles those objects against any CSI driver's CreateSnapshot/DeleteSnapshot.

Neither k3s nor the Longhorn chart ships this. It is a prerequisite for:

  1. VolumeSnapshotClass (driver.longhorn.io) — see ../longhorn/volumesnapshotclass.yaml (applied by platform-config).
  2. CDI snapshot smart-clone — the CDI StorageProfiles set cloneStrategy: snapshot (see ../kubevirt/cdi-storageprofiles.yaml); CDI clones VM disks by taking a CSI VolumeSnapshot instead of a slow host-assisted byte copy.
  3. Clearing the CDIDefaultStorageClassDegraded alert — a default virtualization StorageClass must support both smart-clone and ReadWriteMany.

Wiring

  • Pass: platform (controllers). Registers the CRDs.
  • The VolumeSnapshotClass / StorageProfile CRs that consume the CRDs live in the platform-config pass (dependsOn: platform), per the controllers/configs split.

Version

Pinned to v8.2.0 (Renovate-maintained). The v8.x line aligned to Kubernetes 1.31 at v8.1.0; this cluster is now k3s v1.36.4, so the pin should be re-checked for 1.36 (a newer external-snapshotter line may be the version-matched choice) — do not treat v8.2.0 as verified against 1.36 yet. The snapshot-controller image is re-pinned to the same tag via the kustomization images transformer (the upstream setup manifest lags on the image tag).