为何cass-operator中StorageConfig卷扩容缩容及StatefulSet存储扩容存在限制

• Cassandra本身是分布式有状态数据库，数据持久化存储在本地关联的PV中，缩容操作会直接引发数据风险：目前绝大多数底层存储介质都不支持块存储缩容，即使少数存储支持，若当前节点已写入数据量大于缩容后的容量阈值，会直接导致Cassandra节点崩溃，引发数据丢失甚至集群不可用。
• 扩容限制的核心是保障集群配置一致性：cass-operator的设计逻辑要求集群内所有Cassandra节点的存储配置完全统一，如果允许单独修改单个节点的存储容量，后续新扩容的Pod或重建的Pod会继承初始StorageConfig的配置，出现配置漂移问题，导致集群节点存储能力不一致，引发数据均衡故障。
• 早期版本的Kubernetes StatefulSet本身不支持修改volumeClaimTemplate的存储规格，cass-operator作为基于StatefulSet实现的Operator，会直接拦截不符合校验规则的存储配置修改请求，避免无效操作引发的集群异常。

• 存储介质的特性限制：目前主流的块存储、本地存储方案均仅支持容量扩容，不支持缩容，若放开存储配置修改的校验，用户提交缩容请求后底层PV无法适配，会导致PVC长期处于Pending状态，关联的StatefulSet Pod无法正常启动，影响业务可用性。
• StatefulSet的核心设计目标是保障有状态应用的稳定运行：volumeClaimTemplate是StatefulSet创建PVC的统一模板，随意修改该模板的存储配置会导致同个StatefulSet管理的不同Pod关联的PVC规格不一致，违背了StatefulSet对稳定的持久化存储的设计承诺，极易引发数据库、消息队列这类有状态应用的数据不一致、节点故障等问题。
• 存储扩容操作有严格的前置依赖：要完成PVC扩容，需要对应的StorageClass开启allowVolumeExpansion参数、底层存储提供商支持扩容操作，部分场景下还需要重启Pod才能完成扩容生效，若没有前置校验直接放行配置修改，会出现大量用户配置后无法生效的问题，校验规则本质是提前拦截不符合条件的无效请求。
• 历史版本的API设计限制：Kubernetes 1.27版本才将StatefulSet原地修改volumeClaimTemplate实现存储扩容的特性升级为稳定版，更早的版本中volumeClaimTemplate的存储字段是不可变属性，直接修改会被API Server拒绝，该限制是早期版本的原生设计。

内容的提问来源于stack exchange，提问作者user9607927