feat: add support for generic ephemeral volumes

[jbunting]

Relates to #4417

Description

This feature introduces support for generic ephemeral volumes (volumeClaimTemplate) in Knative Serving, enabling users to dynamically provision per-pod storage through any Kubernetes StorageClass. This is particularly useful for workloads that need local high-performance scratch space, such as NVMe storage on cloud VMs provisioned via a local StorageClass, while retaining Knative's autoscaling capabilities.

Proposed Changes

• Add support for generic ephemeral volume type in Knative Serving
• Enable users to mount ephemeral volumes into their Knative service containers
• Add feature flag control for ephemeral volume support
• Exempt ephemeral volumes from forced readOnly defaulting and validation, matching existing behavior for emptyDir and PersistentVolumeClaim
• Add ephemeral volume field to Configuration, Revision, and Service CRD schemas

Release Note

Adding support for generic ephemeral volumes. This feature allows users to mount dynamically provisioned ephemeral volumes into their Knative service containers using volumeClaimTemplate. It enables per-pod storage provisioned through any Kubernetes StorageClass, such as local NVMe or cloud provider block storage. The feature is behind the flag `kubernetes.podspec-volumes-ephemeral`.

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: jbunting / name: Jared Bunting (1295f8e)

[knative-prow]

Welcome @jbunting! It looks like this is your first PR to knative/serving 🎉

[knative-prow]

Hi @jbunting. Thanks for your PR.

I'm waiting for a knative member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work.

Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[linkvt]

Thanks for this PR, looks great from my side but a maintainer has to give it another look :)

/ok-to-test

[codecov]

Codecov Report

❌ Patch coverage is 92.30769% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 80.20%. Comparing base (fb213e0) to head (1295f8e).
⚠️ Report is 3 commits behind head on main.

Files with missing lines	Patch %	Lines
pkg/apis/serving/v1/revision_defaults.go	0.00%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #16590      +/-   ##
==========================================
- Coverage   80.21%   80.20%   -0.01%     
==========================================
  Files         217      217              
  Lines       13545    13556      +11     
==========================================
+ Hits        10865    10873       +8     
  Misses       2318     2318              
- Partials      362      365       +3     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[linkvt]

We should probably also add a test for this new feature as there are tests in features_test.go for the other Volumes

[jbunting]

Good point, I'll add that.

[linkvt]

I just learned that we should extend the following code to get these changes instead of manually applying them:

serving/cmd/schema-tweak/overrides.go

Lines 251 to 257 in fb213e0

	}, {
	name: "csi",
	flag: config.FeaturePodSpecVolumesCSI,
	}, {
	name: "image",
	flag: config.FeaturePodSpecVolumesImage,
	}},

(CI failed for this reason)

[jbunting]

Ah, I missed that. I'll get that updated.

[jbunting]

I've added this and the related test is passing now.

[jbunting]

/retest

[jbunting]

/test all

[linkvt]

/lgtm but I'm not a maintainer who still has to review and approve

[jbunting]

/lgtm but I'm not a maintainer who still has to review and approve

Thanks for looking at it!

Is there anything else I can do to make it easier for a maintainer to look at?

[linkvt]

Not right now, it's not a completely new topic (similar logic exists for the other volume types already) so it's just about when he's finding time.

[dprotaso]

/lgtm
/approve

thanks for the contribution

What are your thoughts about allowing ephemeral volumes without the feature flag?

Generally we were cautious of volumes in the past to avoid people shooting themselves in the foot - eg. NFS volumes not handling load well when things scale up. But it's not obvious to me if that's possible with this ephemeral volumes - seems akin to emptyDir which we allow.

[knative-prow]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: dprotaso, jbunting, linkvt

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• OWNERS [dprotaso]
• pkg/apis/OWNERS [dprotaso]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[jbunting]

I'm far from an expert but I'm pretty sure that's accurate -- ephemeral volumes are pretty much akin to emptyDir. That's definitely how we use them (we just need the dirs to be created on a specific drive on the node and emptyDir doesn't give us that flexibility without a whole bunch of kubelet reconfiguration that would be bad for other reasons). So yeah, "more configurable emptyDir" seems about right to me.

That being said, I think not having it behind a feature flag makes plenty of sense. I included the feature flag because I figured following the existing pattern would be the smoothest way to contribute.

[dprotaso]

Thanks for the reply

That being said, I think not having it behind a feature flag makes plenty of sense. I included the feature flag because I figured following the existing pattern would be the smoothest way to contribute.

I say let's use the feature flag for a release or two and revisit the decision