《 Kubernetes进阶实战》一3.1.2资源及其在API中的组织形式

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

      在Kubernetes上，资源对象代表了系统上的持久类实体，Kubernetes用这些持久类实体来表达集群的状态，包括容器化的应用程序正运行于哪些节点，每个应用程序有哪些资源可用，以及每个应用程序各自的行为策略，如重启、升级及容错策略等。一个对象可能会包含多个资源，用户可对这些资源执行增、删、改、查等管理操作。Kubernetes通常利用标准的RESTful术语来描述API概念。
    ★    资源类型（resource type）是指在URL中使用的名称，如Pod、Namespace和Service等，其URL格式为“GROUP/VERSION/RESOURCE”，如apps/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、NodeLists等。
    ★     简单（Simple）类：常用于在对象上执行某种特殊操作，或者管理非持久化的实体，如/binding或/status等。
       Kubernetes绝大多数的API资源类型都是“对象”，它们代表着集群中某个概念的实例。有一小部分的API资源类型为“虚拟”（virtual）类型，它们用于表达一类“操作”（operation）。所有的对象型资源都拥有一个独有的名称标识以实现其幂等的创建及获取操作，不过，虚拟型资源无须获取或不依赖于幂等性时也可以不使用专用标识符。
       有些资源类型隶属于集群范畴，如Namespace和PersistentVolume，而多数资源类型则受限于名称空间，如Pod、Deployment和Service等。名称空间级别的资源的URL路径中含有其所属空间的名称，这些资源对象在名称空间被删除时会被一并删除，并且这些资源对象的访问也将受控于其所属的名称空间级别的授权审查。
       Kubernetes将API分割为多个逻辑组合，称为API群组，它们支持单独启用或禁用，并能够再次分解。API Server支持在不同的群组中使用不同的版本，允许各组以不同的速度演进，而且也支持同一群组同时存在不同的版本，如apps/v1、apps/v1beta2和apps/v1beta1，也因此能够在不同的群组中使用同名的资源类型，从而能在稳定版本的群组及新的实验群组中以不同的特性同时使用同一个资源类型。群组化管理的API使得其可以更轻松地进行扩展。当前系统的API Server上的相关信息可通过“kubectl api-versions”命令获取。命令结果中显示的不少API群组在后续的章节中配置资源清单时会多次用到：
                        [root@master ~]# 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
                        batch/v1
                        batch/v1beta1
                        certificates.k8s.io/v1beta1
                        events.k8s.io/v1beta1
                        extensions/v1beta1
                        networking.k8s.io/v1
                        policy/v1beta1
                        rbac.authorization.k8s.io/v1
                        rbac.authorization.k8s.io/v1beta1
                        scheduling.k8s.io/v1beta1
                        storage.k8s.io/v1
                        storage.k8s.io/v1beta1v1
       Kubernetes的API以层级结构组织在一起，每个API群组表现为一个以“/apis”为根路径的REST路径，不过核心群组core有一个专用的简化路径“/api/v1”。目前，常用的API群组可归为如下两类。
    ◆    核心群组（core group）：REST路径为/api/v1，在资源的配置信息apiVersion字段中引用时可以不指定路径，而仅给出版本，如“apiVersion: v1”。
    ◆    命名的群组（named group）：REST路径为/apis/$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对象的列表：
                     ~]$ kubectl get --raw /apis/apps/v1/namespaces/default/deployments | jq .
                      {
                    "kind": "DeploymentList",
                     "apiVersion": "apps/v1",
                     ……
                    "items": [……]
                     }
       另外，Kubernetes还支持用户自定义资源类型，目前常用的方式有三种：一是修改Kubernetes源代码自定义类型；二是创建一个自定义的API Server，并将其聚合至集群中；三是使用自定义资源（Custom Resource Def?inition，CRD）。