一. 简介
Pod总是需要定义过多重复的字段，本着万物皆可“抽象化，模版化”的思维，衍生出了PodPreset功能。Preset 就是预设，有时候想要让一批容器在启动的时候就注入一些信息，比如 secret、volume、volume mount 和环境变量，而又不想一个一个的改这些 Pod 的 tmeplate，这时候就可以用到 PodPreset 这个资源对象了。该对象用来在 Pod 创建的时候向 Pod 中注入某些特定信息。该信息可以包括 secret、volume、volume mount 和环境变量。
PodPreset（Pod 预设置）的功能从 v1.11 版本开始出现，但是又在 v1.20 版本取消。
关于本文的案例，都在此链接中：GitHub地址
二. 原理
2.1 场景
Pod Preset 是用来在 Pod 被创建的时候向其中注入额外的运行时需求的 API 资源。可以使用 label selector 来指定为哪些 Pod 应用 Pod Preset。使用 Pod Preset 使得 pod 模板的作者可以不必为每个 Pod 明确提供所有信息。这样一来，pod 模板的作者就不需要知道关于该服务的所有细节。
2.2 开启
如果版本较新，需要主动开启PodPreset功能。
-
开启API
在apiserver配置文件中增加--runtime-config=settings.k8s.io/v1alpha1/podpreset -
开启准入控制器
在apiserver配置文件中增加--admission-control=PodPreset
2.3 工作机制
当有 Pod 创建请求发生时，系统将执行以下操作：
- 检索所有可用的 PodPresets。
- 检查 PodPreset 标签选择器上的标签，看看其是否能够匹配正在创建的 Pod 上的标签。
- 尝试将由 PodPreset 定义的各种资源合并到正在创建的 Pod 中。
- 出现错误时，在该 Pod 上引发记录合并错误的事件，PodPreset 不会注入任何资源到创建的 Pod 中。
- 注释刚生成的修改过的
Pod spec，以表明它已被 PodPreset 修改过。
注释的格式为：
podpreset.admission.kubernetes.io/podpreset-<pod-preset name>": "<resource version>"
每个 Pod 可以匹配零个或多个 Pod Prestet，并且每个 PodPreset 可以应用于零个或多个 Pod。 PodPreset 应用于一个或多个 Pod 时，Kubernetes 会修改 Pod Spec。
- 对于 Env、EnvFrom 和 VolumeMounts 的更改，Kubernetes 修改 Pod 中所有容器的容器 spec。
- 对于 Volume 的更改，Kubernetes 修改 Pod Spec。
三. 流程
3.1 编写Preset YAML
案例PodPreset YAML如下：
apiVersion: settings.k8s.io/v1alpha1
kind: PodPreset
metadata:
name: demo-podpreset
spec:
selector:
matchLabels:
role: developer
volumeMounts:
- mountPath: /cache
name: cache-volume
volumes:
- name: cache-volume
emptyDir: {}
在这个 PodPreset 的定义中，首先是一个 selector。这就意味着后面这些追加的定义，只会作用于selector 所定义的、带有“role: developer”标签的 Pod 对象，这就可以防止“误伤”。
上面定义了一组 Pod 的 Spec 里的标准字段，以及对应的值。volumeMounts 定义了容器 Volume 的挂载目录，volumes 定义了一个 emptyDir 的 Volume。
3.2 配置Pod YAML
案例的Pod YAML文件如下：
apiVersion: v1
kind: Pod
metadata:
name: test-web
labels:
app: test-web
role: developer
spec:
containers:
- name: website
image: nginx
ports:
- containerPort: 80
3.3 运行
执行时候需要注意顺序，先执行PodPrest相关YAML创建，再执行Pod相关YAML创建。指令如下
kubectl apply -f test-web-podpreset.yaml
kubectl apply -f test-web.yaml
3.4 检查
我们通过使用kubectl get pod指令来检查最终Pod的具体YAML配置。指令如下：
kubectl get pod test-web -o yaml
# 查询结果
apiVersion: v1
kind: Pod
metadata:
name: test-web
labels:
app: test-web
role: developer
annotations:
podpreset.admission.kubernetes.io/podpreset-allow-database: "resource version"
spec:
containers:
- name: website
image: nginx
volumeMounts:
- mountPath: /cache
name: cache-volume
ports:
- containerPort: 80
volumes:
- name: cache-volume
emptyDir: {}
3.5 分析
我们就可以清楚地看到，这个 Pod 里多了新添加的 labels、volumes 和 volumeMount 的定义，它们的配置跟 PodPreset 的内容一样。
此外，这个 Pod 还被自动加上了一个 annotation 表示这个 Pod 对象被 PodPreset 改动过。
PodPreset 里定义的内容，只会在 Pod API 对象被创建之前追加在这个对象本身上，而不会影响任何 Pod 的控制器的定义。
当定义了同时作用于一个 Pod 对象的多个 PodPreset时，Kubernetes 项目会帮合并（Merge）这两个 PodPreset 要做的修改。而如果它们要做的修改有冲突的话，这些冲突字段就不会被修改。
四. 总结
PodPreset 是专门用来对 Pod 进行批量化、自动化修改的工具对象，这也是Kubernetes“一切皆对象”的设计思想的体现。我们还是需要理清楚这些组件的功能，Kubernetes提供了一堆的积木，至于实现什么样的功能还是取决于真实的场景。
不得不说，关于纯粹的CRUD人员要有危机感，Kubernetes真的会消灭掉很多低级和低效岗位。
最后，欢迎关注我的博客：https://blog.wyatt.plus
Reference
https://time.geekbang.org/discuss/detail/28180
https://v1-18.docs.kubernetes.io/docs/concepts/workloads/pods/podpreset/
网友评论