把音视频服务从单机部署迁移到Kubernetes之后，配置文件的存放位置往往成了第一个让人头疼的问题。AppID、临时Token、推流回调地址、转码模板ID这些信息，如果继续打包进镜像，每次改一个回调URL就要重新构建镜像，泄露风险也随之增加。Kubernetes提供了ConfigMap和Secret两种资源来解决这个问题：前者管理普通配置，后者管理敏感数据，两者配合可以做到配置与镜像彻底解耦。下面先看一张示意图，对整体结构有个直观印象。
为什么音视频服务的配置必须单独管理
音视频应用与其他业务服务相比，配置项有明显的特殊性。首先是数量多：一个典型的RTC服务需要配置AppID、AppCertificate、频道名前缀、Token有效期、鉴权服务器地址；如果涉及旁路推流，还要配置CDN域名、推流重试策略；如果做服务端录制，还有存储桶地址、回调密钥等。其次是敏感程度高：AppCertificate一旦泄露，任何人都可以伪造Token加入你的频道，等于把整个房间的安全防线交了出去。
把这些内容写进代码仓库或镜像，至少带来三个问题。第一，环境无法区分，测试环境和生产环境用同一份配置显然不行，而维护多套镜像的成本又极高。第二，密钥泄露后需要轮换时，你得重新走一遍构建、测试、发布流程，动辄半小时以上，这段时间内攻击者可以持续作恶。第三，镜像会被推送到镜像仓库，任何有仓库读权限的人都能拿到密钥。
ConfigMap和Secret的出现正是为了解决这些痛点。它们都是Kubernetes的API资源，把配置数据独立于Pod存在，通过环境变量或文件挂载的方式注入容器。Pod的YAML只引用ConfigMap的名字，不包含具体值，这样开发环境、预发环境、生产环境可以使用同一份镜像，只替换不同的ConfigMap。
ConfigMap的创建与注入方式详解
ConfigMap用于存放非敏感的普通配置，比如日志级别、编解码偏好、最大码率、SDK区域设置等。最基础的创建方式是直接通过命令行，也可以用YAML声明式管理，后者更适合放进Git做版本控制。
先看一个贴合音视频场景的例子，把RTC初始化相关的普通配置做成ConfigMap：
apiVersion: v1
kind: ConfigMap
metadata:
name: rtc-config
namespace: media
data:
RTC_APP_ID: "your-app-id"
RTC_REGION: "CN"
LOG_LEVEL: "info"
MAX_VIDEO_BITRATE: "1200"
AUDIO_SAMPLE_RATE: "48000"
# 复杂结构化配置可以用文件形式存放
encoder.json: |
{
"video": {
"codec": "H264",
"width": 1280,
"height": 720,
"fps": 30
},
"audio": {
"codec": "AAC",
"channels": 2
}
}
注入Pod有两种主流方式。第一种是环境变量，通过envFrom批量引入，适合简单的键值对；第二种是文件挂载，把encoder.json这样的结构化配置挂载到容器内路径，应用按普通文件读取。文件挂载的好处是天然支持复杂格式，Go、Java、C++的各种配置库都能直接解析，而且配合滚动更新，改配置不需要改代码。
apiVersion: apps/v1
kind: Deployment
metadata:
name: rtc-server
namespace: media
spec:
replicas: 3
selector:
matchLabels:
app: rtc-server
template:
metadata:
labels:
app: rtc-server
spec:
containers:
- name: rtc-server
image: registry.ippipp.com/media/rtc-server:v1.4.2
envFrom:
- configMapRef:
name: rtc-config
volumeMounts:
- name: encoder-config
mountPath: /etc/rtc/encoder.json
subPath: encoder.json
volumes:
- name: encoder-config
configMap:
name: rtc-config
这里有一个非常容易踩的坑需要重点说明：如果你希望应用能感知配置热更新，就不要用subPath方式挂载。Kubernetes对ConfigMap的热更新依赖符号链接切换机制，而subPath挂载的文件不会随之更新，只有容器重启才能读到新值。对于运行期读取一次就不再变化的初始化参数，用subPath没问题；对于需要动态调整的开关项，建议挂载整个目录，并让应用定期校验文件的mtime或inode变化。
另外要注意环境变量方式本身不支持热更新，环境变量在容器启动时就固定了。如果你的音视频网关需要动态调整码率上限，这类配置应走文件挂载或自建的控制通道，而不是依赖环境变量。
Secret的正确用法与常见误区
AppCertificate、对象存储的AccessKey、回调签名密钥这类数据应该放进Secret。Secret与ConfigMap在用法上几乎一致，唯一的区别是数据字段经过Base64编码存放。创建时同样推荐声明式写法：
# 方式一：命令行直接创建，适合快速验证 kubectl create secret generic rtc-secret \ --namespace=media \ --from-literal=app-certificate=xxxxxxxxxxxxxxxx \ --from-literal=callback-sign-key=yyyyyyyyyyyyyyyy # 方式二：对字符串做Base64后写进YAML echo -n 'xxxxxxxxxxxxxxxx' | base64
apiVersion: v1 kind: Secret metadata: name: rtc-secret namespace: media type: Opaque data: # value是base64后的结果 app-certificate: eHh4eHh4eHh4eHh4eHh4eHh4 callback-sign-key: eXl5eXl5eXl5eXl5eXl5eXl5
使用时要认清一个广泛存在的误区：Base64不是加密。Base64只是编码，任何人拿到这段数据执行一次解码就能看到原文。Secret的安全边界在于Kubernetes的RBAC权限控制，而不是编码本身。因此务必做好三件事：一是通过RoleBinding限制只有特定ServiceAccount能读取该Secret；二是开启etcd的加密存储（配置EncryptionConfiguration）；三是如果安全要求更高，接入外部密钥管理系统，例如Vault或各大云厂商的KMS，通过CSI驱动把密钥以卷的形式挂进来，集群里就完全不落盘明文。
注入方式上，Secret同样支持环境变量和文件挂载。对于音视频场景，我更推荐文件挂载，理由有两个：一是环境变量会出现在kubectl describe的输出和某些崩溃日志收集器里，增加泄露面；二是文件挂载配合最小文件权限（defaultMode: 0400）可以进一步收窄读取范围。
volumeMounts:
- name: rtc-secret-vol
mountPath: /etc/rtc/secret
readOnly: true
volumes:
- name: rtc-secret-vol
secret:
secretName: rtc-secret
defaultMode: 0400
落地建议：分层设计与多环境管理
实际项目里，建议把配置按变更频率和敏感程度分成三层：第一层是镜像内置的默认配置，作为兜底；第二层是ConfigMap，存放各环境差异化的普通参数；第三层是Secret或外部KMS，只放凭证类数据。应用启动时按优先级从高到低覆盖，这样本地调试、测试环境、生产环境可以用同一套代码逻辑。
多环境隔离推荐用namespace加后缀命名，例如rtc-config-test、rtc-config-prod，配合Kustomize的nameSuffix或Helm的values文件统一管理，避免手工维护多份几乎相同的YAML。对于Token这类需要频繁轮换的凭证，更好的做法是让Pod通过RBAC授权的ServiceAccount去访问API动态获取，或者干脆部署一个专门的Token签发服务，Secret里只存签发服务的访问凭证，实现一次轮换、全局生效。
最后补充一点运维层面的经验：无论是ConfigMap还是Secret，都应该纳入GitOps流程管理，普通配置明文进Git，Secret则用Sealed Secrets或SOPS加密后进Git，保证配置变更有据可查、可回滚。音视频服务对可用性极其敏感，一次配置错误可能导致整个频道的用户全部掉线，版本化的配置管理配合灰度发布，是控制这类风险最有效的手段。
ConfigMapSecretKubernetes配置管理修改时间：2026-09-04 14:34:51