不能直接在HTML里写死集群信息，因为Kubernetes中Pod IP、服务名等元数据是运行时动态分配的，构建阶段不可知；硬编码会破坏“一次构建、多环境部署”原则，导致镜像无法复用。
为什么不能直接在 HTML 里写死集群信息
因为容器化部署（尤其是 Kubernetes）中，Pod 的 IP、服务名、命名空间、节点名等 Metadata 是运行时动态分配的，构建阶段根本不可知。如果在构建时把 cluster-name: prod-us-east 这类值硬编码进 index.html，会导致镜像无法复用于测试/灰度环境，也违背了“一次构建、多环境部署”的核心原则。
用 Nginx 的 sub_filter 在响应时替换占位符
这是最轻量、无需改前端代码的方案：在 Nginx 配置中启用 sub_filter，把 HTML 响应体里的占位符（如 %%CLUSTER_NAME%%）实时替换成从环境变量或 Downward API 注入的值。
关键点：
- 前端构建时保留占位符，例如在
index.html中写：<script>window.CLUSTER = "%%CLUSTER_NAME%%";</script> - 在
nginx.conf中开启sub_filter并设置变量来源：env CLUSTER_NAME; location / { sub_filter '%%CLUSTER_NAME%%' '$CLUSTER_NAME'; sub_filter_once off; sub_filter_types text/html; } - Deployment 中通过 Downward API 把 Pod Metadata 注入容器环境：
env: - name: CLUSTER_NAME valueFrom: fieldRef: fieldPath: metadata.labels['kubernetes.io/cluster-name']
用 initContainer 预处理 HTML 文件
适用于需要注入多个字段（如 namespace、podIP、nodeName）且不希望依赖 Nginx 模块的场景。initContainer 在主容器启动前运行，把占位符替换成真实值。
立即学习“前端免费学习笔记（深入）”；
常见错误：
- 忘记给 initContainer 设置
volumeMounts，导致无法读写主容器的静态资源目录 - HTML 文件被压缩（如 gzip），
sed替换失败 —— 必须确保原始 HTML 是未压缩的文本 - 使用
envFrom直接注入所有 Downward API 字段，但部分字段（如status.hostIP）在 initContainer 阶段可能尚未就绪
推荐做法是只注入确定可用的字段：metadata.namespace、metadata.name、metadata.labels，并用 jq 或简单 sed 处理。
前端构建阶段用 env-cmd + REACT_APP_* 类变量的风险
很多人误以为在 CI/CD 流水线里用 REACT_APP_CLUSTER_NAME=${K8S_CLUSTER} 构建，就能动态注入。这其实只是编译时快照，不是运行时真实值。
问题根源：
- 构建产出的 JS bundle 是静态文件，无法感知 Pod 重启、跨集群迁移、蓝绿发布等运行时变化
- 同一个镜像部署到 dev/staging/prod 三个集群，必须打三个不同 tag，失去镜像一致性
- 无法支持同一 Pod 内多个前端子应用共享同一套 Metadata 注入逻辑
真正需要运行时注入的场景（比如监控上报、AB 实验分流、日志打标），必须绕过构建阶段，走响应层或容器初始化层。
Downward API 能暴露的字段有限，status.podIP 和 status.hostIP 在某些 CNI 插件下可能为空；若需更丰富的上下文（如集群地域、AZ、BCS 导航页域名），建议用 ConfigMap 预置，并通过 volume 挂载 + initContainer 合并写入 HTML —— 这一步最容易被跳过，但恰恰是跨环境可维护性的分水岭。
