API 版本不能只看文件后缀

如果页面只写“老经典版”，却没有明确的版本号、发布日期、支持平台和升级方法，那么它只能作为宣传标签，不能作为部署依据。

若只是为了学习早期 Kubernetes 的对象模型，可以在隔离实验环境中保留“老经典版”；若是新建或改造生产系统，应先确定当前可维护版本，再根据业务依赖选择兼容方案。看到“k8s经典版（老经典版）”或“k8s经典电影版”时，最重要的问题不是名称是否好听，而是它具体对应哪个版本、由谁维护、能否升级，以及故障时能否恢复。

使用老版本前要检查的兼容关系

建议先在虚拟机或测试集群中导入旧配置，使用 kubectl apply --dry-run=server 检查🔥服务端是否🔑接受资源定义，再验证服务发现、持久化存储、Ingress、滚动更新和故障恢复。生产迁移前应准备 etcd 或发行版提供的完整备份，并确认备份确实能够恢复，而不是只保存了一份 YAML 文件。

先确认“老经典版”到底指什么

旧教程中的资源可能仍使用已经废弃的 API，例如 Deployment、Ingress 或 CronJob 的早期 ⚡API。部署前可用 kubectl api-resources 查看集群支持的资源，也可以使用 kubectl explain 检查字段定义。配置文件即使语法正确，也可能因为目标集群不再支持对应 API 而创建失败。

kubectl 是客户端，控制平面是服务端，二者不是同一个版本。客户端过新或过旧都可能造成命令行为、字段显示和认证方式差异。节点版本、容器运行时、网络插件和存储插件也需要符合该发行版的兼容范围，不能仅替换一个 Kubernetes 二进制文件就完成升级。