深入Kubernetes内核：三大核心数据结构解密（系列开篇）

    当我们执行kubectl get pods时，可曾想过这条简单的命令背后，Kubernetes是如何精准识别并管理数百种资源类型的？答案就藏在它的三大核心数据结构中。kubectl get pods流程图如下：

从图中得知：

1.GVR是访问路径：kubectl将命令转换基为GVR的REST API请求。

2.GVK是内部标识：API Server需将GVR映射为GVK，以找到正确的资源定义（Schema）来处理请求。

3.数据持久化：最终操作的是存储在ETCD中的资源对象数据。

4.控制器模式：控制器通过Watch特定的GVR的端点来监听资源变化，并驱动系统向期望状态改变。

在云原生日常使用中，我们经常看到这样的配置：

apiVersion: apps/v1kind: Deployment

但你是否真正理解：

1)apps/v1背后的Group和Version设计哲学？

2)Deployment作为Resource在API层是如何被描述的？

3)为什么需要内外版本？

本系列将带你深入Kubernetes API Machinery的核心，从Group,Version,Resource这三大基石出发，逐步解开Kubernetes资源管理体系的神秘面纱。

如图：

1)层次结构：展示了Group->Version->Resource的从属关系

2)多版本共存：如apps组下同时存在v1和v2beta1版本，体现了API的演进和能力。

3)核心组： 想Pod这样的核心资源位于没有组名的核心组

4)内部版本：所有外部版本在API Server内部都会转换成统一的内部版本进行处理，实现了多版本兼容和稳定。

Kubernetes三大核心数据结构组成

1)Group：被称为资源组，在kubernetes API Server中也可以称其为APIGroup。

2)Version：被称为资源版本，在kubernetes API Server中也可称其为APIVersions。

3)Resource：被称为资源，在kubernetes API Server中也可称其为APIResource。

4)Kind：资源种类，描述Resource的种类，与Resource为同一级别。

kubernetes系统支持多个Group，每个Group支持多个Version，每个Version支持多个Ressource，其中部分资源同时会拥有自己的子资源（即SubResource）。例如Deployment资源拥有Status子资源。如下图：

资源组，资源版本，资源，子资源的完整表现形式为///。以常用的deployment资源为例： apps/v1/deployment/status。

另外，资源对象（Resource Object）也是一个常用概念，由"资源组+资源版本+资源种类"组成，并在实例化后表达一个资源对象，例如deployment资源实例化后拥有资源组，资源版本以及资源种类，其表现形式为/、kind=,例如apps/v1,Kind=deployment。

kubernetes支持的8中操作资源方法（verbs）

目前kubernetes支持的8中资源操作方法，分别是create，delete,deletecollection,get,list,patch,update,watch操作方法。

resource支持的两种内外版本

每一个资源都至少有两个版本，分别是外部版本(External Version)和内部版本(Internal Version)。外部版本用于对外暴露给用户请求的接口所使用的资源对象。内部版本不对外暴露，尽在kubernetes API Server内部使用。

resource支持的两种资源

kubernetes资源也分为两种，分别是kubernetes Resource（kubernetes内置资源）和Custom Resource（自定义资源）。开发这通过CRD（即Custom Resource Definitions）可实现自定义资源，它允许用户将自己定义的资源添加到kubernetes系统中，并像使用kubernetes内置资源一样使用它们。

ResourceList

kubernetes Group，Version，Resource等核心数据结构存放在staging/src/k8s.io/apimachinery/pkg/apis/meta/v1目录中。它包含了kubernetes集群中所有组件使用的通用核心数据结构，例如APIGroup，APIVersion，APIResource等。其中，我们可以通过APIResourceList数据结构描述所有的Group，Version，Resource的结构，以常用的Pod，Deployment，Service资源为例，APIResourceList Example代码示例如下：

kubernetes的每个资源可使用metav1.APIResource结构进行描述，它描述资源的基本信息，例如资源名称（即Name资源），资源所属的命名空间（即Namespaced字段），资源种类（即Kind字段），资源可操作的方法列表（即Verbs字段）。

每一个资源都属于一个或多个资源版本，资源所属的版本通过metav1.APIVersions结构描述，一个或多个资源版本通过Version []string字符串数组进行存储。在APIResourceList example代码示例中，通过GroupVersion字段来描述资源组和资源版本，它是一个字符串，当资源同时存在资源组和资源版本时，它被设置为/;当资源不存在资源组时（Core Group【核心资源组】），它被设置为/。可以看到Pod，Service资源属于v1版本，而deployment属于apps资源组下的V1版本。

kubernetes API

 kubernetes是一个REST API驱动的系统。系统中的所有操作都是通过向其API服务器发出API请求来执行的。这使得kubernetes很容易与外部系统进行交互。大多数与API的初始交互是使用kubectl完成的。kubectl是一个命令行工具，它将用户命令转换为API调用。但是一旦用户熟悉kubectl，对于高级操作，知道如何直接与API交互将是有益的。这为用户提供了更多的权利来更有效的表达操作。

结束语

至此，我们已经完成了Kubernetes 三大核心数据结构的总览之旅。让我们简单回顾一下核心要点：

1)“三大核心”是基石：Group（资源组）、Version（资源版本） 和 Resource（资源） 共同构成了 Kubernetes API 世界的坐标体系，精准定义了每一个资源的身份和位置。

2)“一个列表”统天下：APIResourceList 与 APIResource 这两个核心数据结构，是 Kubernetes 内部统一描述和管理所有资源（包括内置资源和 CRD）的“元数据目录”。

3)“两种版本”保稳定：内部版本与外部版本的分离，是 Kubernetes 实现 API 平滑演进与多版本兼容性的关键设计。

4)“八种方法”定操作：create、get、list 等八大 Verbs，限定了我们对资源的所有操作可能，也是 RBAC 权限控制的底层依据。

理解这些概念，意味着你不再仅仅是一个 kubectl 命令的执行者，而是开始透过现象看本质，从 API 的视角理解 Kubernetes 的资源管理体系。下次当你再执行 kubectl api-resources 命令时，你看到的将不再是一串冰冷的文本，而是一个结构清晰、层次分明的资源宇宙。