hugo-teek is loading...

2025-03-09 k8s +1 pod 7894 字 35 分钟 -- 次

k8s资源清单文件(yaml和json)

最后更新于: 2025-12-06 10:36:40

k8s资源清单文件YAML

1、yaml前言

前面我们得 Kubernetes 集群已经搭建成功了，现在我们就可以在集群里面来跑我们的应用了。要在集群里面运行我们自己的应用，首先我们需要知道几个概念。

第一个当然就是应用的镜像，因为我们在集群中运行的是容器，所以首先需要将我们的应用打包成镜像。镜像准备好了，Kubernetes 集群也准备好了，其实我们就可以把我们的应用部署到集群中了。但是镜像到集群中运行这个过程如何完成呢？必然有一个地方可以来描述我们的应用，然后把这份描述告诉集群，然后集群按照这个描述来部署应用。

在之前 Docker 环境下面我们是直接通过命令 docker run 来运行我们的应用的，在 Kubernetes 环境下面我们同样也可以用类似 kubectl run 这样的命令来运行我们的应用，但是在 Kubernetes 中却是不推荐使用命令行的方式，而是希望使用我们称为资源清单的东西来描述应用，资源清单可以用 YAML 或者 JSON 文件来编写，一般来说 YAML 文件更方便阅读和理解，所以我们的课程中都会使用 YAML 文件来进行描述。

通过一个资源清单文件来定义好一个应用后，我们就可以通过 kubectl 工具来直接运行它：

1kubectl create -f xxxx.yaml #命令行方式
2# 或者
3kubectl apply -f xxxx.yaml #声明式

注意：

我们知道 kubectl 是直接操作 APIServer 的，所以就相当于把我们的清单提交给了 APIServer，然后集群获取到清单描述的应用信息后存入到 etcd 数据库中，然后 kube-scheduler 组件发现这个时候有一个 Pod 还没有绑定到节点上，就会对这个 Pod 进行一系列的调度，把它调度到一个最合适的节点上，然后把这个节点和 Pod 绑定到一起（写回到 etcd），然后节点上的 kubelet 组件这个时候 watch 到有一个 Pod 被分配过来了，就去把这个 Pod 的信息拉取下来，然后根据描述通过容器运行时把容器创建出来，最后当然同样把 Pod 状态再写回到 etcd 中去，这样就完成了一整个的创建流程。

2、第一个容器化应用

🍀 使用资源清单部署应用

比如现在我们通过 YAML 文件编写了一个如下的资源清单，命名为 nginx-deployment.yaml：

[root@master1 ~]#vim nginx-deployment.yaml

 1apiVersion: apps/v1  # API版本
 2kind: Deployment  # API对象类型
 3metadata:
 4  name: nginx-deploy
 5  labels: # 只是deployment这个对象的标识
 6    chapter: first-app
 7  namespace: default # namesapce 是k8s中的一个逻辑上的分组（和容器运行时中的namespace没有任何关系，只是都叫namespace）
 8spec:
 9  selector:
10    matchLabels:
11      app: nginx
12  replicas: 2  # Pod 副本数量
13  template:  # Pod 模板
14    metadata:
15      labels:
16        app: nginx
17    spec:
18      containers:
19      - name: nginx
20        image: nginx:1.7.9
21        ports:
22        - containerPort: 80

然后直接用 kubectl 命令来创建这个应用：

1[root@master1 ~]#kubectl create -f nginx-deployment.yaml
2deployment.apps/nginx-deploy created
3
4[root@master1 ~]#kubectl get po
5NAME                            READY   STATUS    RESTARTS   AGE
6nginx-deploy-5d59d67564-b6wgv   1/1     Running   0          40s
7nginx-deploy-5d59d67564-cwk4p   1/1     Running   0          40s

我们可以看到会在集群中生成两个 Pod 出来。而整个资源清单文件对应到 Kubernetes 中就是一个 API Object（API 对象），我们按照这些对象的要求填充上对应的属性后，提交给 Kubernetes 集群，就可以为我们创建出对应的资源对象，比如我们这里定义的是一个 Deployment 类型的 API 对象，我们按照这个 API 对象的要求填充了一些属性，就会为我们创建出对应的资源对象，我们可以通过下面的命令来获取：

1[root@master1 ~]#kubectl get deployments
2NAME           READY   UP-TO-DATE   AVAILABLE   AGE
3nginx-deploy   2/2     2            2           2m7s

