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文件中。

1. apiVersion: ******
2. kind: ******
3. metadata:<br>  ******<br>  ******
4. spec:<br>  ******<br>  ******

复制代码

参数解释
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   的方法可以获取到该资源下有哪些参数配置。

1. candidate@node01:~$ kubectl explain pod.
2. KIND:       Pod
3. VERSION:    v1
5. DESCRIPTION:
6.     Pod is a collection of containers that can run on a host. This resource is
7.     created by clients and scheduled onto hosts.
9. FIELDS:
10.   apiVersion    <string>
11.     APIVersion defines the versioned schema of this representation of an object.
12.     Servers should convert recognized schemas to the latest internal value, and
13.     may reject unrecognized values. More info:
14.     https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources
16.   kind  <string>
17.     Kind is a string value representing the REST resource this object
18.     represents. Servers may infer this from the endpoint the client submits
19.     requests to. Cannot be updated. In CamelCase. More info:
20.     https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds
22.   metadata      <ObjectMeta>
23.     Standard object's metadata. More info:
24.     https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
26.   spec  <PodSpec>
27.     Specification of the desired behavior of the pod. More info:
28.     https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status
30.   status        <PodStatus>
31.     Most recently observed status of the pod. This data may not be up to date.
32.     Populated by the system. Read-only. More info:
33.     https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status
36. 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卷。

1. apiVersion: v1
2. kind: Pod
3. metadata:
4.   labels:
5.     run: web-server
6.   name: web-server
7. spec:
8.   containers:
9.   - image: nginx
10.     imagePullPolicy: IfNotPresent
11.     name: web-server
12.     ports:
13.     - name: http
14.       containerPort: 80
15.       protocol: TCP
16.     volumeMounts:
17.     - name: test1
18.       mountPath: /v1
19.     - name: test2
20.       mountPath: /v2
21.   restartPolicy: Always
22.   volumes:
23.   - name: test1
24.     emptyDir: {}
25.   - name: test2
26.     emptyDir: {}
27.   nodeSelector:
28.     cpu: amd

复制代码

3.1 何时用横线

当你的父级参数是列表格式时，该父级参数下的第一行子参数前需要加上横线。metadata、spec这两个参数下的第一级子参数首行都不用加横线。
以pod的spec下的containers参数为例，执行kubectl explain  pod.spec.containers. 

 红圈处为containers参数的类型，中括号表示他是一个列表类型的数据，即containers下的第一级子参数第一行必须要加上“-” 横线。
FIELDS行下的橙圈处表示containers下子参数的格式，如果要换行书写，归属他们的第一级子第一行也必须加上“-”横线。

 再看yaml文件中的ports参数，也用kubectl explain  pod.spec.containers.ports. 命令来查看一下。

 通过kubectl explain  pod.spec.containers.ports. 命令查看得知 ports这个参数也是一个列表，同理可得它的下一层首行也必须要加上中横线。

 为了更一步确认找一个不是没加横线的看看，如 pod.spec.containers.name.这个参数，执行命令

 从执行结果看name没有下一级，同时它的格式时在name同行中跟参数即 name: xxxxx。
总结：在执行 kubectl explain 命令时你所要使用的参数父一级类型是列表（ [] ）那么，你需要加横线在该父级参数每个元组的第一行。
 
3.2 何时不用驼峰写法

kubectl explain命令查看到指定资源的类型为map时，该资源的下级资源即为键值对填写不用遵守驼峰写法。
如演示yaml中的nodeSelector参数，它作为pod.spec的子参数他的格式是 ，可直接在同行跟参数，也可换行后指定参数。

 map格式的下一层参数不用适用于驼峰写法。
 
3.3 哪些参数不能省略

kubectl explain结果输出中带有“-required-”字眼的参数不能省略。如pod.spec.containers.ports中的containerPort参数。

pod.spec.volumes.中的name参数一样不能审阅，如果yaml文件中存在pod.spec.volumes那么volumes的下层参数必须要有name这个参数。

 

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！

继续阅读请点击广告