支持服务网格的Dockerfile核心是构建可注入、可管理的基础环境：应用须监听0.0.0.0而非127.0.0.1，EXPOSE业务端口（如8080 8081），提供/health等健康端点，避免硬编码IP和服务地址，改用Kubernetes Service名进行服务发现。
编写支持服务网格的 Dockerfile，核心不是在 Dockerfile 里写路由规则，而是为服务网格（如 Istio、Linkerd）提供可识别、可注入、可管理的基础环境。关键在于容器镜像要满足服务网格的运行前提：监听正确端口、暴露健康检查接口、兼容 sidecar 注入、避免绑定特定 IP 或端口冲突。
确保应用监听 localhost 或 0.0.0.0
服务网格依赖 sidecar 代理（如 Envoy）拦截进出流量。如果应用只监听 127.0.0.1，sidecar 就无法代理请求。
- Node.js 示例中，不要写
server.listen(3000, '127.0.0.1')，应改为server.listen(3000, '0.0.0.0') - Python Flask 应用避免
app.run(host='127.0.0.1')，改用app.run(host='0.0.0.0') - Java Spring Boot 默认已监听 0.0.0.0，但需确认
server.address未被设为 127.0.0.1
显式声明 EXPOSE 并匹配服务端口
虽然 EXPOSE 不直接打开端口，但它是服务网格自动发现服务端口的重要依据（尤其 Istio 的自动端口检测）。
- 若服务监听 8080，Dockerfile 中必须有
EXPOSE 8080 - 若同时提供 HTTP（8080）和健康检查（8081），建议都声明：
EXPOSE 8080 8081 - 避免声明非业务端口（如 15090、15021），这些是 Istio sidecar 自用端口，不应由应用暴露
添加健康检查端点（/health 或 /readyz）
服务网格依赖 readiness/liveness 探针做流量调度与故障剔除。Dockerfile 本身不定义探针，但需确保应用提供对应 HTTP 路径。
- 在应用代码中实现简单 GET
/health返回 200（如 Express 中app.get('/health', (req, res) => res.send('OK'))） - Kubernetes 部署时通过
readinessProbe指向该路径，Istio 会据此控制流量是否转发到该实例 - 不提供健康端点会导致 sidecar 认为服务未就绪，流量被跳过
避免硬编码服务发现地址
服务网格接管 DNS 和服务发现，应用应使用 Kubernetes Service 名（如 product-composite.default.svc.cluster.local）而非 IP 或宿主机名。
- Dockerfile 中不要写
ENV API_URL=http://10.244.1.5:8080这类固定地址 - 改用环境变量传入 Service 名：
ENV API_HOST=product-composite，应用内拼接为http://${API_HOST}:8080 - 这样在 Istio 的 VirtualService 路由生效时，DNS 解析仍能命中目标子集（如
subset: new）