Deployment 这个资源对象就是用来定义多副本应用的对象，而且还支持对每个副本进行滚动更新，上面我们的资源清单中的描述中有一个属性 replicas: 2，所以最后生成两个副本的 Pod。

而这个 Deployment 定义的副本 Pod 具体是什么样的，是通过下面的 Pod 模板来定义的，就是 template 下面的定义。这个模板中定义了我们的 Pod 中只有一个名为 nginx 的容器，容器使用的镜像是 nginx:1.7.9（spec.containers[0].image），并且这个容器监听的端口是 80（spec.containers[0].ports[0].containerPort）。另外我们还为 Pod 添加了一个 app: nginx 这样的 Label 标签，这里需要非常注意的是，上面的 **selector.matchLabels** 区域就是来表示我们的 Deployment 来管理哪些 Pod 的，所以这个地方需要和 Pod 模板中的 Label 标签保持一致，这个 Label 标签之前我们也提到过是非常重要的。

另外我们也可以发现每个 API 对象都有一个 **Metadata** 的字段，用来表示该对象的元数据的，比如定义 name、namespace 等，比如上面 Deployment 和 Pod 模板中都有这个字段，至于为什么 Pod 模板中没有 name 这个元信息呢，这是因为 Deployment 这个控制器会自动在他自己的 name 基础上生成 Pod 名，不过 Deployment 下面定义的 Label 标签就没有 Pod 中定义的 Label 标签那么重要了，只是起到一个对该对象标识和过滤的作用。比如我们在查询对象的时候可以带上标签来进行过滤：

1[root@master1 ~]#kubectl get deployments.apps -l chapter=first-app
2NAME           READY   UP-TO-DATE   AVAILABLE   AGE
3nginx-deploy   2/2     2            2           8m38s
4
5[root@master1 ~]#kubectl get pod -l app=nginx
6NAME                            READY   STATUS    RESTARTS   AGE
7nginx-deploy-5d59d67564-b6wgv   1/1     Running   0          8m53s
8nginx-deploy-5d59d67564-cwk4p   1/1     Running   0          8m53s

🍀 kubectl describe 命令

到这里我们就完成了我们的第一个应用的容器化部署，但是往往我们在部署应用的过程中或多或少会遇到一些问题，这个时候我们可以使用一个 kubectl describe 命令来查看资源对象的详细信息，比如我们用下面的命令来查看 Pod 的详细信息：

 1[root@master1 ~]#kubectl describe pod nginx-deploy-5d59d67564-b6wgv
 2Name:         nginx-deploy-5d59d67564-b6wgv
 3Namespace:    default
 4Priority:     0
 5Node:         node2/172.29.9.53
 6Start Time:   Wed, 03 Nov 2021 06:45:32 +0800
 7Labels:       app=nginx
 8              pod-template-hash=5d59d67564
 9Annotations:  <none>
10Status:       Running
11IP:           10.244.2.4
12IPs:
13  IP:           10.244.2.4
14Controlled By:  ReplicaSet/nginx-deploy-5d59d67564
15Containers:
16  nginx:
17    Container ID:   containerd://0f8616db94d988102db55d916d33df6cfa4bf747a3d02fb6bc82c3b8c086fdcc
18    Image:          nginx:1.7.9
19    Image ID:       sha256:35d28df486f6150fa3174367499d1eb01f22f5a410afe4b9581ac0e0e58b3eaf
20    Port:           80/TCP
21    Host Port:      0/TCP
22    State:          Running
23      Started:      Wed, 03 Nov 2021 06:46:00 +0800
24    Ready:          True
25    Restart Count:  0
26    Environment:    <none>
27    Mounts:
28      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-f27xw (ro)
29Conditions:
30  Type              Status
31  Initialized       True
32  Ready             True
33  ContainersReady   True
34  PodScheduled      True
35Volumes:
36  kube-api-access-f27xw:
37    Type:                    Projected (a volume that contains injected data from multiple sources)
38    TokenExpirationSeconds:  3607
39    ConfigMapName:           kube-root-ca.crt
40    ConfigMapOptional:       <nil>
41    DownwardAPI:             true
42QoS Class:                   BestEffort
43Node-Selectors:              <none>
44Tolerations:                 node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
45                             node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
46Events:
47  Type    Reason     Age    From               Message
48  ----    ------     ----   ----               -------
49  Normal  Scheduled  9m47s  default-scheduler  Successfully assigned default/nginx-deploy-5d59d67564-b6wgv to node2
50  Normal  Pulling    9m46s  kubelet            Pulling image "nginx:1.7.9"
51  Normal  Pulled     9m20s  kubelet            Successfully pulled image "nginx:1.7.9" in 26.476277224s
52  Normal  Created    9m20s  kubelet            Created container nginx
53  Normal  Started    9m19s  kubelet            Started container nginx

