参考

• K8s源码分析(3)-Resource Version

内外部版本

1 | 简介

众所周知，在 kubernetes 中所有的 resource 都是基于 group 分组的，例如 apps group 中定义了我们熟悉并常用的 deployment， statefullset， daemonset 等 resource，rbac group 中定义了我们经常用到的 role， role binding， clusterrole， clusterrolebinding 等等 resource。对于不同的 group 中的 resource 又有不同的 version，例如 apps group 中又分为 v1， v1beta1， v1beta2 等不同版本。所以在 kubernetes 中去定位一种 resource 我们就会需要 group (例如 apps)， version (例如 v1)，kind (例如 deployment)，也就是我们常常说的 GVK，如下图例。

2 | 为什么要有版本的概念

• 其实在 kubernetes 中对于 resource 之所以会有 version 的概念，是因为方便持续的渐进演化。
  • 例如一个 deployment 在 v1 里有功能 A, 那么在 v1beta1 里就可能会对功能 A 来进行 enhancement 或者去增加新功能 B， 然后在 v1beta2 中又会有更多的特性加入。
• 从设计角度上看 kubernetes 引入的 internal version 的概念，在同一个 group 之中的所有 version 的 resource 都会转化成 internal version, 然后来持久化在 etcd cluster 之中。反之从 etcd cluster 中读取数据的时候，就会从 internal version来转化成相应的对外 version，也就是如下所示：

• 引入 internal version 的概念就是希望其它所有的 version 在转化的过程中仅仅会和 internal version 产生关联依赖，不会相互关联依赖。而 internal version 并不会暴露给外面使用，完全交由 kuberbetes 研发团队来维护。如果没有 internal version 那么就需要如下图来提供所有 version 之间的相互转换，这样就极大的增加了演进的复杂度，所以并没有采用如下的设计。

3 | 不同版本所在位置

// 外部版本所在位置
kubernetes/staging/src/k8s.io/api/
// 内部版本所在位置
kubernetes/pkg/apis/

接下来我们来看一下不同 version 的 resource 都定义在什么地方：

• 对于各个资源组外部版本的定义在如下源码位置：

• 我们以 apps group 资源组为例，对于其外部版本的 resource 定义如下：

• 对于各个资源组 internal version 的定义在如下源码位置：

• 同样我们还是以 apps 资源组为例，其 internal version 的 resource 定义如下：

从源码的角度来看，我们以 apps group 中的 v1 version 的 deployment resource 为例，它在 staging/src/k8s.io/api/apps/v1/types.go 中被定义:

type Deployment struct {
  metav1.TypeMeta `json:",inline"`
  metav1.ObjectMeta `json:"metadata,omitempty" protobuf:"bytes,1,opt,name=metadata"`
  Spec DeploymentSpec `json:"spec,omitempty" protobuf:"bytes,2,opt,name=spec"`
  Status DeploymentStatus `json:"status,omitempty" protobuf:"bytes,3,opt,name=status"`
}

同样对于 apps 资源组中的 internal version 的 deployment resource 来说，它的具体定义在 /pkg/apis/apps/types.go 文件中：

type Deployment struct {
  metav1.TypeMeta
  metav1.ObjectMeta
  Spec DeploymentSpec
  Status DeploymentStatus
}