通常情况下，安装了认证的Kubernetes发行版后，是否会自动设置一个默认的存储类(可能基于环境)?
我已经提交了#68949,但在上述背景下，我想知道默认存储类的存在是否应该总是被假设。

我认为我们不能要求所有的发行版都提供一个默认的存储类，但是，我们正在考虑一个包含存储测试的可选一致性配置文件。预计符合一致性配置文件的发行版必须在开箱即用的情况下提供一个不需要用户配置的默认存储类。

/cc

/area conformance

问题在90天不活跃后过期。
使用 /remove-lifecycle stale 将问题标记为新鲜。
过期的问题在30天不活跃后开始腐烂并最终关闭。
如果现在可以安全地关闭此问题，请使用 /close 进行操作。
向 sig-testing, kubernetes/test-infra 和/或 fejta 发送反馈。
生命周期：过期

/remove-lifecycle stale
/lifecycle frozen

因此，一致性测试有一个限制，即它们需要被定义为单独的测试用例，而不是作为框架的一部分。例如，ConformanceIt() 无法与当前的存储测试框架一起使用，因为对于插件特定的测试，运行相同的It()。
我可以看到两种解决方法：

1. 定义一个新的StorageConformanceIt(),只有在驱动程序类型为"default storageclass"时才能应用一致性标签。
2. 为默认存储类测试定义单独的套件，并重构测试用例以便共享测试用例代码。只有It()的定义被复制。

同时，让我们开始添加使用默认存储类的潜在测试用例。我认为这些将是很好的起点：

• Pod 可以挂载并读写到一个卷
• 同一个Pod中的两个容器可以读写该卷
• 数据在Pod重启时持久化
• 有状态集Pod可以读写多个卷：https://sourcegraph.com/github.com/kubernetes/kubernetes/-/blob/test/e2e/storage/persistent_volumes.go#L309
• 在Pod正在使用PVC时不删除PVC:https://sourcegraph.com/github.com/kubernetes/kubernetes/-/blob/test/e2e/storage/pvc_protection.go#L33
• 在仍然绑定到PVC时不删除PV:https://sourcegraph.com/github.com/kubernetes/kubernetes/-/blob/test/e2e/storage/pv_protection.go#L36

前两个案例可能利用了第三个测试用例正在使用的相同功能。我们也应该将其作为这项工作的一部分来解决：#68949