我们可以看到看到很多这个 Pod 的详细信息，比如调度到的节点、状态、IP 等，一般我们比较关心的是下面的 Events 部分，就是我们说的事件。

在 Kubernetes 创建资源对象的过程中，对该对象的一些重要操作，都会被记录在这个对象的 Events 里面，可以通过 kubectl describe 指令查看对应的结果。所以这个指令也会是以后我们排错过程中会经常使用的命令，一定要记住这个重要的命令。比如上面我们描述的这个 Pod，我们可以看到它被创建之后，被调度器调度（Successfully assigned）到了 node2 节点上，然后拉取镜像，然后创建我们定义的 nginx 容器，最后启动定义的容器。

注意：这个event是有一个时效性的，过了一定的时间，就会被清空的。以后如果想看一个历史数据的话，可以考虑把event数据给收集起来。

🍀 滚动升级

另外一个方面如果我们相对我们的应用进行升级的话应该怎么办呢？这个操作在我们日常工作中还是非常常见的，而在 Kubernetes 这里也是非常简单的，我们只需要修改我们的资源清单文件即可，比如我们把镜像升级到最新版本 nginx:latest：

1...
2    spec:
3      containers:
4      - name: nginx
5        image: nginx:latest  # 这里被从 1.7.9 修改为latest
6        ports:
7      - containerPort: 80

然后我们可以通过kubectl apply命令来直接更新，这个命令也是推荐我们使用的，我们不必关心当前的操作是创建，还是更新，执行的命令始终是 **kubectl apply**，Kubernetes 则会根据 YAML 文件的内容变化，自动进行具体的处理，所以无论是创建还是更新都可以直接使用这个命令：

1[root@master1 ~]#kubectl apply -f nginx-deployment.yaml
2Warning: resource deployments/nginx-deploy is missing the kubectl.kubernetes.io/last-applied-configuration annotation which is required by kubectl apply. kubectl apply should only be used on resources created declaratively by either kubectl create --save-config or kubectl apply. The missing annotation will be patched automatically.
3deployment.apps/nginx-deploy configured

通过这个命令就可以来更新我们的应用了，由于我们这里使用的是一个 Deployment 的控制器，所以会滚动更新我们的应用，我们可以通过在命令后面加上 --watch 参数来查看 Pod 的更新过程：

 1[root@master1 ~]#kubectl get po -l app=nginx --watch
 2NAME                            READY   STATUS    RESTARTS   AGE
 3nginx-deploy-5d59d67564-b6wgv   1/1     Running   0          16m
 4nginx-deploy-5d59d67564-cwk4p   1/1     Running   0          16m
 5nginx-deploy-75b69bd684-5jh8p   0/1     Pending   0          0s
 6nginx-deploy-75b69bd684-5jh8p   0/1     Pending   0          0s
 7nginx-deploy-75b69bd684-5jh8p   0/1     ContainerCreating   0          0s
 8nginx-deploy-75b69bd684-5jh8p   1/1     Running             0          17s
 9nginx-deploy-5d59d67564-cwk4p   1/1     Terminating         0          17m
10nginx-deploy-75b69bd684-7k47q   0/1     Pending             0          0s
11nginx-deploy-75b69bd684-7k47q   0/1     Pending             0          0s
12nginx-deploy-75b69bd684-7k47q   0/1     ContainerCreating   0          0s
13nginx-deploy-5d59d67564-cwk4p   0/1     Terminating         0          17m
14nginx-deploy-5d59d67564-cwk4p   0/1     Terminating         0          17m
15nginx-deploy-5d59d67564-cwk4p   0/1     Terminating         0          17m
16nginx-deploy-75b69bd684-7k47q   1/1     Running             0          33s
17nginx-deploy-5d59d67564-b6wgv   1/1     Terminating         0          17m
18nginx-deploy-5d59d67564-b6wgv   0/1     Terminating         0          17m
19nginx-deploy-5d59d67564-b6wgv   0/1     Terminating         0          17m
20nginx-deploy-5d59d67564-b6wgv   0/1     Terminating         0          17m
21
22[root@master1 ~]#kubectl get po
23NAME                            READY   STATUS    RESTARTS   AGE
24nginx-deploy-75b69bd684-5jh8p   1/1     Running   0          97s
25nginx-deploy-75b69bd684-7k47q   1/1     Running   0          80s
26[root@master1 ~]#kubectl get deployments.apps
27NAME           READY   UP-TO-DATE   AVAILABLE   AGE
28nginx-deploy   2/2     2            2           18m
29
30[root@master1 ~]#kubectl get replicasets #注意这里
31NAME                      DESIRED   CURRENT   READY   AGE
32nginx-deploy-5d59d67564   0         0         0       20m
33nginx-deploy-75b69bd684   2         2         2       3m50s

