AWS EKS中关于弃用的kubernetes.io/aws-ebs StorageClass的移除、默认设置及升级影响咨询

嗨，针对你在AWS EKS里遇到的旧有AWS EBS存储类相关问题，我来给你梳理下关键的实操建议和知识点：

一、是否应该切换默认存储类/移除旧的in-tree存储类？ #

答案是非常推荐切换到CSI驱动的存储类作为默认，不建议直接删除旧的存储类，而是分阶段过渡：

1. 官方已经明确标记kubernetes.io/aws-ebs为弃用，后续Kubernetes版本会逐步移除in-tree驱动的支持，CSI驱动是未来的标准方案，功能更丰富（比如快照、卷克隆、多AZ卷调度优化等），也更贴合AWS的最新存储特性。
2. 操作步骤建议：
   • 先将你的CSI存储类ebs-generic设为默认，同时取消旧gp2的默认标记：

     # 标记CSI存储类为默认
     kubectl patch storageclass ebs-generic -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'
     # 取消旧存储类的默认标记
     kubectl patch storageclass gp2 -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"false"}}}'
     

   • 先保留旧的gp2存储类，因为现有已经创建的PVC/PV是关联旧存储类的，删除旧存储类不会影响已有的卷，但如果有应用还显式指定使用gp2存储类来创建新卷，就会报错。
   • 等你确认所有新的PVC都使用了CSI存储类，且没有应用再依赖旧存储类的名称后，再考虑删除旧的gp2存储类。
   • 可以用这条命令快速查看所有PVC关联的存储类：

     kubectl get pvc -A -o=jsonpath='{range .items[*]}{.metadata.namespace}{"\t"}{.metadata.name}{"\t"}{.spec.storageClassName}{"\n"}'
     

二、EKS升级会不会重新创建旧的存储类？ #

是的，AWS EKS在集群升级（甚至部分版本的补丁更新）时，会重新创建默认的gp2（或新集群的gp3）in-tree存储类，并且可能会再次将它设为默认。

应对方案：

• 简单方式：每次升级后手动重新执行前面的patch命令，调整默认存储类；
• 自动化方式：用GitOps工具（比如Argo CD）或者EKS Addon的自定义配置，将存储类的配置作为集群的基础设施代码进行管理，确保集群启动或升级后自动应用正确的存储类设置，覆盖默认的in-tree存储类配置。

三、这么做是否合理？ #

完全合理！切换到CSI驱动的存储类是符合Kubernetes生态发展趋势的必要操作：

• in-tree驱动已经进入弃用生命周期，后续Kubernetes版本会彻底移除相关代码，届时依赖它的应用将无法创建新的EBS卷；
• CSI驱动提供了更强大的功能和更好的性能，比如支持EBS快照、卷克隆、动态调整卷大小（你可以给ebs-generic开启ALLOWVOLUMEEXPANSION: true来支持这个功能），以及更灵活的调度策略；
• 过渡阶段的操作成本很低，只要做好兼容性验证，不会对现有业务造成影响。

备注：内容来源于stack exchange，提问作者ipeacocks