GVK和GVR

一、GVK与GVR

在Kubernetes体系中，资源是最重要的概念。Kubernetes使用Group、Version、Resource、Kind来描述

Group即资源组，在kubernetes中有两种Group：有组名资源组和无组名资源组(也叫核心资源组Core Groups)。如deployment有组名，pod没有组名。核心资源组API为api/v1，非核心资源组API为/apis/group/version。
Version即版本，kubernetes的版本分为三种：
　1）Alpha：内部测试版本，如v1alpha1
　2）Beta：经历了官方和社区测试的相对稳定版，如v1beta1
　3）Stable：正式发布版，如v1、v2
在Kubernetes中，一个资源可能对应多个Version，也可能对应多个Group，因此通常使用GVK或GVR来区别特定的Kubernetes资源。二者有如下区别与联系：
　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。

二、GVR详细说明

从上一篇中的 CRD 定义中，可以发现在 Kubernetes 中要想完成一个 CRD，需要指定 group/kind 和 version，这个在 Kubernetes 的 API Server 中简称为 GVK。GVK 是定位一种类型的方式，例如，daemonsets 就是 Kubernetes 中的一种资源，当我们跟 Kubernetes 说我想要创建一个 daemonsets 的时候，kubectl 是如何知道该怎么向 API Server 发送呢？是所有的不同资源都发向同一个 URL，还是每种资源都是不同的？

这就得看回我定义 daemonsets 的描述文件了

[root@liqiang.io]# head -4 00-sample-daemonsets.yaml
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: node-exporter

这里我就声明了 apiVersion 是 apps/v1，其实就是隐含了 Group 是 apps，Version 是 v1，Kind 就是定义的 DaemonSet，而 kubectl 接收到这个声明之后，就可以根据这个声明去调用 API Server 对应的 URL 去获取信息，例如这个就是 /api/apps/v1/daemonset（kubetl 怎么知道 DaemonSet 对应的就是 daemonset？第一篇有说到）

可能到这里你已经猜到了，Kubernetes 组织资源的方式是以 REST 的 URI 的形式来的，而组织的路径就是：

额，不对，不是说是 G(roup)V(ersion)K(ind) 的吗，怎么这里又是 G(roup)V(ersion)R(ource) ？嘿，是的，这就是 API Server 中的第二个概念，GVR

三、REST Mapping

当我们要定义一个 GVR 的时候，那么怎么知道这个 GVR 是属于哪个 GVK 的呢？也就是前面说的，kubectl 是如何从 YAML 描述文件中知道该请求的是哪个 GVR URL？这就是 REST Mapping 的功能，REST Mapping 可以指定一个 GVR（例如 daemonset 的这个例子），然后它返回对应的 GVK 以及支持的操作等。

在代码中，其实就对应于这个接口

这样，就把 GVK 和 GVR 联系起来了

四、scheme

Scheme 存储了 GVK 和 Go type 的映射关系

五、API Server

既然，前面都说了，API Server 可以通过 URI 的形式访问到资源，那么这里我就来实战一下，一般来说，如果是正常安装的 Kubernetes 集群，那么肯定会有 http 证书以及认证证书，这会让我的尝试很麻烦，所以，为了去掉这重麻烦，我会通过 kubectl proxy 来代理一个本地的 API Server 端口，这样就可以绕过认证了，直接可以以 http 的形式进行

[root@liqiang.io]# kubectl proxy --port=9090
Starting to serve on 127.0.0.1:9090

然后直接访问 API Server：　

[root@liqiang.io]# GET http://127.0.0.1:9090/apis/apps/v1/daemonsets/
{
  "kind": "DaemonSetList",
  "apiVersion": "apps/v1",
  "metadata": {
    "selfLink": "/apis/apps/v1/daemonsets/",
    "resourceVersion": "209282"
  },
  "items": [
    {
      "metadata": {
        "name": "svclb-traefik",
        "namespace": "kube-system",
        "selfLink": "/apis/apps/v1/namespaces/kube-system/daemonsets/svclb-traefik",
        "uid": "bd42f48c-42de-4df6-96bd-15e56bdfaec7",
        "resourceVersion": "176921",
        "generation": 2,
... ...　　

六、核心资源

如果想看系统支持哪些 GVK，那么可以通过 kubectl 的命令查看

[root@liqiang.io]# k api-resources