可以看到更新过程是先杀掉了一个 Pod，然后又重新创建了一个新的 Pod，然后又杀掉一个旧的 Pod，再创建一个新的 Pod，这样交替替换的，最后剩下两个新的 Pod，这就是我们所说的滚动更新，滚动更新对于我们的应用持续提供服务是非常重要的手段，在日常工作中更新应用肯定会采用这种方式。

🍀 删除资源

最后，如果需要把我们的应用从集群中删除掉，可以用 kubectl delete 命令来清理：

1kubectl delete -f nginx-deployment.yaml

3、YAML 文件

上面我们在 Kubernetes 中部署了我们的第一个容器化应用，我们了解到要部署应用最重要的就是编写应用的资源清单文件。那么如何编写资源清单文件呢？日常使用的时候我们都是使用 YAML 文件来编写，但是现状却是大部分同学对 JSON 更加熟悉，对 YAML 文件的格式不是很熟悉，所以也导致很多同学在编写资源清单的时候似懂非懂的感觉，所以在了解如何编写资源清单之前我们非常有必要来了解下 YAML 文件的用法。

YAML 是专门用来写配置文件的语言，非常简洁和强大，远比 JSON 格式方便。YAML语言（发音 /ˈjæməl/）的设计目标，就是方便人类读写。它实质上是一种通用的数据串行化格式。

yaml的基本语法规则如下：

大小写敏感
使用缩进表示层级关系
缩进时不允许使用Tab键，只允许使用空格
缩进的空格数目不重要，只要相同层级的元素左侧对齐即可
# 表示注释，从这个字符一直到行尾，都会被解析器忽略

在 Kubernetes 中，我们只需要了解两种结构类型就行了：

Lists（列表） []
Maps（字典）

也就是说，你可能会遇到 Lists 的 Maps 和 Maps 的 Lists，等等。不过不用担心，你只要掌握了这两种结构也就可以了，其他更加复杂的我们暂不讨论。

1.Maps

首先，---是分隔符，是可选的，在单一文件中，可用连续三个连字号---区分多个文件。

我们来看看 Maps，我们都知道 Map 是字典，就是一个 key:value 的键值对，Maps 可以让我们更加方便的去书写配置信息，例如：

1apiVersion: v1
2kind: Pod

这里我们可以看到，我们有两个键：kind 和 apiVersion，他们对应的值分别是：v1 和 Pod。上面的 YAML 文件转换成 JSON 格式的话，你肯定就容易明白了：

1{    
2  "apiVersion": "v1",    
3  "kind": "pod"
4}

我们在创建一个相对复杂一点的 YAML 文件，创建一个 KEY 对应的值不是字符串而是一个 Maps：

1apiVersion: v1
2kind: Pod
3metadata:
4  name: ydzs-site
5  labels:
6    app: web

上面的 YAML 文件，metadata 这个 KEY 对应的值就是一个 Maps 了，而且嵌套的 labels 这个 KEY 的值又是一个 Map，你可以根据你自己的情况进行多层嵌套。

同样的，我们可以将上面的 YAML 文件转换成 JSON 文件：

 1{
 2  "apiVersion": "v1",
 3  "kind": "Pod",
 4  "metadata": {
 5    "name": "kube100-site",
 6    "labels": {
 7      "app": "web"
 8    }
 9  }
10}

或许你对上面的 JSON 文件更熟悉，但是你不得不承认 YAML 文件的语义化程度更高吧？

上面我们也提到了 YAML 文件的语法规则，YAML 处理器是根据行缩进来知道内容之间的嗯关联性的。比如我们上面的 YAML 文件，我用了两个空格作为缩进，空格的数量并不重要，但是你得保持一致，并且至少要求一个空格。我们可以看到 name 和 labels 是相同级别的缩进，所以 YAML 处理器就知道了他们属于同一个 Map，而 app 是 labels 的值是因为 app 的缩进更大。

