K8s回滚至v1.8.12后无法识别apps/v1资源问题咨询

从你的操作流程和报错信息来看，核心问题在于etcd中存储的资源对象仍保留了apps/v1版本的API标识，但回滚后的v1.8.12集群并不支持该API版本，具体原因和解决思路如下：

为什么v1.8.12会尝试加载apps/v1的资源？ #

Kubernetes在升级过程中，会自动将现有资源对象转换为新版本集群支持的API版本进行存储。当你从v1.8.x升级到v1.9.x再到v1.10.x时，集群中的Deployment、DaemonSet、ReplicaSet等资源已经被转换并存储为apps/v1版本（该版本从v1.9开始引入）。

但Kubernetes的回滚操作不会自动将etcd中存储的资源对象转换回旧版本的API标识。当你回滚到v1.8.12时，这个版本的kube-apiserver只支持extensions/v1beta1版本的Deployment、DaemonSet等资源，完全不认识apps/v1这个API组版本，因此在尝试从etcd中读取这些资源时就会抛出“no kind xxx registered for version apps/v1”的错误。

可行的解决步骤 #

• 临时回退到v1.9.8集群：因为v1.9.x同时支持apps/v1和extensions/v1beta1版本，先重新升级回v1.9.8，确保集群能正常读取etcd中的资源。
• 将所有apps/v1版本的资源转换为extensions/v1beta1：
  1. 导出相关资源：

     # 导出kube-system下的Deployment
     kubectl get deploy -nkube-system -o yaml --export > kube-system-deploys.yaml
     # 导出所有DaemonSet
     kubectl get ds -A -o yaml --export > all-daemonsets.yaml
     # 导出所有ReplicaSet
     kubectl get rs -A -o yaml --export > all-replicasets.yaml
     

  2. 编辑导出的YAML文件，将apiVersion字段从apps/v1修改为extensions/v1beta1，同时确保资源的字段配置符合extensions/v1beta1的要求（比如Deployment的spec.selector在该版本的规则）。
  3. 删除原有资源并重新应用修改后的YAML：

     kubectl delete deploy -nkube-system $(kubectl get deploy -nkube-system -o name)
     kubectl apply -f kube-system-deploys.yaml
     # 对DaemonSet和ReplicaSet执行同样的删除-重新应用操作
     

• 再次回滚到v1.8.12：完成资源版本转换后，再执行集群回滚操作，此时kube-apiserver读取的是extensions/v1beta1版本的资源，就能正常识别和处理了。

额外提示 #

Kubernetes跨小版本回滚本身存在一定风险，尤其是涉及API版本变更的场景。建议后续回滚前，先确认etcd中存储的资源API版本是否与目标集群版本兼容，必要时提前完成资源版本的转换工作。

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