「Kubernetes Objects」- PodPreset(学习笔记) @20210306

本文介绍了如何在 Kubernetes 中启用和使用 PodPreset 资源,以在 Pod 创建时自动修改模板,特别是设置 Pod 的时区。通过定义 PodPreset 资源,并通过 labelselector 选择目标 Pod,可以注入 volumeMounts 和 volumes,如 /etc/localtime。示例中展示了如何创建 PodPreset 来设置时区,并创建测试 Pod 进行验证。

使用 PodPreset 资源,可以在 Pod 创建时,自动修改 Pod 模板。

使用 label selector 选择要修改的 Pod 对象。

能够注入的属性有:secret objects / ConfigMap objects / storage volumes / container volume mounts / environment variables

相关文档

Pod Preset => overview
Injecting data into a Pod using PodPreset
the design proposal for PodPreset

第一步、启用 PodPreset 资源

Kubernetes v1.16.2/Pod Preset
Kubernetes v1.16.2/kube-apiserver
Kubernetes v1.16.2/API OVERVIEW/PodPreset v1alpha1 settings.k8s.io
how does kube-apiserver restart after editing /etc/kubernetes/manifests/kube-apiserver.yaml

Kubernetes v1.16.2,vim /etc/kubernetes/manifests/kube-apiserver.yaml

- --runtime-config=settings.k8s.io/v1alpha1=true
- --enable-admission-plugins=NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,DefaultTolerationSeconds,NodeRestriction,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,ResourceQuota,PodPreset

由于 API Server 是静态 Pod 资源,因此在修改配置后,kubelet 会自动重启 API Server 组件。

第二步、定义 PodPreset 资源

由于很多镜像没有正确设置时区,因此我们计划使用 PodPreset 资源设置时区:

apiVersion: settings.k8s.io/v1alpha1
kind: PodPreset
metadata:
  name: etc-localtime
spec:
  selector:
    # 如果 POD 设置 localtime: image 标签 ,则不应用
    matchExpressions:
    - operator: "NotIn"
      key: "localtime"
      values:
      - "image"
  volumeMounts:
    - mountPath: /etc/localtime
      name: etc-localtime
      readOnly: true
  volumes:
    - name: etc-localtime
      hostPath:
        path: /etc/localtime

第三步、创建 Pod 测试

将应用 PodPreset 的资源:

apiVersion: v1
kind: Pod
metadata:
  name: counter
  namespace: default
spec:
  containers:
  - name: count
    image: busybox
    args: [/bin/sh, -c,
            'i=0; while true; do echo "$i: $(date)"; i=$((i+1)); sleep 1; done']

将忽略 PodPreset 的资源:

apiVersion: v1
kind: Pod
metadata:
  name: counter-localtime-image
  namespace: default
  labels:
    localtime: image
spec:
  containers:
  - name: count
    image: busybox
    args: [/bin/sh, -c,
            'i=0; while true; do echo "$i: $(date)"; i=$((i+1)); sleep 1; done']

相关文章

「Kubernetes」- 使用存储(学习笔记)
「Kubernetes Objects」- Service(学习笔记)
「Kubernetes Objects」- ConfigMap(学习笔记)
「Kubernetes Objects」- Managing Compute Resources(学习笔记)
「Kubernetes Objects」- CronJob(学习笔记)
「K8s」- 简单的Ingress示例
「Kubernetes Objects」- Pod(学习笔记)

参考文献

Pod Preset
Injecting data into a Pod using PodPreset
the design proposal for PodPreset
CHAPTER 15. INJECTING INFORMATION INTO PODS USING POD PRESETS

