说一说Kubernetes 源码分析之Resource和API

zhpzhw13

在的世界里对各种的操作都是基于API来完成的，提供了一系列的RESTAPI来完成对的基本操作。[url=http:///www.wangsu.com/]cdn[/url]的具体问题可以到我们网站了解一下，也有业内领域专业的客服为您解答问题，为成功合作打下一个良好的开端！[align=center]

                               
登录/注册后可看大图

[/align]


本文是一个系列文章，以学习为目的，对源码进行分析，意在可以更好的去理解基本原理。


文章使用主分支()，主要介绍中相关组件。另外如果感兴趣也可以参看络系列文章和部署系列文章。


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


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



如果某一种例是被定义在某一个中的，既隶属于级别，那么这个就可以看作是一个基于当前的资源对象例，例如我们常见的，，等等。
如果某一种例是被定义在整个中的，既隶属于集群级别，那么这个就可以看作是非的资源对象例，例如我们常见的，，，等等。

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



对于核心来说常见的有,,,,等等，这些资源提供了最基本的能力。例如提供计算能力，和提供络和访问能力，提供配置能力。
非核心资源例如，，等等提供更高级的功能。对于非核心资源来说提供了基于和的管理概念，把不同的资源归纳为同一个组，在同一个组内，同样的资源又有不同。这样对资源的组织和结构，非常有利于功能的演进和变化，即通过不同的来演进和增强的能力。

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






I1和I2是对于核心的操作定义格式，都以为前缀，对于核心来说并没有的概念，但是却有的概念，所以里面有的变量${}。
1为对基于的核心的操作，所以定义里面有的变量${-}。
2为对基于非的核心的操作，所以定义里面并没有的变量。
和4为对非核心的操作定义，以为前缀。
为对基于的非核心的操作定义，所以访问路径里面就会有，，者的变量定义，即${-}和${}以及${-}。
4为基于整个的非核心的操作，所以定义里面就会有，的变量${-}和${}，却并没有的变量。

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





一般对于典型的YAML文件都会分为个部分，,还有。



里一般定义了的还有信息，和API访问路径里定义的${-}${}${-}等变量直接对应。
里一般定义的字，所属的，以及等元数据信息，会和API访问路径里的${-}和${-}等变量来直接对应。
里一般就是定义这个具体的属性和特性了(不同一定会有所不一样)，会以的形式和API来对应。

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


本文转载自微信「TA码字」，可以通过以下二维码关注。转载本文请联系TA码字。