《 Kubernetes进阶实战》一3.2对象类资源格式

3.2　对象类资源格式

       Kubernetes API仅接受及响应JSON格式的数据（JSON对象），同时，为了便于使用，它也允许用户提供YAML格式的POST对象，但API Server需要事先自行将其转换为JSON格式后方能提交。API Server接受和返回的所有JSON对象都遵循同一个模式，它们都具有kind和apiVersion字段，用于标识对象所属的资源类型、API群组及相关的版本。
       进一步地，大多数的对象或列表类型的资源还需要具有三个嵌套型的字段metadata、spec和status。其中metadata字段为资源提供元数据信息，如名称、隶属的名称空间和标签等；spec则用于定义用户期望的状态，不同的资源类型，其状态的意义也各有不同，例如Pod资源最为核心的功能在于运行容器；而status则记录着活动对象的当前状态信息，它由Kubernetes系统自行维护，对用户来说为只读字段。
       每个资源通常仅接受并返回单一类型的数据，而一种类型可以被多个反映特定用例的资源所接受或返回。例如对于Pod类型的资源来说，用户可创建、更新或删除Pod对象，然而，每个Pod对象的metadata、spec和status字段的值却又是各自独立的对象型数据，它们可被单独操作，尤其是status对象，是由Kubernetes系统单独进行自动更新，而不能由用户手动操作它。

3.2.1　资源配置清单

       3.1节中曾使用curl命令通过代理的方式于API Server上请求到了kube-system这个Namespace活动对象的状态信息，事实上，用户也可以直接使用“kubectl get TYPE/NAME -o yaml”命令获取任何一个对象的YAML格式的配置清单，或者使用“kubectl get TYPE/NAME -o json”命令获取JSON格式的配置清单。例如，可使用下面的命令获取kube-system的状态：
                  ~]$ kubectl get namespace kube-system -o yaml
                  apiVersion: v1
                  kind: Namespace
                  metadata:
                  creationTimestamp: 2018-08-11T02:33:23Z
                  name: kube-system
                  resourceVersion: "33"
                  selfLink: /api/v1/namespaces/kube-system
                  uid: eb6bf659-9d0e-11e8-bf0d-000c29ab0f5b
                  spec:
                  finalizers:
                  - kubernetes
                  status:
                  phase: Active
        除了极少数的资源之外，Kubernetes系统上的绝大多数资源都是由其使用者所创建的。创建时，需要以与上述输出结果中类似的方式以YAML或JSON序列化方案定义资源的相关配置数据，即用户期望的目标状态，而后再由Kubernetes的底层组件确保活动对象的运行时状态与用户提供的配置清单中定义的状态无限接近。因此，资源的创建要通过用户提供的资源配置清单来进行，其格式类似于kubectl get命令获取到的YAML或JSON形式的输出结果。不过，status字段对用户来说为只读字段，它由Kubernetes集群自动维护。例如，下面就是一个创建Namespace资源时提供的资源配置清单示例，它仅提供了几个必要的字段：
                apiVersion: v1
                kind: Namespace
                metadata:
                name: dev
                spec:
                finalizers:
                - kubernetes
       将如上所述配置清单中的内容保存于文件中，使用“kubectl create -f /PATH/TO/FILE”命令即可将其创建到集群中。创建完成后查看其YAML或JSON格式的输出结果，可以看到Kubernetes会补全其大部分的字段，并提供相应的数据。事实上，Kubernetes的大多数资源都能够以类似的方式进行创建和查看，而且它们几乎都遵循类似的组织结构，下面的命令显示了第2章中使用kubectl run命令创建的Deployment资源对象myapp的状态信息：
             ~]$ kubectl get deployment myapp -o yaml
            apiVersion: extensions/v1beta1
             kind: Deployment
            metadata:
             ……
            name: myapp
            spec:
             replicas: 3
            selector:
            matchLabels:
            run: myapp
             ……
            status:
              ……
       为了节约篇幅，上面的输出结果省去了大部分内容，仅保留了其主体结构。从命令结果可以看出，它也遵循Kubernetes API标准的资源组织格式，由apiVersion、kind、metadata、spec和status五个核心字段组成，只是spec字段中嵌套的内容与Namespace资源几乎完全不同。
       事实上，对几乎所有的资源来说，apiVersion、kind和metadata字段的功能基本上都是相同的，但spec则用于资源的期望状态，而资源之所以存在类型上的不同，也在于它们的嵌套属性存在显著差别，它由用户定义和维护。而status字段则用于记录活动对象的当前状态，它要与用户在spec中定义的期望状态相同，或者正处于转换为与其相同的过程中。