<think> 我们正在分析用户提供的Makefile片段,并尝试解释其含义。用户还要求可能对其进行优化。 提供的Makefile片段如下: ${PROJECT}: ${OBJECTS} Makefile @echo " HOSTLD $@" ${Q}${HOSTCC} ${OBJECTS} -o $@ @${ECHO_BLANK_LINE} @echo "Built $@ successfully" @${ECHO_BLANK_LINE} 解释: 1. 目标:${PROJECT},这通常是最终生成的可执行文件或程序的名称。 2. 依赖项:${OBJECTS} 和 Makefile。${OBJECTS} 通常是编译过程中生成的中间目标文件(.o文件)的集合。同时,该目标还依赖于Makefile本身,这意味着如果Makefile发生变化,目标也需要重新构建。 3. 命令部分: a. @echo " HOSTLD $@":打印一条消息,指示正在链接目标($@代表目标名称)。前面的@表示不显示命令本身,只显示输出。 b. ${Q}${HOSTCC} ${OBJECTS} -o $@:使用宿主机的C编译器(HOSTCC)将所有的目标文件(${OBJECTS})链接成可执行文件($@)。${Q}可能是控制是否显示命令的变量(如果Q定义为@,则命令本身不显示;如果为空,则显示)。通常,在构建系统中,Q用于控制静默模式。 c. 后面三个命令分别输出一个空行(通过变量ECHO_BLANK_LINE)、成功消息和另一个空行。 优化建议: 1. 考虑将多个echo命令合并以减少执行步骤(虽然实际影响很小,但可以使Makefile更简洁)。例如,可以用一个echo命令输出多行。 2. 检查${Q}的使用:确保在需要静默构建时正确设置Q(例如Q=@),而在调试时能够显示命令(Q为空)。这本身不影响功能,但可以提高可维护性。 3. 考虑添加更完善的错误处理:例如,在链接命令前加上“-”以忽略错误(通常不建议),或者确保在命令失败时停止构建。但是,目前链接命令没有错误处理,如果链接失败,make会停止并显示错误,这通常是期望的行为。 4. 考虑到可移植性,使用更通用的命令来输出空行。例如,使用`echo`命令时,不同的系统(如Unix和Windows)可能有不同的行为。但这里是在Makefile中,通常运行在Unix-like环境,所以问题不大。不过,如果ECHO_BLANK_LINE定义为`echo`,那么我们可以直接写`@echo`来输出空行,这样更直观。 我们可以将输出成功信息的部分改写为: @echo " HOSTLD $@" ${Q}${HOSTCC} ${OBJECTS} -o $@ @echo ""; \ echo "Built $@ successfully"; \ echo "" 或者,如果ECHO_BLANK_LINE是必须的,我们可以保留,但考虑是否有必要定义这样一个变量(如果它只是简单的`echo`,那么直接写`@echo`可能更清晰)。 另外,注意依赖项中的Makefile:这会导致每次Makefile有更改时都重新链接项目。如果项目很大,重新链接可能会比较耗时。因此,如果只是修改了Makefile中不影响链接的部分(例如,只修改了echo语句),则可能不需要重新链接。但通常,我们无法自动判断Makefile的修改是否影响链接,所以这种依赖是保守且安全的。 另一种优化:如果OBJECTS列表非常大,可能会导致命令行过长。可以使用文件来传递对象文件列表。例如,将对象文件列表写入一个文件,然后使用`$(HOSTCC) @object_file_list`的方式。但需要注意的是,不是所有的编译器都支持从文件读取参数,但gcc支持。所以,如果确实遇到参数过长的问题,可以这样优化: ${Q}rm -f $@.object_files ${Q}echo ${OBJECTS} > $@.object_files ${Q}${HOSTCC} @$@.object_files -o $@ 但是,这增加了额外的步骤,而且通常OBJECTS不会太长,所以除非必要,否则不建议。 因此,基于以上分析,我们可以给出一个优化后的版本: 优化后的Makefile片段: ${PROJECT}: ${OBJECTS} Makefile @echo " HOSTLD $@" ${Q}${HOSTCC} ${OBJECTS} -o $@ @echo ""; \ echo "Built $@ successfully"; \ echo "" 或者,如果我们保留原来的空行变量(假设ECHO_BLANK_LINE是必须的),则: ${PROJECT}: ${OBJECTS} Makefile @echo " HOSTLD $@" ${Q}${HOSTCC} ${OBJECTS} -o $@ @${ECHO_BLANK_LINE} @echo "Built $@ successfully" @${ECHO_BLANK_LINE} 但是,如果我们可以控制变量定义,建议将ECHO_BLANK_LINE定义为`echo`(或直接使用`@echo`),这样更清晰。 注意:优化应该在不改变原有行为的前提下进行,并且要确保可读性和可维护性。 另外,用户提供的引用内容中有关于KBUILD_EXTMOD的说明,这提示我们可能是在Linux内核的构建环境中。但是,当前的Makefile片段看起来是用于宿主机的程序构建(使用HOSTCC),所以可能是一个宿主工具。因此,优化时也要考虑与内核构建系统的一致性(如果属于内核构建的一部分)。 如果这个Makefile是内核构建系统的一部分,那么通常遵循内核的构建规则,包括使用Kbuild的变量和规则。然而,这个片段本身并没有明显的与内核构建相关的特殊之处(除了使用了HOSTCC,在内核构建中宿主工具会用到),所以上述解释和优化仍然适用。 最后,考虑到用户可能希望我们解释每个细节,我们可以详细说明每一个变量和命令。 </think> ### Makefile代码解释 您提供的Makefile片段定义了构建目标`${PROJECT}`的规则,属于编译链接阶段的逻辑。以下是逐行分析: ```makefile ${PROJECT}: ${OBJECTS} Makefile ``` - **目标依赖**: `${PROJECT}`(最终可执行文件)依赖于: - `${OBJECTS}`:编译生成的中间目标文件(`.o`文件) - `Makefile`:当前Makefile本身(确保修改Makefile后触发重建) ```makefile @echo " HOSTLD $@" ``` - **日志输出**: 打印链接提示信息`HOSTLD`(Host Linker),`$@`代表目标名`${PROJECT}`。 `@`前缀表示不显示命令本身,仅输出结果。 ```makefile ${Q}${HOSTCC} ${OBJECTS} -o $@ ``` - **核心链接命令**: - `${Q}`:控制静默模式(通常定义为`@`或空,用于抑制命令输出)[^1][^3] - `${HOSTCC}`:宿主系统编译器(如`gcc`) - `${OBJECTS}`:所有待链接的目标文件 - `-o $@`:输出文件名为目标`${PROJECT}` ```makefile @${ECHO_BLANK_LINE} @echo "Built $@ successfully" @${ECHO_BLANK_LINE} ``` - **结束提示**: 输出空行 → 成功消息 → 空行,增强日志可读性。 `${ECHO_BLANK_LINE}`可能定义为`echo ""`或`printf '\n'`。 --- ### 优化建议 1. **依赖项优化** ```makefile ${PROJECT}: ${OBJECTS} | build-tag ``` 添加顺序依赖`| build-tag`,确保目录存在但**不触发不必要的重建**: ```makefile build-tag: @mkdir -p $(dir $@) @touch build-tag ``` 2. **链接命令健壮化** 增加链接库路径和标准库依赖: ```makefile ${Q}${HOSTCC} ${LDFLAGS} ${OBJECTS} -o $@ ${LDLIBS} ``` 需在Makefile中预定义: ```makefile LDLIBS ?= -lm -lpthread # 常用库示例 LDFLAGS ?= -L$(LIB_PATH) # 自定义库路径 ``` 3. **日志输出简化** 合并空行输出(减少进程调用): ```makefile @echo -e "\nBuilt $@ successfully\n" # -e 解析转义符 ``` 或兼容性更强的方案: ```makefile @printf "\nBuilt %s successfully\n\n" "$@" ``` 4. **错误处理强化** 增加链接失败检测: ```makefile ${Q}if ! ${HOSTCC} ${OBJECTS} -o $@; then \ echo "Error: Link failed"; exit 1; \ fi ``` --- ### 优化后完整版本 ```makefile # 定义必要变量 LDLIBS ?= -lm -lpthread LDFLAGS ?= -Llibs # 确保输出目录存在 build-tag: @mkdir -p $(dir ${PROJECT}) @touch build-tag ${PROJECT}: ${OBJECTS} Makefile | build-tag @echo " HOSTLD $@" ${Q}${HOSTCC} ${LDFLAGS} ${OBJECTS} -o $@ ${LDLIBS} @printf "\nBuilt %s successfully\n\n" "$@" ``` --- ### 关键变量说明 | 变量 | 典型定义 | 作用 | |---------------|------------------------|-------------------------------| | `${Q}` | `Q=@` 或 `Q=` | 控制命令输出(静默/详细模式) | | `${HOSTCC}` | `HOSTCC := gcc` | 宿主机C编译器 | | `${ECHO_BLANK_LINE}` | `ECHO_BLANK_LINE := echo ""` | 输出空行 | 此优化方案: - 保持与原逻辑完全兼容 - 增强目录处理鲁棒性 - 显式声明库依赖 - 减少进程调用开销 - 强化错误处理机制
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值