4、k8s资源清单文件(yaml和json)
更新于：2024年3月7日
k8s资源清单文件YAML
目录
[toc]
1、yaml前言
前面我们得 Kubernetes 集群已经搭建成功了，现在我们就可以在集群里面来跑我们的应用了。要在集群里面运行我们自己的应用，首先我们需要知道几个概念。
第一个当然就是应用的镜像，因为我们在集群中运行的是容器，所以首先需要将我们的应用打包成镜像。镜像准备好了，Kubernetes 集群也准备好了，其实我们就可以把我们的应用部署到集群中了。但是镜像到集群中运行这个过程如何完成呢？必然有一个地方可以来描述我们的应用，然后把这份描述告诉集群，然后集群按照这个描述来部署应用。
在 之前 Docker 环境下面我们是直接通过命令 docker run 来运行我们的应用的，在 Kubernetes 环境下面我们同样也可以用类似 kubectl run 这样的命令来运行我们的应用，但是在 Kubernetes 中却是不推荐使用命令行的方式，而是希望使用我们称为资源清单的东西来描述应用，资源清单可以用 YAML 或者 JSON 文件来编写，一般来说 YAML 文件更方便阅读和理解，所以我们的课程中都会使用 YAML 文件来进行描述。
通过一个资源清单文件来定义好一个应用后，我们就可以通过 kubectl 工具来直接运行它：
kubectl create -f xxxx.yaml #命令行方式
# 或者
kubectl 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
apiVersion: apps/v1 # API版本
kind: Deployment # API对象类型
metadata:
name: nginx-deploy
labels: # 只是deployment这个对象的标识
chapter: first-app
namespace: default # namesapce 是k8s中的一个逻辑上的分组（和容器运行时中的namespace没有任何关系，只是都叫namespace）
spec:
selector:
matchLabels:
app: nginx
replicas: 2 # Pod 副本数量
template: # Pod 模板
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.7.9
ports:
- containerPort: 80
然后直接用 kubectl 命令来创建这个应用：
[root@master1 ~]#kubectl create -f nginx-deployment.yaml
deployment.apps/nginx-deploy created
[root@master1 ~]#kubectl get po
NAME READY STATUS RESTARTS AGE
nginx-deploy-5d59d67564-b6wgv 1/1 Running 0 40s
nginx-deploy-5d59d67564-cwk4p 1/1 Running 0 40s
我们可以看到会在集群中生成两个 Pod 出来。而整个资源清单文件对应到 Kubernetes 中就是一个 API Object（API 对象），我们按照这些对象的要求填充上对应的属性后，提交给 Kubernetes 集群，就可以为我们创建出对应的资源对象，比如我们这里定义的是一个 Deployment 类型的 API 对象，我们按照这个 API 对象的要求填充了一些属性，就会为我们创建出对应的资源对象，我们可以通过下面的命令来获取：
[root@master1 ~]#kubectl get deployments
NAME READY UP-TO-DATE AVAILABLE AGE
nginx-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 标签那么重要了，只是起到一个对该对象标识和过滤的作用。比如我们在查询对象的时候可以带上标签来进行过滤：
[root@master1 ~]#kubectl get deployments.apps -l chapter=first-app
NAME READY UP-TO-DATE AVAILABLE AGE
nginx-deploy 2/2 2 2 8m38s
[root@master1 ~]#kubectl get pod -l app=nginx
NAME READY STATUS RESTARTS AGE
nginx-deploy-5d59d67564-b6wgv 1/1 Running 0 8m53s
nginx-deploy-5d59d67564-cwk4p 1/1 Running 0 8m53s
🍀 kubectl describe 命令
到这里我们就完成了我们的第一个应用的容器化部署，但是往往我们在部署应用的过程中或多或少会遇到一些问题，这个时候我们可以使用一个 kubectl describe 命令来查看资源对象的详细信息，比如我们用下面的命令来查看 Pod 的详细信息：
[root@master1 ~]#kubectl describe pod nginx-deploy-5d59d67564-b6wgv
Name: nginx-deploy-5d59d67564-b6wgv
Namespace: default
Priority: 0
Node: node2/172.29.9.53
Start Time: Wed, 03 Nov 2021 06:45:32 +0800
Labels: app=nginx
pod-template-hash=5d59d67564
Annotations: <none>
Status: Running
IP: 10.244.2.4
IPs:
IP: 10.244.2.4
Controlled By: ReplicaSet/nginx-deploy-5d59d67564
Containers:
nginx:
Container ID: containerd://0f8616db94d988102db55d916d33df6cfa4bf747a3d02fb6bc82c3b8c086fdcc
Image: nginx:1.7.9
Image ID: sha256:35d28df486f6150fa3174367499d1eb01f22f5a410afe4b9581ac0e0e58b3eaf
Port: 80/TCP
Host Port: 0/TCP
State: Running
Started: Wed, 03 Nov 2021 06:46:00 +0800
Ready: True
Restart Count: 0
Environment: <none>
Mounts:
/var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-f27xw (ro)
Conditions:
Type Status
Initialized True
Ready True
ContainersReady True
PodScheduled True
Volumes:
kube-api-access-f27xw:
Type: Projected (a volume that contains injected data from multiple sources)
TokenExpirationSeconds: 3607
ConfigMapName: kube-root-ca.crt
ConfigMapOptional: <nil>
DownwardAPI: true
QoS Class: BestEffort
Node-Selectors: <none>
Tolerations: node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled 9m47s default-scheduler Successfully assigned default/nginx-deploy-5d59d67564-b6wgv to node2
Normal Pulling 9m46s kubelet Pulling image "nginx:1.7.9"
Normal Pulled 9m20s kubelet Successfully pulled image "nginx:1.7.9" in 26.476277224s
Normal Created 9m20s kubelet Created container nginx
Normal Started 9m19s kubelet Started container nginx
我们可以看到看到很多这个 Pod 的详细信息，比如调度到的节点、状态、IP 等，一般我们比较关心的是下面的 Events 部分，就是我们说的事件。
在 Kubernetes 创建资源对象的过程中，对该对象的一些重要操作，都会被记录在这个对象的 Events 里面，可以通过 kubectl describe 指令查看对应的结果。所以这个指令也会是以后我们排错过程中会经常使用的命令，一定要记住这个重要的命令。比如上面我们描述的这个 Pod，我们可以看到它被创建之后，被调度器调度（Successfully assigned）到了 node2 节点上，然后拉取镜像，然后创建我们定义的 nginx 容器，最后启动定义的容器。
注意：这个event是有一个时效性的，过了一定的时间，就会被清空的。以后如果想看一个历史数据的话，可以考虑把event数据给收集起来。
🍀 滚动升级
另外一个方面如果我们相对我们的应用进行升级的话应该怎么办呢？这个操作在我们日常工作中还是非常常见的，而在 Kubernetes 这里也是非常简单的，我们只需要修改我们的资源清单文件即可，比如我们把镜像升级到最新版本 nginx:latest：
...
spec:
containers:
- name: nginx
image: nginx:latest # 这里被从 1.7.9 修改为latest
ports:
- containerPort: 80
然后我们可以通过kubectl apply命令来直接更新，这个命令也是推荐我们使用的，我们不必关心当前的操作是创建，还是更新，执行的命令始终是 **kubectl apply**，Kubernetes 则会根据 YAML 文件的内容变化，自动进行具体的处理，所以无论是创建还是更新都可以直接使用这个命令：
[root@master1 ~]#kubectl apply -f nginx-deployment.yaml
Warning: 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.
deployment.apps/nginx-deploy configured
通过这个命令就可以来更新我们的应用了，由于我们这里使用的是一个 Deployment 的控制器，所以会滚动更新我们的应用，我们可以通过在命令后面加上 --watch 参数来查看 Pod 的更新过程：
[root@master1 ~]#kubectl get po -l app=nginx --watch
NAME READY STATUS RESTARTS AGE
nginx-deploy-5d59d67564-b6wgv 1/1 Running 0 16m
nginx-deploy-5d59d67564-cwk4p 1/1 Running 0 16m
nginx-deploy-75b69bd684-5jh8p 0/1 Pending 0 0s
nginx-deploy-75b69bd684-5jh8p 0/1 Pending 0 0s
nginx-deploy-75b69bd684-5jh8p 0/1 ContainerCreating 0 0s
nginx-deploy-75b69bd684-5jh8p 1/1 Running 0 17s
nginx-deploy-5d59d67564-cwk4p 1/1 Terminating 0 17m
nginx-deploy-75b69bd684-7k47q 0/1 Pending 0 0s
nginx-deploy-75b69bd684-7k47q 0/1 Pending 0 0s
nginx-deploy-75b69bd684-7k47q 0/1 ContainerCreating 0 0s
nginx-deploy-5d59d67564-cwk4p 0/1 Terminating 0 17m
nginx-deploy-5d59d67564-cwk4p 0/1 Terminating 0 17m
nginx-deploy-5d59d67564-cwk4p 0/1 Terminating 0 17m
nginx-deploy-75b69bd684-7k47q 1/1 Running 0 33s
nginx-deploy-5d59d67564-b6wgv 1/1 Terminating 0 17m
nginx-deploy-5d59d67564-b6wgv 0/1 Terminating 0 17m
nginx-deploy-5d59d67564-b6wgv 0/1 Terminating 0 17m
nginx-deploy-5d59d67564-b6wgv 0/1 Terminating 0 17m
[root@master1 ~]#kubectl get po
NAME READY STATUS RESTARTS AGE
nginx-deploy-75b69bd684-5jh8p 1/1 Running 0 97s
nginx-deploy-75b69bd684-7k47q 1/1 Running 0 80s
[root@master1 ~]#kubectl get deployments.apps
NAME READY UP-TO-DATE AVAILABLE AGE
nginx-deploy 2/2 2 2 18m
[root@master1 ~]#kubectl get replicasets #注意这里
NAME DESIRED CURRENT READY AGE
nginx-deploy-5d59d67564 0 0 0 20m
nginx-deploy-75b69bd684 2 2 2 3m50s
可以看到更新过程是先杀掉了一个 Pod，然后又重新创建了一个新的 Pod，然后又杀掉一个旧的 Pod，再创建一个新的 Pod，这样交替替换的，最后剩下两个新的 Pod，这就是我们所说的滚动更新，滚动更新对于我们的应用持续提供服务是非常重要的手段，在日常工作中更新应用肯定会采用这种方式。
🍀 删除资源
最后，如果需要把我们的应用从集群中删除掉，可以用 kubectl delete 命令来清理：
kubectl 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 可以让我们更加方便的去书写配置信息，例如：
apiVersion: v1
kind: Pod
这里我们可以看到，我们有两个键：kind 和 apiVersion，他们对应的值分别是：v1 和 Pod。上面的 YAML 文件转换成 JSON 格式的话，你肯定就容易明白了：
{
"apiVersion": "v1",
"kind": "pod"
}
我们在创建一个相对复杂一点的 YAML 文件，创建一个 KEY 对应的值不是字符串而是一个 Maps：
apiVersion: v1
kind: Pod
metadata:
name: ydzs-site
labels:
app: web
上面的 YAML 文件，metadata 这个 KEY 对应的值就是一个 Maps 了，而且嵌套的 labels 这个 KEY 的值又是一个 Map，你可以根据你自己的情况进行多层嵌套。
同样的，我们可以将上面的 YAML 文件转换成 JSON 文件：
{
"apiVersion": "v1",
"kind": "Pod",
"metadata": {
"name": "kube100-site",
"labels": {
"app": "web"
}
}
}
或许你对上面的 JSON 文件更熟悉，但是你不得不承认 YAML 文件的语义化程度更高吧？
上面我们也提到了 YAML 文件的语法规则，YAML 处理器是根据行缩进来知道内容之间的嗯关联性的。比如我们上面的 YAML 文件，我用了两个空格作为缩进，空格的数量并不重要，但是你得保持一致，并且至少要求一个空格。我们可以看到 name 和 labels 是相同级别的缩进，所以 YAML 处理器就知道了他们属于同一个 Map，而 app 是 labels 的值是因为 app 的缩进更大。
2.Lists
Lists就是列表，说白了就是数组，在 YAML 文件中我们可以这样定义：
args:
- Cat
- Dog
- Fish
或者
args:
- Cat
- Dog
- Fish
#注意：args: ["Cat", "Dog", "Fish"]这样写也可以的；
你可以有任何数量的项在列表中，每个项的定义以破折号（-）开头的，**与父元素之间可以缩进也可以不缩进**。对应的 JSON 格式如下：
{
"args": ["Cat", "Dog", "Fish"]
}
当然，Lists 的子项也可以是 Maps，Maps 的子项也可以是 Lists 如下所示：
apiVersion: v1
kind: Pod
metadata:
name: ydzs-site
labels:
app: web
spec:
containers: # 下面是破折号，那么说明containers是数组。
- name: front-end
image: nginx
ports:
- containerPort: 80
- name: flaskapp-demo
image: cnych/flaskapp
ports:
- containerPort: 5000
比如这个 YAML 文件，我们定义了一个叫 containers 的 List 对象，每个子项都由 name、image、ports 组成，每个 ports 都有一个 key 为 containerPort 的 Map 组成，同样的，我们可以转成如下 JSON 格式文件：
注意下：这里的json写法，不要搞错了。。。
{
"apiVersion": "v1",
"kind": "Pod",
"metadata": {
"name": "ydzs-site",
"labels": {
"app": "web"
}
},
"spec": {
"containers": [
{
"name": "front-end",
"image": "nginx",
"ports": [
{
"containerPort": "80"
}
]
},
{
"name": "flaskapp-demo",
"image": "cnych/flaskapp",
"ports": [
{
"containerPort": "5000"
}
]
}
]
}
}
是不是觉得用 JSON 格式的话文件明显比 YAML 文件更复杂了呢？
- 对象数组的item前后顺序没关系的
据自己预测：name和image无论哪个字段在前面都可以的；-->因为这是个对象数组，下面的选项是没有顺序的。
老师的写法：pod.yaml
老师多个容器的pod.yaml写法：
3.yaml VS json
json只是对于应用程序来说比较友好而已；
资源清单可以用 YAML 或者 JSON 文件来编写，一般来说 YAML 文件更方便阅读和理解，yaml的可读性比json远远好多了;
YAML 是专门用来写配置文件的语言，非常简洁和强大，远比 JSON 格式方便。YAML语言（发音 /ˈjæməl/）的设计目标，就是方便人类读写。它实质上是一种通用的数据串行化格式。
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 命令来了解：
[root@master1 ~]#kubectl explain deployment
KIND: Deployment
VERSION: apps/v1
DESCRIPTION:
Deployment enables declarative updates for Pods and ReplicaSets.
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 <Object>
Standard object's metadata. More info:
https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
spec <Object>
Specification of the desired behavior of the Deployment.
status <Object>
Most recently observed status of the Deployment.
我们可以看到上面的信息和我们在 API 文档中查看到的基本一致，比如我们看到其中 spec 字段是一个 <Object> 类型的，证明该字段下面是一个对象，我们可以继续去查看这个字段下面的详细信息：
[root@master1 ~]#kubectl explain deployment.spec
KIND: Deployment
VERSION: apps/v1
RESOURCE: spec <Object>
DESCRIPTION:
Specification of the desired behavior of the Deployment.
DeploymentSpec is the specification of the desired behavior of the
Deployment.
FIELDS:
minReadySeconds <integer>
Minimum number of seconds for which a newly created pod should be ready
without any of its container crashing, for it to be considered available.
Defaults to 0 (pod will be considered available as soon as it is ready)
paused <boolean>
Indicates that the deployment is paused.
progressDeadlineSeconds <integer>
The maximum time in seconds for a deployment to make progress before it is
considered to be failed. The deployment controller will continue to process
failed deployments and a condition with a ProgressDeadlineExceeded reason
will be surfaced in the deployment status. Note that progress will not be
estimated during the time a deployment is paused. Defaults to 600s.
replicas <integer>
Number of desired pods. This is a pointer to distinguish between explicit
zero and not specified. Defaults to 1.
revisionHistoryLimit <integer>
The number of old ReplicaSets to retain to allow rollback. This is a
pointer to distinguish between explicit zero and not specified. Defaults to
10.
selector <Object> -required-
Label selector for pods. Existing ReplicaSets whose pods are selected by
this will be the ones affected by this deployment. It must match the pod
template's labels.
strategy <Object>
The deployment strategy to use to replace existing pods with new ones.
template <Object> -required-
Template describes the pods that will be created.
如果一个字段显示的是 required，这就证明该自动是必填的，也就是我们在创建这个资源对象的时候必须声明这个字段，每个字段的类型也都完全为我们进行了说明。所以有了 kubectl explain 这个命令我们就完全可以写出一个不熟悉的资源对象的清单说明了，这个命令我们也是必须要记住的，会在以后的工作中为我们提供很大的帮助。
注意：常见字段如下。
<Object> 对象
<[]Object> 对象数组
--`required`，这就证明该自动是必填的
<map[string]string>： 字符串数组。
注意：某个资源的status字段是系统默认帮我们生成并填充的一些信息；
4、yaml编写工具
1.vscode
🍀 vscode yaml插件1
注意：windows下的yaml插件也是可以自动补齐的；(貌似要在一个独立的.yaml文件下才会智能补全)
如果写的有问题，这里还会提示的：
vscode yaml插件2（推荐）
这2个插件都可以
kubernetes support和kubernetes templates
小伙伴使用效果:
小伙伴使用效果:
个人使用效果：
感觉还是很不错的哈哈😘
🍀 使用vscode写yaml也还是很不错的哦-2022.3.13
2.golang
- 有垂直竖线对齐功能，这个还是不错的
- 竟然能直接格式化代码，呵呵，但是格式化的并不是很智能。。。。
注意：此时vscode里面的yaml代码是没缩进的。。。
- 将无缩进的代码赋值到gplang里，可以发现被格式化成有缩进的代码了，666，呵呵，但是格式化的并不是很智能。。。。
3.sublime
- 效果如下
5、json
jq工具
jq 是一个非常有用的命令行工具，用于处理和解析 JSON 数据。
1、安装
yum install -y epel-release
yum install -y jq
2、测试
json->yaml
json在线转换工具
或者：
json里的key都是要加双引号的
python -m json.tool工具
同样我们还是可以通过 kubectl 来查询对应对象下面的数据
[root@master1 rbac]#kubectl get --raw /apis/batch/v1 | python -m json.tool
{
"apiVersion": "v1",
"groupVersion": "batch/v1",
"kind": "APIResourceList",
"resources": [
{
"categories": [
"all"
],
"kind": "CronJob",
"name": "cronjobs",
"namespaced": true,
"shortNames": [
"cj"
],
"singularName": "",
"storageVersionHash": "sd5LIXh4Fjs=",
"verbs": [
"create",
"delete",
"deletecollection",
"get",
"list",
"patch",
"update",
"watch"
]
},
{
"kind": "CronJob",
"name": "cronjobs/status",
"namespaced": true,
"singularName": "",
"verbs": [
"get",
"patch",
"update"
]
},
{
"categories": [
"all"
],
"kind": "Job",
"name": "jobs",
"namespaced": true,
"singularName": "",
"storageVersionHash": "mudhfqk/qZY=",
"verbs": [
"create",
"delete",
"deletecollection",
"get",
"list",
"patch",
"update",
"watch"
]
},
{
"kind": "Job",
"name": "jobs/status",
"namespaced": true,
"singularName": "",
"verbs": [
"get",
"patch",
"update"
]
}
]
}
[root@master1 rbac]#
jsonpath
kubectl get secret cnych-sa-token-gbqm7 -o jsonpath={.data.token} -nkube-system |base64 -d
#因为这个secret里面的token是经过base64加密的，因此dashboard想要使用的话，需要先解密
[root@master1 rbac]#kubectl get secret cnych-sa-token-gbqm7 -o jsonpath={.data.token} -nkube-system |base64 -d
eyJhbGciOiJSUzI1NiIsImtpZCI6Im9hOERROHhuWTRSeVFweG1kdnpXSTRNNXg3bDZ0ZkRDVWNzN0l5Z0haT1UifQ.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJrdWJlLXN5c3RlbSIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VjcmV0Lm5hbWUiOiJjbnljaC1zYS10b2tlbi1nYnFtNyIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50Lm5hbWUiOiJjbnljaC1zYSIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50LnVpZCI6IjQ0NzRlMDkyLWEwNjAtNDZhMi04MDY5LTg4YjRhYWQyNTlkNyIsInN1YiI6InN5c3RlbTpzZXJ2aWNlYWNjb3VudDprdWJlLXN5c3RlbTpjbnljaC1zYSJ9.D_iKDmhTAyvbOPW7FfT_r23r0QXW7vXnr8WTFp7sSHWiwzD6eiMpGyv_Xp-TRrvPdmNDwEhm-FcW8JuaPkesjNbkdaTDg0dW2EbYz3UiCSMd-YBxlbP2au6rqu2PA8EZ8i2EypDZYH6g7n_9IV7x2DVU7wyXdFsDNq1MUZytgtGBYui9xjyb5wE-dMHFZB5nwr-qCqWn1naCLsEVhOJFC4i1Ws_nHktYzY_TealCjnfqXcfwyqHKJ_XZN_-dshiE743eEHQIZvhUsoL5rl68qvWsx6g5YDgekZfJBCRCbFMVbmCTX0YV0Nonzhz876xl0UrT0JnCq5xyUz62fIWJKQ[root@master1 rbac]#
6、xml
- xml格式文件注释方法
方法：
<!-- …… -->
注释前：
注释后：
FAQ
字符串数组概念
<[]string>
数组：一定要有个波折号。
🚩 例子
正常yaml的格式应该是如下这种：
但是也是可以写成如下这种形式的：是没什么问题的
**这个是json类型格式的书写方式的！**需要再次注意下json和yaml之间的格式转换；
🚩 例子
等价于
k8s yaml中资源名称的命名方式
特别注意：
一般k8s资源清单yaml的书写规律：key的命名方式是小驼峰命名法，而value里面涉及资源名称的是大驼峰命名法
建议一律缩进2个空格
你可以有任何数量的项在列表中，每个项的定义以破折号（-）开头的，与父元素之间可以缩进也可以不缩进。
对象数组这2种方式都是可以的，但是推荐前面那种方式(一律缩进2个空格)
- 方法1:
一律缩进2个空格（推荐）
#test-nginx.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deploy
spec:
replicas: 2
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.7.9
ports:
- containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
name: nginx-service
labels:
name: nginx-service
spec:
ports:
- port: 5000
targetPort: 80
selector:
app: nginx
- 方法2：
不缩进
#test-nginx.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deploy
spec:
replicas: 2
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.7.9
ports:
- containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
name: nginx-service
labels:
name: nginx-service
spec:
ports:
- port: 5000
targetPort: 80
selector:
app: nginx
yaml中|、|+、|-和>的用法
ConfigMap 资源对象使用 key-value 形式的键值对来配置数据，这些数据可以在 Pod 里面使用，如下所示的资源清单：
apiVersion: v1
kind: ConfigMap
metadata:
name: cm-demo
namespace: default
data:
data.1: hello
data.2: world
config: |
property.1=value-1
property.2=value-2
property.3=value-3
其中配置数据在 data 属性下面进行配置，前两个被用来保存单个属性，后面一个被用来保存一个配置文件。
注意：yaml中|和>的用法。
这个有点绕啊……🤣
（1）我们可以看到 config 后面有一个竖线符 |，这在 yaml 中表示保留换行 。 每行的缩进和行尾空白都会被去掉(最后一行的空白和换行符会被取掉，前面换行被被保留)，而额外的缩进会被保留。
lines: |
我是第一行
我是第二行
我是吴彦祖
我是第四行
我是第五行
# JSON
{"lines": "我是第一行\n我是第二行\n 我是吴彦祖\n 我是第四行\n我是第五行"}
（2）除了竖线之外还可以使用 > 右尖括号，用来表示折叠换行，只有空白行才会被识别为换行，原来的换行符都会被转换成空格。
lines: >
我是第一行
我也是第一行
我仍是第一行
我依旧是第一行
我是第二行
这么巧我也是第二行
# JSON
{"lines": "我 是第一行 我也是第一行 我仍是第一行 我依旧是第一行\n我是第二行 这么巧我也是第二行"}
（3）除了这两个指令之外，我们还可以使用竖线和加号或者减号进行配合使用，+ 表示保留文字块末尾的换行，- 表示删除字符串末尾的换行。
value: |
hello
hello
# {"value": "hello\nhello"}
value: |-
hello
# {"value": "hello"}
value: |+
hello
# {"value": "hello\n\n"} (有多少个回车就有多少个\n)
关于我
我的博客主旨：
- 排版美观，语言精炼；
- 文档即手册，步骤明细，拒绝埋坑，提供源码；
- 本人实战文档都是亲测成功的，各位小伙伴在实际操作过程中如有什么疑问，可随时联系本人帮您解决问题，让我们一起进步！
🍀 微信二维码
x2675263825 （舍得）， qq：2675263825。
🍀 微信公众号
《云原生架构师实战》
🍀 语雀
https://www.yuque.com/xyy-onlyone
https://www.yuque.com/xyy-onlyone/exkgza?# 《语雀博客》
🍀 博客
🍀 csdn
https://blog.csdn.net/weixin_39246554?spm=1010.2135.3001.5421
🍀 知乎
https://www.zhihu.com/people/foryouone
最后
好了，关于本次就到这里了，感谢大家阅读，最后祝大家生活快乐，每天都过的有意义哦，我们下期见！
1