继续运行老集群前必须划清的边界

集群版本还可能与客户端版本不同。k💫ubectl 只代表客户端程序，控制平面版本才决定 API 能力，节点上的 kubelet 版本则影响节点注册、调度和工作负载运行。排查时应分别记录客户端、服务端、节点和关键插件版本。

老版本 Kubernetes 集群可以作为短期过渡环境，但不适合在没有评估的情况下长期承载新增核心业务。版本过旧后，问题通常不只表现为功能缺失，还可能表现为安全补丁不足、镜像无法拉取、加密套件不兼容和🌈新客户端无法操作。

迁移验收应覆盖用户请求、内部服务调用、持久化读写、定时任务、扩缩容、节点故障、滚动更新和日志告警。只有业务验证完成后，才能清💡理旧集群中的凭据、负载和存储资源。

为什么“经典版”不能直接当作 Kubernetes 版本

老版本 Kubernetes 集群出现故障时，排查顺序应从控制平面到节点🤔、网络、存储和业务容器逐层收窄。重复重启 kubelet、删除 Pod 或重建节点，可能暂时改变现象，却会掩盖真正原因。

从老经典版迁移到新集群的稳妥流程

旧版环境可能由 kubeadm、二进制文件🔮、脚本工具📢或厂商安装器部署。安装方式会影响证书位置、组件配置、升级路径和回滚手段，因此仅凭网页标题、登录页名称或目录名称判断版本，容易把管理面板版本误认为集群版本。

实际检查可以先执行 kubectl version、kubectl get nodes、kubectl get pods --all-namespaces 和 kubectl api-resources，随后查看控制平面组件启动参数与安装目录。命令输出应保存到独立文件，便于迁移前后对比。