2.Lists

Lists就是列表，说白了就是数组，在 YAML 文件中我们可以这样定义：

 1args:
 2- Cat
 3- Dog
 4- Fish
 5
 6或者
 7args:
 8- Cat
 9- Dog
10- Fish
11
12#注意：args: ["Cat", "Dog", "Fish"]这样写也可以的；

你可以有任何数量的项在列表中，每个项的定义以破折号（-）开头的，**与父元素之间可以缩进也可以不缩进**。对应的 JSON 格式如下：

1{
2  "args": ["Cat", "Dog", "Fish"]
3}

当然，Lists 的子项也可以是 Maps，Maps 的子项也可以是 Lists 如下所示：

 1apiVersion: v1
 2kind: Pod
 3metadata:
 4  name: ydzs-site
 5  labels:
 6    app: web
 7spec:
 8  containers: # 下面是破折号，那么说明containers是数组。
 9    - name: front-end
10    	image: nginx
11    	ports:
12    		- containerPort: 80
13    - name: flaskapp-demo
14      image: cnych/flaskapp
15      ports:
16        - containerPort: 5000

比如这个 YAML 文件，我们定义了一个叫 containers 的 List 对象，每个子项都由 name、image、ports 组成，每个 ports 都有一个 key 为 containerPort 的 Map 组成，同样的，我们可以转成如下 JSON 格式文件：

 1注意下：这里的json写法，不要搞错了。。。
 2{
 3"apiVersion": "v1",
 4"kind": "Pod",
 5"metadata": {
 6  "name": "ydzs-site",
 7  "labels": {
 8    "app": "web"
 9  }
10},
11"spec": {
12  "containers": [
13    {
14      "name": "front-end",
15      "image": "nginx",
16      "ports": [
17        {
18          "containerPort": "80"
19        }
20      ]
21    },
22    {
23      "name": "flaskapp-demo",
24      "image": "cnych/flaskapp",
25      "ports": [
26        {
27          "containerPort": "5000"
28        }
29      ]
30    }
31  ]
32}
33}

是不是觉得用 JSON 格式的话文件明显比 YAML 文件更复杂了呢？

对象数组的item前后顺序没关系的

据自己预测：name和image无论哪个字段在前面都可以的；–>因为这是个对象数组，下面的选项是没有顺序的。

老师的写法：pod.yaml

老师多个容器的pod.yaml写法：

3.yaml VS json

json只是对于应用程序来说比较友好而已；

资源清单可以用 YAML 或者 JSON 文件来编写，一般来说 YAML 文件更方便阅读和理解，yaml的可读性比json远远好多了;

4.如何编写资源清单

上面我们了解了 YAML 文件的基本语法，现在至少可以保证我们的编写的 YAML 文件语法是合法的，那么要怎么编写符合 Kubernetes API 对象的资源清单呢？比如我们怎么知道 Pod、Deployment 这些资源对象有哪些功能、有哪些字段呢？

一些简单的资源对象我们可能可以凭借记忆写出对应的资源清单，但是 Kubernetes 发展也非常快，版本迭代也很快，每个版本中资源对象可能又有很多变化，那么有没有一种办法可以让我们做到有的放矢呢？

🍀 查找 Kubernetes API 文档

实际上是有的，最简单的方法就是查找 Kubernetes API 文档，比如我们现在使用的是 v1.25.4 版本的集群，可以通过地址https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.25/查找到对应的 API 文档，在这个文档中我们可以找到所有资源对象的一些字段。

比如我们要了解创建一个 Deployment 资源对象需要哪些字段，我们可以打开上面的 API 文档页面，在左侧侧边栏找到 Deployment v1 apps，点击下面的 Write Operations，然后点击 Create，然后我们查找到创建 Deployment 需要提交的 Body 参数

然后点击 Body，进入到参数详情页：

这个时候我们就可以看到我们创建 Deployment 需要的一些字段了，比如 apiVersion、kind、metadata、spec 等，而且每个字段都有对应的文档说明，比如我们像要了解 DeploymentSpec 下面有哪些字段，继续点击进去查看就行：

每个字段具体什么含义以及每个字段下面是否还有其他字段都可以这样去追溯。

🍀 kubectl explains命令

