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 的状态：

**[terminal]
**[delimiter $ ]**[command kubectl get namespace kube-system -o yaml]
apiVersion: v1
kind: Namespace
metadata:
  creationTimestamp: "2019-11-20T14:28:38Z"
  name: kube-system
  resourceVersion: "16"
  selfLink: /api/v1/namespaces/kube-system
  uid: 0af98bf7-0ba2-11ea-9b5d-000c29d3bc46
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 的大多数资源都能够以类似的方式进行创建和查看，而且它们几乎都遵循类似的组织结构，下面的命令显示了第二章中使用 kubectl run 命令创建的 Deployment 资源对象 myapp 的状态信息：

**[terminal]
**[delimiter $ ]**[command kubectl get deployment myapp -o yaml]
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  annotations:
    deployment.kubernetes.io/revision: "1"
  creationTimestamp: "2019-11-30T11:31:38Z"
  generation: 1
  labels:
    run: myapp
  name: myapp
  namespace: default
  resourceVersion: "1362322"
  selfLink: /apis/extensions/v1beta1/namespaces/default/deployments/myapp
  uid: f8ffa298-1364-11ea-bba9-000c29d3bc46
spec:
  progressDeadlineSeconds: 600
  replicas: 3
  revisionHistoryLimit: 10
  selector:
    matchLabels:
      run: myapp
  strategy:
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%
    type: RollingUpdate
  template:
    metadata:
      creationTimestamp: null
      labels:
        run: myapp
    spec:
      containers:
      - image: ikubernetes/myapp:v1
        imagePullPolicy: IfNotPresent
        name: myapp
        ports:
        - containerPort: 80
          protocol: TCP
        resources: {}
        terminationMessagePath: /dev/termination-log
        terminationMessagePolicy: File
      dnsPolicy: ClusterFirst
      restartPolicy: Always
      schedulerName: default-scheduler
      securityContext: {}
      terminationGracePeriodSeconds: 30
status:
  availableReplicas: 3
  conditions:
  - lastTransitionTime: "2019-11-30T11:31:49Z"
    lastUpdateTime: "2019-11-30T11:31:49Z"
    message: Deployment has minimum availability.
    reason: MinimumReplicasAvailable
    status: "True"
    type: Available
  - lastTransitionTime: "2019-11-30T11:31:38Z"
    lastUpdateTime: "2019-11-30T11:31:49Z"
    message: ReplicaSet "myapp-5c647497bf" has successfully progressed.
    reason: NewReplicaSetAvailable
    status: "True"
    type: Progressing
  observedGeneration: 1
  readyReplicas: 3
  replicas: 3
  updatedReplicas: 3

从命令的结果可以看出，它也遵循 kubernetes API 标准的资源组织格式，由 apiVersion、kind、metadata、spec和status五个核心字段组成，只是spec字段中嵌套的内容与Namespace资源几乎完全不同。

事实上，对几乎所有的资源来说，apiVerison、kind和metadata 字段的功能基本上都是相同的，但spec则用于资源的期望状态，而资源之所以存在类型上的不同，也在于它们的嵌套属性存在显著差别，它由用户定义和维护。而status字段则用于记录活动对象的当前状态，它要与用户在 spec 中定义的期望状态相同，或者正处于转换为与其相关的过程中。