3.1.2 资源及其在API中的组织形式

在Kubernetes上，资源对象代表了系统中的持久类实体，Kubernetes用这些持久类实体来表达集群的状态，包括容器化的应用程序正运行于哪些节点，每个应用程序有哪些资源可用，以及每个应用程序各自的行为策略，如重启、升级及容错策略等。一个对象可能会包含多个资源，用户可对这些资源执行增、删、改、查等管理操作。Kubernetes通常利用标准的RESTful术语来描述API概念。

  • 资源类型（resource type）是指在URL中使用的名称，如Pod、Namespace和Service等，其URL格式为“GROUP/VERSION/RESOURCE”，如app/v1/deployment。

  • 所有资源类型都有一个对应的JSON表示格式，称为“种类”（kind）；客户端创建对象必须以JSON提交对象的配置信息。

  • 隶属于同一种资源类型的对象组成的列表称为“集合”（collection），如PodList。

  • 某种类型的单个实例称为“资源”（resource）或“对象”（object），如名为pod-demo的Pod对象。

kind 代表着资源对象所属的类型，如Namespace、Deployment、Service及Pod等，而这些资源类型大体又可以分为三个类别，具体如下：

  • 对象（object）类：对象表示kubernetes系统上的持久化实例，一个对象可能包含多个资源，客户端可用它执行多种操作。Namespace、Deployment、Service及Pod都属于这个类别。

  • 列表（list）类：列表通常是指同一类型资源的集合，如PodLists、NodeList等。

  • 简单（Simple）类：常用于在对象上执行某种特殊操作，或者管理非持久化的实体，如/binding或/status等。

Kubernetes绝大多数的API资源类型都是“对象”，它们代表着集群中某个概念的实例。有一小部分的API资源类型为“虚拟”（virtual）类型，它们用于表达一类“操作”（opration）。所有的对象类型都拥有一个独有的名称标识以实现其幂等的创建及获取操作，不过，虚拟型资源无须获取或不依赖与幂等性时也可以不使用专用标识符。

有些资源类型隶属于集群范畴，如Namespace和PersistentVolume，而多数资源类型则含受限于名称空间，如Pod、Deployment和Service等。名称空间级别的资源的URL路径中含有其所属空间的名称，这些资源对象在名称空间中被删除时会被一并删除，并且这些资源对象的访问也将受控于其所属的名称空间级别的授权审查。

Kubernetes 将API分割为多个逻辑组合、称为API群组，它们支持单独启用或禁用，并能够再次分解。API Server 支持在不同的群组中使用不同的版本，允许各组以不同的速度演进，而且也支持同一群组同时存在不同版本，如apps/v1、apps/v1beta2和apps/v1beta1，也因此能够再不同的群组中使用同名的资源类型，从而能在稳定版本的群组及新的实验群组中以不同的特性同时使用同一个资源类型。群组化管理的API使得其可以更轻松地进行扩展。当前系统的API Server上的相关信息可通过“kube api-versions”命令获取。命令结果中显示的不少API群组在后续的章节中配置资源清单时会多次用到：

**[terminal]
**[prompt root@master]**[path ~]**[delimiter  $ ]**[command kubectl api-versions]
admissionregistration.k8s.io/v1beta1
apiextensions.k8s.io/v1beta1
apiregistration.k8s.io/v1
apiregistration.k8s.io/v1beta1
apps/v1
apps/v1beta1
apps/v1beta2
authentication.k8s.io/v1
authentication.k8s.io/v1beta1
authorization.k8s.io/v1
authorization.k8s.io/v1beta1
autoscaling/v1
autoscaling/v2beta1
autoscaling/v2beta2
batch/v1
batch/v1beta1
certificates.k8s.io/v1beta1
coordination.k8s.io/v1
coordination.k8s.io/v1beta1
devices.kubeedge.io/v1alpha1
events.k8s.io/v1beta1
extensions/v1beta1
networking.k8s.io/v1
networking.k8s.io/v1beta1
node.k8s.io/v1beta1
policy/v1beta1
rbac.authorization.k8s.io/v1
rbac.authorization.k8s.io/v1beta1
scheduling.k8s.io/v1
scheduling.k8s.io/v1beta1
storage.k8s.io/v1
storage.k8s.io/v1beta1
v1

kubernetes 的 API 以层级结构组织在一起，每个API群组表现为一个以“/apis”为根路径的REST路径，不过核心群组core有一个专用的简化路径“/api/v1”。目前，常用的API群组可归为如下两类：

  • 核心群组（core group）：REST 路径为/api/v1，在资源的配置信息 apiVersion 字段中引用时间可以不指定路径，而仅给出版本，如 “apiVersion:v1”。

  • 命名的群组（named group）：REST 路径为 /api/$GROUP_NAME/$VERSION，例如/apis/apps/v1，它在apiVersion字段中引用的格式为“apiVersion:$GROUP_NAME/$VERSION”，如“apiVersion:apps/v1”。

总结起来，名称空间级别的每一个资源类型在API中的URL路径表示都可简单抽象为形如：/apis/<group>/<version>/namespaces/<namespace>/<kind-plural>的路径，如default名称空间中Deployment类型的路径为/apis/apps/v1/namespaces/default/deployments，通过此路径可获取到 default 名称空间中所有的 Deployment 对象的列表。

**[terminal]
**[delimiter $ ]**[command kubectl get --raw /apis/apps/v1/namespaces/default/deployments | jq .]
{
  "kind": "DeploymentList",
  "apiVersion": "apps/v1",
  "metadata": {
    "selfLink": "/apis/apps/v1/namespaces/default/deployments",
    "resourceVersion": "1244879"
  },
  "items": []
}

另外，Kubernetes 还支持用户自定义资源类型，目前常用的方式有三种：一是修改Kubernetes源代码自定义类型；二是创建一个自定义的 API Server，并经其聚合至集群内；三是使用自定义资源（Custom Resource Definition，CRD）。

results matching ""

    No results matching ""