microsoft/aspire · error · InvalidOperationException

Unsupported storage type

Error message

Unsupported storage type: {context.Parent.DefaultStorageType}

What it means

When generating pod template volumes, the Kubernetes publisher switches on the resource's DefaultStorageType. Only known storage kinds (e.g. empty-dir, PVC) are supported; any other value hits the default case and throws InvalidOperationException. This is an internal invariant guard against unrecognized storage configurations.

Solutions

Use a supported storage type for the resource's volumes (persisted volume / empty-dir as applicable).
Upgrade to the latest Aspire version where the storage type may be supported.
Remove or reconfigure the volume on the resource so DefaultStorageType falls within supported values.
If the value comes from your own resource extension, set it to a recognized storage kind.

Example fix

// before
var cache = builder.AddRedis("cache")
    .WithDataVolume(storageType: /* unsupported custom kind */);
// after
var cache = builder.AddRedis("cache")
    .WithDataVolume(); // uses a storage type the Kubernetes publisher supports

Defensive patterns

Strategy: validation

Validate before calling

var supported = new HashSet<string>(StringComparer.OrdinalIgnoreCase) { "EmptyDir", "PersistentVolume" };
if (!supported.Contains(resource.DefaultStorageType))
{
    throw new InvalidOperationException($"Storage type '{resource.DefaultStorageType}' is not supported by the Kubernetes publisher.");
}

Prevention

Only use storage types documented as supported by the Kubernetes publisher.
Pin to a supported Aspire version or upgrade when adding new volume kinds.
Check the switch in ResourceExtensions.WithPodSpecVolumes when introducing custom storage types.

When it happens

Trigger: A resource with volumes whose DefaultStorageType holds a value the Kubernetes publisher does not map, evaluated in WithPodSpecVolumes during publish.

Common situations: A newly introduced storage type not yet handled by the Kubernetes publisher; a custom resource setting DefaultStorageType to an unexpected value; version skew where hosting added a storage kind before the Kubernetes publisher supported it.

Related errors

AI-assisted analysis of microsoft/aspire@25830f84bd (2026-09-16). Data as JSON: /api/errors/a9cfe1cc34e37e6a. Report an issue: GitHub.

Appendix: source

Thrown at src/Aspire.Hosting.Kubernetes/Extensions/ResourceExtensions.cs:286

                case "pvc":
                    // Only emit a PersistentVolumeClaim — the cluster's StorageClass
                    // (named by DefaultStorageClassName or the cluster default) drives
                    // dynamic provisioning of the backing PersistentVolume. Statically
                    // pre-provisioned PVs are only emitted by the first-class
                    // KubernetesPersistentVolumeResource path above; emitting a bare PV
                    // here would be missing a PersistentVolumeSource (csi/hostPath/local
                    // /nfs/...) and would be rejected by `kubectl apply`. See
                    // https://kubernetes.io/docs/concepts/storage/persistent-volumes/#dynamic.
                    var pvc = CreatePersistentVolumeClaim(context, volume);
                    podVolume.PersistentVolumeClaim = new()
                    {
                        ClaimName = pvc.Metadata.Name,
                    };
                    break;

                default:
                    throw new InvalidOperationException($"Unsupported storage type: {context.Parent.DefaultStorageType}");
            }

            podTemplateSpec.Spec.Volumes.Add(podVolume);
        }

        return podTemplateSpec;
    }

    private static ContainerV1 ToContainerV1(this IResource resource, KubernetesResource context)
    {
        var container = new ContainerV1
        {
            Name = resource.Name,
            ImagePullPolicy = context.Parent.DefaultImagePullPolicy,
        };

        return container
            .WithContainerImage(context)

View on GitHub (pinned to 25830f84bd)