Kubernetes版本与API版本对应规则及升级关联问题咨询

核心绑定规则 #

Kubernetes API版本和集群服务端版本是强绑定关系，不存在脱离服务端版本独立升级API版本的可能。所有API组、对应版本的实现、启用/废弃逻辑都是直接编译在kube-apiserver组件的二进制文件里的，只有升级集群控制面的kube-apiserver版本，支持的API版本列表才会发生变化，没有单独给API打版本升级的操作入口。

Kubernetes API按照成熟度分三个等级，随版本迭代逐步推进：

• Alpha版本：命名格式为v1alphaX/v2alphaX，默认禁用，仅用于功能测试，随时可能调整或废弃，不保证兼容性
• Beta版本：命名格式为v1betaX/v2betaX，默认启用，功能经过验证，但字段可能存在调整，不会无预告直接删除
• Stable稳定版本：命名格式为vX（X为整数，核心稳定资源多为v1），长期提供兼容支持，正式生产环境推荐使用

以Kubernetes 1.22为例的默认支持API版本 #

Kubernetes每个小版本都会新增部分稳定版API、废弃/移除到期的旧版API，1.22版本默认支持的常见核心API如下：

• 核心资源组（无组名前缀）：仅v1稳定版，覆盖Pod、Service、ConfigMap、Secret、Namespace、Node等核心资源
• apps资源组：仅v1稳定版，覆盖Deployment、StatefulSet、DaemonSet、ReplicaSet等工作负载资源
• networking.k8s.io资源组：仅v1稳定版，覆盖Ingress、NetworkPolicy、IngressClass等网络资源，1.22版本正式移除了此前的v1beta1版本Ingress API
• batch资源组：同时提供v1稳定版（CronJob在1.21版本正式GA）、v1beta1兼容版，覆盖Job、CronJob等任务类资源
• rbac.authorization.k8s.io资源组：仅v1稳定版，覆盖Role、RoleBinding、ClusterRole、ClusterRoleBinding等权限资源
• admissionregistration.k8s.io、apiextensions.k8s.io资源组：仅v1稳定版，1.22版本正式移除了这两个组下的v1beta1版本API（对应Webhook配置、CRD资源）

注意：同一资源可能在同一个K8s版本中同时对应多个可用API版本，多个版本操作的是同一份后端存储的资源数据，直到旧版本被官方正式移除。

集群升级时的API版本变化逻辑 #

升级Kubernetes版本时，支持的API版本列表会随kube-apiserver版本同步变更，不存在独立于集群版本的API升级路径，实际变更遵循固定的兼容规则：

• 所有API的废弃都会提前至少2个小版本发出预告，调用即将废弃的API版本时，接口会返回明确的弃用警告，提示用户迁移到新版本
• 正式移除旧版API后，使用旧版本API路径的请求会直接报错，因此升级集群前必须检查现有资源清单、控制器调用是否还在使用即将被移除的旧API
• 不需要死记硬背每个K8s版本对应的API列表，在集群中执行kubectl api-versions命令，就能拿到当前集群实际支持的全量API版本，结果100%准确

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