externalname service 实现容器集群访问外部中间件的轻量解耦，不改中间件、不暴露ip、不写死域名，通过 dns 层将集群内服务解析至外部 fqdn，适用于 redis/mysql/elasticsearch 等老旧中间件。
用 ExternalName Service 拉通容器集群访问外部老旧中间件，核心是“不改中间件、不暴露IP、不写死域名”，靠 DNS 层做轻量级解耦。它不是代理流量，而是让集群内服务像调用本地 Service 一样解析到外部地址，适合 Redis、MySQL、Elasticsearch 等部署在物理机、VM 或老 IDC 的中间件。
为什么选 ExternalName 而不是 ClusterIP + Endpoints
ExternalName 更轻、更安全、更易维护：
- 无需手动维护 endpoints 列表，避免因外部中间件 IP 变更（如 LB 切换、VIP 迁移）导致集群内解析失败
- 不经过 kube-proxy 流量转发，无额外延迟和连接池干扰，对 TCP 长连接中间件（如 Redis、Kafka）更友好
- 不占用 ClusterIP 地址段，不创建 iptables/ipvs 规则，降低节点网络组件负载
- 天然支持 DNS CNAME 语义，可对接已有域名体系（如 internal-redis.prod.company.com）
配置要点：三步到位
关键不在写 YAML，而在理解 DNS 解析路径和命名规范：
-
Service 名称需与目标中间件语义一致：比如外部 MySQL 实例域名为
mysql-prod-vip.internal，Service 名就设为mysql-external，便于开发者识别用途 -
externalName 字段必须填完整 FQDN：不能写
mysql-prod-vip，必须写mysql-prod-vip.internal.（结尾点号表示绝对域名，防止 DNS 搜索域追加造成误解析） -
跨 namespace 访问要带全限定域名：Pod 中访问需用
mysql-external.default.svc.cluster.local；若 Service 在infra命名空间，则用mysql-external.infra.svc.cluster.local
验证与排障关键动作
不要只看 kubectl get svc，要进 Pod 实际测 DNS 解析链路：
- 进任意测试 Pod（如
utils镜像），执行nslookup mysql-external.default.svc.cluster.local，确认返回 CNAME → 外部域名 → A 记录三级解析 - 用
dig +short查看是否被 CoreDNS 缓存或重写：CoreDNS 默认会缓存 CNAME，但不会缓存最终 A 记录（除非显式配置），确保外部域名 TTL 合理（建议 60–300 秒） - 若解析卡住或超时，检查 CoreDNS 日志中是否有
refused或servfail，常见原因是 externalName 域名无法被集群 DNS 上游服务器解析（比如内部 DNS 未配置 forwarding 到企业内网 DNS）
生产环境增强建议
ExternalName 本身简单，但要“完美拉通”，得补上可观测性和容错：
- 在 Service 注解里加
prometheus.io/scrape: "true"，配合 CoreDNS metrics，监控该域名解析成功率与延迟 - 为关键中间件准备 fallback 域名：比如
externalName: mysql-prod-vip-bak.internal.，通过 CI/CD 切换 YAML 即可快速切换后端 - 搭配 NetworkPolicy 限制只有指定命名空间的 Pod 能解析该 Service，防止误用或越权访问
