资源清单

k8s 集群中的应用通常由多个资源对象组成，每个资源对象都有自己的定义和配置。k8s 提供2种方式来定义和配置资源对象
第1种是命令式，就是通过k8s提供的命令 kubectl 对资源对象进操作。

第2种式声明式，把资源对象的特征按要求记录在资源清单文件中，这个文件是 YAML 或 JSON 格式。然后通过 kubectl 命令来操作资源对象。

除了测试，大部分都是用资源清单

创建资源清单文件

资源清单文件的内容很多。一个基础的资源清单内容如下

1
2
3
4
5
6
7
8
9
---
apiVersion: v1  # 资源对象版本
Kind: Pod # 资源对象类型
metadata: # 元数据
  name: nginx # 资源对象名称
spec: # 资源对象配置
  containers: # 容器列表
  - name: nginx # 容器名称
    image: nginx:1.14.2 # 镜像名称

这么多的内容，手敲很麻烦，k8s 可以由命令来生产资源清单配置

1
2
3
4
5
kubectl create deployment hello-openshift -o yaml \ 
  --image registry.ocp4.example.com:8443/redhattraining/hello-world-nginx:v1.0 \
  --save-config \ 
  --dry-run=client \ 
  > ~/my-app/example-deployment.yaml

上面这条命令的选项 --dry-run=client 表示只生成资源清单文件，不执行任何操作。-o yaml 表示生成 YAML 格式的资源清单文件。最后将生成的配置重定向到 ~/my-app/example-deployment.yaml 文件中。这样就简单多了。所以需要我们能看懂资源清单的定义语法。这是很重要的。

当然了，除了用 --dry-run=client 选项外，我们也可以查看 kubernetes 的官网来获得最全的资源清单配置。Open
Shift 的Web控制台也提供了使用资源的YAML 视图。

生成的配置文件也不一定符合我们的要求，可以自己增删内容。

最开始我们说应用是多个资源对象的组合。现在我们只有一个资源对象，那怎么创建多个资源对象呢？ 也有2种方式。
第1种是把多个资源清单文件放在一个目录下，然后通过 kubectl create -f 命令添加 –recursive=true 或 -R 选项，以递归方式处理多个子目录中提供的资源文件(这个目录下以及子目录的所有清单文件都会被处理)

1
2
3
4
5
6
7
8
9
[user@host ~]$ tree my-app
my-app
├── example_deployment.yaml
└── service
    └── example_service.yaml

[user@host ~]$ kubectl create -R -f ~/my-app
deployment.apps/hello-openshift created
service/hello-openshift created

第2种是把多个清单文件的内容放在一个文件中，用 kubectl create -f 命令处理。这个方式要注意的是，每个资源对象需要用 — 行作为分隔

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
---
apiVersion: apps/v1
kind: Deployment
metadata:
  namespace: resource-manifests
  annotations:
  ...output omitted...
---
apiVersion: v1
kind: Service
metadata:
  namespace: resource-manifests
  labels:
    app: hello-openshift
  name: hello-openshift
spec:
  ...output omitted...

更新资源

当我们需要对已经创建的资源对象做修改时，要用到 kubectl apply 命令来更新资源。

kubectl apply 命令也可以来创建资源对象。作用跟 kubectl create 命令一样，但是 apply 命令会检查资源对象是否存在，如果存在则更新，不存在则创建。

更新资源比创建资源更复杂。​kubectl apply 命令实施了多种技术来应用更新且不会导致问题。​

kubectl apply 命令将配置文件的内容写入到 kubectl.kubernetes.io/last-applied-configuration 注释。​kubectl create 命令也可以通过使用 –save-config 选项生成此注释。​kubectl apply 命令使用 last-applied-configuration 注释来标识已从配置文件中删除并且必须从实时配置中清除的字段。​

虽然 kubectl create -f 命令可以从清单创建资源，但命令是命令式的，因此不考虑活动资源的当前状态。​对实时资源的清单执行 kubectl create -f 会出错。​相比之下，kubectl apply -f 命令是声明式的，会考虑集群中当前资源状态与清单中表示的预期资源状态之间的差异。

YAML 验证

在操作之前，可以用 --dry-run=server 和 --validate=true 标志来检查文件是否有错误。

  • --dry-run=server 选项提交服务器端请求，但不持久保留资源。​
  • --validate=true 选项使用模式来验证输入，如果输入无效，则请求失败。
1
2
3
4
[user@host ~]$ kubectl apply -f ~/my-app/example-deployment.yaml \
  --dry-run=server --validate=true
...output omitted...
deployment.apps/hello-openshift created (server dry-run)

以 (server dry-run) 结尾的输出行提供了应用资源文件将执行的操作。

--dry-run=server 和 --dry-run=client 选项的区别：--dry-run=server 提交服务器端请求，但不持久保存资源。--dry-run=client 仅检查输入，但不提交请求。

比较资源

kubecel diff 命令可以查看文件的差异。 - 表示删除，+ 表示添加。这可以反应资源的更新变化。

应用更改

那么什么时候会更新资源呢？ kubectl apply 比较三个来源

  1. 清单文件
  2. 集群中资源的实时配置
  3. 存储在 last-applied-configuration 注释中的配置

如果清单文件中指定的资源不存在，则 kubectl apply 命令创建该资源。​如果实时资源的 last-applied-configuration 注释中的任何字段不在清单中，则命令将从实时配置中删除这些字段。​将更改应用到实时资源后，kubectl apply 命令会更新实时资源的 last-applied-configuration 注释以考虑更改。​

创建资源时，kubectl create 命令的 –save-config 选项会生成所需的注释，供将来的 kubectl apply 命令操作。​