在 kubernetes 的世界里对各种 resoure 的操作都是基于 API 来完成的，kubernetes 提供了一系列的 RESTfull API 来完成对 resource 的基本操作。

本文是一个系列文章，以学习为目的，对 kubernetes 源码进行分析，意在可以更好的去理解 kuberbetes 基本原理。文章使用主分支(https://github.com/kubernetes/kubernetes)，主要介绍 kubernates 中相关组件。另外如果感兴趣也可以参看 网络系列文章 和 部署系列文章。

众所周知 kubernetes 是基于 API 的 infrastructure，在此之上的 kubernetes 之中的概念都被抽象成各种 resource，不同的 resource 拥有不同的功能，例如我们熟悉并经常使用的 deployment 资源， service 资源， configmap 资源， statefulset 资源， service account 资源等等。在 kubernetes 的世界里对各种 resoure 的操作都是基于 API 来完成的，kubernetes 提供了一系列的 RESTfull API 来完成对 resource 的基本操作。

对于 resource 来说基本上有两个维度的划分，一个是基于 namespace 的维度，还有一个是基于是否为核心 resource 的维度，首先我们看基于 namespace 的维度。

• 如果某一种 resource 实例是被定义在某一个 namespace 中的，既隶属于 namespace 级别， 那么这个 resource 就可以看作是一个基于当前 namespace 的资源对象实例，例如我们常见的 deployment， service， pod 等等。

• 如果某一种 resource 实例是被定义在整个 kubernetes cluster 中的， 既隶属于集群级别， 那么这个 resource 就可以看作是非 namesapce 的资源对象实例，例如我们常见的 node， cluster role， cluster role binding， persistent volume 等等。

接着从 resource 是否为核心资源的维度看，可以把其分为核心资源与非核心资源。

• 对于核心 resource 来说常见的有 pod, podtemplate, service, endpoint, configmap 等等，这些资源提供了 kubernetes 最基本的能力。例如 pod 提供计算能力，service 和 endpoint 提供网络和访问能力，configmap 提供配置能力。

• 非核心资源例如 deployment， statefulset， deamonset 等等提供更高级的功能。对于非核心资源来说 kubernetes 提供了基于 group 和 version 的管理概念，把不同的资源归纳为同一个组，在同一个组内，同样的资源又有不同 version。这样对资源的组织和结构，非常有利于 kubernetes 功能的演进和变化，即通过不同的 resource version 来演进和增强 resource 的能力。

因为 kubernetes 提供了标准的 RESTfull API，从 API 的角度看，基于以上不同维度各种 resource 的操作 API 模板可以如下：

• Item1 和 Item2 是对于核心 resource 的操作定义格式，都以 /api 为 uri path 前缀，对于核心 resource 来说并没有 group 的概念，但是却有 version 的概念，所以里面有 version 的 path 变量 ${version}。

• item1 为对基于 namespace 的核心 resource 的操作，所以定义里面有 namespace 的 path 变量 ${namespace-name}。

• item2 为对基于非 namespace 的核心 resource 的操作，所以定义里面并没有 namespace 的 path 变量。

• item3 和 item4 为对非核心 resource 的操作定义，以 /apis 为 uri path 前缀。

• iems3 为对基于 namespace 的非核心 resource 的操作定义，所以访问路径里面就会有 group， version， namespace 三者的 path 变量定义， 即 ${group-name} 和 ${version} 以及 ${namespace-name}。

• items4 为基于整个cluster 的非核心 resource 的操作，所以定义里面就会有 group， version 的 path 变量 ${group-name} 和 ${version}，却并没有 namespace 的 path 变量。

另外我们一般对 kubernetes 资源的操作都是基于 YAML 格式的文件来进行(毕竟 YAML 文件相对于 human 来说更友好)，并不是直接基于 Restfull API 来操作资源，但是在 YAML 文件的背后却是转换成 RESTfull API，一般一个 YAML 文件的格式如下：

一般对于 resource 典型的 YAML 文件都会分为三个部分，type meta, object meta 还有 spec。

• type meta 里一般定义了 resource 的 group version 还有 kind 信息，和 API 访问路径里定义的 ${group-name} ${version} ${resource-kind} 等 path 变量直接对应。

• object meta 里一般定义 resource 的名字，所属的 namespace，以及 label 等元数据信息，会和 API 访问路径里的 ${namespace-name} 和 ${resource-name} 等 path 变量来直接对应。

• spec 里一般就是定义这个 resource 具体的属性和特性了(不同 resource spec 一定会有所不一样)，会以 request body 的形式和 API 来对应。

目前先我们写到这里，在下一篇文章中我们继续从源码的角度来梳理 resource 中的 type meta，object meta 等关键信息的定义。