但是如果平时我们编写资源清单的时候都这样去查找文档势必会效率低下，Kubernetes 也考虑到了这点，我们可以直接通过 kubectl 命令行工具来获取这些字段信息，同样的，比如我们要获取 Deployment 的字段信息，我们可以通过 kubectl explain 命令来了解：

 1[root@master1 ~]#kubectl explain deployment
 2KIND:     Deployment
 3VERSION:  apps/v1
 4
 5DESCRIPTION:
 6     Deployment enables declarative updates for Pods and ReplicaSets.
 7
 8FIELDS:
 9   apiVersion   <string>
10     APIVersion defines the versioned schema of this representation of an
11     object. Servers should convert recognized schemas to the latest internal
12     value, and may reject unrecognized values. More info:
13     https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources
14
15   kind <string>
16     Kind is a string value representing the REST resource this object
17     represents. Servers may infer this from the endpoint the client submits
18     requests to. Cannot be updated. In CamelCase. More info:
19     https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds
20
21   metadata     <Object>
22     Standard object's metadata. More info:
23     https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
24
25   spec <Object>
26     Specification of the desired behavior of the Deployment.
27
28   status       <Object>
29     Most recently observed status of the Deployment.

我们可以看到上面的信息和我们在 API 文档中查看到的基本一致，比如我们看到其中 spec 字段是一个 <Object> 类型的，证明该字段下面是一个对象，我们可以继续去查看这个字段下面的详细信息：

 1[root@master1 ~]#kubectl explain deployment.spec
 2KIND:     Deployment
 3VERSION:  apps/v1
 4
 5RESOURCE: spec <Object>
 6
 7DESCRIPTION:
 8     Specification of the desired behavior of the Deployment.
 9
10     DeploymentSpec is the specification of the desired behavior of the
11     Deployment.
12
13FIELDS:
14   minReadySeconds      <integer>
15     Minimum number of seconds for which a newly created pod should be ready
16     without any of its container crashing, for it to be considered available.
17     Defaults to 0 (pod will be considered available as soon as it is ready)
18
19   paused       <boolean>
20     Indicates that the deployment is paused.
21
22   progressDeadlineSeconds      <integer>
23     The maximum time in seconds for a deployment to make progress before it is
24     considered to be failed. The deployment controller will continue to process
25     failed deployments and a condition with a ProgressDeadlineExceeded reason
26     will be surfaced in the deployment status. Note that progress will not be
27     estimated during the time a deployment is paused. Defaults to 600s.
28
29   replicas     <integer>
30     Number of desired pods. This is a pointer to distinguish between explicit
31     zero and not specified. Defaults to 1.
32
33   revisionHistoryLimit <integer>
34     The number of old ReplicaSets to retain to allow rollback. This is a
35     pointer to distinguish between explicit zero and not specified. Defaults to
36     10.
37
38   selector     <Object> -required-
39     Label selector for pods. Existing ReplicaSets whose pods are selected by
40     this will be the ones affected by this deployment. It must match the pod
41     template's labels.
42
43   strategy     <Object>
44     The deployment strategy to use to replace existing pods with new ones.
45
46   template     <Object> -required-
47     Template describes the pods that will be created.

如果一个字段显示的是 required，这就证明该自动是必填的，也就是我们在创建这个资源对象的时候必须声明这个字段，每个字段的类型也都完全为我们进行了说明。所以有了 kubectl explain 这个命令我们就完全可以写出一个不熟悉的资源对象的清单说明了，这个命令我们也是必须要记住的，会在以后的工作中为我们提供很大的帮助。

注意：常见字段如下。

1<Object> 对象
2<[]Object> 对象数组
3
4--`required`，这就证明该自动是必填的
5
6<map[string]string>： 字符串数组。

注意：某个资源的status字段是系统默认帮我们生成并填充的一些信息；

4、yaml编写工具

1.vscode

🍀 vscode yaml插件1

注意：windows下的yaml插件也是可以自动补齐的；(貌似要在一个独立的.yaml文件下才会智能补全)

如果写的有问题，这里还会提示的：

vscode yaml插件2（推荐）

这2个插件都可以

1kubernetes support和kubernetes templates

小伙伴使用效果:

个人使用效果：

感觉还是很不错的哈哈😘

🍀 使用vscode写yaml也还是很不错的哦-2022.3.13

2.golang

有垂直竖线对齐功能，这个还是不错的

