k8s学习笔记-07(借助kubectl explain编写yaml文件）

原创文档编写不易，未经许可请勿转载。文档中有疑问的可以邮件联系我。邮箱：yinwanit@163.com

说明

文章记录了本人学习yaml文件编写过程中的一些经验分享。

在k8s学习过程中yaml文件的编写无疑是比较让人头痛的，尤其是最开始学习的时候。作者结合自己学习过程总结了以下几点编写yaml文件时遇到的问题，或者说困惑更贴切：

哪些资源归属哪些apiVersion？
yaml文件的基础格式和行文规定是怎么样的？
一个yaml文件基本格式包含哪些内容？
一个参数项后是否包含子参数项？
什么时候该用 - 横线什么时候不该用横线？

针对以上问题，第一点和第二点文章不再累述可在我往期的文章中找到答案（https://www.cnblogs.com/Pigs-Will-Fly/p/17602022.html）,本文仅对第3、4、5三点进行经验分享。

全文归纳：

通过kubectl explain 命令可查看资源参数配置项。
通过kubectl explain命令查看到的参数类型为"[]"时，他的下级参数每个元组首行需要加中横线。
通过kubectl explain命令查看到的参数类型为"map"时，他的下级参数每个元组以键值对出现不用遵守驼峰写法。
通过kubectl explain命令查看到的子参数类型后包含"-required-"时，表示这个子参数对于他归属的父参数而言为必须的不可省略。

一、yaml文件基础组成

k8s中yaml文件结尾需以.yml或.yaml结尾。文件放置位置不做限定。

常见的的yaml文件中一般都包含这四个元素：apiVersion、kind、metadata、spec，这四个元素均处于最顶层层级就是说书写时这四个元素前不需要用空格。

书写yaml文件时可首先把四个元素写入到yaml文件中。

apiVersion: ******
kind: ******
metadata:
  ******
  ******
spec:
  ******
  ******

参数解释

apiVersion: 置于首行，标注该yaml文件使用的版本。不同资源版本中资源使用方式和配置参数存在一定的差异。

kind: 一般置于第二行，紧跟apiVersion行后。标注该yaml文件中使用的资源类型。

metadata: 一般处于第三行yaml文件的元数据，如名称、标签、属于哪个命名空间、文件作者信息等。

spec: 定义具体的资源配置参数信息。如pod、pv、svc、deployments等资源的具体参数配置。

（apiVersion、kind、metadata这行的配置方法对于k8s中所有类型资源参数基本通用，所以需要付出一点点汗水把常用的项记下来，如metadata中的name、namespace等）。

对于spec中的内容有一点映像就行不用死记硬背，不太清楚的可以上官网查看，也可以通过kubectl explain命令查看具体配置。

二、kubectl explain命令基础用法

在编写yaml文件时知道了资源类型即kind行处填写的值，本章节以pod资源举例展示kubectl explain命令使用方法及如何把explain的结果置入到yaml文件中。

通过kubectl explain <资源类型> 的方法可以获取到该资源下有哪些参数配置。

candidate@node01:~$ kubectl explain pod.
KIND: Pod
VERSION: v1

DESCRIPTION:
Pod is a collection of containers that can run on a host. This resource is
created by clients and scheduled onto hosts.

FIELDS:
apiVersion <string>
APIVersion defines the versioned schema of this representation of an object.
Servers should convert recognized schemas to the latest internal value, and
may reject unrecognized values. More info:
https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources

kind <string>
Kind is a string value representing the REST resource this object
represents. Servers may infer this from the endpoint the client submits
requests to. Cannot be updated. In CamelCase. More info:
https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds

metadata <ObjectMeta>
Standard object's metadata. More info:
https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata

spec <PodSpec>
Specification of the desired behavior of the pod. More info:
https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status

status <PodStatus>
Most recently observed status of the pod. This data may not be up to date.
Populated by the system. Read-only. More info:
https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status

candidate@node01:~$

通过kubectl explain pod 命令可以看到pod这个资源对应的第一层（顶层）参数5个，最后一个status这个在我们编写yaml时可以省略不写，只对前四个进行定义编写。

如果想看到下一层级有哪些参数，只需继续执行 kubectl explain 命令加上你想要参看的参数名（每个层级间用半角点隔开），以spec为例 kubectl explain pod.spec.

在输出结果中的FIELDS: 行以下就是pod这个资源spec参数下可设置的参数名。如果还想继续查看同理继续执行 kubectl explain xx.xxx.xxx就行了。

三、选项前是否需要加-横线

通过第二章，基本上可以找到资源各个层级的对应关系，但是这些内容怎么体现在yaml中，如经常能看到yaml文件中，有的参数名后直接跟的参数值，有的参数名前有横线，还有些没有按照驼峰格式来书写。

本章节通过一个简单的yaml文件来进行辅助说明。

yaml文件描述：使用nginx镜像创建一个名为web-server的pod，容器和pod同名，必须运行在标签为 cpu=amd的node节点。容器中提供一个名为http的TCP协议80端口服务。同时在容器的/v1目录挂载一个名为test1的emptydir类型的卷，/v2目录下挂载另外一个名为test2的emptydir卷。

apiVersion: v1
kind: Pod
metadata:
  labels:
    run: web-server
  name: web-server
spec:
  containers:
  - image: nginx
    imagePullPolicy: IfNotPresent
    name: web-server
    ports:
    - name: http
      containerPort: 80
      protocol: TCP
    volumeMounts:
    - name: test1
      mountPath: /v1
    - name: test2
      mountPath: /v2
  restartPolicy: Always
  volumes:
  - name: test1
    emptyDir: {}
  - name: test2
    emptyDir: {}
  nodeSelector:
    cpu: amd