在上一篇文章中我们主要介绍了 kubernetes 中的 resource meta，以及相关的定义，在这里我们主要介绍 kubernetes resource 的 version。众所周知，在 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，如下图例。
其实在 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 之间的相互转换，这样就极大的增加了演进的复杂度，所以并没有采用如下的设计。
接下来我们来看一下不同 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 中被定义:
代码语言：javascript复制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 文件中：
代码语言：javascript复制type Deployment struct {
metav1.TypeMeta
metav1.ObjectMeta
Spec DeploymentSpec
Status DeploymentStatus
}从上面例子中 deployment 资源的外部版本和内部版本的定义源码看，我们发现里面都会有 type meta，object meta， spec ， status 等属性的定义，这也和以前文章中介绍的 API 与资源对象的对应关系相呼应。当然资源的 status 并不会在 API 的请求中定义的，它只会在查询 API 的响应中返回。
目前先我们写到这里，在下一篇文章中我们来介绍 kubernates resource 的 model 的定义。