竟然能直接格式化代码，呵呵，但是格式化的并不是很智能。。。。

注意：此时vscode里面的yaml代码是没缩进的。。。

将无缩进的代码赋值到gplang里，可以发现被格式化成有缩进的代码了，666，呵呵，但是格式化的并不是很智能。。。。

3.sublime

效果如下

5、json

`jq`工具

jq 是一个非常有用的命令行工具，用于处理和解析 JSON 数据。

1、安装

1yum install -y epel-release
2yum install -y jq

2、测试

json->yaml

json在线转换工具

https://www.json.cn/

或者：

json里的key都是要加双引号的

python -m json.tool工具

同样我们还是可以通过 kubectl 来查询对应对象下面的数据

 1[root@master1 rbac]#kubectl get --raw /apis/batch/v1 | python -m json.tool
 2{
 3    "apiVersion": "v1",
 4    "groupVersion": "batch/v1",
 5    "kind": "APIResourceList",
 6    "resources": [
 7        {
 8            "categories": [
 9                "all"
10            ],
11            "kind": "CronJob",
12            "name": "cronjobs",
13            "namespaced": true,
14            "shortNames": [
15                "cj"
16            ],
17            "singularName": "",
18            "storageVersionHash": "sd5LIXh4Fjs=",
19            "verbs": [
20                "create",
21                "delete",
22                "deletecollection",
23                "get",
24                "list",
25                "patch",
26                "update",
27                "watch"
28            ]
29        },
30        {
31            "kind": "CronJob",
32            "name": "cronjobs/status",
33            "namespaced": true,
34            "singularName": "",
35            "verbs": [
36                "get",
37                "patch",
38                "update"
39            ]
40        },
41        {
42            "categories": [
43                "all"
44            ],
45            "kind": "Job",
46            "name": "jobs",
47            "namespaced": true,
48            "singularName": "",
49            "storageVersionHash": "mudhfqk/qZY=",
50            "verbs": [
51                "create",
52                "delete",
53                "deletecollection",
54                "get",
55                "list",
56                "patch",
57                "update",
58                "watch"
59            ]
60        },
61        {
62            "kind": "Job",
63            "name": "jobs/status",
64            "namespaced": true,
65            "singularName": "",
66            "verbs": [
67                "get",
68                "patch",
69                "update"
70            ]
71        }
72    ]
73}
74[root@master1 rbac]#

jsonpath

kubectl get secret cnych-sa-token-gbqm7 -o jsonpath={.data.token} -nkube-system |base64 -d

1#因为这个secret里面的token是经过base64加密的，因此dashboard想要使用的话，需要先解密
2[root@master1 rbac]#kubectl get secret cnych-sa-token-gbqm7 -o jsonpath={.data.token} -nkube-system |base64 -d
3eyJhbGciOiJSUzI1NiIsImtpZCI6Im9hOERROHhuWTRSeVFweG1kdnpXSTRNNXg3bDZ0ZkRDVWNzN0l5Z0haT1UifQ.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJrdWJlLXN5c3RlbSIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VjcmV0Lm5hbWUiOiJjbnljaC1zYS10b2tlbi1nYnFtNyIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50Lm5hbWUiOiJjbnljaC1zYSIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50LnVpZCI6IjQ0NzRlMDkyLWEwNjAtNDZhMi04MDY5LTg4YjRhYWQyNTlkNyIsInN1YiI6InN5c3RlbTpzZXJ2aWNlYWNjb3VudDprdWJlLXN5c3RlbTpjbnljaC1zYSJ9.D_iKDmhTAyvbOPW7FfT_r23r0QXW7vXnr8WTFp7sSHWiwzD6eiMpGyv_Xp-TRrvPdmNDwEhm-FcW8JuaPkesjNbkdaTDg0dW2EbYz3UiCSMd-YBxlbP2au6rqu2PA8EZ8i2EypDZYH6g7n_9IV7x2DVU7wyXdFsDNq1MUZytgtGBYui9xjyb5wE-dMHFZB5nwr-qCqWn1naCLsEVhOJFC4i1Ws_nHktYzY_TealCjnfqXcfwyqHKJ_XZN_-dshiE743eEHQIZvhUsoL5rl68qvWsx6g5YDgekZfJBCRCbFMVbmCTX0YV0Nonzhz876xl0UrT0JnCq5xyUz62fIWJKQ[root@master1 rbac]#

6、xml

xml格式文件注释方法

方法：

1<!-- ……  -->

