工作负载

ConfigMap 把非敏感配置放在镜像之外，让环境相关设置发生变化时，不必重新构建应用产物。真正有用的边界需要明确：镜像提供代码，工作负载定义则指定这些代码应该读取哪份配置。因此，一次发布不仅是一个镜像标签，配置引用同样属于正在交付的行为。只记录镜像版本，可能无法解释两个环境为什么表现不同。 配置引用属于发布的一部分。图示解释历史选择和依赖旧输入的回退，不证明应用兼容性、滚动期间可用性或外部副作用回滚。本次未重跑示例。 给配置一个可审阅的身份 ConfigMap 的 data 值是字符串，也可以通过 binaryData 表达二进制内容及其 API 编码形式。它适合小规模配置，数据大小有一 MiB 限制，不是通用文件仓库，更不是保护秘密的机制。API 能检查对象结构，却不知道某个应用参数在业务上是否合理。因此，结构合法和业务正确仍需分别验证，不能以创建成功代替配置审查。 Pod 可以通过环境变量引用或挂载文件消费配置。普通 Pod 引用要求 ConfigMap 位于这个 Pod 所在的命名空间。名称、必需键和应用解释方式都应明确。Deployment 对象被 API 接受，并不证明它引用的每个键都存在，也不证明新容器能够带着这些值成功启动。发布检查必须继续观察真实工作负载的结果。 单位、允许值与默认值应属于应用配置规范。某个字符串看起来像布尔值或数字，并不说明接收方会采用什么转换规则。在不同环境之间推广配置之前，需要结合真实消费者检查这些规则，避免同一份文本被解释成不同业务含义。 版本化的不可变 ConfigMap 更容易表达发布身份。settings-v2 可以与 settings-v1 同时保留，而 immutable 会禁止修改当前对象的数据。但这项保护不阻止有权限的操作者删除对象，再用同名重新创建另一份内容。对象生命周期权限和发布记录，应与希望实现的不可变承诺一致，不能把一个字段理解成所有可能路径都被永久封闭。 ...

与其描述步骤，不如描述终态。这条思想支撑起副本、滚动更新与回滚的一切机制。 数量序列解释原文的本地算术模型。真实控制器各有职责，异步协调也可能受阻。历史模型通过记录保持不变；本次未重跑示例。 声明规范胜过过程脚本 一份 Deployment 是「终态」的陈述,而不是一张命令清单:多少副本、哪个镜像、哪条 tag、什么标签。操作者写下「要什么」,控制器这位 reconcile 循环决定「怎么要」。区别在于资源所有权，而不是有没有使用命令行。kubectl run 通常创建独立 Pod，kubelet 可以重启其中容器，但这个 Pod 消失后，没有 ReplicaSet 负责补足一组替代对象。Deployment 同样可以通过一条命令创建，客户端退出之后，存储下来的规范仍会持续指导控制器。中断客户端并不能可靠说明 API 是否已经接纳请求；重试或诊断收敛之前，先查看实际存储的对象，区分请求传递状态与控制器执行状态。 由控制器填补差距 Deployment 控制器管理 ReplicaSet，再由副本集控制器维持 Pod 数量。容器崩溃时，kubelet 可以在同一个 Pod 内重启容器；删除或丢失 Pod 后创建替代对象，则是另一条协调路径。它们会配合工作，但不能都说成同一个控制器每隔几秒创建一个 Pod，否则无法区分实例身份、重启与替换。 ...