kubernetes基础-GVR和GVK

初步认识 kubernetes 的 api 基础结构，GVR 和 GVK.

理解 GVK 和 GVR

• GVK 就是 group、verison、kind

• GVR 就是 group、version、resource

Group

在 kubernetes 对资源进行分组时，对应的数据结构就是 Group，源码路径：k8s.io/apimachinery/pkg/apis/meta/v1/types.go ，如下，可见 Group 有自己的名称和版本：

1
2
3
4
5
6
7

type APIGroup struct {
	TypeMeta `json:",inline"`
	Name string `json:"name" protobuf:"bytes,1,opt,name=name"`
	Versions []GroupVersionForDiscovery `json:"versions" protobuf:"bytes,2,rep,name=versions"`
	PreferredVersion GroupVersionForDiscovery `json:"preferredVersion,omitempty" protobuf:"bytes,3,opt,name=preferredVersion"`
	ServerAddressByClientCIDRs []ServerAddressByClientCIDR `json:"serverAddressByClientCIDRs,omitempty" protobuf:"bytes,4,rep,name=serverAddressByClientCIDRs"`
}

在 kubernetes 中有两种资源组：有组名资源组和无组名资源组(也叫核心资源组Core Groups)，它们都很常见

deployment 有组名，pod 没有组名，咱们把它俩的 OpenAPI 放在一起对比就一目了然了

有组名资源组

有组名资源组 api 是复数的 apis，紧跟着后面的 apps 是组名， v1 是版本， deployments 是资源

无组名资源组

有组名资源组 api 是单数的 api，后面没有组名， v1 是版本， pods 是资源

Version

这个好理解，kubernetes 的版本分为三种：

• Alpha：内部测试版本，如 v1alpha1

• Beta：经历了官方和社区测试的相对稳定版，如 v1beta1

• Stable：正式发布版，如 v1、v2

在 Kubernetes 中，一个资源可能对应多个 Version，也可能对应多个 Group，因此通常使用GVK或GVR来区别特定的 Kubernetes 资源。

Resource

1. Resource 资源在 kubernetes 中的重要性是不言而喻的，常见的资源如：pods、services、deployments

2. 在 kubernetes 环境被实例化的资源即资源对象(ResourceObject)

3. 资源被分为持久性（Persistent Entity）和非持久性（Ephemeral Entity），持久性如 deployment，创建后会在etcd保存，非持久性如 pod.

Kind

Kind 是 API 顶级资源对象的类型，每个资源对象都需要 Kind 来区分它自身代表的资源类型

一般来说，在 kubernetes API 中有三种不同的 Kind：

• 单个资源对象的类型，最典型的就是刚才例子中提到的 Pod

• 资源对象的列表类型，例如 PodList 以及 NodeList 等

• 特殊类型以及非持久化操作的类型，很多这种类型的资源是 subresource， 例如用于绑定资源的 /binding、更新资源状态的 /status 以及读写资源实例数量的 /scale

GVK 和 GVR 的区别

简单通俗点来讲：Kind 就是我们的资源种类，如 Pod、Deployment 等，Resource 是 Kind 资源种类的资源子类，如：pods、services、deployments

二者有如下区别与联系：

1. GVR 与 HTTP 请求里的 PATH 对应，查询Pod的请求GET /api/v1/namespaces/{namespace}/pods就是一个 GVR。GVK 与存储在 ETCD 中的 Object 类型对应。

2. GVR 与 GVK 通过REST映射可进行转化。

使用客户端工具如 kubectl、clientSet、curl 时，首先会根据 GVR 生成请求，然后 Kubernetes API Server 会查询 HTTP PATH 对应的 Resource 是否支持，并与 ETCD 进行交互。

当 API Server 不支持该 Resource 时，Kubernetes 会报错the server doesn’t have a resource type “…”，使用 kubectl api-resources 命令可查看支持的 Resource。

官方 API 文档

在实际学习和开发中，对指定资源做增删改查操作时，官方文档是我们最可靠的依赖.