注释前：

注释后：

FAQ

字符串数组概念

<[]string>

数组：一定要有个波折号。

🚩 例子

正常yaml的格式应该是如下这种：

但是也是可以写成如下这种形式的：是没什么问题的

**这个是json类型格式的书写方式的！**需要再次注意下json和yaml之间的格式转换；

🚩 例子

等价于

k8s yaml中资源名称的命名方式

特别注意：

一般k8s资源清单yaml的书写规律：key的命名方式是小驼峰命名法，而value里面涉及资源名称的是大驼峰命名法

建议一律缩进2个空格

你可以有任何数量的项在列表中，每个项的定义以破折号（-）开头的，与父元素之间可以缩进也可以不缩进。
对象数组这2种方式都是可以的，但是推荐前面那种方式(一律缩进2个空格)

方法1: 一律缩进2个空格（推荐）

 1#test-nginx.yaml 
 2apiVersion: apps/v1
 3kind: Deployment
 4metadata:
 5 name: nginx-deploy
 6spec:
 7 replicas: 2
 8 selector:
 9   matchLabels:
10     app: nginx
11 template:
12   metadata:
13     labels:
14       app: nginx
15   spec:
16     containers:
17       - name: nginx
18         image: nginx:1.7.9
19         ports:
20           - containerPort: 80
21---
22apiVersion: v1
23kind: Service
24metadata:
25 name: nginx-service
26 labels:
27   name: nginx-service
28spec:
29 ports:
30   - port: 5000
31     targetPort: 80
32 selector:
33   app: nginx

方法2： 不缩进

 1#test-nginx.yaml 
 2apiVersion: apps/v1
 3kind: Deployment
 4metadata:
 5 name: nginx-deploy
 6spec:
 7 replicas: 2
 8 selector:
 9   matchLabels:
10     app: nginx
11 template:
12   metadata:
13     labels:
14       app: nginx
15   spec:
16     containers:
17     - name: nginx
18       image: nginx:1.7.9
19       ports:
20       - containerPort: 80
21---
22apiVersion: v1
23kind: Service
24metadata:
25 name: nginx-service
26 labels:
27   name: nginx-service
28spec:
29 ports:
30 - port: 5000
31   targetPort: 80
32 selector:
33   app: nginx

yaml中`|、|+、|-`和`>`的用法

ConfigMap 资源对象使用 key-value 形式的键值对来配置数据，这些数据可以在 Pod 里面使用，如下所示的资源清单：

 1apiVersion: v1
 2kind: ConfigMap
 3metadata:
 4  name: cm-demo
 5  namespace: default
 6data:
 7  data.1: hello
 8  data.2: world
 9  config: |
10    property.1=value-1
11    property.2=value-2
12    property.3=value-3

其中配置数据在 data 属性下面进行配置，前两个被用来保存单个属性，后面一个被用来保存一个配置文件。

注意：yaml中|和>的用法。

这个有点绕啊……🤣

（1）我们可以看到 config 后面有一个竖线符 |，这在 yaml 中表示保留换行。每行的缩进和行尾空白都会被去掉(最后一行的空白和换行符会被取掉，前面换行被被保留)，而额外的缩进会被保留。

1lines: |
2  我是第一行
3  我是第二行
4    我是吴彦祖
5      我是第四行
6  我是第五行
7
8# JSON
9{"lines": "我是第一行\n我是第二行\n  我是吴彦祖\n     我是第四行\n我是第五行"}

（2）除了竖线之外还可以使用 > 右尖括号，用来表示折叠换行，只有空白行才会被识别为换行，原来的换行符都会被转换成空格。

 1lines: >
 2  我是第一行
 3  我也是第一行
 4  我仍是第一行
 5  我依旧是第一行
 6
 7  我是第二行
 8  这么巧我也是第二行
 9
10# JSON
11{"lines": "我是第一行 我也是第一行 我仍是第一行 我依旧是第一行\n我是第二行 这么巧我也是第二行"}

（3）除了这两个指令之外，我们还可以使用竖线和加号或者减号进行配合使用，+ 表示保留文字块末尾的换行，- 表示删除字符串末尾的换行。

 1value: |
 2  hello
 3  hello
 4
 5# {"value": "hello\nhello"}
 6
 7value: |-
 8  hello
 9
10# {"value": "hello"}
11
12value: |+
13  hello
14
15# {"value": "hello\n\n"} (有多少个回车就有多少个\n)