binaryData 是什么
ConfigMap 的 data 字段只接受合法 UTF-8 文本，塞入图片、压缩包这类二进制内容会被 API Server 直接拒绝。binaryData 是与之并列的补充字段：它的值必须是 base64 编码后的字符串，落库时再解成字节序列。kubectl 读写 YAML 时会自动做 base64 转换，所以命令行上看到的是编码文本，程序里拿到的是原始字节。两个字段的键名互斥，同一个键不能既在 data 又在 binaryData 里。
基本信息
| 所属 API | core/v1 的 ConfigMap，字段位于顶层，与 data 并列 |
|---|---|
| 值格式 | base64 编码字符串，不能带换行或空格 |
| 键名规则 | 字母、数字、减号、下划线、点；且不能与 data 中的键重名 |
| 容量上限 | 单个 ConfigMap 全部键值合计 1MiB |
| 消费方式 | 卷挂载（还原为字节）、envFrom / configMapKeyRef、subPath、projected |
典型使用场景
- 随配置下发小图标、字体片段、二进制测试向量，省掉一个镜像层
- 联调期放一段证书或密钥材料，正式环境仍应换成 Secret（Secret 能独立限制读取权限）
- 用 subPath 只覆盖某个目录里的单个二进制文件，不动同目录其他内容
- 用 kubectl create configmap --from-file 直接吸入二进制文件，由 kubectl 自动改用 binaryData
- 把 base64 文本作为数据源交给应用自行解码，避免应用依赖文件系统挂载
binaryData 声明
binaryData 声明
apiVersion: v1
kind: ConfigMap
metadata:
name: assets
binaryData:
logo.png: iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAYAAAAfFcSJAAAADUlEQVR42mP8z8BQDwAEhQGAhKmMIQAAAABJRU5ErkJggg== # 单行 base64，不能折行
immutable: true # 可选项：禁止误改，但设成 true 后不可回退生成与校验
生成与校验
base64 -w0 logo.png > logo.b64 # GNU coreutils 生成单行 base64；macOS 用 base64 -i logo.png -o logo.b64
kubectl create configmap assets --from-file=logo.png # kubectl 检测到非 UTF-8 会自动写进 binaryData
kubectl get cm assets -o jsonpath="{.binaryData['logo.png']}" | base64 -d | cmp - logo.png # 逐字节比对，无输出即一致
kubectl create configmap assets --from-file=logo.png --dry-run=client -o yaml # 先出模板再手工加 immutable 等字段data 与 binaryData 对照
| 字段 | 值的要求 | 卷挂载后的内容 | 环境变量注入后 |
|---|---|---|---|
| data | 合法 UTF-8 文本 | 与值完全一致 | 与值完全一致，支持 envFrom 批量注入 |
| binaryData | base64 字符串，API 层会校验 | 解码后的原始字节 | 不保证按原始字节还原，不建议用于二进制 |
更新 ConfigMap 后，卷挂载的文件会由 kubelet 周期性同步（通常一分钟内生效，具体间隔由 kubelet 的 sync 配置与缓存决定）；通过环境变量注入的值不会随更新变化，必须重建 Pod。subPath 挂载的文件同样不会收到更新。
1MiB 是硬上限，超限直接创建失败，不会自动截断。ConfigMap 存放在 etcd 里，内容越大会同步放大 etcd 体积与 watch 压力；镜像、大字体、模型权重这类内容应走镜像层或对象存储，用 initContainer 拉取。
base64 只是编码不是加密：任何拥有该 ConfigMap 读权限的对象都能还原出原文。密钥、私钥、口令应放入 Secret，通过 RBAC 单独收紧读取权限。