在Kubernetes中通过ConfigMap实现前端访问后端服务的问题

核心问题分析 #

你当前的配置硬编码了后端Ingress域名，尝试用Service IP做环境变量失败的原因有两点：

1. Service ClusterIP是动态分配的，重启或重建服务会变更，无法稳定依赖；
2. 前端运行在浏览器中，无法直接读取容器的环境变量，必须通过可访问的静态文件（如env.js）传递配置。

要避免暴露后端到集群外，应该使用Kubernetes内部Service DNS实现前端与后端的集群内通信，无需依赖外部Ingress。

步骤1：创建后端Service（缺失的关键配置） #

Deployment本身没有网络访问入口，必须创建Service来暴露后端服务给集群内其他Pod：

apiVersion: v1
kind: Service
metadata:
  name: backend-service
  labels:
    app: backend
spec:
  selector:
    app: backend # 匹配后端Deployment的Pod标签
  ports:
    - protocol: TCP
      port: 80 # Service对外暴露的端口
      targetPort: http # 对应后端容器的containerPort名称

步骤2：修改ConfigMap使用Service内部DNS #

将ConfigMap中的后端地址替换为Service的内部DNS名称，同Namespace下可直接使用Service名称，跨Namespace需使用完整域名：

apiVersion: v1
kind: ConfigMap
metadata:
  name: frontend-config
data:
  env.js: |
    window.env = {
      # 同Namespace下直接用Service名称
      host: "http://backend-service"
      # 跨Namespace时使用完整域名：http://backend-service.your-namespace.svc.cluster.local
    }

步骤3：验证前端代码逻辑 #

确保前端代码是运行时读取env.js中的配置，而非构建时硬编码后端地址。例如在前端请求中使用：

// 示例：发起后端请求
fetch(`${window.env.host}/api/endpoint`)
  .then(response => response.json())
  .then(data => console.log(data));

方案优势 #

• 集群内通信安全：后端仅通过Service暴露给集群内部Pod，不会对外暴露IP或域名；
• 配置稳定可靠：Service的DNS名称固定，即使ClusterIP变更，Kubernetes DNS会自动解析到新的IP；
• 动态更新方便：后续如需修改后端地址，只需更新ConfigMap，前端Pod会自动加载新配置（无需重启Pod，ConfigMap挂载默认会自动同步）。

内容的提问来源于stack exchange，提问作者Fatemeh Izadi