关于Kubernetes Core API组归属、版本化与弃用政策的咨询

1. Core API与命名API组的归属问题 #

• Core API属于API组，它是一种特殊的核心（Legacy）API组，和apps、batch这类命名API组的区别在于：Core组的API路径不带组名标识，直接用版本号（比如/api/v1），而命名API组的路径会明确带上组名（比如/apis/apps/v1、/apis/batch/v1）。
• apps、batch这类完全属于命名API组，是Kubernetes为分类管理不同功能模块资源设计的正式API组。

2. Core API的版本规则与版本化范围问题 #

Core API是否默认视为稳定版本？ #

大部分Core API的v1版本是稳定版，比如Pod、Service、ConfigMap这类核心资源，从Kubernetes 1.0起就以v1稳定发布。不过早期Core组也存在过alpha/beta版本的资源（比如PersistentVolumeClaim曾有v1beta1版本），这些版本后来都演进到了稳定的v1。

Core API是否适用命名API组的相同规则？ #

基本适用。Core组资源同样遵循「Alpha→Beta→Stable」的版本演进流程，弃用规则也和命名组一致：只有在Kubernetes大版本发布时才会移除已弃用的API版本，不会在小版本中突然移除。

是否有Core API已被弃用？ #

有，典型例子包括：

• PodSecurityPolicy：属于Core相关组（曾在policy/v1beta1、policy/v1），在Kubernetes 1.21版本被标记为弃用，1.25版本完全移除。
• 早期Core组的v1beta1版本资源：比如PersistentVolumeClaim的v1beta1、StorageClass的v1beta1，这些版本早已被稳定的v1版本取代并弃用。

API版本化是否仅适用于命名组？ #

不是。Core组同样支持版本化，早期Kubernetes中Core组存在过v1alpha1、v1beta1等预发布版本的资源，只是随着项目成熟，大部分Core资源都演进到了稳定的v1版本，现在较少看到Core组的预发布版本，但版本化机制本身对Core组和命名组都适用。

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